Advanced Tiled Loader - No longer maintained

[szensk]

Also, could you tell me how the tiles are loaded into memory -- that is... are they individual images, or is it like a sprite sheet/ tile sheet? (In other words is a tileset in the loader a table of individual images, or one image that each of the tiles are taken from) -- if this makes any sense?

Each tile-set has it's own source image. In order to access the individual tiles ATL generates a set of quads (see:love.graphics.newQuad).

Is there a way you could implement dynamic map loading?

Have you considered splitting up the map into smaller maps and loading the next map as you reach the end of the current map? This would allow you to distribute the loading over time.

[Uhfgood]

Also, could you tell me how the tiles are loaded into memory -- that is... are they individual images, or is it like a sprite sheet/ tile sheet? (In other words is a tileset in the loader a table of individual images, or one image that each of the tiles are taken from) -- if this makes any sense?

Each tile-set has it's own source image. In order to access the individual tiles ATL generates a set of quads (see:love.graphics.newQuad).

szensk - The reason I asked about this is earlier I was asking about how to reskin a map and Kadoba gave some sample code, but it made me think that the table of tiles were individual images, rather than all coming from the same source image (like in the actual tmx file itself).

Is there a way you could implement dynamic map loading?

Have you considered splitting up the map into smaller maps and loading the next map as you reach the end of the current map? This would allow you to distribute the loading over time.

I guess that's one approach... an awful lot of work. Also more trouble when I may have multiple layers for parallaxing (as I remember it, Kadoba added some sort of offset value). In any case I'll keep it in mind.

I also have another question, and that's the auto-draw-range stuff... A bigger map is starting to affect my rendering speed, which makes me think I haven't implemented the draw range stuff correctly. So could someone tell me how to properly do the draw range stuff?

[Uhfgood]

I got the draw range stuff sorted, it's working normally. I'm thinking that with bigger maps that it takes longer to index into the map. I do a lot of reading tile properties and processing and stuff, so as the size of the map grows the longer it takes. I'm not really sure what to do about this, if that is the case.

[Kadoba]

The rendering of the map shouldn't increase with the size, although currently multiple layers will slow it down considerably. The load times are slow because the tmx file has to first be translated into lua tables, then uncompressed, then processed into ATL objects. All of this is done in pure lua.

If you are using very small tiles with a considerably large map then you are going to get quite a bit of slowdown on the loading, especially if you have several layers. One thing you can try to do to speed up the loading is disable compression and save the map as csv. You should also be able to load maps in the background using coroutines. I'm working on the next version of ATL which will improve the rendering time of multiple layers and give some faster loading choices.

To answer your other questions: The tileset images are loaded once and cached. Dymanic loading isn't possible with a single tmx file.

[Uhfgood]

Thanks for replying Kadoba. Right now I'm not really that concerned with how long it takes to initially load a map. However with a large map my frame-rate seems to drop considerably. The draw range stuff appears to be working fine (as I can set the draw range to be smaller than the window, but it will still slow down frame rate) -- I am thinking the slow down isn't because of actual rendering. So it must be how I'm accessing it or something.

Let me upload the love file. Make sure you're on a system where you can turn ON vsync (that is, my laptop has an integrated intel chip, and it's vsync is always off, but my desktop is just a geforce 8600 gt) -- with vsync on, the framerate will fluctuate between 60 (when doing nothing) to the low-mid 40's when going up and down slopes.

FFEv1_0.love

(67.76 KiB) Downloaded 193 times

[Kadoba]

60-40 fps sounds normal for vsync assuming the refresh rate on your monitor is 60Hz. Do you understand how vsync works?

[Uhfgood]

60-40 fps sounds normal for vsync assuming the refresh rate on your monitor is 60Hz. Do you understand how vsync works?

I understand perfectly how vsync works.

My game shouldn't dip below 60fps however. It only does this with huge tiled maps.

Another interesting thing is I am using this little profiler - viewtopic.php?f=3&t=9387

What it's showing me is that the ATL is taking about 50% of the time in drawing. I'm not really sure why. I would have thought it was only drawing in the draw range (which is essentially the screen) -- So it shouldn't be taking a whole lot of time. There's a possibility you wrote a proper way to render the map that doesn't take that much time and I'm just not using it correctly.

