News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Carnivius

Tile limits?

Started by Carnivius, 16:17, 20 July 14

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Carnivius

Not really sure where else to put this but it's game development related to I thought Programming would be best.   While I'm not programming on CPC myself I still have to think about what is possible and what ain't, for when the time comes these projects will become real CPC games.

Anyways during the RoboCop: Prime thread it was mentioned to me (I think by arnoldemu) that it was best to keep to under 256 tiles.   I'd just like some more information about that. 

Does it make any difference how big the tiles are?   Because mine are 4x8 pixels... 256 of which would use up less memory than 256 8x16 pixel tiles surely?

Does that include fonts?  Are fonts done like tiles as they are often on the NES?  I mean cos that would be well over 30 tiles gone already.  Plus I've seen enough games on CPC that use multiple fonts at different sizes too so I can't see how they would use up any tile limits.

Does it include status panels/menu graphics (mine are crafted from tiles at moment)?

How are tiles overlaid and told if they are foreground or background?  SwitchBlade for example uses a lot of foreground tiles some of which are the same as background tiles (such as the 'crates').

Can tiles be easily recoloured? 

How is collision often done?   I mean can a platform be solid in one place and non-solid in another and yet use the same tile graphic? 
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

SyX

If you have 256 different tiles, you only need to use a byte (0-255) for representing a tile in your map (or tilemap). And that is nice because your maps are more compact and easy to handle in 8 bits CPUs.

But you are free of doing what you like, the CPC doesn't force any tile limits; even you don't need to use tiles, you can define screens as a composition of objects, an object can be a tree or a wall or a dinosaur or ..., your screens would be storaged as a list of object types and screen coords where those objects are printed.

As you are free, you can use different tile banks (each of one of 256 tiles... or less or more) for different sections, for example a tile bank for the fonts, other for the background tiles, other for the scoreboard, ...

The only limit is going to be the ram (or rom in a cartridge/rom game) used by your tiles. A 4x8 pixels mode 0 tile takes 16 bytes, 256 tiles takes 4 KBs. In the case of a 8x16 tiles in mode 0, this takes 64 bytes and 256 tiles will take 16 KBs. As you can see bigger tiles, means more ram used by your tiles.

But you have another nice trick in your hat, you can make "metatiles" or "composite tiles", those tiles are made from other tiles. For example, you have your 256 tiles of 4x8 pixels in mode 0 and your metatiles are build with 4 of those tiles.

A metatile of 8x16 pixels will be made by 4 tiles of 4x8, like this:
T1 T2
T3 T4

And each of one of those metatiles uses 4 bytes (the tile number of the 4x8 tiles). Because that, the 256 metatiles will take 1 KB plus the 4 KBs taken for the 256 tiles of 4x8 pixels. 5 KBs instead of 16 KBs is a good saving :)

Of course, you can make bigger metatiles using small metatiles made of tiles, ... but every extra step  in composition will mean that the z80 will work more for printing your graphics. The usual is two (map made of tiles) or three (map made of metatiles and metatiles made of tiles) steps, although i have seen one or two cpc games using 4 steps.

Quote from: Carnivac on 16:17, 20 July 14
How are tiles overlaid and told if they are foreground or background?

How is collision often done?   I mean can a platform be solid in one place and non-solid in another and yet use the same tile graphic? 
Both questions have the same answer, this information is storaged in the map usually.

In a simple game without collisions or priority, a game map is only a list of tile numbers  (or metatiles ;) ). For a more complex game, you need a collision map, where you mark the zones in the map that the sprites can not cross or zones that need to be printed in front of the sprites. In every decent map editor, you simple add a transparent layer and set those attributtes there.

In a more simple game, you could add this information in the tiles, too. Instead of those being only the graphics, you could add attributtes, the tile X is solid or the Tile Y has priority over the player. Even you can reserve range of tiles for certain attributtes, for example, the first 16 tiles are solid, tiles 32-48 has priority over sprites, ...

