Beginners question on character/color RAM

[stufm]

Hello - newcomer here but had a 464 a long time ago. I've got a little knowledge on how to do chars & sprites on the C64 and I'm trying to learn the same for the 464, but really struggling so far.


My question at the minute is regarding user defined gfx, coming from the 64 world I know to poke an 8x8 bitmap into the character ra, poke it to screen ram and poke the colour values into the colour ram, then my char appears in the desired colour. Does the 464 work in the same way? What's making me question this is when I see screenshots like the one below for North and South. I know 464 doesn't have HW sprites like the 64, so I assume these little men are all user defined chars(?), but they have lots of colour so I'm not sure how that's done? At that resolution I'd expect each char to be made up of 2-bit pixels so a max of 4 colours per char, but there appears to be more colours here in each of these chars?


Any help much appreciated.


https://www.retrogamer.net/wp-content/uploads/2013/12/north-and-south-616x462.png

[arnoldemu]

All the sprites are drawn 1 byte at a time from left to right, top to bottom.

All cpc modes are bitmapped. Mode 0 which is 16 colour has 2 pixels per byte.
Mode 1 has 4 colours which is 4 pixels per byte.
Mode 2 has 2 colours which is 8 pixels per byte.

You can try this out in basic.

MODE 0
poke &c000,&34

Try all numbers 0 to 255 and you will see pixels changing and the colours changing.

So to draw a small sprite it would be like this in basic:

10 poke &c000,&aa:poke &c001,&55
20 poke &c800,&aa:poke &c801,&aa

CPC's screen is a bit unusual in it's form.

What a lot of games do, like north and south is to draw the background, then draw the sprite on the screen over the top. This done using AND to remove the pixels you are going to replace and then OR to add your pixels to the screen.

The pseudo code is:

read byte from screen
AND with byte to remove pixels you will cahnge
OR with sprite pixels
write back to screen

this repeats for all bytes in the sprite.

The same is true for text and drawing tiles etc. All is done in a similar way. With tiles you can just write to the screen without masking.

The CPC doesn't have colour ram. The 16 colours (in mode 0) can be freely placed anywhere. If you want to change any of the colours in basic you can use the "INK" command. e.g. ink 1,24 or ink 1,6 and the colours change where used.

In BASIC you can draw characters by defining characters using SYMBOL and using PRINT etc to show them.

I hope that helps. Feel free to ask more

[arnoldemu]

a fun thing to try in basic to appreciate the pixels and screen layout is this:

for i=&c000 to &ffff:poke i,rand()*255:next

From this you can see the bytes as they are drawn, random bytes giving random pixels and colours from the current palette.

[keith56]

I find playing with the scren from basic a lot of fun, and helps you learn how the pixels are stored
Trying something like this:

10 FOR i=0 TO 255:FOR x=0 TO 39 STEP 2:POKE &C000+X,i:NEXT:NEXT   

in various screen modes may help you see how diffrerent byte values affect the shown color

[stufm]

Thanks for the replies, arnold thanks for all that info.

Can I just ask 2 more questions to help my understanding.

1. On the C64 the screen is divided up into 40x25 chars of 8x8 pixels. Is it the same on the CPC? Are the 'sprites' then just one or more bitmapped chars that you copy and paste across the screen ram?

2. Regarding the image below from N&S, my understanding so far is if we're in Mode 0 all the 'pixels' should be 4-bits wide, to allow you to pick from 16 colours in the bitmap. In this little sprite though this isn't the case, the pixels are various widths, yet there are >4 colours being used? I think that's the root of my confusion, once I get my head round this I can stop asking questions!

[robcfg]

In that image, pixels are all of the same width.


Here, I added a grid so you can see the pixels:
[attachimg=1]


Don't hesitate to ask any questions!

[arnoldemu]

1. On the C64 the screen is divided up into 40x25 chars of 8x8 pixels. Is it the same on the CPC? Are the 'sprites' then just one or more bitmapped chars that you copy and paste across the screen ram?

The implementation of the CPC hardware complicates things, but you can think of it as a rectangle of pixels and that is how I and most games treat it.

In cells terms a byte could be considered a cell.

In mode 0, it's 2x1, in mode 1 it's 4x1, in mode 8 it's 8x1. POKE to write 1 byte and update 1 cell, but it's no different for text or sprites or background or tiles.

So for 160x200 there are 80 bytes in width and 200 lines tall.

Think more of graph paper from school where you have 16 pens (with any of the 27 inks). Make your choice of inks for the pens and then colour the graph cells in as you wish.

