Duck wrote:Thats correct. And I can understand that people want optimized games thus want to write their own routines, and for that purpose one needs to understand the grayscale principles and GPP's implementation. The paper would serve these needs.
yeah it would be interesting to know how to do youre own grayscale routines, especially if youre game isnt going to be a GS game but just output a GS pic or something
well good luck duck
hey maybe u should release a zelda tutorial. Its the only Gs open source rpg right now. I was reading through the source i couldnt really understand much. The map routine is slightly modified. Well it would be cool if you could tell me what the
- submaps are
- what does charcyle, supermapx and all the variable stand for
- and is the sprite size 8X8
Would be cool if u could explain the concept of the submaps
The big 16x16 tiles in the game are actually composed of four 8*8 tiles. The tilemap stores the 'matrix' of the big tiles.
The file "convert.asm" is used to look up which four 8x8 tiles the big tiles are composed of.
So if '6' is the tile# of a 8x8 grass tile, and '7' is the tile# of a flower tile, the 'conversion data' of the big 16*16 tile with grass and flowers with tile# '1' would be stored in 'convert.asm' as:
Using only 16x16 tiles would be extremely redundant. If i used complete 16x16 tiles, the (graphical) tileset would take a huge amount of space! Remember that a single 16x16 sprite takes 2*2*16=64 bytes of data! An 8x8 sprite takes 'only' 16 bytes of data. The original Gameboy Zelda also uses small 8x8 tiles to form complete 16x16 tiles. Many 8x8 tiles are used throughout many different 16x16 tiles, like grass or sand or wall etc, or used multiple times in the same 16x16 tile.
This way, we got the best of two worlds: small tilemap size because we store them as 16x16 tiles; and small tileset (sprite) size because they graphical tile data is stored as combining 8x8 sprites that are each used mutiple times.
So when Link enters a submap (which is actually one screen in the Gameboy Zelda), the 16x16 tiles are 'decompressed' into smaller 8x8 tiles into the buffer 'submap'. Again, this is exactly the way the original Zelda did it. Corbin also uses this; funny enough in that time I didnt know Zelda used it too.
It could be even more space-efficient though. Why restrict the size of combined tiles to 16x16? It would be nice if they could be of variable size... 8x16, 16x8, 64x32.. you name it. When decompressing (entering a submap), the height+width+contents of each big tile could be looked up and 'decomposed' to small 8x8 units. (Like decomposing of 16x16 tile to 8x8 tiles in Zelda). The good thing of this is that multi-tile structures that are used multiple times in a game would only have to be stored once: as a very big combined tile. Applying this to every reocurring structure like grass field, forests, parts of houses etc, this is the ultimate way of reducing tilemap size.
This has never been implemented though, but I would like to make a level editor with this technique once.
This Zelda game is everything except optimized for speed, its written to be structured. Yes, it would be plenty faster to drawn 1 big 16x16 sprite instead of 4 8x8 sprites. Also, the game redraws the complete tilemap when scrolling. This could be much faster by drawing the map to a buffer and updating this buffer every time you scroll. There may be even faster methods. Plenty of room for speed optimizations.