I do have autoDrawRange set and I did set the spritebatch property on the map to true.

The only reason I said to make sure you can run the program with vsync on is because when it's turned off and the card is able to go all out it's usually on the order of 700-900 fps -- Which wouldn't really show me where any slow down was. With vsync on, dipping below 60fps is showing me there's a problem and a slow down.

At this stage any slow down that might be caused by my code isn't as important since it it's not bearing the brunt of the processing time.

Would you mind looking at the drawing code to see if I'm drawing with the ATL properly?

[Kadoba]

I wrote my last post in a hurry and I realize I may have come off a little condescending which wasn't my intention so I apologize.

Yes you're using the draw range correctly and it's only drawing what you see on the screen. I think the slowdown is due to the way ATL uses spritebatches. ATL will re-update the spritebatch every time the range of the displayed tiles change, so if the screen is moving at a very fast rate then the sprite batch data is constantly updating which is probably why you get the slowdown.

I'm changing rendering in the next version. Instead of having one sprite batch that updates automatically, it will section the entire map into separate sprite batches that will not update automatically. Only the spritebatches that are viewable will be drawn. This should solve both the multiple layer issue and yours as well. It does introduce some other problems which I'm trying to iron out before I finalize it.

I'm also working on support for lua exported maps and possibly ones generated with tmx2lua. This should improve the loading time for those who want to use it.

[Uhfgood]

Cool. Thanks for replying Kadoba

p.s. -- Could I also get you to take a look at how you handle flipped tiles. It looks like you create a table of tiles that are flipped. It does cause me to have to index into that table separately. Could you integrate flipped tile data into the actual tile map array/table? So that way I could simply check the tile I've already grabbed. For instance tile = map("layer")(x, y); -- then I could simply do if( tile.isFlipped )then -- do something here end; When I looked at the output of the profiler it was calling the IsFlipped function quite a bit because I have to check the flipped tiles table. -- Not a big deal but maybe you could think about it

[Kadoba]

All tiles of the same type share the same data so I can't really do that. I might have overlooked it but I'm not finding an isFlipped function unless you are talking about these functions in your code:

Code: Select all

function IsMapLayerTileFlippedHorz( mapLayer, x, y )
--
	local flipped = false;
	local flipX = nil;
	local flippedTile = mapLayer._flippedTiles(x,y);
	if ( flippedTile ) then
		flipX = flippedTile >= 4 and -1 or 1;
		if ( flipX < 0 ) then flipped = true; else flipped = false; end;
	end;
	return( flipped );
--
end;

function IsMapLayerTileFlippedVert( mapLayer, x, y )
--
	local flipped = false;
	local flipY = nil;
	local flippedTile = mapLayer._flippedTiles( x, y );
	if ( flippedTile ) then
		flipY = (flippedTile % 4) >= 2 and -1 or 1;
		if ( flipY < 0 ) then flipped = true; else flipped = false; end;
	end;
	return( flipped );
--
end;

You can make these faster and condense them down to one line if you want:

Code: Select all

function IsMapLayerTileFlippedHorz( mapLayer, x, y )
--
        return (mapLayer._flippedTiles(x,y) or 0) >= 4;
--
end;

function IsMapLayerTileFlippedVert( mapLayer, x, y )
--
         return (mapLayer._flippedTiles(x,y) or 0) % 4 >= 2;
--
end;

If you want to sacrifice some readability for speed then you make this even faster by placing the grid __call function inline.

Code: Select all

function IsMapLayerTileFlippedHorz( mapLayer, x, y )
--
        return (mapLayer._flippedTiles.cells[x] and mapLayer._flippedTiles.cells[x][y]  or 0) >= 4;
--
end;

function IsMapLayerTileFlippedVert( mapLayer, x, y )
--
         return (mapLayer._flippedTiles.cells[x] and mapLayer._flippedTiles.cells[x][y]  or 0) % 4 >= 2;
--
end;

I don't know why TileLayer doesn't have access functions like these anyway.