Quote from: Carnivac on 16:17, 20 July 14
Can tiles be easily recoloured? 
They can, but at least is something so simply like a INK in basic (everything in color X in screen changes to color Y), you should only do this between levels or before to enter in new zones. Because the process is changing pixels from pen X to pen Y.

Of course, if you want to have in te same screen two (or more) tiles that only change in the colours used, then it would be better having two copies of the tiles in your tile bank, one using your first palette and other using your second one.

Carnivius

Thanks for all that.  :)
Hm, ok I think I understood most of it.   I may need to re-read through it some more though.
I wasn't aware of tile banks.   Sounds neat. 

Ok so here's the current tileset for RoboCop: Prime.  (most of the tiles look crappy out of context but most are also very recyclable into other background elements).



In the bottom right hand corner there are 24 tiles of tubes and panels which make up the status bar and menus.  So I could move those to another sheet (maybe the same one that has the fonts?) and have them be seperate tile banks (and then freeing up those 24 tile spaces on that sheet there for other level tiles)?   And three tile banks of 256 4x8 tiles each would be 12k?   Is that an ok amount of tile graphics for a game? 

Starting to think this isn't as limiting as I thought.
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

SyX

Quote from: Carnivac on 17:26, 20 July 14
In the bottom right hand corner there are 24 tiles of tubes and panels which make up the status bar and menus.  So I could move those to another sheet (maybe the same one that has the fonts?) and have them be seperate tile banks (and then freeing up those 24 tile spaces on that sheet there for other level tiles)?
Yes, you can have a few sheets perfectly.

From the programmer side, our print tile routine will have an extra parameter, the tile sheet to use. And when we are going to print letters, then we pass to the routine the font tile sheet; when we want to print the status, we pass the status tile sheet, ...

And yes, you can put the font and the tiles for the status bar and menus in the same sheet of tiles, our only consideration is that the tiles of the font and the status bar/menus must have the same dimensions. But neither that is a limitation, if you font tiles are bigger than other ones, you have a few solutions, since making the font using "metatiles" until put the font in an exclusive tile sheet and using an exclusive routine for drawing this big and pretty font :)

For example, i usually use an special and faster routine for printing the numbers in a font, because those are the most printed characters during the game (scores and lives).

Quote from: Carnivac on 17:26, 20 July 14And three tile banks of 256 4x8 tiles each would be 12k?   Is that an ok amount of tile graphics for a game?
Of course, it's ok for a 464 tape game, even 16 KBs is not a bad thing.

I have seen a lot of games using near of 32 KBs (tiles + sprites + map) perfectly and the typical multiload games as Robocop, Renegade, ... usually a new level load block is around 16 KBs (new tiles + new sprites + new map).

And remember that you don't need to fill fully all the sheets, only put the tiles that you need. For example, 256 tiles for background + 24 scoreboard + 48 for the font ( letters + numbers + heart and other arcade symbols) is around 5 KBs.

Quote from: Carnivac on 17:26, 20 July 14
Starting to think this isn't as limiting as I thought.
We have limitations, a lot, but i always feel that it's better not compromise your vision and let your imagination free, at least at first. Because the only important thing should be "making the game you want to play" :)

Not add extra artificial limitations at the beginning of the project, for example not start for limiting your idea to a 464 + tape. If you can put your dream game in that configuration, FANTASTIC!!! Everybody will love it and i'm sure your coder will fight to make that version possible.

But if you feel that when you reach certain place in the level, it would be good to load extra content for getting more variety, then go on, because our disk drives are fast and the game will be not worst because that and 664,6128 and 464 + DD1 people will love it. In the same way, if you feel that you need bigger maps or more tile sheets or maybe intermissions for telling the story (Robo reaching the zone in the car or getting a briefing of the mission level or TV reports of gang vandalism in Detroit or ...) for making reality your vision, then go on again, there is a lot of people with a 6128 (default configuration in emulators) or a 464/664+Ram Expansion that will enjoy your project.



Carnivius