Sprites/tiles/text it's all the same you poke the bytes to the screen. You calculate where to start poking and then poke bytes into the screen. The only difference between sprites and other graphics is how you poke to the screen so that parts that are transparent don't overwrite the background here is where you do those AND/OR operations on each byte to decide what to keep and what to replace.
If you want to draw 2 sprites over the top of each other you must draw them in the correct order.

So working in mode 0, make everything a multiple of 2 in width, the horse sprite in this thread is 9 pixels, either loose the first column to make it 8 pixels wide (4 bytes), or add a column to make it 10 pixels wide (5 bytes).

The height can be anything. 10 bytes wide, 17 lines tall, that is 170 bytes to poke for that sprite. It's data takes 170 bytes in memory too if you keep it uncompressed.

To save memory, games often re-use tiles (rectangular bits of background). On CPC these can be any size you want.

Drawing the screen: Draw the tiles and then draw the sprites over the top.

160x200 is 80*200, = 16,000 bytes just for background + more bytes for sprites.

On CPC you have to do everything: If a sprite goes partially off screen you need to handle that yourself too and cut the sprite into smaller bits to draw or design the game so the sprite doesn't go off the screen.

In addition on the cpc, because you poked the sprites into screen memory and that changed the bytes, you have to *erase* the sprites by yourself too to restore the background before drawing the sprites in their new location and that is almost like drawing twice as many sprites.

Summary: So think on the cpc it's like drawing a load of rectangles in the order you want to get the picture you want.

Compare this to c64:

If you used char map mode on the c64 and it's hardware sprites. Drawing the tiles to the screen is 960 bytes. Drawing the sprites is like 16 bytes(?) x coord, y coord, colour, stretch.
The C64 hardware sees the char number and automatically fetches the graphics to display the tiles to display. Same is true of the sprites, you tell it the x,y,colour and stretch and it automatically fetches the sprite pixels and puts them on the display, cuts them to the border, and it doesn't need to erase them after.

[||C|-|E||]

Aaah... Mode 0. Dani loved to create the graphics for our little adventure in Mode 1 but it took some time for him to get used to Mode 0 and I still think that he does not like it much. On the bright side, there is no attribute clash here, yay! 

[stufm]

Thanks all for the replies, much appreciated. I've got it now, it's making sense. Just a bit of shift in approach from what I was used to on the 64. It feels like the 464 is more akin to the bitmap mode on the 64 but with lots more colour.


One thing I have realised which was the cause of my confusion is the resolution on the 464. For some reason I was assuming it was 320x200 max, that's why I couldn't get my head round having 4-bit pixels but still having a 160 resolution. It makes perfect sense if you consider the max res is actually 640.


Have to say the 464 sounds much more flexible then in terms of graphics compared to the 64. Granted HW sprites are a big thing but in 160 res on the 464 you could have a 16-colour 8x8 tile, unheard of on the 64! In 320 mode you have lots more flexibility too, the 64 does have a mode for multicolours in 320 mode but I think your colour choices are restricted by whatever you set in color ram for the whole 8x8 tile, and you don't have that problem on the 464.


If you could combine the gfx capabilities of the 464 with the SID chip from the 64 you'd have a killer system!


Question, were there many games made in the 640 resolution? Granted they'd be monochrome but even so an 8-bit era game at that resolution would be something to play. I imagine the text adventures did a lot in this mode? Even something like Ultima where there's little action going on would look great IMO.

[keith56]

It's worth bearing in mind with clever tricks you can switch screen mode midway on the screen - so part is in mode 1 and part is in mode 0 (or any mode you want)

I don't know of any mode 2 games, but quite a lot used Mode 1 for part (like the score) and mode 0 for the game area... worth bearing in mind before you see a screenshot you don't understand

If memory serves me correct Gremilns 2 used it for the 'gremlins' logo at the top, and renegade used it for the score, oh and Sorcery plus did it too - but there were many many other examples!

Also as a shameless plug for my own game, Chibi akumas switches palette midscreen, so even though it's in '4 color' mode, there appear a lot more colors on screen
eg: http://www.chibiakumas.com/TitleScreenRaster.png

I think the C64 could do similar raster tricks - so please excuse me if I'm telling you things you already know.

also the CPC PLUS did have hardware sprites, and they didn't follow the normal CPC rules at all - I was very confused when I saw Robocop 2 which has a 'mode 1' resolution sprite with 16 colors on a 'mode 0' resolution screen

[||C|-|E||]

