Working through compression

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
tokumaru
Posts: 11933
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Sat Mar 08, 2008 8:42 pm

tepples wrote:Another question that few people seem to stop to consider: How big is a pixel in SI units? For example, if an object is 16 pixels tall, how much distance does that represent?
Why do you think this is important? Because of physics formulas perhaps? Anyway, I guess it varies a lot from game to game. A 16x16-pixel block is probably much smaller in "Rescue Rangers" or "Monster in my Pocket" than blocks that are also represented in 16x16 pixels in many other games, right?
Celius wrote:I'm going to look into applying more lookup tables to the method.
If you got the ROM space to spare, this is always good. Most types of lookup tables are only bad choices for NROM games, where each byte is so very precious.

tepples
Posts: 22224
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Sat Mar 08, 2008 9:24 pm

tokumaru wrote:
tepples wrote:How big is a pixel in SI units? For example, if an object is 16 pixels tall, how much distance does that represent?
Why do you think this is important? Because of physics formulas perhaps?
That, and a couple other reasons.
Anyway, I guess it varies a lot from game to game. A 16x16-pixel block is probably much smaller in "Rescue Rangers" or "Monster in my Pocket" than blocks that are also represented in 16x16 pixels in many other games, right?
I understand that the scale can vary from game to game, and it can also vary from scene to scene in one game. For example, Zelda II's overworld is scaled differently from its side-scrolling parts. The indoor areas in that other game with monsters and pockets are scaled differently from the outdoor areas, as is the case in plenty of other RPGs. It's just a good idea to have some sort of sense of scale while you are designing things, so that you know how big your worlds really are.

Example 1: Wikipedia says Sonic is 100 cm tall. This would put 32px = 1 m, meaning tokumaru's engine supports levels up to about 1 km long.

Example 2: In Animal Crossing, an "acre" in outdoor scenes is 16 cells by 16 cells. Google says an acre is 4047 square meters, and this puts the scale very close to 1 cell = 4 m on a side.

My point:
  1. A game is a scale model of an imaginary world. If you know the scale of your maps, level designs might end up more consistent.
  2. If you have game characters talk about units of time in "frames" and units of distance in "pixels" or "screens", that blows holes in the fourth wall.
  3. Most importantly for this topic: if you know the scale of your maps, you can figure out how big you can reasonably expect a map to be, and you can calculate what kind of compression ratio you will need.

User avatar
Bregalad
Posts: 8007
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Sun Mar 09, 2008 2:13 am

Well, scales are often unrealistic. It's very common to see game characters that are as tall as a tree, and sometimes even as tall as a town or only half of the size of a castle (Dragon Warrior, Final Fantasy !)

Also, what compression method to use really depends on how you want the game to be. Celius's platformer seems to really need to work with screens, as the game has been designed that way. All white areas don't have to be encoded as long as the scrolling engine doesn't allow scrolling when a screen isn't present in that direction. In the case where screens always scroll only one direction, this even allow clever switching to horizontal and vertical mirroring so that you can always write big blocks of data to nametables without worriying about a row/column format and without having glitches. However, this won't work if scrolling to both directions is needed at the same time.

Eventually, having bigger maps often also mean bigger metatiles and then, your decompressed map takes less space since the metatiles are enormous, and you only need to keep track of the metatiles, not lower units. After all it doesn't seem that hard to random-acess a RLE map, so yeah, if it's possible to do it without having it to RAM then do it. Personally I like the RAM approach as the map is "modifiable", but I'll admit I've never made code that modify a map like that in my game yet (but I plan to do it). It's also good with object that interact with their background. For example if you want an enemy who is a statue, and when the player approaches it the statue starts to move and attack him. If you do only a sprite approach, when the statue will be scrolled in screen, it will most likely be viewable that it's made of sprites, and the player won't be tricked (especially in my game, where a whole map is scrolled at a time without any care to sprites before it's fully scrolled), so that's not a good approach. However, if you made it BG, and then have the object replace the statue graphics by some other metatile, but then create its own statue sprite, everything will be fine. You then need RAM so that when the player open the menu and close it, you know if you what metatile to draw, that can be a different one than the original when the map was loaded.

User avatar
tokumaru
Posts: 11933
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Sun Mar 09, 2008 10:28 am

Bregalad wrote:For example if you want an enemy who is a statue, and when the player approaches it the statue starts to move and attack him. If you do only a sprite approach, when the statue will be scrolled in screen, it will most likely be viewable that it's made of sprites, and the player won't be tricked (especially in my game, where a whole map is scrolled at a time without any care to sprites before it's fully scrolled), so that's not a good approach. However, if you made it BG, and then have the object replace the statue graphics by some other metatile, but then create its own statue sprite, everything will be fine. You then need RAM so that when the player open the menu and close it, you know if you what metatile to draw, that can be a different one than the original when the map was loaded.
There are different ways to go about this. In my game, background objects are never defined in the level map. They are defined along with all other objects, and they watch the drawing of rows and columns to draw their graphics. To "erase" them I have to read the metatiles from the level map.

But I agree that, in this particular case, it is better to have a copy of what exactly is on screen. Then again, RPGs and platformers are totally different games.

Celius
Posts: 2157
Joined: Sun Jun 05, 2005 2:04 pm
Location: Minneapolis, Minnesota, United States
Contact:

Post by Celius » Sun Mar 09, 2008 12:41 pm

I hadn't really thought about objects that change on the world map. There are a few that actually do. Most of the time, the world map remains the same. I could probably do something where I draw an object's final state on the map, and then I can draw over it if it's supposed to appear different. But I just thought of an idea, I don't know if it's good or not. It could end up saving me a lot of time. So for the RPG map, you know I have to start out at the beginning of a row and decompress my way to the end. This felt to me like a nice/clean/professional way to do it. However, I could save myself A LOT of time by keeping where the pointers are when they stop decompressing in each row on screen. This might be a little complicated, but I'm pretty sure that in the end, it will save me a lot of time.

As for the platformer, I'm still a little unsure about the exact level format. I don't know if this sounds weird or not, but I want to still make everything have 16-bit coordinates as if the whole map were one big level. So each room doesn't have a 0,0 coordinate. Since the map is 64x60 screens, I don't see why I should seperate them. But I was thinking of also still keeping all the screen definitions together, and not organize them by room. Just because if I were to define the rooms all in blocks, the "squares" drawn around each room would overlap, which means I'd be wasting space.

I'll see about applying the idea I had about saving pointer status to my RPG map. It really could save me a lot of time.

Post Reply