Ah ok.  Yeah the main font is a 4x8 pixel thing the same as the tiles.  The larger font (which at moment is only numbers 0-9 and % since it's just for the large green score and health percentage) is 8x16 (but counted on my font sheet as each letter being 4 8x16 tiles).   Main thing I'm trying to avoid is it being a multi-load.  That's fine on disk since it can find and access data easier but on tape you have to have things in order and I'd really like to not have to load and rewind too much.

And yeah I was certainly thinking about pixelling some story scenes which are likely to be disc only but should work on 464 with disc drive.   A tape version will simply just have these scenes with text without the picture.

Hm, this all goes for my other project Cosmic Prison Commando too.   Same sorta technical thinking behind them both despite some obvious differences in gameplay (RoboCop Prime has a smaller game screen but scrolls and C.P.C. has larger screens but is flick screen). 
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

SyX

Quote from: Carnivac on 20:37, 20 July 14
Main thing I'm trying to avoid is it being a multi-load.
Yes, i know and the first rule is making the game you want, you can consider the opinions of others, but at the end of the day the person taking decisions is you :)

But those days a lot of the limitations in tape systems are not true anymore. The first is that we have much better compression algorithms and something that in the old days was a boring 16 KBs load, those days can be only between 3-6 KBs, much more tolerable and having extra tiles and maps gives a lot of variety :)

And the second one, Breaking Baud has showed that you can do things while the tape is loading, a variation of it could be used  for showing those scene stories while the next level is loading.

Carnivius

Quote from: SyX on 21:54, 20 July 14
Yes, i know and the first rule is making the game you want, you can consider the opinions of others, but at the end of the day the person taking decisions is you :)

But those days a lot of the limitations in tape systems are not true anymore. The first is that we have much better compression algorithms and something that in the old days was a boring 16 KBs load, those days can be only between 3-6 KBs, much more tolerable and having extra tiles and maps gives a lot of variety :)

And the second one, Breaking Baud has showed that you can do things while the tape is loading, a variation of it could be used  for showing those scene stories while the next level is loading.

Yeah though multi-loading on cassette limits the type of game when it comes to it's structure.   A linear level based game is one thing, but a Metroid style thing where you can return to earlier parts to unlock different routes due to having a new iterm or power isn't quite as simple.   Plus when it comes to just starting a new game it's much quicker if all the game was in memory already rather than having to rewind and load up level 1 again. 

The improved compression techniques give me hope in fitting as much as possible into a single load though.
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

CraigsBar

Disc only multi load is fine surely? I mean that would give 800k without disc swaps, or 4 sides of a cf2.
IRC:  #Retro4All on Freenode

Carnivius

Quote from: CraigsBar on 22:47, 20 July 14
Disc only multi load is fine surely? I mean that would give 800k without disc swaps, or 4 sides of a cf2.

Am not sure what you mean.  For it to be multi-load only on the disc version (then what happens with the tape one) or you mean simply only having a disc version and no tape version?
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

CraigsBar

#9
I was thinking disc or hxc only. Or rather disc, hxc and multiple eproms only.

The reasoning simply being that it is a sign of the times that most of the people playing will be doing so on an emulator, and those of us with the real hardware have disc drives or hxc's these days.
IRC:  #Retro4All on Freenode

Carnivius

Quote from: CraigsBar on 22:59, 20 July 14
I was thinking disc or hxc only. Or rather disc, hxc and multiple eproms only.

I don't really even know what hxc or eproms are.  I'm not into all the modern expansion thingies or whatever they are.  And I want a tape version cos I only have a 464 and have no plans to add anything to it.
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

Trebmint

