Map format experiment


By rsg167 25 Sep 2015 16:42

Member · 37 comments

Hello. I'm experimenting and writing a map compiler. It will take as input a Tiled map, and it will emit as output in a map format crafted specifically for Tuxemon's needs. My experiment has the following goals.

  • Make it possible to shed pytmx as a game dependency.
  • Simplify map code.
  • Speed up loading.

The current map loader (link) has to calculate collision information itself. I hope to move this calculation to the compiler, so that the game doesn't have to perform this vital function.

I will be doing this work on the "compiled_maps" branch of my repository. … piled_maps


By rsg167 29 Sep 2015 19:36

Member · 37 comments

This is a progress report on my experiment. I am designing a map format specification.

First, a map file will have the header:

Bytes   Type    Name
00-01   16-bit  Map width
02-03   16-bit  Map height

Then, a total of width*height tile structures. Each structure will look like:

Bytes   Type    Name
00      8-bit   Special flags
01-02   16-bit  Image number of bottom tile
03-04   16-bit  Image number of middle tile
05-06   16-bit  Image number of top tile

I have only specified 5 special flags. They are:

Flag    Description
0x01    Can't enter the tile from the NORTH
0x02    Can't enter the tile from the EAST
0x04    Can't enter the tile from the SOUTH
0x08    Can't enter the tile from the WEST
0x10    Only swimmers can enter tile

Collision information is stored in flags 0x01, 0x02, 0x04, and 0x08. Both polyline and rectangle collisions can be easily compiled into this format. I haven't considered the problem of loading correct tileset images, though.

Even at this point, this format would requires less computation for the game to load it. The main reason is that the collision information from the Tiled map has been compiled into a useful form.

I have not yet implemented it in my repository, but I hope to soon.

EDIT: Also, remember this is just an experiment. I don't expect this to be included in Tuxemon master repository because it adds an extra mental step for the user to take: compiling their maps.

Last edited by rsg167 (29 Sep 2015 19:37)


By ShadowApex 30 Sep 2015 05:22

Lead Developer · 374 comments

Very nice. Let me know if you do any kind of performance benchmarks that show improved performance on the compiled side. Another thing we could try and do is pre-load some of the graphics for other maps. The only downside to pre-loading is it will consume extra memory by holding the other tilesets and sprites in memory.


By rsg167 30 Sep 2015 12:56

Member · 37 comments

Honestly the graphics are so small that I think preloading them would be a good idea, even on Android phones. I don't know Android's memory capacity, though.

We could load all tilesets at game startup. If we did, then this experimental map format would have access to every tile in the game. It would also eliminate a lot of the harddisk I/O that occurs when teleporting.

Last edited by rsg167 (30 Sep 2015 13:15)


By ShadowApex 30 Sep 2015 21:49

Lead Developer · 374 comments

I was previously toying with the idea of pre-loading all the resources on start up. It still needs some work to convert everything over, but I do have some functions in core.prepare that are commented out at the moment: … Let me know how your experiments go!