Author Topic: Tilemapping efficiently  (Read 9172 times)

0 Members and 1 Guest are viewing this topic.

Offline nemo

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1203
  • Rating: +95/-11
    • View Profile
Tilemapping efficiently
« on: June 07, 2010, 12:43:03 pm »
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.


Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55931
  • Rating: +3153/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Tilemapping efficiently
« Reply #1 on: June 07, 2010, 01:43:40 pm »
Instead of doing deltalist(1,2,8,11,12,11,255,255,1) you would do [0102080B0C0BFFFF01]

Offline nemo

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1203
  • Rating: +95/-11
    • View Profile
Re: Tilemapping efficiently
« Reply #2 on: June 07, 2010, 01:50:56 pm »
thank you


Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Tilemapping efficiently
« Reply #3 on: June 07, 2010, 01:53:23 pm »
Don't forget, the executable is the same size regardless, and you can archive your source before compiling to save space.

If you're using half byte tiles though, hex is more convenient since every digit 0-F are individual tiles.
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55931
  • Rating: +3153/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Tilemapping efficiently
« Reply #4 on: June 07, 2010, 01:56:07 pm »
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 x.x). I would keep half bytes for when you are very experienced with Axe, personally.

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Tilemapping efficiently
« Reply #5 on: June 07, 2010, 02:46:12 pm »
If you wanted the compression of half byte, but still wanted the ease of use, you could store your data as half byte, and then decompress it into single byte for ease of use.  (Even i dont use half byte in portal because its so much of a hassle x.x)

Offline jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Tilemapping efficiently
« Reply #6 on: June 07, 2010, 02:56:19 pm »
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?

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Tilemapping efficiently
« Reply #7 on: June 07, 2010, 02:59:48 pm »
How would you store the data tho? Since 37 isnt a full byte (255) you would have to either do some very tricky modular arithmatic to even get the numbers out of memory, or just store them in a byte, which kind of defeats the purpose of using 37 in the first place.

Offline jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Tilemapping efficiently
« Reply #8 on: June 07, 2010, 03:17:24 pm »
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.

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Tilemapping efficiently
« Reply #9 on: June 07, 2010, 03:22:51 pm »
Well no matter what your storage is, you can then decompress it into a matrix buffer so that you are working with simple bytes and not this weird byte thingies.  PortalX uses RLE where up to 16 tiles can be stored in a single byte, and i find that it offers much more compression that tile squeezing.  However its not random access so it has to be decompressed at the start of each level, and stored in byte form.

Offline nemo

  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1203
  • Rating: +95/-11
    • View Profile
Re: Tilemapping efficiently
« Reply #10 on: June 07, 2010, 03:30:22 pm »
Quote
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


Offline jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Tilemapping efficiently
« Reply #11 on: June 07, 2010, 03:31:36 pm »
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.

Of course, has anyone thought of this?:
UDLRbyte, where:
U: Up
D: Down
L: Left
R: Right
byte: ironically, byte is 4 chars long, and nibble is 6.  anyway, this refers to the 4 bit reference for the tile.
This way of storing provides an interesting advantage.  There is no collision detection.  You simply have to look at the reference here.  If there is a 0 for up, and a 1 for down, then that mean you can jump over it heading from the top direction, but not from the bottom.  Kinda like in pokemon.  You could also store other data there if you wanted to.

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Tilemapping efficiently
« Reply #12 on: June 07, 2010, 03:41:17 pm »
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.

Offline jnesselr

  • King Graphmastur
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2270
  • Rating: +81/-20
  • TAO == epic
    • View Profile
Re: Tilemapping efficiently
« Reply #13 on: June 07, 2010, 03:51:00 pm »
Quote
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
Very glad we could help.

Yes, you could decompress it into memory.  That gives you 3 bits extra for data or something.  What could be stored in there?  The first two bits could be configurations of blocked sides.  Like:
00 - You can cross from anywhere.
01 - You can cross from the top
10 - You can cross from the bottom
11 - You can't cross.

You could also do a sort of macro lookup.  There only 8 possibilities with 3 bits, though.  Maybe having the previous idea for borders, and have a 0 or 1 to tell if there is a macro for this tile.  You would have to know what tile location, or where it would end up being in memory though.

What do you think?

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Tilemapping efficiently
« Reply #14 on: June 07, 2010, 03:54:26 pm »
That gives you 3 bits extra for data or something.

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