I think if you want a single load onto a 464, it will be a real struggle to get the sort of game you've been writing about if I'm honest. Compression can give 30-50% more space but you have to remember it needs to be decompressed to use it quickly (if you're talking about sprite graphics) or maps.
Even if you have say 3 sets of tiles that are 12k in size and they each compress to 4k, to hold all three would be 4k,4k,4k, plus any one decompressed at any one time 12k = 24k, and thats too big


Dont forget you need
1. Graphic Tiles (Probably some meta tiles as you're using very small 4x8 size) - Else each screen would require 40x25 or 1k
2. Mapping layout / A collision map
3. Sprites / Animation data
4. Game Code
5. Object Info
6. Music / Music Routine
Even silly little things that you realize once you're coding that you need like a small table, or a collision list etc take up 500bytes / 1k etc. They all start to build up and up and the 40 something k you start with looks tiny.


Imho if you want lots of graphics you'll have no choice but to design the game to be multiload. That doesn't have to be as limiting as you'd imagine though

TotO

#12
Amstrad made the 464 to be able to run programs from ROM since 1984.
With that your game instantly start like an arcade machine, when you power ON or with |ROBOCOP for example.
And you can display the greats messages ROM OK / RAM OK when all goes fine. :)

More than hundreds of CPC users own a ROM board and can't wait to play your games.
It will cost around 15£ for your dream come true, with respect of the 464 64K RAM.

Best!
Works on your game by making all GFx and level design, and I will give you this board for free, when all will be done.
You will be proud about your game, and all the CPC community too! :)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

arnoldemu

Quote from: Carnivac on 16:17, 20 July 14
Not really sure where else to put this but it's game development related to I thought Programming would be best.   While I'm not programming on CPC myself I still have to think about what is possible and what ain't, for when the time comes these projects will become real CPC games.

Anyways during the RoboCop: Prime thread it was mentioned to me (I think by arnoldemu) that it was best to keep to under 256 tiles.   I'd just like some more information about that. 

Does it make any difference how big the tiles are?   Because mine are 4x8 pixels... 256 of which would use up less memory than 256 8x16 pixel tiles surely?
the 256 is the biggest number to fit inside a byte. 1 byte per tile number in a tilemap means less storage and is quick to access.
16-bit indexes mean a larger tilemap, and if you have that many tiles it would often take too much ram.
Smaller sizes e.g. 64 don't fit exactly into a byte so are harder to extract from the tilemap if you choose to put the bits side by side.

if you're using hardware scrolling tiles should be a multiple of 2 bytes wide and 8 pixels tall because this is the minimum hardware scroll size.

Using 8x16 is fine because it's 2 times the size of a 4x8.


Quote from: Carnivac on 16:17, 20 July 14
Does that include fonts?  Are fonts done like tiles as they are often on the NES?  I mean cos that would be well over 30 tiles gone already.  Plus I've seen enough games on CPC that use multiple fonts at different sizes too so I can't see how they would use up any tile limits.
I always treat fonts seperately. They're not referenced in the tile map so are seperate.

Quote from: Carnivac on 16:17, 20 July 14
Does it include status panels/menu graphics (mine are crafted from tiles at moment)?
No, this can be treated as a seperate tilemap if you want or as a one-time bitmap created from tiles.

Generally 256 tiles per tilemap. So this means 1 for level and then 1 for anything else.

Quote from: Carnivac on 16:17, 20 July 14
How are tiles overlaid and told if they are foreground or background?  SwitchBlade for example uses a lot of foreground tiles some of which are the same as background tiles (such as the 'crates').
You can either define 2 tilemaps, one for foreground or one for background, then draw back, draw sprites, draw front.
But that can be wasteful for memory because you need twice the number of tilemaps many of which are transparent.

The alternative is to actually to define sprites which overlay, or perhaps rectangular regions composed of tiles.

Quote from: Carnivac on 16:17, 20 July 14
Can tiles be easily recoloured? 
yes, but there is a speed penalty for doing so, so takes longer to draw, because recolouring a tile involves:

read original pixels
lookup new coloured pixels
write new pixels

whereas a non-coloured tile is:

read original pixels
write new pixels

Tiles can also be mirrored in horizontal or vertical, but again there is a time penalty at least for horizontally mirrored ones.
Best avoided unless memory is really tight.

