Carnivac's CPC pixels

[Sykobee (Briggsy)]

Sure, but this great mock-up don't use that.

To me it looks like it does, with a total of around 40-50 unique tiles on the screen. From top-left, scanning lines for unique tiles:
1. Cracked Window Pane Top Left
2. Smooth Window Pane Top Right
3. Brick
4. Broken Top Left Window Pane
5. Broken Top Right Window Pane
6. Brick Shadow
7. Sky Top (Black with blue at bottom) (end of row 1)
8. Smooth Window Pane Bottom Left
9. Cracked Window Pane #2
10. Dodgy Brick
11. Broken Bottom Left Window Pane
12. Broken Bottom Right Window Pane
13. Angled Skyscraper Top
14. Plain Blue Sky
15. Small Angled Skyscraper Top (end of row 2)
16[size=78%]. Skyscraper Windows[/size]
17. Very small angled skyscraper top
18. Small Skyscraper Windows
19. Small Skyscraper Windows #2 (end of row 3)
20. Sign Left
21. VI
22. DE
23. OS
24. HA
25. CK
26. Sign Right
27. Small Skyscraper Windows With Sunset
28. Skyscraper Windows #2
29. Skyscraper Windows #3 (end of row 4)
30. Broken PC Left
31. Broken PC Right
32. Shop Window Middle
33. Shop Window Blank
34. Unbroken PC
35. Broken Window Top Right #2
36 - 39. Fire Animation (end of row five)
40. Broken Window Bottom Left #2
41. Amstrad CPC 464
42. Broken PC
43. Hydrant Top in front of window
44. Broken Window Bottom Right #2
45. Wall Top (end of row six)
46. Shop Window Sill
47. Hydrant Stem in front of window sill
48. Wall Bottom (end of row seven)
49. Road/Pavement #1
50. Road/Pavement #2
51. Road/Pavement Puddle?
52. Road/Pavement with drain?
53. Crate (although this looks more like a sprite rather than background)
54. Whey Protein Container (again, sprite)


This isn't hundreds of blocks! It's 50 on a single screen of 128 blocks (I see now it's merely 16x8, not 16x10 like I wrote previously). The rest of  the level would be reusing a lot of these blocks (bricks, broken windows, road, wall, etc). I guess there would be some drainpipes, some chainlink fencing, a postbox, phone box, more shop signs, shuttered windows, etc. A total under 256 is easy, and more likely 128 is achievable.


128 64-byte 8x16 tiles. A shocking 8KB of graphics tile memory.

[Sykobee (Briggsy)]

If you use 8x16 tiles then evey tile is soooo big that you need huge-ass RAM for GFX _and_ you will need 1024 tiles ;-)
In my games I use a tile size of 16x16 pixel in MODE 0. One screen has 13(x) * 18(y) tiles. Every tile is represented by a 16 bit variable, which can turn every tile in any kind of special-field.
So one screen has 13 * 18 * bytes, right? That's 468. Now for one level let's say using 20 screens would be 9368 bytes. Now I handle it a bit more tricky and get 3 levels in one 16 KB block (including tables needed for special tiles functions.

Each type of game will have it's own best solution for how the level data is organised. One game needs special bits to denote something at a tile, other games simply have special tiles because you don't need the flexibility of enabling every tile to be flippable, mirrorable, dissolvable, etc.


This RoboCop game has special tiles (in my mind). When a new column of tiles is processed as it is scrolling onto the screen, the game engine checks them. Broken Window = Enemy At The Window. "Brick #8" triggers an enemy running along ground. You can also have a per-level table of "When RoboCop is X tiles into level, do Y" where Y could be something like "Add Enemy 4 at 90,3" or "Drop Ammo Pack at 40".


The animated fire would be a major difficulty to achieve in my opinion, especially when it is layered over the background. Maybe it could be done at 1/4 frame rate, updating two tile rows each frame.


As for 1024 tiles - I think you can design a beautiful game with 1/10 the tiles, and 1/4 would make it luxurious! :-)

[ralferoo]

@Toto: Right. And if you work with 128 tiles (not much!), then you pretty much need 16 bit variables. 7 bits for the tile-number and 9 bit for any kind of special functions (like, moving tile, deadly tile, walkable tile, and and and). Very soon a lot of RAM is used.
Using 8 bit variables for tiles can provide 2 bits for special functions (this way only four!) and 6 bits for tile-number (only 64 here). And that's not much. Like a Speccy port.

Well, that's one way of doing it. Another is to have up-to-256 tiles and use a lookup table to hold information about each tile.
You could also compress the tile data and decompress a screen of tiles at a time. etc...

[TotO]

