Tiled (TMX) Loader

[BurningHand]

Hi there,

I am newly experimenting with libgdx and have an "immediate" (used very loosely) need for a Tiled (TMX) loader. I have started making one and just want to see if anybody has any insight. For simplicity sake, I think I am going to enforce a single tileset per layer, so that I don't have to muck around with managing and binding textures mid-layer.

I am thinking that this is just a matter of flood-filling a mesh with the grid and u/v coordinates and then doing some basic culling based on the camera position. It looks like there is a lot of useful info on how to do this with libgdx on the "noob questions" thread. I am assuming that the TerrainTest sample is a good place to start with this?

[mzechner]

You intuition is correct. I'd love to implement that right away but i currently lack the time to do so. The terrain test example is suitable as an initial pointer to the solution. However, the terrain test uses a single texture coordinate per vertex (actually there are no texture coordinates, it's just random colors for now...). So it's not tiled. I'd do the following:

- for each layer: split up the tiles in the layer into sub grids of a small size, e.g. 8x8 or 16x16 tiles. Keeping them in a single mesh and just indexing into it with an offset might be beneficial. Whether to use vertex indexing for more performance needs to be benchmarked. I assume it has more overhead than going with simple triangle lists (note: strips are out of the window as each vertex is unique in a tile map).
- perform culling for each layers sub-grid based on a rectangle in the tile maps coordinate system. I say this cause there might be cases were you might want to rotate your tilemap on screen so you wouldn't have an axis aligned viewport in tile map space. I'd just take the rotate viewport and take the min/max in the tile map space. It will render a little more than needed but that should be ok.

I know that's pretty high-level and i wished i could implement it. Maybe i find some time to squeeze that in this week. No promises though. I suggest starting on your own solution just to meet potential deadlines

[BurningHand]

Awesome, thanks for the insight. Who knows, maybe I'll get something usable done that can be included (in whole or part) in libgdx. I'll definitely keep you up to date with my progress. You may beat me to it anyway lol.

[mzechner]

I'd love to integrate contribution. just make it generic enough

[aksarfevad]

The beginnings of my attempt at a TMX loader: http://www.filedropper.com/myrpg . It is fairly generic, and probably has 90% of the features people would want. I figured it was complete enough to post a "beta". Hopefully I will update this to do more soon. It could really be improved if I could figure out a simple way to put multiple images into a single texture while still keeping it managed. Don't mind the random stuff in the main part of the project, I didn't clean it up at all. Also, I'm not sure if I have set up the projects correctly as I fought with Eclipse for a while to get it loaded. Let me know what you think and if you have any suggestions or comments.

Features:
-Loads Base64 gzip TMX format (only this format for now)
-Loads multiple layers
-Create a single triangle strip (class TileMapLayerMesh) for all tiles (note: I used some interesting tricks with the alignment of the triangles and some degenerate triangles to achieve this)

Limitations (some I will probably fix/add later):
-Will not load objects
-TileMapLayerMesh only allows for one tileset per layer
-Probably many other limitations not listed here
-Only supports Orthogonal maps
-Not loading all map properties (will be simple to add)

[mzechner]

Oi, that sounds great. I didn't look at the code yet but the use of triangle strips with degenerate triangles seems interesting. That works fine for terrain meshes as a vertex with the same attributes is shared by 4 triangles in general. In case of a tile map i'm not exactly sure how that might work as a corner vertex has different texture coordinates depending on which tile it belongs to.

Concerning the image packing problem: you could use Nate's image packer (see blog) which will generate a nice and dandy sprite sheet. When you load the tiled map don't resolve each separate image but reference the regions in the sprite sheet.

Keep up the good work, i'll try to check it out asap.

[consiliens]

Have you looked at any of the existing TMX loaders, such as Slick 2D's BSD licensed TiledMap? The XML parsing should be similar in Android.

There's also cocos2d-android which seems to also support tiled maps. An updated fork of cocos2d-android is on github.

[BurningHand]

My main concern with this specific implementation is that it doesn't support partial rendering (from my brief lookover). In most cases, the tiled map is going to be considerably larger than the screen. In those cases, sending the entire mesh to be rendered is overkill when you only want a very small portion rendered.

I had already built a parser, but haven't gotten to the mesh piece yet. Might look at the mentioned implementations to see what they do, otherwise Replica Island has a pretty decent partial grid rendering mechanism that would probably be pretty easy to port over to a Mesh.

[aksarfevad]

Mario: Thanks for the tip on the sprite packer. I will look into using this. The way I got triangle meshes to work is to draw points over each other. The vertices really take up about the same amount of space as though they were separate meshes. They are arranged like this:

Code: Select all

2  4,5  6
_________
|\  |  /|
| \ | / |
|__\|/__|
1  3,7  8


Since triangle meshes are drawn as (D = degenerate triangle):
1,2,3 -> 3,2,4 -> 3,4,5 (D) -> 5,4,6 (D) -> 5,6,7 -> 7,6,8 . . .
the triangles remain drawn in a clockwise direction all the time. I disabled GL_CULL_FACE but only because I noticed that it was disabled in SpriteBatch. I will also be performance testing this myself though.

Consiliens: Slick 2D's implementation appears to be similar to mine. It looks a little overcomplicated as well. I was worried about using arraylists as that does to store the data. There are so many warnings against using them on android. I'd rather implement my own code then force fit someone else's code into gdx.

BurningHand: As for the partial rendering, I was a little worried about it myself. From what I hear, OpenGL ES does a good job of not drawing any unseen points around the edges of the screen. I was going to test this though. To remove this limitation what I would do is index the tile vertices and then use render(ShaderProgram shader, int primitiveType, int offset, int count) to draw just a section at a time.

The actual rendering of the maps is not my focus at this point. As far as I'm concerned, render it any way you see fit but for what I am making what I have works well so far. I'm keeping the rendering class separated well enough that you don't need to use it if you don't like how it is implemented.

Again, this is fairly early and I haven't done too much in the way of optimizing.

[BurningHand]

I actually had a test yesterday where I plopped 1000 quads into a world far larger than the screen. Without manually culling the non-visible quads it resulted in an unusable frame-rate. I'd assume the same from a Argentina tile map, but can't confirm yet.