does anyone know what routine is best for tilemapping? i only need 8 or so different tiles. builderboy's method seems pretty good, but i was wondering if there's a more efficient way to manage a tilemap? also, size plays a factor. i'd rather not use
deltalist(_tilemap data_)->GDB1
as that takes up a lot of size.

thank you

True, you can fit about 100 12x8 maps in 4200 bytes. You need some sort of special routine for collision detection and displaying the tilemap, though (which I pretty much failed on ). I would keep half bytes for when you are very experienced with Axe, personally.

I usually store the data as half-bytes, and then decompress it as two individual bytes for use.  Not that hard to do if you understand the math involved in mod and then dividing by 16 for the two parts.

Any time I have problems with a concept in another base, I always try to think of it in base 10.  Say I had the number 98.  If I were to do 98 mod 10, it would give me 8.  If I were to do 98/10, and because Axe doesn't keep decimals, I get 9.  Those are the two parts.  If axe supported base 37, we could do up to 37 different tiles with 0-9, a-z, and theta.  You would just mod 37 and store that, then divide by 37, and store that.

Can we get axe to support base 37?

True, I guess.  I didn't think about it all being in bytes and bits.  I guess you could do 32, and have it be 5 bits.  That would mean tiles would have to be 8 chars long for 5 bits a piece = 40 bits, or 5 bytes.  To do a row of twelve...  Yeah, that won't work.  You would have an extra 4 bits.  I guess you could use that for something interesting.  Actually, if you have another byte at the end of that, you could have twelve bits extra.  Possibly useful for collision detection.

So if all of my math adds up, thats 9 bytes.  Can anyone confirm my math?  The programming code to do this would be confusing, though.  VERY confusing.  You would basically have to have a counter location for the bits.  This could possibly be slow for RPGs though.  Still, for a game with many tiles, and not smooth scrolling, I believe it's possible.  Not insanely fast, but possible.  You would just have to figure out how to isolate a single bit, so it's possible.  It is not, however, possible for me to stop using the word 'possible'.

In the meantime, we could just convert the data by hand into bytes.

Say I had the number 98.  If I were to do 98 mod 10, it would give me 8.  If I were to do 98/10, and because Axe doesn't keep decimals, I get 9.  Those are the two parts.

this makes an astounding amount of sense to me. NOW i get why in the tutorial for tile-mapping you had to ^16 and /16. thank you! however, in my game i think i'll work on the physics of it and then when quigibo adds tile-mapping support i'll work on the maps. i'm still messing around with this concept however. this thread has been helpful

That could be done, but in this case, it loses the biggest advantage which is more tiles.  If you have to de-compress it, this doubly defeats your program, because instead of saving those bytes, you have to make a large enough buffer inside your program in order to contain all of the bytes.  Unless you absolutely needed those 16 extra tiles, it doesn't seem to be worth it.

True, the disadvantage to decompressing means that you have to have 2 copies of the map, one thats in your program and one that is in memory.  But say you used L1 to store your map buffer, you could have over 700 tiles in your map matrix with no detriment to your program size, it only includes the compressed data, which is significantly smaller.

That gives you 3 bits extra for data or something.

Hmmm? Now im confused, where are these 4 bits coming from?