Dwedit wrote:
you can do sequential access to RLE in a reasonable amount of time, provided you have row pointers.
That's an example of "dividing the map into entities of fixed dimensions", the rows being such entities, because you have random access through them via those pointers.
I don't think row RLE is a good choice for free scrolling though, unless the length of the rows was small enough for you to not have to process a lot of data you don't need when scrolling horizontally.
65024U wrote:
And yeah doing it screen-by screen would enable dumping maps to RAM in sections a lot easier I guess and quicker to be able to decompress the map on the fly, so that seems like a good idea.
Yeah, if your largest metatiles are between 256 and 64 pixels wide/tall, keeping a good number of them in RAM is not such a big deal. You just have to update that RAM as the camera scrolls, by progressively decompressing the map.
Quote:
I was thinking of just the compression scheme that was talked about where it is just the TILE# byte then the REPEAT byte.
That's RLE.
Quote:
Also, if you were making an RPG game, how would you know when to decompress the map and change something before it enters the screen?
Look at the camera's coordinates. When they move a certain number of pixels (usually the dimension of the blocks you keep in RAM) you have to update a row/column of data.
For example, say I'm using 32x32-pixel metatiles to build my map. I then decided to set aside 256 bytes of RAM to represent an area of 16x16 of those blocks, covering a total area of 512x512 pixels. That's an area much larger than the screen, so it should be enough for the "active" map.
Now, to keep my "active map" always updated, I have to change it as the camera moves. To detect if I need a new column of metatiles, I have to detect when the camera completes 32 pixels of movement to the left or to the right. The easiest way to do that is to save its old X coordinate, move it, and EOR both coordinates. Then check bit 5 (since 32 in binary is %100000), if it's 1, the camera crossed a 32-pixel boundary and you need to decode a new column. Check the direction in which the camera moved to know if the new column is at the left or at the right. It works the same way for vertical movements.
It's not mandatory that you update the "active map" every metatile though... Depending on your compression scheme you could update it every 2, 4 or even a whole screen of metatiles, as long as you have at least a screen worth of valid data and enough CPU time to decode larger portions of data.
You'd use the same basic technique for rendering tiles to the name tables. You can detect when the camera has moved 8 or 16 pixels (depends on how fast you scroll and how many tiles you are able to update every frame - 8 pixels is OK for most games, but Sonic for example needs 16) and read the metatiles from your "active map" to get tiles out of it, tiles that you will write to the name tables during VBlank. The source and destination coordinates are always calculated based on the camera coordinates.
Quote:
Maybe a adventure scrolling game isn't a good idea. :/
That's up to you. If the idea isn't clear in your head, you probably shouldn't do it. You shouldn't take my word for it, when I explain solutions like I just did I do it hoping that it will give you ideas, and not that you will try to follow my explanation like some sort of guide, believing that it will work just because I said so.
So if what people here are telling you makes sense, and gives you better ideas on how to implement scrolling, go ahead. If not, go with something simpler, like horizontal scrolling only, which is infinitely simpler than horizontal+vertical.