Quote from: Carnivac on 16:17, 20 July 14
How is collision often done?   I mean can a platform be solid in one place and non-solid in another and yet use the same tile graphic?
It depends.

If you have enough memory you have a "control map". it's a tilemap but instead of tile indexes, each cell has a tag e.g. "platform" or "will kill you".

This eats up ram, so another alternative is to organise your tiles so that tile 0-8 is platform, 16-32 is kill etc.

Collision is generally done when the sprite is moved. you move the sprite, update it's map coordinates and detect if you are going to hit a tile (e.g. a wall), then you make a decision about if you can move or not.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

Quote from: Carnivac on 17:26, 20 July 14
Thanks for all that.  :)
Hm, ok I think I understood most of it.   I may need to re-read through it some more though.
I wasn't aware of tile banks.   Sounds neat. 

Ok so here's the current tileset for RoboCop: Prime.  (most of the tiles look crappy out of context but most are also very recyclable into other background elements).



In the bottom right hand corner there are 24 tiles of tubes and panels which make up the status bar and menus.  So I could move those to another sheet (maybe the same one that has the fonts?) and have them be seperate tile banks (and then freeing up those 24 tile spaces on that sheet there for other level tiles)?   And three tile banks of 256 4x8 tiles each would be 12k?   Is that an ok amount of tile graphics for a game? 

Starting to think this isn't as limiting as I thought.
yes you can move them.

the limiting factor is always ram, even on a 128k game.
e.g. if you have lots of animations and graphics you then use a load of 128k with graphics.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

my thoughts:

design it to be multi-load.
design it for fast loading on disc.
limit it to 64k if you want.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Sykobee (Briggsy)

#16

I know other people have answered already, but I'll put my thoughts in before reading their answers.

Quote from: Carnivac on 16:17, 20 July 14
Does it make any difference how big the tiles are?   Because mine are 4x8 pixels... 256 of which would use up less memory than 256 8x16 pixel tiles surely?


No, 4x8 tiles will use less memory (4KB per tile bank of 256 tiles) of course, but the memory usage here relates to the map data, not the tile data itself.


Smaller tiles will result in larger map data, each tile is a byte, so a 40x20 screen of 4x8 MODE 0 tiles would use up 800 bytes. A 20x10 screen of 8x16 MODE 0 tiles uses 200 bytes.


You can also consider compound tiles - these are large tiles made of smaller tiles. E.g., you could have a 4x4 compound tile (16x32 pixels) built out of 4x8 tiles. Games like Times Of Lore did this, I suspect Turrican did too. This puts more stress on the programmer, but it really reduces the map's memory requirements, and allows massive maps, as the cost of having finer detail.  For an example of this on another platform, look at SEUCK on the C64, which had a compound tile designer.

Quote
Does that include fonts?  Are fonts done like tiles as they are often on the NES?  I mean cos that would be well over 30 tiles gone already.  Plus I've seen enough games on CPC that use multiple fonts at different sizes too so I can't see how they would use up any tile limits.
Does it include status panels/menu graphics (mine are crafted from tiles at moment)?



No, you can put your fonts elsewhere in memory, and render text using that different bank of character tiles.  Might be a little work for the coder here.
The same goes for all non-map graphics - borders around the play area, scoreboard, HUD, sprites, etc.

Quote
How are tiles overlaid and told if they are foreground or background?  SwitchBlade for example uses a lot of foreground tiles some of which are the same as background tiles (such as the 'crates').


You could set aside a bit in the tile map to indicate solid/non-solid. But this reduces you to 128 tiles.


You could have two tile maps - foreground and background (these could be RLE encoded to save space in a flip-screen game, because there would be large empty spaces with such a system). The current displayed screen can store more tile metadata than the general map remember, as there is only one currently displayed screen. This meta data could contain foreground/background bit, visibility bit (e.g., Switchblade/Ranarama hidden areas), deadly bit, and anything else you can think of. This also lets you have separate tile maps for foreground and background graphics (512 tiles).

