Hi,

Does someone know how the maps and screens are coded in Metal Gear ?

I'm working on a game with a similar layout, and I came up with this coding :
- The game area within the screen is 192x192
- Each screen is built on 16x16 blocks
- Each block is coded on one byte in the memory

Thus one screen is coded by 144 bytes in memory.

Is this the way Metal Gear was coded ?
Or did they came with a more efficient way of coding screens ?

Well metal gear has a simple method for loading object data,in specific areas of the rom if you change some bytes then different objects are loaded on screen.Each block is indeed one byte.I remember hacking the game years ago and removing the fences and i could get card 4 at once!

If you use openmsx and dump the contents of vram and view it on screen you will see the 16x16 blocks you mentioned,now each of this block corresponds to one byte.and one room for example could be something like this "AAAAAAAAAAAAAAAABBBBBBBBEEEEEERRRRRRRRR"

with A B and R to be different blocks.

I have done many experiments with this game in the past.

There are many ways to store maps. You could bitbust/plet your whole map with 8x8 blocks even. As there is a lot of repeating data, the compression algorithm will get rid of it. Disadvantage is that you need to unpack the whole map in one go.

Another way would be a kind of script language. A single screen with a fence of 32x8 tiles (of 8x8 pixels) could be stored in 5 bytes:
x
y
stamp
width
height

You could even store it in 4 bytes if you combine y and height into 1 byte. If one stamp of a Metal Gear tank is 8x8 tiles, then a width of 16 and height of 8 would place 2 such tanks next to each other. It would be reasonable to assume that 1 screen could be made out of 10 such objects, then it'd be 10x4 = 40 bytes. And those 40 bytes are raw, perhaps a compression algorithm could strip away another 10 bytes. What you need is of course code that builds such a map based on those 4 bytes but that's not a bad thing to do anyway.

I always use the VRAM to store map data. Probably not the best solution but at least it eats no normal RAM.

yeah, after all, why should that bloody RAM contain the map anyway...

Quote:

There are many ways to store maps. You could bitbust/plet your whole map with 8x8 blocks even. As there is a lot of repeating data, the compression algorithm will get rid of it. Disadvantage is that you need to unpack the whole map in one go.

Packing / Unpacking is not the issue ... Of course I can use that trick, but before that I want to develop a simple and efficient method to store screens and maps.

Quote:

Another way would be a kind of script language.

Perhaps, but I feel that my screens are too complicated (no simple fence there) to be efficiently described by a script langage.

My gaming space is made of rooms. The map itself is described by room numbers in all directions. Let's assume R is the current room number and is stored at the A address in RAM. The room to the north is contained in the A+1 address, the room to the east is contained in the A+2 address ... You get the idea. Knowing that I have also rooms up and down, it means I need 6 bytes per room to describe the map.

Then, when a new room is needed on screen, the new R byte calls for a set of 144 bytes (12x12) describing the room screen by its content of 16x16 pixels blocks. There's even the option of having a specific color palette for each room, loaded when the R room is built on screen.

All that coding mean I can have a maximum of 255 rooms (zero meaning there's no room there), which imply 255x144=30680 bytes of room blocks description. The map itself needs a total space of 255x6+1=1531 bytes. I have also to add the necessary block data, which could run all the way to 256 blocks of 128 bytes (SCREEN5), so to a maximum of 256x128=32768 bytes. So I already have here 32768+30680+1531=64979 bytes !

Yeah, I know, I can always have less rooms, or less blocks to build the rooms