Oh, I see. Well my maps don't cleanly divide into 12x8 pieces, so I don't know how to answer your question that way.
To answer in terms of bytes, I have currently about 42kb of map to use. I am thinking about going back to nibbles to decrease the amount of user RAM and the amount of space the maps take up, so you can say 42000 bytes = 84000 squares then. However, depending on how large I decide to make the game, I could easily add or remove map data, so you could expect the final game to use anywhere from only 22kb to 66kb (I don't think I will need more than 66 kb...with nibbles that is 132000 squares O_O)

It is completely uncompressed so it's just an array...like
[7777777777777777
0211111111111110
0200000000000000
0200000000000000
0000000000000000
00A0000000000000
00A0000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000030000000
0000000000000000]

or something similar where each nibble/hex digit corresponds to a tile.

(0,1,2,3,4 are all walkable tiles, the rest are solid tiles)

The example map posted would be mainly empty, with a random door towards the bottom, some rocks in the upper left corner, some trees on the top row, and some other random tiles towards the mid left

As for compression, I'd favor routines that are smaller in size and compress less over those that are larger but compress more

Would most maps be filled with mainly one tile like this?

---

EDIT: How about RLE? I made a program (ASHCOSRC) to compress nibble tilemaps with 4-bit RLE for you To use it, change the width and height variables present at the start of the source program to what you want and put the hex for the uncompressed tilemap under GDB0M. Then run the program and the hex for the compressed map will be put into Str1. Your example tilemap compressed very well, from 120 bytes to 24.

And of course, what compression algorithm is any good without the proper decompression algorithm? ASHDESRC is the decompression program. The part of it that is the actual algorithm, which is all you would want, is the code under the tag ".DECOMPRESSION" excluding the Disp "DECOMPRESSING..." line. The decompression algorithm is only 113 103 bytes.

F70002C11002E002F0F00AE00AF0F0F0F0F0F0F04003F060
I hope I made it straightforward and user-friendly enough that you can simply stick all your maps into ASHCOSRC one at a time and easily retrieve the compressed map data. If you have any questions, feel free to ask.

EDIT 2: Uploaded a new, further optimized decompression program. The algorithm is now 103 bytes instead of 113.

...That is very sexy Runer.

Thanks

Ok, update Thanksgiving is coming up which means that I'm going to be getting a lot of time to work on this
Updates

• Merged map engine and battle engine into an app that is only 13kb
• Ingame menu works
• Saving and loading also works
• Map engine is faster and less flickery
• Free RAM requirement dropped to 6288 bytes
• Character can change direction he is facing without moving

Planned updates for this weekend:

• Make character sprite 12x24 to make it look better and improve animations (he will bob up and down with each step )
• Battle transitions!!!! (looking at E:SoR for help on this)
• Improve status screen to display current skills and give option to unequip equipment
• Move status screen program to external appvar to test the copy-from-appvar-to-program-and-then-run-it-from-app method of circumventing the code limit
• Fix tiles so they look better (have the dunes pattern 'behind' them to make it look more realistic)
• Shops/inns

Also behold: the corrupted save file

The glitches are actually caused by the loading of a nonexistent save file; it doesn't yet check to see if the save file exists or not
The random tiles towards the top of the map look like random pieces of memory, and they are, due to the fact that my mapping engine (to increase speed) doesn't bother checking if you're walking/viewing outside the map

The glitches are actually caused by the loading of a nonexistent save file; it doesn't yet check to see if the save file exists or not
The random tiles towards the top of the map look like random pieces of memory, and they are, due to the fact that my mapping engine (to increase speed) doesn't bother checking if you're walking/viewing outside the map

Ah ok. Would adding checking for map boundaries slow down the engine a lot? If it does, I generally just do like FF1 through 4 and keep the character in the middle of the map and simply add a few more tiles at the top of the map.

Ah ok. Personally I'm fine with the char staying in the center. It is a bit more realistic and it's more old-skool since most old RPGs worked like this. The only problem is that depending of the map design, sometimes you don't know when you're about to exit an area like a forest.

Also sorry about the mem clear, I'm glad you had a recent backup, though.