How to share tile graphics Switchblade-style with having two different tile maps? Overlap the tile maps. Tiles 128-255 of Tile Map A (foreground) could be Tiles 0-127 of Tile Map B (background).

Quote
Can tiles be easily recoloured? 


Short answer: No.
Long answer: Yes, with careful palette organisation and programming work to recolour at render time.

Quote
How is collision often done?   I mean can a platform be solid in one place and non-solid in another and yet use the same tile graphic?


Use the solid/not-solid metadata map I mention above - check sprite location against this metadata map.


How the metadata map is arranged is a programmer problem to be honest. Some might want each type of metadata in it's own bitmap (5 bytes by 20 bytes for a 40x20 screen), or stored alongside the screen's tile map, or whatever.  Just be aware that there will be a way to define, on a tile-by-tile basis, some tile properties, that can be generated at run-time (foreground tile is solid, background tiles 64-96 are deadly, etc) or in the map data itself.

Carnivius

Thanks for all the advice. :) 

Regarding memory needed for music:  Music is something that I will likely have in the 128k versions only.  I don't consider it as important as graphics.  I mean, good music is great and the original RoboCop game had music in the 64k version but sound is something you can kinda add yourself in some ways.  Heck you could grab the tune from the game as an mp3 and play it on your phone while you're playing the game on the CPC 464.   Even sound effects to some degree (I often found myself even as a kid doing my own sound effects in games that had little to no sounds) whereas graphics aren't something you can manually 'insert' into the game experience the same way so for me they take priority.


Colour swapping is something I can probably avoid on the tiles, but I really do want it on the sprites.  Does it matter how many colours within the sprite get changed?  I mean is changing 1 colour in a 10 colour sprite faster than changing all 10 colours in it?   It's very important for the re-used leg sprites in both projects. 

For example if you look at these sprites from Cosmic Prison Commando you'll see they share the same leg sprites (cos the legs have 8 frame walk cycles and such) and that they are recoloured.  If you take the middle one as the 'default' version of the leg sprite with the dark green and the orange coloration you'll see it only needs one colour to become the other character's legs.  So the dark green turns to magenta to form the left sprite's coloured legs and the orange turns to bright green for the zombie trooper's leg sprite on the right.   Now is that gonna be ok?    The enemies in RoboCop: Prime use a few more colours to swap but am curious to know whether this will have a notable speed issue.


Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

Trebmint

Actually colour changing is possible with both tiles and sprites at a fairly decent speed (this wouldnt be the case for tiles if you were scrolling, only on flip screen) given that drawing a whole screen with tiles of colour changes would only take a few tenths longer to render which is acceptable with a flip screen.


And the speed is the same if you want to change 1 colour or 15. We would use something called a series of lookup tables. The 2 pixels in mode 0 that make up 1 byte corrospond to a set of 256bytes for each palette. Therefore if you have 4 palette sets then you'd require an additional 1k to store this as lookup tables.


The other issue with colour changes on the tiles would be that you also have to encode the palette required. If you had say 4 sets of palette and 256 tiles, you'd effectively have 1024 tiles, and mapping with 1024 tiles takes more room that 256 tiles. 25% more in fact

arnoldemu

Quote from: Carnivac on 12:01, 22 July 14
Thanks for all the advice. :) 

Regarding memory needed for music:  Music is something that I will likely have in the 128k versions only.  I don't consider it as important as graphics.  I mean, good music is great and the original RoboCop game had music in the 64k version but sound is something you can kinda add yourself in some ways.  Heck you could grab the tune from the game as an mp3 and play it on your phone while you're playing the game on the CPC 464.   Even sound effects to some degree (I often found myself even as a kid doing my own sound effects in games that had little to no sounds) whereas graphics aren't something you can manually 'insert' into the game experience the same way so for me they take priority.


Colour swapping is something I can probably avoid on the tiles, but I really do want it on the sprites.  Does it matter how many colours within the sprite get changed?  I mean is changing 1 colour in a 10 colour sprite faster than changing all 10 colours in it?   It's very important for the re-used leg sprites in both projects. 
Trebmint has mentioned this.

