Respect for CPC game programmers

[djaybee]

While I had done some BASIC programming on the CPC, my next machine (Atari ST) is the one where I sank my teeth into assembly programming, which I started when I was 16.

On the ST, a lot of things are reasonably easy when it comes to graphics: there's a lot of RAM so that double or even triple buffering is affordable, the framebuffer layout is friendly to quite a few operations, the CPU is fast enough to copy the whole size of the screen 50 times a second. Of course, there isn't enough margin to be sloppy, especially on baseline machines without a blitter. With a little bit of teenage hubris, though, it did feel like many programmers of commercial games were leaving quite some capabilities on the table, making me feel that I could often have done better.

As emulation now allows me to go back to the CPC, my first love, and as I'm writing assembly for it, I'm gaining a lot of respect for the game programmers of the time. There isn't enough RAM to use a double buffer without sacrificing a lot of features, let alone a triple buffer, especially for games that have to be loaded from tape. The framebuffer layout isn't that fun (I'm finding mode 1 especially painful). Copying large amounts of data is so slow that any naive implementation is just about guaranteed to have slow frame rates. Any half-decent game must have needed some optimizations, and the top games seem to have been written by wizards.

I am not getting discouraged, but I've got to reset my expectations about what it takes to get something that looks good on the CPC, and I tip my hat to those who put themselves through that exercise, either back then or more recently. Well done, folks!

[McArti0]

Have you played Pinball Dream on CPC? See how it works inside. It's best not to copy anything. 

What should people programming for the Atari 2600 say? 128+256 bytes RAM 

[djaybee]

Pinball dreams looks very nice on the CPC, I don't think I had seen it yet. It smells of some fun CRTC trickery. I seem to remember playing it years ago, but I can't remember on which hardware that was (Amiga, maybe?)

The 2600 is a very different kind of beast. Since it doesn't store the whole frame, it's hard to compare it to other machines (in that way, it's similar to the 7800 and the Neo Geo, which expand on the same principles). It's fun to code for it, actually, it doesn't need the same coding skills as most other machines.

[McArti0]

(Amiga, maybe?)

most probably.

[McArti0]

It smells of some fun CRTC trickery

some have sprites, others have crtc 

[djaybee]

(Amiga, maybe?)

most probably.

Actually, I'm guessing Atari Falcon. I had a Falcon, but no Amiga, and I remember playing it on my own hardware.

[andycadley]

People who can produce anything at all from the 2600 are absolute legends, it's an insane system to even consider.

[djaybee]

People who can produce anything at all from the 2600 are absolute legends, it's an insane system to even consider.

My experience coding for the 2600 is mostly that the 4kB size limit for cartridges is annoyingly small. The 2600 is bit daunting at first because it's not capable of a stable display without constant CPU intervention, but, once that's in place, it's not as hard as it seems, especially because there are a few details that really help.

What I like about the 2600 is that it's reasonably easy to predict whether an idea will work or not, and the answer is very sharp (there's enough time, or there isn't, but there's nothing in between). For many other machines, that prediction takes more work. The ease with which you can have many colors on screen and the natural smoothness of the display compensate for a lot of its weaknesses.

I'm hoping to release something for the 2600 later this year, though CPC is my current target.