u/TachyonFireGame

Github: https://github.com/Krobenlakroc/tachyonfire

In about 2020, my *other* C game engine had become too convoluted to be able to finish any projects and I wanted to venture into more modern rendering techniques so I decided to start on a new one.

Now 6 years later, I am done.

Expanding my C skills and learning graphics was challenging, but I found the process of making something that works on a variety of machines to be extremely painful.

In this post I'm going to go over the pitfalls I ran into.

1.) On Linux, newer glibc is backwards compatible with builds of older glibc but not the other way around. This really sucks because that means if you want to make a build that works on machines older than yours, you need an environment with older glibc.

That is a huge problem, because an older linux distro also has and older compiler from the package manager so newer compiler flags like x86_64-v3 don't work. The workaround for this is building in a debian buster container, downloading a builder a newer gcc, and then using that to compile the game.

Also keep in mind that your libraries will need to use the older glibc version as well, but they can be compiled with the older compiler.

2.) I don't use windows much so making a windows build as someone who learned programming in unix land is a challenge, the msvc interface is alien to me. I found MSYS2 to be easy to use for doing the port.

Windows is nicer to work with than linux, because you can compile against UCRT (universal C runtime) and it just works. The bad news is, there are some types that are different sizes on linux and windows.

If you are reading from a binary file that you generated on linux and you didnt use stdint.h types, you are screwed (but only some of the time not always).

3.) More windows stuff. If you include <windows.h> it pollutes the namespace with a lot of differnt macros that might conflict with your macros or types.

"TokenType" was the one i ran into. This is bad.

4.) Mysterious crashes, this is more common knowledge but i'll include it anyway. I found a lot of "silent" bugs using valgrind, asan, ubsan, and tsan (not all at once). In my experience windows is more sensitive to memory errors than linux, so using these tools is a must if you want to avoid headaches later.

5.) Compiler bugs, I ran into one using an older version of gcc. I was so confused, and it really stressed me out. If you run into something baffling when you change compilers, it might be the compiler.

6.) When testing, you need to make sure that what you think you are testing actually runs. I didn't write a single unit test for the entirety of development, I just tried to play the game in the debugger with some printfs to see if edge cases are being hit during testing. I think it worked out ok.

7.) fopen(). fopen accepts UTF-8 on linux, but not on windows unless you change the locale and you are using a new enough version of UCRT. Windows has its own _wfopen() that takes in wchar_t, so you need to convert to wchar_t using windows' api functions in case the file path includes a non ascii-username.

If you remember one thing, remember this: test across a matrix of different machines.

Laptops, Desktops, AMD/NVIDIA/Intel, different compilers, different operating systems.

Its the only way to truly be sure your app has broad compatibility. Don't trust your development machine.

What used to have to be pre-rendered is now realtime.