A byte can have 256 possibilities. To change colour of one or more pixels in a byte, we use a conversion table.
We use the byte from the original pixels to find the replacement byte which has been recoloured.

So each possible choice of colour changes requires 1 table at 256 bytes each. e.g. if you want to change red and blue, that is one table, if you want to change red, blue and green that is a second table.

The conversion process adds a little more cpu time.

So here you are both limited by ram and how much you want to change.

I normally have 1 table for sprite mask.
Another table which can turn the sprite white when hit.
Another table for reversing pixels so we can draw sprites in the opposite direction.
Another table where the pixels are shifted by 1 pixel (more tables in mode 1).

So that is 1k of tables already. I then have two 16k screens which is 32k. If I wanted the panel seperately and the main part hardware scrolling, add another few k for the panel to be in it's own part of ram away from the hardware scroll.

I then put the graphics into the 2nd 64k. I make it visible in the range &4000-&7fff. In the main ram &4000-&7fff holds the tile map and some tile graphics.
We're limited to about 10k for code/sound in the main ram.

So if you want to do more colouring choose the colour changes wisely and minimize the use of them.

Re-colouring tiles is possible, but adds to cpu time. If they animate they generally have to be redrawn as they are scrolled.


Quote from: Carnivac on 12:01, 22 July 14

For example if you look at these sprites from Cosmic Prison Commando you'll see they share the same leg sprites (cos the legs have 8 frame walk cycles and such) and that they are recoloured.  If you take the middle one as the 'default' version of the leg sprite with the dark green and the orange coloration you'll see it only needs one colour to become the other character's legs.  So the dark green turns to magenta to form the left sprite's coloured legs and the orange turns to bright green for the zombie trooper's leg sprite on the right.   Now is that gonna be ok?    The enemies in RoboCop: Prime use a few more colours to swap but am curious to know whether this will have a notable speed issue.


It will slow down the drawing of the sprites and if everything requires re-colouring yes it will impact frame rate.

What you are doing with recolouring is a trade off: memory vs cpu time.
less memory, but more cpu time.

So the problem is always memory even on 128k games. Lots of graphics means less code to speed it up. So if you have lots of graphics the 128k is then taken up with making it look nice rather than making it faster.
Always a trade off.

If there are less graphics then you can use the 128k to speed it up by a special bit of code for each sprite.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Carnivius

Ok so if I keep the amount of different colour schemes fairly low it should be alright and still hopefully use less memory than storing pre-recoloured versions of all the leg sprites.  yay for recycling!  Even the jump frames are simply taken from the walk cycle to save memory too.  So currently legs are 8 frames for walking, 1 for standing, 1 for crouching, 2 for back/front views (when turning or going in/out doors) and I may have to do some for dying but not decided how that'll look yet.  So that's 12 frames at present.  If they were seperate even just for the characters shown in the image there that would be 36 and that's not including other cases where they may get reused and recoloured.  So yeah I'm keeping that memory usage quite low by doing it this way at least.   There are a couple of other walk cycles in the game with different legs but they don't take much (2 frames for the small robot one of which is his standing frame, and the other is his jumping frame, and a small-ish 3 frame that equals 4 when moving 1,2,3,2) 'chicken leg' sorta walk sprite for the enemy droids. 

And as for swapping colours of tiles, fine for Cosmic Prison Commando which is flip screen but not so much for RoboCop: Prime which scrolls.  Ok. :)   I'll keep that in mind.

Hm, though with RoboCop: Prime the magenta colour (in that tilesheet it's 255,0,127) is only ever used in the background (almost exclusively in the sky but also it's the 'mask colour' of any sprites that need transparency) so I'm tempted to have the whole sky use that magenta index and then have it change as a raster gradient effect.  Similar in appearance to how I have it tiled at moment but it would be a lot more flexible being that it would affect the occurences of that magenta colour in tiles of the background that have sky in them (like the moon tile or the sloped parts of the backdrop buildings). 