The very good Guild of Thieves uses a clever split screen mode to display high resolution text and colorful graphics

[andycadley]

Yes, it's more flexible than the C64 bitmap mode in many ways but does come with the penalty of a whopping 16K of screen memory that you have to push around in software. Occasionally it would be quite nice to have something more akin to the 64's character mode!

[Sykobee (Briggsy)]

Definitely, or the NES tiled mode with 4 colours per tile.


[But tiled modes need more bandwidth than the equivalent colour-depth bitmap display (as you have to read tile#+attributes, then tiledata), so you'd likely end up with 4 colours at mode 0 resolution, but with attributes allowing the 4 colours to be set on a per-tile basis.]

[Morri]

Question, were there many games made in the 640 resolution? Granted they'd be monochrome but even so an 8-bit era game at that resolution would be something to play. I imagine the text adventures did a lot in this mode? Even something like Ultima where there's little action going on would look great IMO.

I know of Fres Attack by Bollaware which was in "MODE 2" or 640 res. It is a good example of fast sprites.

[AMSDOS]

I know of Fres Attack by Bollaware which was in "MODE 2" or 640 res. It is a good example of fast sprites.

Thanks, I was able to picture this game but forgot the name of it.


Not in the same league as Fres Attack because they don't use Sprites are 2 games I remember from AA Type-ins are NIM II and Warzone. Ironically the Menu in Warzone is in MODE 1, but the game itself is MODE 2 and it's also a BASIC 1.1 game, but should be easy enough to convert for BASIC 1.0 










NIM II is the followup to NIM, which is also in Mode 2 that was published in Computing With The Amstrad, though doesn't seem to have any Graphics.


I remember AA reviewing some Text games that were released by Cult, I don't remember the name of the games and I think they were in MODE 1, despite being Text Only I remember AA giving one of those games a score for Graphics saying something along the lines of the Text was in Different Colours. 


EDIT: The other game AA had which is also MODE 2 is the Life Game from AA44





This game always throws me because of the chunky nature of the Graphics, though the Demo Text at the top confirms it as MODE 2.

[arnoldemu]

Thanks all for the replies, much appreciated. I've got it now, it's making sense. Just a bit of shift in approach from what I was used to on the 64. It feels like the 464 is more akin to the bitmap mode on the 64 but with lots more colour.

Yes. There are no restrictions compared to the c64 but it does take more ram than the c64.

Also the colour palette of the cpc has more contrast compared to the c64 so you may need to think differently about how you mix and use the colours on the cpc.

One thing I have realised which was the cause of my confusion is the resolution on the 464. For some reason I was assuming it was 320x200 max, that's why I couldn't get my head round having 4-bit pixels but still having a 160 resolution. It makes perfect sense if you consider the max res is actually 640.

Yes 640 is the higher mode, think of everything being some multiple of that.

Mode 2 pixels are like tall rectangles, mode 1 pixels are nearly square but not exactly, mode 0 pixels are wide.
mode 0 is close to c64's lower graphics, mode 1 is closer to c64's hi-res graphics, mode 2 is closer to c128's vdc modes.

The Amstrad screen can be resized to be smaller or larger. Some games made it smaller because they were working within 64KB and the memory was tight. 160x200,320x200 and 640x200 are the default sizes as set by the CPC OS.

This page may be useful:
http://www.cpcwiki.eu/index.php/Comparing_C64_to_CPC

If you could combine the gfx capabilities of the 464 with the SID chip from the 64 you'd have a killer system!

True, but if it was c64 based you'd need a supercpu or similar to push the graphics fast enough.
I believe there has been a project somewhere to connect a sid to the cpc.

Our closest equivalent which is close to the spirit of the cpc is the playcity with dual AY, so 6 channels of sound.

Question, were there many games made in the 640 resolution? Granted they'd be monochrome but even so an 8-bit era game at that resolution would be something to play. I imagine the text adventures did a lot in this mode? Even something like Ultima where there's little action going on would look great IMO.

One thing we don't have on the CPC, is the c64 mode where you can mix lo-res graphics with hi-res text. (Multi-colour character mode??), so the text would need to be in the same mode as the graphics.

The mode can be changed at any scan-line, although the cpc doesn't have line based raster interrupts like the c64, so games generally restrict changes to one of the 6 interrupt regions. So that is why the screenshot from the adventure game in this thread has lo-res graphics at the top, and hi-res at the bottom.

In terms of games that used mode 2, it was mostly adventure games and  utilities. I think it was underused and could get more love.

Feel free to ask more questions