Hi,
A few Questions on Level backgrounds:
1)A good level should be around 960 pixels wide 224 High. True?
2)Colors ... Like Sprites should level colors have a maximum 15 colors. True?
3)Level Backgrounds have the actual background art such as tree, sky etc ... and then Sprites like buildings, bridges roads are added to the level. True?
Color Problems:
I am using 15 colors but the levels look very faded and washed out when I use 15 colors 8 x8 optimised converting in Imagenesis.
The qulaity is gone when I compile and load in the Emulator.
Advice from You:
Basically what things should I look at while making a Top Quality level?
Advice on the Art of Genesis level Building
Moderator: BigEvilCorporation
Advice on the Art of Genesis level Building
I need a Black Belt in Game Programming!
False for all the three, because you've forgot to specify your goal.
You have four 16-color (15+transparency) palettes. It is up to you how you assign them to the graphics. You could use them all for the background, if you want, but in this case sprites graphics should share the same palettes.
If you make graphics with arbitrary palette, even 16-color, and then convert it, you should remember that SMD has R3G3B3 color space (512 colors), and after the conversion close colors from R8G8B8 color space could became the same color in R3G3B3. To avoid the problem, make your graphics using SMD palette.
It is also up to you which background objects you have on background layers or as sprites. Usually you don't have to use the sprites for background elements, because number of the sprites on the screen, and especially on the raster line, is limited.
You have four 16-color (15+transparency) palettes. It is up to you how you assign them to the graphics. You could use them all for the background, if you want, but in this case sprites graphics should share the same palettes.
If you make graphics with arbitrary palette, even 16-color, and then convert it, you should remember that SMD has R3G3B3 color space (512 colors), and after the conversion close colors from R8G8B8 color space could became the same color in R3G3B3. To avoid the problem, make your graphics using SMD palette.
It is also up to you which background objects you have on background layers or as sprites. Usually you don't have to use the sprites for background elements, because number of the sprites on the screen, and especially on the raster line, is limited.
Shiru Hi,
Thanks again for your advice your always so helpful.
Shiru the color pallette is in SGTD. Should I follow the pallette in SGTD while coloring the level?
Your right it doesn't make sense to limit it to 15 colors when SMD has 4 pallettes
Good point okay I will stay away from level sprites and just draw the background.
Because I want many sprites fighting on raster line.
I was looking at Double Dragon and it was using alot of level sprites so that inspired me.
Oh Shiru I sent you e-mail.
Thanks again for your advice your always so helpful.
Shiru the color pallette is in SGTD. Should I follow the pallette in SGTD while coloring the level?
Your right it doesn't make sense to limit it to 15 colors when SMD has 4 pallettes
Good point okay I will stay away from level sprites and just draw the background.
Because I want many sprites fighting on raster line.
I was looking at Double Dragon and it was using alot of level sprites so that inspired me.
Oh Shiru I sent you e-mail.
I need a Black Belt in Game Programming!
Each sprite/tile is mapped to one of the 4 palettes, so each tile can have up to 15 colors (or 16 if you care transparent one*), and each sprite up to 15 colors.
*The deeper background can use the background color as own color.
When working with backgrounds the limit are the tiles, so I recommend to start first drawing them (or may be some composition of them), and then compose the background. Or if you like more a very short but intense game, draw all background as a whole, but you have to dinamicaly load it.
You can change the priority of every title to be up or down respect each sprite, so, a background can be a foreground too. A lot of games use this feature to implement one tile map only and save memory.
Each moveable independent 'thing' should be a sprite since planes are a whole thing. So all dependent drawings go to a plane.
You are very limited (MD has more than 20 years), so it is pretty clear that you can not do; but at first stages use only your imagination, do not think about limits.
*The deeper background can use the background color as own color.
When working with backgrounds the limit are the tiles, so I recommend to start first drawing them (or may be some composition of them), and then compose the background. Or if you like more a very short but intense game, draw all background as a whole, but you have to dinamicaly load it.
You can change the priority of every title to be up or down respect each sprite, so, a background can be a foreground too. A lot of games use this feature to implement one tile map only and save memory.
Each moveable independent 'thing' should be a sprite since planes are a whole thing. So all dependent drawings go to a plane.
You are very limited (MD has more than 20 years), so it is pretty clear that you can not do; but at first stages use only your imagination, do not think about limits.
Just for information, you can't get 960x224 picture on the SMD if every tile in the picture is unique - it's 3360 tiles total, and you can have ~1900 max at once, in the very best case, and this number is for everything, including sprites. So, you have to plan your backgrounds to be tile-based, with least possible number of different tiles.
>>Each sprite/tile is mapped to one of the 4 palettes, so each tile can have up to 15 colors (or 16 if you care transparent one*), and each sprite up to 15 colors.
'Ok!
>>so I recommend to start first drawing them (or may be some composition of them), and then compose the background.
'Yes ... You know I was just creating an art background without create a pre-determined tile set and number of tiles is going well over the limit.
>>Each moveable independent 'thing' should be a sprite since planes are a whole thing. So all dependent drawings go to a plane.
'Independent on Plane A ... Dependent on Plane B ... Ok!
>>Just for information, you can't get 960x224 picture on the SMD if every tile in the picture is unique - it's 3360 tiles total, and you can have ~1900 max at once, in the very best case.
'I am getting Sprite Limit reached on SMD !
NOOOOOOO!
Your right Shiru too may unique tools charged
'Ok!
>>so I recommend to start first drawing them (or may be some composition of them), and then compose the background.
'Yes ... You know I was just creating an art background without create a pre-determined tile set and number of tiles is going well over the limit.
>>Each moveable independent 'thing' should be a sprite since planes are a whole thing. So all dependent drawings go to a plane.
'Independent on Plane A ... Dependent on Plane B ... Ok!
>>Just for information, you can't get 960x224 picture on the SMD if every tile in the picture is unique - it's 3360 tiles total, and you can have ~1900 max at once, in the very best case.
'I am getting Sprite Limit reached on SMD !
NOOOOOOO!Your right Shiru too may unique tools charged
I need a Black Belt in Game Programming!
No. You have:Alex Khan wrote: >>Each moveable independent 'thing' should be a sprite since planes are a whole thing. So all dependent drawings go to a plane.
'Independent on Plane A ... Dependent on Plane B ... Ok!
- Two big pictures named planeA and planeB* (and may be window too), usually used to draw background, foreground and/or ground.
- Up to 80 little pictures, named sprites, to draw all other things.
For example, if you character touch a rock on the ground and then it falls, it should be a sprite since his movement is independent from the ground (see sonic 1 and rock-edges falling on level 1).
You can animate titles on a plane (break a window, for example), but they can-t move at its own.
* as they always scrolls, they should be considered infinite pictures.
Regarding "I am getting Sprite Limit reached on SMD ! Sad NOOOOOOO!"
Actually, if you do things right, you are unlikely to reach that limit, unless background is white noise that needs to be preserved losslessly.
I am writing down all this stuff from my (about 10 year old) memories, so correct me where I'm wrong.
Remember that every tile eats up 32bytes and it could be good to use up 20-30kbytes of the entire 64k vram for the backgrounds.
Animation for all sprites for most elaborate animated games is done using dma and sprite tile data is transferred from rom at every animation frame for every sprite.
30-45 palette entries (2-3 palettes) could be used for backgrounds, the remaining colors for protagonists and antagonists
Palette can be reprogrammet on HINT to add watter and similar efects. Palette can be reprogrammed on VINT for classic 'water'/'waterfall' effect (crolling blue and white shades on few palette entries)
500 tiles for backgrounds is more than enough if used carefully and can also be reprogrammed live (on certain level advances). Sonic does that a lot (when passing on-way-only doors etc). Also fans and other background animated element tiles can be updated via dma at runtime using VINT.
For any large images, that need to be stored on carts, there are programs called tile optimizers (or whatever) that do automatically search similar tiles and optimize them off until certain loss or tile count treshold is reached.
Most artwork-ful background games like aladdin/lionking/junglebook have backgrounds drawn as a pictures of large spots with stuff, without some intricate details and interaction objects, than run through optimizer to see how much it weights and how does it fit into tiles. Then tiles get slightly 'filed' to optimize better (sometimes by moving some parts on drawings, so they match in 8x8grid with other objects and optimize off), then a lot of crispy yet small objects are drawin in tiles and placed on optimized map, as well as interaction objects added (ropes, poles, anything).
I did know one of the artists behind lion king back in the days, and she described their in-house proprietary process also to be similar to the described above. By the way, I remember she told me that she would like to take part creating in some open source / free / leisure / experimental game. Will try to dig up old contacts and see what's changed in ten years
Regarding oclors, avoid floyd-steinberg/noise type dithering, as it would eat up a hell lot more tiles than it should. Use ordered dithering of 2x2 tiles (that gives about 2 additional 'bits'). So you have about 5 bits/channel with dithering or 4bits/chan if tricks are used (reprogramming some palette entries on even/odd fields for example).
Anyways 500 tiles is quite a lot, especially if engine is wise enough to be able to reprogram tiles when certain object/obstacle is passed.
Actually, if you do things right, you are unlikely to reach that limit, unless background is white noise that needs to be preserved losslessly.
I am writing down all this stuff from my (about 10 year old) memories, so correct me where I'm wrong.
Remember that every tile eats up 32bytes and it could be good to use up 20-30kbytes of the entire 64k vram for the backgrounds.
Animation for all sprites for most elaborate animated games is done using dma and sprite tile data is transferred from rom at every animation frame for every sprite.
30-45 palette entries (2-3 palettes) could be used for backgrounds, the remaining colors for protagonists and antagonists
Palette can be reprogrammet on HINT to add watter and similar efects. Palette can be reprogrammed on VINT for classic 'water'/'waterfall' effect (crolling blue and white shades on few palette entries)
500 tiles for backgrounds is more than enough if used carefully and can also be reprogrammed live (on certain level advances). Sonic does that a lot (when passing on-way-only doors etc). Also fans and other background animated element tiles can be updated via dma at runtime using VINT.
For any large images, that need to be stored on carts, there are programs called tile optimizers (or whatever) that do automatically search similar tiles and optimize them off until certain loss or tile count treshold is reached.
Most artwork-ful background games like aladdin/lionking/junglebook have backgrounds drawn as a pictures of large spots with stuff, without some intricate details and interaction objects, than run through optimizer to see how much it weights and how does it fit into tiles. Then tiles get slightly 'filed' to optimize better (sometimes by moving some parts on drawings, so they match in 8x8grid with other objects and optimize off), then a lot of crispy yet small objects are drawin in tiles and placed on optimized map, as well as interaction objects added (ropes, poles, anything).
I did know one of the artists behind lion king back in the days, and she described their in-house proprietary process also to be similar to the described above. By the way, I remember she told me that she would like to take part creating in some open source / free / leisure / experimental game. Will try to dig up old contacts and see what's changed in ten years
Regarding oclors, avoid floyd-steinberg/noise type dithering, as it would eat up a hell lot more tiles than it should. Use ordered dithering of 2x2 tiles (that gives about 2 additional 'bits'). So you have about 5 bits/channel with dithering or 4bits/chan if tricks are used (reprogramming some palette entries on even/odd fields for example).
Anyways 500 tiles is quite a lot, especially if engine is wise enough to be able to reprogram tiles when certain object/obstacle is passed.
>>the remaining colors for protagonists and antagonists
Wow this sentence alone tells me I'm in the presence of a very intelligent and eloquent person.
>>Actually, if you do things right, you are unlikely to reach that limit, unless background is white noise that needs to be preserved losslessly.
Hmmm ... interesting.
>>I am writing down all this stuff from my (about 10 year old) memories, so correct me where I'm wrong.
Yah back in those days they knew how to make games. Not the bloated crap on the market these days.
>>Remember that every tile eats up 32bytes and it could be good to use up 20-30kbytes of the entire 64k vram for the backgrounds.
Oh I see ...
>>Animation for all sprites for most elaborate animated games is done using dma and sprite tile data is transferred from rom at every animation frame for every sprite.
Uh Huh ...
>>Palette can be reprogrammet on HINT to add watter and similar efects. Palette can be reprogrammed on VINT for classic 'water'/'waterfall' effect (crolling blue and white shades on few palette entries)
Wow I did not know that! HINT AND VINT I must research this.
>>500 tiles for backgrounds is more than enough if used carefully and can also be reprogrammed live (on certain level advances). Sonic does that a lot (when passing on-way-only doors etc). Also fans and other background animated element tiles can be updated via dma at runtime using VINT.
Woot!?!? In all my research thus far no one has told me these things.
>>For any large images, that need to be stored on carts, there are programs called tile optimizers (or whatever) that do automatically search similar tiles and optimize them off until certain loss or tile count treshold is reached.
I would love to get my hands on one of those optimisers.
>>Most artwork-ful background games like aladdin/lionking/junglebook have backgrounds drawn as a pictures of large spots with stuff ...
Hmmm ... I am kind of losing you here are not the ladders and ropes sprites draw on one of the Planes?
>>I did know one of the artists behind lion king back in the days, and she described their in-house proprietary process also to be similar to the described above. By the way, I remember she told me that she would like to take part creating in some open source / free / leisure / experimental game. Will try to dig up old contacts and see what's changed in ten years
Really? That would be absolutely Fantastic! Lion King and Aladdin I remember really well don't recall Jungle Book.
>>Regarding oclors, avoid floyd-steinberg/noise type dithering, as it would eat up a hell lot more tiles than it should. Use ordered dithering of 2x2 tiles (that gives about 2 additional 'bits'). So you have about 5 bits/channel with dithering or 4bits/chan if tricks are used (reprogramming some palette entries on even/odd fields for example).
Jesus Christ Dude! You need to write a tutorial or something your very knowledgeable!
>>Anyways 500 tiles is quite a lot, especially if engine is wise enough to be able to reprogram tiles when certain object/obstacle is passed.
Damn ... The Engine will have to be written to factor reprogramming tiles. WOOT?!?! And I thought Collision detection and AI was going to be the real challenge. How do I do that bro? the reprogramming tile part?
Wow this sentence alone tells me I'm in the presence of a very intelligent and eloquent person.
>>Actually, if you do things right, you are unlikely to reach that limit, unless background is white noise that needs to be preserved losslessly.
Hmmm ... interesting.
>>I am writing down all this stuff from my (about 10 year old) memories, so correct me where I'm wrong.
Yah back in those days they knew how to make games. Not the bloated crap on the market these days.
>>Remember that every tile eats up 32bytes and it could be good to use up 20-30kbytes of the entire 64k vram for the backgrounds.
Oh I see ...
>>Animation for all sprites for most elaborate animated games is done using dma and sprite tile data is transferred from rom at every animation frame for every sprite.
Uh Huh ...
>>Palette can be reprogrammet on HINT to add watter and similar efects. Palette can be reprogrammed on VINT for classic 'water'/'waterfall' effect (crolling blue and white shades on few palette entries)
Wow I did not know that! HINT AND VINT I must research this.
>>500 tiles for backgrounds is more than enough if used carefully and can also be reprogrammed live (on certain level advances). Sonic does that a lot (when passing on-way-only doors etc). Also fans and other background animated element tiles can be updated via dma at runtime using VINT.
Woot!?!? In all my research thus far no one has told me these things.
>>For any large images, that need to be stored on carts, there are programs called tile optimizers (or whatever) that do automatically search similar tiles and optimize them off until certain loss or tile count treshold is reached.
I would love to get my hands on one of those optimisers.
>>Most artwork-ful background games like aladdin/lionking/junglebook have backgrounds drawn as a pictures of large spots with stuff ...
Hmmm ... I am kind of losing you here are not the ladders and ropes sprites draw on one of the Planes?
>>I did know one of the artists behind lion king back in the days, and she described their in-house proprietary process also to be similar to the described above. By the way, I remember she told me that she would like to take part creating in some open source / free / leisure / experimental game. Will try to dig up old contacts and see what's changed in ten years
Really? That would be absolutely Fantastic! Lion King and Aladdin I remember really well don't recall Jungle Book.
>>Regarding oclors, avoid floyd-steinberg/noise type dithering, as it would eat up a hell lot more tiles than it should. Use ordered dithering of 2x2 tiles (that gives about 2 additional 'bits'). So you have about 5 bits/channel with dithering or 4bits/chan if tricks are used (reprogramming some palette entries on even/odd fields for example).
Jesus Christ Dude! You need to write a tutorial or something your very knowledgeable!
>>Anyways 500 tiles is quite a lot, especially if engine is wise enough to be able to reprogram tiles when certain object/obstacle is passed.
Damn ... The Engine will have to be written to factor reprogramming tiles. WOOT?!?! And I thought Collision detection and AI was going to be the real challenge. How do I do that bro? the reprogramming tile part?
I need a Black Belt in Game Programming!
(A short reply due to lack of time at the moment)
HINT and VINT - horisontal and vertical interrupt, realy work well on genny, in contrast to pc cga/ega/vga hell
Sonic3 and many other games use hint for water.
Regarding reprogramming - challenge is everything!
To have large, interesting levels, you also need to reprogram the maps quite frequently and fast, usually involving decompression of some sort. This is a challenge, especially if a game is a fast scroller. I remember playfield was programmable to 64x64 tiles and thus, when running around, that flayfield need to be updated off-screen for all the new stuff there is. Also handle the disapperaing and appearing enemies and their actions. This all is a hard part.
Reprogramming, however, is a relatively easy one - when some token is reached with the hero alone in the center on mostly only background visible and ground of some sort, engine updates specific blocks of tile data (that is used on the next part of the level), the ones, which are on the screen, stay intact. Games usualy have a slight hickup at that point (a freeze for a frame or two) and then does not allow you to go back (because graphics will be trashed up by new tiles). sonic2/3/knuckles do this stuff a lot and quite smoothly.
I think i could dig up my old tool sources that had quite a powerful optimiser amongst them, and maybe rework them for windows and any user interface (they were for DOS and x-mode graphics hahaha *scary*).
Another extreme programming challenge is to make effective enemy/object engine - again, sonic2/3/K does this amazingly well. Challenge is to make it all flexible and fluent - that every object that enters the proximity space, becomes active and has it's own processing/interaction routine (form rom, shared for all enemies of the same type), yet have dynamically assigned context scratchpads (separate for every 'live' object), that hold objects behaviour/position/action/phase, and that all such objects are processed using a dynamically maintained list where such routine can terminate itself and remove from list (when, for example, enemy is killed and explosion animation is done and over) or suspend (or keep alve) if that object is important (boss doesn't disapper or stop operating when leaving frame).
Such engine allows almost interaction things to be handled in the same way (like it's done in sonic) - be it a wall opening from a button press or operating a pulleys or some mechanisms, bosses that can release more enemies, animated checkpoints, etc...
I find this thing, along with map update engine, to be the hardest points, but also most beneficial ones, when those are up and running Because creating detailed and ellaborate levels becomes a joy! As well as creating enemies, that can generate more enemies (even by just shooting) and interactive objects.
Contra hard corps is an another example of extremely well programmed engine that does hell lot of tricks and everything combined in a solid piece of consistent code. Same about vectorman and well... many many other games
HINT and VINT - horisontal and vertical interrupt, realy work well on genny, in contrast to pc cga/ega/vga hell
Sonic3 and many other games use hint for water.
Regarding reprogramming - challenge is everything!
To have large, interesting levels, you also need to reprogram the maps quite frequently and fast, usually involving decompression of some sort. This is a challenge, especially if a game is a fast scroller. I remember playfield was programmable to 64x64 tiles and thus, when running around, that flayfield need to be updated off-screen for all the new stuff there is. Also handle the disapperaing and appearing enemies and their actions. This all is a hard part.
Reprogramming, however, is a relatively easy one - when some token is reached with the hero alone in the center on mostly only background visible and ground of some sort, engine updates specific blocks of tile data (that is used on the next part of the level), the ones, which are on the screen, stay intact. Games usualy have a slight hickup at that point (a freeze for a frame or two) and then does not allow you to go back (because graphics will be trashed up by new tiles). sonic2/3/knuckles do this stuff a lot and quite smoothly.
I think i could dig up my old tool sources that had quite a powerful optimiser amongst them, and maybe rework them for windows and any user interface (they were for DOS and x-mode graphics hahaha *scary*).
Another extreme programming challenge is to make effective enemy/object engine - again, sonic2/3/K does this amazingly well. Challenge is to make it all flexible and fluent - that every object that enters the proximity space, becomes active and has it's own processing/interaction routine (form rom, shared for all enemies of the same type), yet have dynamically assigned context scratchpads (separate for every 'live' object), that hold objects behaviour/position/action/phase, and that all such objects are processed using a dynamically maintained list where such routine can terminate itself and remove from list (when, for example, enemy is killed and explosion animation is done and over) or suspend (or keep alve) if that object is important (boss doesn't disapper or stop operating when leaving frame).
Such engine allows almost interaction things to be handled in the same way (like it's done in sonic) - be it a wall opening from a button press or operating a pulleys or some mechanisms, bosses that can release more enemies, animated checkpoints, etc...
I find this thing, along with map update engine, to be the hardest points, but also most beneficial ones, when those are up and running
Because creating detailed and ellaborate levels becomes a joy! As well as creating enemies, that can generate more enemies (even by just shooting) and interactive objects.Contra hard corps is an another example of extremely well programmed engine that does hell lot of tricks and everything combined in a solid piece of consistent code. Same about vectorman and well... many many other games
-
Chilly Willy
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Actually, with current flash cards and emulators, you don't NEED compression. Look at the Sonic series - Sonic 1 is only 512KB, and Sonic 2 just 1MB. If you assume all compression gave an average of 4:1 (really high), both fit in a flash cart uncompressed without a problem. Compression was used initially to keep the size down when roms where still expensive. So unless you are shooting for Sonic 3 or better size, you don't really need to worry about compressing anything.
If it doesn-t involve decompresion, I think this is very easy, you online need to move 2bytes for each tile.dtech wrote: Regarding reprogramming - challenge is everything!
To have large, interesting levels, you also need to reprogram the maps quite frequently and fast, usually involving decompression of some sort. This is a challenge, especially if a game is a fast scroller.
And I don't think you can use compression in this instant. Compression only works for large amount of data with a big package. I think what games do is unzip to memory the level-map at the beginning of it. Do you have an info about it?
This is used in Contra. It-s by far the most impressive game, technically speaking. But I don-t found any other game that uses this tecnic (Comix zone may be...). Most of other games did: screeen-off, load all needed data for level, screen-on.dtech wrote:.
Reprogramming, however, is a relatively easy one - when some token is reached with the hero alone in the center on mostly only background visible and ground of some sort, engine updates specific blocks of tile data (that is used on the next part of the level), the ones, which are on the screen, stay intact. Games usualy have a slight hickup at that point (a freeze for a frame or two) and then does not allow you to go back (because graphics will be trashed up by new tiles). sonic2/3/knuckles do this stuff a lot and quite smoothly.
But, since (surely) data is compresed in Contra it tooks more than 2 frames, something near half second. This game used the explosion of mid boss to do this trick (character can-t move for a bit seconds), so I am not sure a game that uses compression can do that trick, and maybe without either compression...
Again, do you have more info?
If you know C++ there is no challenge, it's the same! Well, I found collision detection (all to all mode) more interesting... simply MD can-t handle a 'for' inside 'for'... (order n^2)... or I'm doing things bad.dtech wrote: Another extreme programming challenge is to make effective enemy/object engine - again, sonic2/3/K does this amazingly well. Challenge is to make it all flexible and fluent - that every object that enters the proximity space, becomes active and has it's own processing/interaction routine (form rom, shared for all enemies of the same type), yet have dynamically assigned context scratchpads (separate for every 'live' object), that hold objects behaviour/position/action/phase, and that all such objects are processed using a dynamically maintained list where such routine can terminate itself and remove from list (when, for example, enemy is killed and explosion animation is done and over) or suspend (or keep alve) if that object is important (boss doesn't disapper or stop operating when leaving frame).
Such engine allows almost interaction things to be handled in the same way (like it's done in sonic) - be it a wall opening from a button press or operating a pulleys or some mechanisms, bosses that can release more enemies, animated checkpoints, etc...
I find this thing, along with map update engine, to be the hardest points, but also most beneficial ones, when those are up and running
On SNES with 128Kb of WRAM I was thinking about what you could possibly need all that RAM for in the average game. This came to mind. Compressing level data (or other background data or graphics data) and decompressing it into some free RAM so it can be quickly DMAed into place when needed. Genesis has 64Kb of RAM which is also quite alot. I would guess you've still got plenty of room to take a compressed level and expand it to a huge background table in RAM for quick DMAing.eteream wrote:If it doesn-t involve decompresion, I think this is very easy, you online need to move 2bytes for each tile.dtech wrote: Regarding reprogramming - challenge is everything!
To have large, interesting levels, you also need to reprogram the maps quite frequently and fast, usually involving decompression of some sort. This is a challenge, especially if a game is a fast scroller.
And I don't think you can use compression in this instant. Compression only works for large amount of data with a big package. I think what games do is unzip to memory the level-map at the beginning of it. Do you have an info about it?
In commercial games I've heard of compression techniques like a Tree system where you have your level made up of big blocks which are defined somewhere. Sometimes these big blocks are made up of smaller blocks that are defined elsewhere. Then with all of that you might use RLE or some other compression to get size down even more. I suppose if you only had a few of these "big" blocks or little blocks you could save data room by only using as many bits as you needed. I'm sure there are alot of ways to compress level data.
Even now with being able to have 4 megabytes of data for low cost, you still may want to use some compression as huge level data really can get HUGE.
For tile updates, you could transfer a manageable number of tiles every frame until you're done. Uncompressing can be done in the background when the game is idle. In an upcoming game I'm making, I switch to a background task that performs loading of world data whenever I'm waiting for the next frame, enabling seamless scrolling in a very large world. I used the same technique in a NES game (which was never finished) with splendid results. In both games, I have 4x4 screenfuls loaded at once.
Usually, level data is not based on individual tiles, but larger blocks composed of tiles (usually 2 by 2 or 4 by 4 tiles). This is also so in my game, where the result after loading is an arrangement of blocks made of 2 by 2 tiles. The world data itself is command based, where there are commands to draw floors, walls and other objects, and the objects can be placed freely without regard for screeen boundaries.
Usually, level data is not based on individual tiles, but larger blocks composed of tiles (usually 2 by 2 or 4 by 4 tiles). This is also so in my game, where the result after loading is an arrangement of blocks made of 2 by 2 tiles. The world data itself is command based, where there are commands to draw floors, walls and other objects, and the objects can be placed freely without regard for screeen boundaries.