Update: Pigeons Ported to Windows

Andy Craft

August 27, 2016

So as some of you might know, I’ve been developing this game in Linux from the start. Recently I bought a new Windows laptop, with the plan to develop on it as well. First step, however, is to port the game.

Step 1: Choose a compiler

Of course, while porting the game should be pretty easy since I am using SDL and OpenGL, things are never that straightforward. The first thing I need in Windows is a compiler. Most people go to Visual Studio here, and I did check that out myself. But IDEs are never really my cup of tea. Certainly I could use it as a compiler, and I might still, but for now I just want something working so I can actually work on my game. Priority One for me is usually “Get it working”.

Whenever I’m stuck in a Windows environment, one of the first things I do is install Cygwin, which gives me Unix tools, a better command prompt, vim, and more (this is by no means a promotional piece – I personally like these things, you might not). The nice thing is that Cygwin offers a MinGW compiler, with libraries for SDL, GLEW, etc. – stuff that I’m using. After trying several compilers and environments, I ended up using something that was already familiar to me. All I had to do was modify my Makefile (yep, I use make too) to point to the MinGW compiler with the correct library names, and I had a compiled game in minutes.

Step 2: WTF is happening??

Yeah, so I start it up, and my new laptop has really high DPI, so fullscreen is an absolute mess. I have to run in windowed mode for the time being, but I’ll research that later. More concerning is that the pigeons and food appear to just fall right through the floor. Which is a little concerning – why should Windows vs. Linux affect my game’s physics and collision in that way?

Well, it turns out the food and pigeons are fine, just being drawn behind the floor. I know, WAT? Well, apparently I failed to specify the depth function – in Linux, the default must be GL_LEQUAL whereas in Windows it’s GL_LESS I guess? Easy fix then, right – all I have to do is specify the depth function:

Hahaha NOPE! Something else is going on here. I double-checked and the floor was supposed to be drawing at -0.5, with ground-level sprites drawing at 0. At this point, I used my mad tracing skills (not “mad” as in expert – “mad” as in I said a lot of swear words) to dig up the actual Z values from the transforms – yeah, I was kind of losing it. I was able to confirm that the ground was drawing at a higher Z value than the sprites, but somehow was still drawing in front. So basically math hates me now.

After doing some more research though, it turns out that the problem had to do with my near plane. Apparently, with OpenGL (and it seems to me specifically in Windows), the closer the near plane is to zero, the more Z-fighting you get. I didn’t know this – I assumed that the transformation was more linear than that. In any case, I had a near plane of 0.1 – yeah, pretty close to 0. So I moved it back to 10, and the problem is solved!

Step 3: Pigeons really like that one corner

The next thing I have to research is why the pigeons keep doing this:

Not just the pigeons, but most of the food spawns in that bottom corner. So I add in some code to print out where pigeons are spawning, and guess what? All the values are negative. I should point out that the center of the map is 0, 0. So I did some analysis and I noticed that there was something going on with my random value functions. Apparently the GNU compiler on Linux uses a long int as the return value for rand(), whereas the MinGW compiler uses a short int. The values from rand() were falling way short from what I was expecting, so as I transformed it into a space on the screen, they all became negative. Oops!

Step 4: Anything else?

So there were also some minor timing issues that caused feathers to sometimes fly farther than usual (these were easy to fix), some issues with detecting the edge of the screen (the issues being that I wasn’t doing it for food), and there are still some outstanding issues with animation that I need to research. But all-in-all, I think the problems I ran into going straight to Windows were minimal and pretty easy to solve. This makes me hopeful about eventually porting the game to mobile.