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

That gives you 3 bits extra for data or something.

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

One thing i would recommend from experience is to consider using 4x4 tiles, it makes collision SO much faster, as you only have to divide by 4 instead of 5.

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.

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.

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 )

I tried '7IN INTO CM' and it gave a syntax error i also tried '7 IN INTO CM' and '7 In Into Cm' and '7In Into Cm' and they all gave syntax errors and when i press goto it just goes to the program