/BERGASMS/GBA/09

Well, I finished up a week or so ago, fair to say i'm feeling more 'unfocussed by unmet needs' than I am 'satisfied at producing a masterwork'. I completed my game, gnoq, which is a variation of pong in which the traditional level is split into three sections that move up and down independently, so the walls that bounce the ball move. The ball also teleports between bottom and top if it moves behind a section.

I managed to get the gameplay working fine, the physics works by running the simulation at a 4x higher resolution than the pixes are displayed and then dividing the final positions by 4 to get the screen positions. This is done because there is no real floating point on the gameboy, so if you want integer stepping to look like a real ball bouncing you need to work at bigger than pixel values. This is a thing that has been done since the NES and probably before (look up sub pixel positioning). Fun fact, the GBA also has a very special function call you have to make to divide which costs a lot of function calls, but luckily we are using a power of two, so you can just bitshift (number >> 2) to simulate division by 4 in one instruction.

I dove into the sound architecture, which was wild, and managed to get some fairly simple beep/bloop noises playing. However at this point I started to run into a problem which stifled all further progress. When setting up the GBA rom you need to set a stack pointer (\\ldr sp, =__sp_irq), which is all fine unless your games code (the stuff that executes) gets too big, in which case __sp_irq becomes too large to fit the program counter value into. I was initially bemused to run into this because my game is super simple, and i solved it the first time by asking Zig to compile in ReleaseSmall instead of ReleaseFast. It turns out ReleaseFast was unrolling a lot of loops when i was copying across massive blobs of data into VRAM, which was not good. Making this change bought me time but eventually i ran into the problem again. It basically boils down to a few things, firstly, the version of the Zig compiler i was using was not a stable release, it was one of the nightly builds, which was a bit silly as it's not optimised. Secondly, Zig is focussing on just completing the self hosted compiler and flattening bugs, so optimisiation of the GBA code is not on their list. Thirdly, I don't know enough about the GBA architecture to actually know the best way to structure and tweak my code to make it optimal. I am learning and I don't know what I don't know.

So this is my final comment on this game jam. I really enjoyed it and glad i challenged myself. I wrote a bunch of fun code, it was a blast to see my game running on real hardware. I learned some Zig and got better at using Vim. I'm going to upgrade my Zig level from (Dabbling) to (Novice). It's annoying that I couldn't technically realise what I wanted to do. If i wrote it in C i am sure I could have but that is part of learning a new language and platform. I am going to enter into game jams again for sure, but I have some other things to finish first. Anyway, the whole process was very satisfying.