mhmm interesting. I would like to see it in action in a program. I wonder how fast is it? It would be useful for extremly large maps with large areas filled with the same tile over and over

Oh wait! I remember now. There have been just so many people joining in the past few months and active users that I have an hard time remembering who's working on what Axe project anymore, now

Yeah I guessed that scrolling may be a bit overkill. I heard half-byte compression with scrolling required a 15 MHz calc to get a speed similar to my ball game. Often, decompressing the entire map will be necessary, but then, what if the maps are like 16 KB each?

Could you explain what did I said wrong and why would RLE compression would not be for me? I am not sure what you imply by that.

Well maybe 16 KB was a bit overkill as an example. Let's say 5-6 KB. The game would most likely require the entire remainder of the calc RAM for the uncompressing.

If it's slow, I think it may be best to keep RLE for stuff that requires no constant refreshing of the map during gameplay.

Yeah, I guess RLE is out of the question, then , especially when collision detection needs to be added.

There actually is a way to decompress RLE on the fly for gigantic maps.  It's not as efficient as the original RLE, but it allows random access (well random-er at least) to the data in the structure.  Its a little complicated, but here is what I am thinking:

First of all, for this to be worth it, each row has to save more than 2 bytes on average, or 4 tiles if you're using this as an alternative to half byte encoding.  The way this works, is you only compress each row or column with RLE instead of the entire data.  You then keep a list of pointers that each point to the individual rows of the data.  The rows themselves are small compared to the whole thing so they can be decompressed on the fly.

Here are some phony numbers:
Maps size: 100x100
Tiles: 10,000
Half Byte compression size: 5,000 bytes
Each row given RLE compression: 3,000 bytes
List of pointers: 200 bytes
Combined total size: 3,200 bytes

Average bytes in a row: 30
Average worst case number of operations to get to intended data: 30
^ This is definitely fast enough for on the fly decompression.

This is valid syntax when defined in this order:

[RLE row 1]->Str0
[RLE row 2]->Str1
[RLE row 3]->Str2
...
[RLE row 100]->Str99
{Str0^r,Str1^r,...,Str99^r}->GDB1


Unfortunately, that list already uses 100 out of the 150 names you're allowed so it might be better to keep track of the cumulative size and use Str0+Offset so that you're only using one name.

RLE compression. compresses as the first half-byte is the frequency, and the second is the tile number. this routine exports the data as a hex string in Str1.

.Uncompressed (24 bytes. each pair is a byte.)
[010101010101
[010303000001
[010200000201
[010101010101
.Compressed (8 bytes. each pair is a byte.)
[7123202112201271->GDB1

.ROUTINE
[010101010101->GDB1
[010303000001
[010200000201
[010101010101
"0123456789ABCDEF"->Str1
"Str1"->Str2
GetCalc(Str2,16)->M    .16 is the size because our compressed map is 8 bytes, which is 16 half-bytes.
0->C->D
For(G,0,23)    .23 is the size of the map minus one.
If {GDB1+G}->A={GDB1+G+1} and (C!=14)  . "!=" is the does not equal sign
C+1->C
Else
{Str1+C+1}->{M+D}
{Str1+A}->{M+D+1}
D+2->D
0->C
End
End