MaxCoderz

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

_________________
visit www.PRGMERz.tk
Lookng For new Members.

Yes, in that case, you wont needs the interrupt and just put the grayscale outputting method in a loop. Would be faster, too.

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:

.db 0, 0, 0, 0 ;tile 0
.db 6, 7, 7, 6 ;tile 1 grass with flowers

When drawing the map, the tile# of the big tile is looked up in convert.asm, and the looked-up smaller 8x8 tiles are drawn on screen.

A submap is the part of the complete map where Link is right now, the "currently walkable area". When entering a submap, a part of the complete map is scanned and copied to form the submap.

SupermapX and supermapY are the coordinates of the current submap on the complete map. So (0,0) means the upper-left submap on the complete map, and (1,0) means the submap to the right of it.

I hope that pretty much answers your questions. Feel free to ask more.

Well i just took out the 11 pg source print out. I ll try figure it out.
And do u mind if i use any part of your code in my program. I ll give u credit for whatever i use
Thx for the help

You're actually printing out the source? Nice

About my above post: I made a little mistake, I wrote:
"The submap is used..."
Which should be
"The file "convert.asm" is used..."
I have edited it.

No, I dont mind if you use any source code. You're free to use it for any purpose you like.

Why exactly do u use a submap though. u could have 16X16 sprites or just 8X8
Is it for compression or something

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.

but does using compresion (submaps) reduce the speed of the game. I m especially worried because the prgm is in GS

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.

I like the Zelda source, it is very well written.

You are the MASTER Duck!

*Worships*

_________________
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."

*going to search for Zelda source*
just one question from this newbie(me), if your sprite is like this

sprites:
.db 0,0
.db 0,1
;spr2
.db 0,1
.db 0,0

and the map is like
map:
.db 0,0,0
.db 0,0,1
you know the submap is in the 1 area, but would you just go like map(2,3) to draw it?

_________________
Life is getting better.

Well i made a 8by8 scroll routine but i cant figure out why the map display screws up can someone help

heres the link for the code
http://l-man.calcpages.com/forum/index. ... owtopic=71


(Worship) X 100