News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Respect for CPC game programmers

Started by djaybee, 17:37, 19 April 24

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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  :laugh:
CPC 6128, Whole 6128 and Only 6128, with .....
NewPAL v3 for use all 128kB RAM by CRTC as VRAM
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

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

CPC 6128, Whole 6128 and Only 6128, with .....
NewPAL v3 for use all 128kB RAM by CRTC as VRAM
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

McArti0

Quote from: djaybee on 20:08, 19 April 24It smells of some fun CRTC trickery
some have sprites, others have crtc  :D
CPC 6128, Whole 6128 and Only 6128, with .....
NewPAL v3 for use all 128kB RAM by CRTC as VRAM
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

djaybee

Quote from: McArti0 on 20:19, 19 April 24
Quote from: djaybee on 20:08, 19 April 24(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

Quote from: andycadley on 22:20, 19 April 24People 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.

zhulien

I think atari 2700 Solaris is an example of something amazing for an Atari 2600.  In many ways better than most CPC games of that genre

https://en.wikipedia.org/wiki/Solaris_(video_game)

https://youtu.be/ng58csrrLu0?si=xeBJzb6EL64UZ0bZ

djaybee

Quote from: zhulien on 04:54, 20 April 24I think atari 2700 [sic] Solaris is an example of something amazing for an Atari 2600.  In many ways better than most CPC games of that genre
Indeed, Solaris is one of the greatest 2600 examples.

Whether it can be replicated as-is on the CPC is an interesting question. Obviously, the CPC's palette is more limited than the 2600's, but, other than that, it should all be within reach, by using similar techniques, albeit probably harder to write on the CPC than on the 2600.

I'm trying to convince myself not to give it a try, because, well, I don't have that much spare time!

zhulien

Can the cpc draw graphics like an atari 2600 by racing the beam?

andycadley

Quote from: zhulien on 09:57, 20 April 24Can the cpc draw graphics like an atari 2600 by racing the beam?
Well you could turn the display off so that everything is BORDER and then just keep toggling the BORDER colour. I'm not sure that would be especially useful though, having the hardware do the heavy lifting is usually preferable.

BSC

Quote from: zhulien on 09:57, 20 April 24Can the cpc draw graphics like an atari 2600 by racing the beam?
This has already been done long ago, for example here, the whole background is made of so-called split-rasters, changing the background colour while racing the beam: 

GCS - Inventing tricks before the Frenchies get their CPCs :D 

** My website ** Some music

My hardware: ** Schneider CPC 464 with colour screen, 64k extension, 3" and 5,25 drives and more ** Amstrad CPC 6128 with M4 board, GreaseWeazle.

zhulien

#13
Thats impressive, how do they layer text on top of rasters?  Does crtc allow some type of layering? I'm thinking of the space invader in 3d meets the aging bits also...

Prodatron


GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

Deevee

Quote from: zhulien on 12:43, 20 April 24Thats impressive, how do they layer text on top of rasters?  Does crtc allow some type of layering? I'm thinking of the space invader in 3d meets the aging bits also...

Raster just modify 1 ink every HBL, that's 3 inks left in mode 1 to draw whatever you want on top. You can also change the text ink as well, and your raster is on top.
The CRTC is probably not involved in that at all. Just good timings.
ORIGIN 320,200:FOR r=1 TO 360:PLOT 5*(16*(SIN(r))^3),5*(13*COS(r)-5*COS(2*r)-2*COS(3*r)-COS(4*r)):NEXT

andycadley

Yeah, no CRTC tricks there. Just changing one INK at high frequency to update the background colour and letting the normal video hardware handle the text. So not really very Atari 2600ish, unless you got rid of the text.

djaybee

Quote from: zhulien on 09:57, 20 April 24Can the cpc draw graphics like an atari 2600 by racing the beam?
The answer is "it depends".

If we're talking about changing a color (or a few colors) each line, which is something that many 2600 games do, the answer is "yes", though it's less natural on the CPC (because that's not how code is typically written) and more difficult (because that requires to count cycles, while on the 2600 there's some hardware to help with that).

If we're talking about changing a color mid-line, the answer is "somewhat". The 2600 needs at least 9 pixels between color changes, the CPC needs 16 in mode 0. The 2600 can directly change any color you want (the palette is directly mapped), the CPC can change the same color over and over but takes some effort to switch between colors. At the same time, the 2600 can only store 3 colors in registers to change at the highest possible speed, the CPC has 6 registers for that (and easily some more with the alternate registers). And the CPC has plenty of RAM to store generated code or self-modifying code, while on the 2600 there's so little RAM that code is normally all in ROM.

On the other hand, if we're talking about the way the 2600 naturally repeats the same graphics over and over and you've got to change those graphics line-by-line or more often, the CPC doesn't normally do that, it's got a real framebuffer, so you are less constrained by timing, but it's still possible to draw just ahead of the beam and to delete right after it. (CRTC experts would know if it's possible to display a one-line screen 200 times followed by a border-only screen of 112 lines with a VSYNC in the middle, or any other such combination of 312 lines, but I'm not at that level yet).

Finally, on the 2600, nothing is persistent in practice, so there's no need to erase things (like in pure sprite-driven systems), while on the CPC everything that gets drawn must typically be erased at some point.

FWIW, on the Atari ST, that I'm very familiar with, once you synchronize with the beam, it's easy to change colors a lot more often, which opens the door for a lot more effects.

Powered by SMFPacks Menu Editor Mod