Well, that's one way of doing it. Another is to have up-to-256 tiles and use a lookup table to hold information about each tile.
You could also compress the tile data and decompress a screen of tiles at a time. etc...

Sure, it's an attribute table. A clever way, but take space too.
And for storing compressed GFx in memory, you need a buffer to uncompress them and display each time that was needed. So forget, it's not possible. It's a game, not a slideshow.

[TotO]

To me it looks like it does, with a total of around 40-50 unique tiles on the screen. [...]
This isn't hundreds of blocks! It's 50 on a single screen of 128 blocks (I see now it's merely 16x8, not 16x10 like I wrote previously). The rest of  the level would be reusing a lot of these blocks (bricks, broken windows, road, wall, etc). I guess there would be some drainpipes, some chainlink fencing, a postbox, phone box, more shop signs, shuttered windows, etc. A total under 256 is easy, and more likely 128 is achievable.

128 64-byte 8x16 tiles. A shocking 8KB of graphics tile memory.

Sure, you can cut the background with 4x4, 4x8 or 8x8 chars patterns, or everything you want to recompose the background picture. But, you have to keep all from the same size for doing a map. Else, you can't manage the scrolling properly. (not like in your list)


Now, better to restore this place for the Carnivac's mockups.
I want to see another stage, or a boss battle now...

Serve the public trust, Protect the innocent, Uphold the law!!! 

[arnoldemu]

@Toto: Right. And if you work with 128 tiles (not much!), then you pretty much need 16 bit variables. 7 bits for the tile-number and 9 bit for any kind of special functions (like, moving tile, deadly tile, walkable tile, and and and). Very soon a lot of RAM is used.

No you don't.

re-organise your tiles. Then use tile id to define it's function.
so all tiles between 0 and 7 are walkable, etc.
This is another way to do it.

I know you will never believe 64k can do a good game.

True, 128k gives more content, larger game and is much easier to use without sweating over each byte.
But 64k is still enough.

true, 64k is not suited to games with overscan, and sure overscan is nice in a game, but it's not a must have.
let's move the talk to be constructive and not 64k vs 128k.

[Gryzor]

I think Carnivac will come back in a week (good luck with the play!!) and be in shock

[TotO]

true, 64k is not suited to games with overscan, and sure overscan is nice in a game, but it's not a must have.
let's move the talk to be constructive and not 64k vs 128k.

The CPC (64K or 128K) is not suitable for overscan arcade games, at all.

A good game is not a game with nice GFx and music. But, a game with a nice gameplay first where you take fun to play.
One of my favotite CPC game is a BASIC Tron clone...  

Both computers are the same, just that with 128K you get 4 pages more to see the game with a more ambitious look.
More GFx, more musics, faster and smooth display, less loadings ... All can be better, but not more easy... It's much work too.

It's not the problem on CPC+, because 64K is enough for all games if you do it on a cartridge.
But on a CPC, with Tape, all need to be stored in memory.
You don't make worst or better games, but different games.

EDIT:
Here a solution to solve the "problem".
This close picture use 48 uniques tiles (2x2 chars*) and some ompimized things for fonts.
With that, you can manage a full level with a 128 tiles map and mirror flip on a 64K CPC.


* fix: I wrote 16x16, like for MODE1. Stupid me.

[TFM]

Well, that's one way of doing it. Another is to have up-to-256 tiles and use a lookup table to hold information about each tile.
You could also compress the tile data and decompress a screen of tiles at a time. etc...

Well in my engine I use 16 bit variables, and in addition a couple (!) of look up tables. Tables f.e. for doors, field where a person interacts, field where something is located, and and and....
Also moving tiles (flames f.e.) are not so easy. A flame .. let's say is has 5 phases. You can show it 1-2-3-4-5, 1-2-3-4-5, 1-2-3-4-5,  or you can show it like 1-2-3-4-5, 5-4-3-2-1, 1-2-3-4-5, 5-4-3-2-1, 1-2-3-4-5, 5-4-3-2-1, .
There is so much that can be considered, well you won't need that for Robocop. But if I write an engine, then not only for one game ;-) Sure, the disadvantage may be RAM usage, but there is a speed gain too.

@Arnoldemu: Reorganize tiles??? My tile-sets do usually have 128 different tiles (and 64 is for the CPCs sake not enough, else it looks boring!). So I will not get everything else in one bit. However I like to do games as good as possible. That excludes thereby the dogma of memory saving just for 464 compatibility and the price of sacrificing well GFX, samples, bigger sprites and andvanced gameplay. However TotO is right here, the gameplay can be the same and does less depend on RAM usage.

[Sykobee (Briggsy)]

Here a solution to solve the "problem". This close picture use 48 uniques tiles (16x16) and some ompimized things for fonts.With that, you can manage a full level with a 128 tiles map and mirror flip on a 64K CPC.

16x16 - why? 8x16 is far more flexible, and in MODE 0 the resulting tile is square.
Otherwise this is exactly what I've been writing, even going as far as to enumerate every unique tile on Carnivac's mockup when people were saying that there weren't many duplicate tiles, needing 1024 tiles, etc.

[fano]

16x16 - why? 8x16 is far more flexible, and in MODE 0 the resulting tile is square.

When he wrote 16*16 he means same thing like you , a 4*16 bytes tile.Using 2*8 bytes tiles is a good deal too if you uses bigger patterns than 2*2 chars (like 4*2 or 4*4 for example).There are 2 advantages of using patterns, first you reduce dramaticaly map size (/16 for a 4*4 pattern) and this allow you increase variety.Its counterpart is you need to store patterns but if your pattern size is adapted to map style, you still save memory.
Another advantage of using pattern is you can store tiles behavior (solid,instantkill,water,ladder and so on) in the pattern instead of attaching it to a particular tile.That make player interaction with map more flexible.

[TotO]

16x16 - why? 8x16 is far more flexible, and in MODE 0 the resulting tile is square.
Otherwise this is exactly what I've been writing, even going as far as to enumerate every unique tile on Carnivac's mockup when people were saying that there weren't many duplicate tiles, needing 1024 tiles, etc.

Sorry, I would like to said 2x2 chars, so 8x16 pixels in mode 0.
The Carnivac's mockup need more tiles, because too much chars change for few pixels (like walls).

EDIT:
Thank you fano. :p

[Sykobee (Briggsy)]

When he wrote 16*16 he means same thing like you , a 4*16 bytes tile.Using 2*8 bytes tiles is a good deal too if you uses bigger patterns than 2*2 chars (like 4*2 or 4*4 for example).There are 2 advantages of using patterns, first you reduce dramaticaly map size (/16 for a 4*4 pattern) and this allow you increase variety.Its counterpart is you need to store patterns but if your pattern size is adapted to map style, you still save memory.
Another advantage of using pattern is you can store tiles behavior (solid,instantkill,water,ladder and so on) in the pattern instead of attaching it to a particular tile.That make player interaction with map more flexible.

Ah thanks, I thought so but just needed to clarify.


I've been working on some graphics that use 4x8 pixel tiles composed 4x4 into larger tiles as you write, the 4x8 tileset is in the top right, and tiles in two sizes elsewhere.

[TFM]

Ok, IMHO smaller tiles lead ultimately to ugly GFX. Having said this, that's not true for all GFX creators, but for a lot of them. Furthermore smaller tiles need more RAM in the map again. For a cannon fodder like game smaller tiles will be fine, but for GFX-ORGY games it's IMHO better to use bigger tiles. Reason? Compare commercial games... Ok, for GFX experts like Tolkin, MacDeath or Carnivac (just to mention three) this is all not a problem. For the average creator it is though.

[fano]

Ok, IMHO smaller tiles lead ultimately to ugly GFX. Having said this, that's not true for all GFX creators, but for a lot of them. Furthermore smaller tiles need more RAM in the map again.

Smaller tiles is the final result, the gfx creator work on 4*4 char tiles (sized enough to make good graphics) , the tool build patterns from theses and cut down them to 1 char tiles, removing redundancy.The final result is often smaller.If you take a look, major part of the commercial games (whatever the machine) use patterns.

[TFM]

Hi fano, you brought me straight into the 20 century, even a bit into the 21 century. Well, I've been talking more about the old days of the CPC. But yes, you can break down tiles after creating them. However, I think one single character may be already too small, because you need will have a huge number of them.
We probably all agree, that it always depends on the single game to find an optimum. (I found that for me in 16x16 pixel tiles).

[fano]

We probably all agree, that it always depends on the single game to find an optimum. (I found that for me in 16x16 pixel tiles).

That's right , i don't think this method would save memory on a game like Cybernoid/II that uses 4*16 bytes tiles 
Btw , that's not i am doing a fixation on char but simply it is the most close to hardware unit at the end (CRTC like a lot of graphics chip is character based)

[TFM]

Well, I don't see a need to connect the hardware features to tile size. For example my 16x16 tiles get moved into the visible screen (right or left) in four steps. So I have four extra routines for that (not that extra though, since using self modifying code). Smaller tiles would only need one such routine, but the gain of memory is probably not that much... However, pleasure to talk about it 

[ivarf]

I like the button that makes it possible to comment "ivarf likes this". But where is the "ivarf doesn't have a clue about this" button?

[fano]

Well, I don't see a need to connect the hardware features to tile size. For example my 16x16 tiles get moved into the visible screen (right or left) in four steps. So I have four extra routines for that (not that extra though, since using self modifying code). Smaller tiles would only need one such routine, but the gain of memory is probably not that much... However, pleasure to talk about it 

Yes , it is pleasure to discuss about technics and programming philosophy  (sorry to pollute a bit the thread).The main point about trying to connect to the hardware is optimisation.Designing program around character as unit allows a lot of optimisation , for drawing , addresses calculation or control for addresses cycling when using hardware scrolling.

[MacDeath]

Ok, IMHO smaller tiles lead ultimately to ugly GFX. Having said this, that's not true for all GFX creators, but for a lot of them.

this is not really how it works, the quality comes from the actual surface of original content...

Furthermore smaller tiles need more RAM in the map again.

but this is true...
while the pure Data is according to the total surface of all tiles/sprites, getting the "tiles" smaller means far more addressing... and we all know address code is often bigger than Data itself.

For a cannon fodder like game smaller tiles will be fine, but for GFX-ORGY games it's IMHO better to use bigger tiles.

Rick dangerous actually used 4x8 tiles in a bigg line of 4x4096 ... ouch, painest pain for my eyes in my life ever.

Reason? Compare commercial games...

well done smaller tiles can be quite interesting for a few specific textures...
but if you want to include a few bigger elements, this can be some waste of address I guess.
the problem with big tiles is that you get a "Nintendo NES effect", with very repetitive textures.

with smaller tiles you can mix it up far more and get some more realistic effects, but at cost off addressing time and the tiles coordinates map (perhaps even collisions) is bigger in RAM I guess, perhaps even longer to put all those tiles in "VRAM" ?
May not be good with scrollings too.

smaller tiles = bigger MAP "resolution".

Ok, for GFX experts like Tolkin, MacDeath or Carnivac (just to mention three) this is all not a problem. For the average creator it is though.

oh please, I am not that much an expert, Carnivac is far better than me...
I just happen to used to be better than average in drawing/art while at school, which still help me a little big nowadays when "trituring" a few pixels.
but thx anyway to compare me with the 2 others.

BTW, getting the 128K as mundane format is always better I guess.

The CPC (64K or 128K) is not suitable for overscan arcade games, at all.

is this true if no scrollings are needed ?
well having "VRAM" into 32K must reduce even more the actual CPU time I guess.

[TotO]

is this true if no scrollings are needed ?

It's why I said, for Arcade games.

[fano]

Rick dangerous actually used 4x8 tiles in a bigg line of 4x4096 ... ouch, painest pain for my eyes in my life ever.

Sorry for you m8 but you still made a nice on work on so small tiles  , that was just because it was a hack and this 4*4096 was the extraction format.RD (and RD2) uses 2*8 bytes tiles but all is arranged in 4*4 chars patterns that i think that was the original format the GFX artists worked on.

[Sykobee (Briggsy)]

Sorry for you m8 but you still made a nice on work on so small tiles  , that was just because it was a hack and this 4*4096 was the extraction format.RD (and RD2) uses 2*8 bytes tiles but all is arranged in 4*4 chars patterns that i think that was the original format the GFX artists worked on.

4096 different 'char-sized' tiles is interesting - surely that used a significant amount of memory, at 16 bytes per tile? 64KB? Maybe each tile was only 4-colours, and the tileset was divided into different paletted regions (0-127=muds,128-255=stones,256-383=backgrounds,etc).
Each 4x4 'supertile' would have therefore used 32 bytes to define it. Assuming 256 supertiles, that's 8KB of supertile definitions. Quite a lot! Each tile in a supertile could have had flags to denote solid/clear, climbable, etc. Maybe there was some additional compression employed, I can think of ways to halve the memory requirement.
But each screen in the game is definable in 48 bytes, and it looked great. Possibly even you have fewer supertiles per level you could compress it even further. I guess each screen also needs some bytes for adjacent screen connections.


RD128+ looks lovely, btw!

[fano]

4096 was the high in pixels in fact.RD uses 512 tiles but for each room is limited to 256 tiles , the high bit acts as a tileset selector and is given in the room definition, that allows to keep 8bits patterns (that you call supertiles).I can not remember how collisions with tiles are managed.
Yes , 32bytes patterns is a bit big but when you paid this "entry ticket", you can make a lot of rooms for a few bytes.
Actually , we choose 4*2 patterns in 16 bits because that fit well with our maps.The main advantage of using 16 bits is you can store directly address in pattern cell and the 4 lower bits are free for flags because tiles are 16 bytes and are 16 bytes aligned.
btw another advantage of using small tiles is for slopes calculation on a non flat landscape, this is a thing difficult to do with bigger tiles.