Author Topic: Tilemapping efficiently (Read 11654 times)

jnesselr · « **Reply #15 on:** June 07, 2010, 03:58:53 pm »

Well, if you use the 5 bit method, when you decompress it into individual bytes for easer, faster reading, you have 3 bits left over. They would be tile specific. For example, you can walk on ground, but not on rock.

Builderboy · « **Reply #16 on:** June 07, 2010, 04:01:47 pm »

Ah i see. That would work

So you would have a byte per tile, and instead of having 256 different tiles, you would have 32 different tiles with 8 different characteristics.

jnesselr · « **Reply #17 on:** June 07, 2010, 04:05:58 pm »

Yes, which saves space in your actual program. Except, I want to write a computer compiler for axe. Sort of like a higher level programming language to axe source code. I'm thinking that there will be a way to know what byte your tile is in when decompressed, so you could have a subroutine, that if the tile had a macro, would call the macro from the subroutine. Just an idea, though.

TIfanx1999 · « **Reply #18 on:** June 07, 2010, 04:11:16 pm »

Quote from: Builderboy 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.

I'm curious as to how you could fit 16 tiles in one byte, that sounds like some ridonkulous compression magic. Also, what size tiles are you using?

Builderboy · « **Reply #19 on:** June 07, 2010, 04:19:14 pm »

Yeah that might be really cool

I think i am going to stick with my RLE though, as it provides a lot more compression, even if it does only allow 16 tiles (plenty for what i need)

And as for RLE, its a maximum of 16 tiles, it could be as low as one. The way it works is this, say you have a map

0000000 0-----0 0-----0 0000000

which looks like this in memory

00000000-----00---00000000

A pretty simple map with 28 tiles, but there is a lot of repetition, so lets compress it into this

805-205-80
which might look like gibberish, but here is what it means, first take the first 2 numbers, 8 and 0. What it means is that there are 8 of the 0 character at the beginning of the tilemap. The second part looks like 5-, which says that it is followed by 5 of the - characters. You do this for the entire map and you end up with some good compression, depending on the map design of course. I use 1 byte per grouping, which means i have 1 byte to say what the tile type is, and what the length is. I use 1 half of the byte for each, so i can have a maximum length of 16 tiles, with a max of 16 different tiles. You can push these values around a bit if you have less or more tiles you want to work with, but it gets worse and worse compression the shorter you make the length.

So at the worst, this compression gives a single byte per tile

jsj795 · « **Reply #20 on:** June 07, 2010, 04:56:55 pm »

How fast is the decompression tho? I don't think I can use RLE for mine, since mine will be more than 16 tiles, but graphmastur's seems interesting, because I need different tile sprites for different orientation and property. Except it seems pretty hard to implement

Builderboy · « **Reply #21 on:** June 07, 2010, 05:00:07 pm »

Decompression is very fast in Axe with the help of the Fill() command, and in Basic it can be done while drawing the map. Decompression for Graphmastur's would also be speedy, although maybe less so since you would be doing division and modular arithmatic on every tile. In Axe it doesn't matter that much i wouldn't think, the differences would be very small

Quigibo · « **Reply #22 on:** June 07, 2010, 06:01:27 pm »

RLE is great for decompressing. BUT, if you have a very large tile map, say its 60x40 for example that needs to be scrolled through, that's 2400 bytes. You can use half byte compression to only take up 1200 bytes and maybe half-byte RLE would be 500 bytes in this example. The fact is, the map is too large to decompress anywhere in RAM unless you tack on extra size to the program. So you're better off reading directly from the map in the program data. When you read off that map, it needs to be fast so RLE isn't going to be possible.

jsj795 · « **Reply #23 on:** June 07, 2010, 06:15:38 pm »

I guess RLE is made for Portal X since it doesn't require scrolling

Builderboy · « **Reply #24 on:** June 07, 2010, 06:16:42 pm »

Exactly ^^ it fits all of my needs perfectly

DJ Omnimaga · « **Reply #25 on:** June 08, 2010, 12:45:26 am »

Yeah, personally I always felt compression is easier for when you do not need scrolling (especially smooth scrolling). It is possible to have smooth scrolling in an half-byte compressed tilemap, I am certain, but I have yet to figure out how to do it.

Author Topic: Tilemapping efficiently (Read 11654 times)

jnesselr

Re: Tilemapping efficiently

Builderboy

Re: Tilemapping efficiently

jnesselr

Re: Tilemapping efficiently

TIfanx1999

Re: Tilemapping efficiently

Builderboy

Re: Tilemapping efficiently

jsj795

Re: Tilemapping efficiently

Builderboy

Re: Tilemapping efficiently

Quigibo

Re: Tilemapping efficiently

jsj795

Re: Tilemapping efficiently

Builderboy

Re: Tilemapping efficiently

DJ Omnimaga

Re: Tilemapping efficiently