Teach Yourself Game Programming in 21 Days - Day 6

This is an important chapter, for sure. It's titled "Real-Time Animation and Effects", which is a little odd considering that's pretty much all we've been doing until this point. However, games are written in a fundamentally different way to that existing code, and that's because of something called a double buffer.

If you've been running the programs up to this point, you'll notice that the display flickers, seemingly at random. This is because we're updating the screen while it's being drawn. Console hardware has a variety of ways around this problem; from my time with the Game Boy, I know it's very common for screen drawing to be done during the Vertical Blank Interrupt. This means you'll never see a half-drawn frame, unless the game lags heavily. André recommends a similar method for the PC, though without the use of a hardware interrupt. It polls the VGA status register to work out what's happening (see vertical), and waits until it's safe to do an update.

Because we have to maintain this separate buffer which represents the frame to-be-drawn, it requires as much memory as the screen does. This isn't too bad; our typical display resolution of 320x200 mandates a buffer of 63KiB. At the time a typical PC might have 2MiB of RAM, so it was a viable technique. Now, PCs have massive stacks of high-performance memory (mine has 8GiB) and buffering is done by specialised graphics hardware, but it's neat to see how these tricks changed development.

Of course, that means all of our functions that write to the screen should now write to the double buffer instead, so this chapter adds a lot of stuff to our quickly-growing game library.

As a child, the most exciting part was when the author started to describe scrolling. This is a fundamental technique to pretty much all 2D games; either by swapping in new rooms when you enter them or smoothly moving with the player character. You probably won't be surprised to learn that early console hardware was specialised for this, but with the PC you have to do it all manually. Reading this, all kinds of ideas for games burst into my head, and they really haven't stopped coming since. Combined with the quickly-following discussion of using cell-based game worlds to reduce memory use, I was hooked to games (and game development) for life.

I recommend you try out robo because it's a decent beginning for a platformer. Again, I had to recreate the graphics, so excuse my terrible pixels.

There was one listing from the book that I didn't type out; it's called paper and it uses colour rotation to achieve animation. Essentially, the same paper aeroplane is drawn at different points on the same image, but in different colours. Then, the code loads that single image and rapidly changes which palette registers are black and non-black. In this way, very little work is being done by the processor. I don't think there are many wide uses for this technique, but it is interesting nonetheless.

As always, the code is available here.