Hmm...

Ok another thing.  This example image shows how the top half of the RoboCop player object is constructed.   When I started it was like the right one where the top half was all just one sprite but then I wanted the head to be seperate (to do the 'staggered' movement when Robo turns like in the films but also to be replaced by the helmet-less version showing Murphy's face) and then the gun to be seperate (since all the directions of the gun pointing then get flipped through when he spins his gun before putting it back in the holster) so the one on the left is how it's constructed in the current game engine.    Now is the CPC alright with doing it the way on the left?  Is it better in some way on memory or is it slow on speed having to display 3 smaller sprites instead of one larger one?  Obviously the positioning of the sprites is trickier (and a pain in the butt when I'm doing it but worth it for the flexibility of the sprites).
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

arnoldemu

Quote from: Carnivac on 13:31, 22 July 14
Ok another thing.  This example image shows how the top half of the RoboCop player object is constructed.   When I started it was like the right one where the top half was all just one sprite but then I wanted the head to be seperate (to do the 'staggered' movement when Robo turns like in the films but also to be replaced by the helmet-less version showing Murphy's face) and then the gun to be seperate (since all the directions of the gun pointing then get flipped through when he spins his gun before putting it back in the holster) so the one on the left is how it's constructed in the current game engine.    Now is the CPC alright with doing it the way on the left?  Is it better in some way on memory or is it slow on speed having to display 3 smaller sprites instead of one larger one?  Obviously the positioning of the sprites is trickier (and a pain in the butt when I'm doing it but worth it for the flexibility of the sprites).


cpc can do this.

Is it slower for cpu? potentially, but then it's not wasting so many cycles drawing the transparent bits, but then again if the sprite was stored in a "compressed" form it wouldn't be doing that either.
Is it using less ram? yes.

difficult to say if it's worse or not.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

andycadley

To be honest, I suspect you're worrying about details that don't really matter so much. Write the game the way you want it to be, then leave the finer points of how to translate that to the CPC itself as a whole other issue for whoever develops it. Chances are they'll have to compromise in places anyway and worrying now about whether that's by recoloring leg sprites on the fly or storing multiple copies is probably less helpful - you may for example optimize for recoloring when that turns out to be too CPU incentive and will have sacrificed other features that potentially could have been carried across more easily.

Obviously don't go nuts and fill the screen with millions of large unique sprites, but don't worry so much about the fine details of how it ports and trust the smart folks in the CPC scene to translate your vision as well as possible.

Carnivius

Quote from: andycadley on 18:40, 22 July 14
To be honest, I suspect you're worrying about details that don't really matter so much. Write the game the way you want it to be, then leave the finer points of how to translate that to the CPC itself as a whole other issue for whoever develops it. Chances are they'll have to compromise in places anyway and worrying now about whether that's by recoloring leg sprites on the fly or storing multiple copies is probably less helpful - you may for example optimize for recoloring when that turns out to be too CPU incentive and will have sacrificed other features that potentially could have been carried across more easily.

Obviously don't go nuts and fill the screen with millions of large unique sprites, but don't worry so much about the fine details of how it ports and trust the smart folks in the CPC scene to translate your vision as well as possible.

Yeah but I'm trying to just get into the way of thinking that CPC coders have to and try to work within those confines.  I'd hate to waste hours on some feature or boss sprite only to find it cannot make it into the final product. 

Thanks though.  :)
Favorite CPC games: Count Duckula 3, Oh Mummy Returns, RoboCop Resurrection, Tankbusters Afterlife

TotO

Don't expect that you can only produce useful and accurate graphics at the first time. You will lie to yourself. :)
The best is that you not waste time with problems that is for you and not for programmers.
Use this time to be productive by doing what you know: great graphics.
In all cases, you will have to update them for the final result.
(a programmer does the same with its code, but you don't see that ;D )
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Powered by SMFPacks Menu Editor Mod