Advanced Tiled Loader - No longer maintained

[Kadoba]

Are you going to add sprite-batch?
Also can you use a sane class system?

A map can consist of multiple tilesets with differing tile size on the same layer so I don't think sprite batch will work. The reason I didn't add a class system is because I never really saw the great need for one the way lua is designed so it seemed like an unneeded dependency. The only really insane thing I can think of is some aspects of objects. Specifically, I think draw_info is really messy. A lot of the object-class mess is mostly due to a new release of Tiled that added tile based objects literally hours before I first released this library so I quickly hacked support for that in.

This was really the first thing I ever did with love or lua so there are definitely some clunky parts I want to go back and change. Things like hard-coding the directory path into every included file. I do have some stuff planned for the next release.

But anyway, I'm glad to see this being used and people find it helpful.

[adrix89]

You just need multiple sprite batches for different tile sets
I'm pretty sure you can pump allot more performance with it
The thing is right now it has problems with existing objects when loading a new map
Still haven't figured it out how to make it work
I wished I could have used different system but the only way I can draw a sprite with proper layering is by using the objects layer

[Kadoba]

Okay, I'll test out sprite batches then.

Can you be more specific on the types of problems existing objects cause? Maps don't share any data and are self contained so objects from other maps shouldn't interfere with one another.

You can create your own layers by altering the map's draw_list. If objects are giving you a lot of trouble then try gutting the object layers, reading what data you need from them, and creating your own layer. Object layers are sort of bloated at the moment to remain compatible with Tiled.

[adrix89]

Then how do I render another layer on the sprite?
There is no draw over function from what I have seen so for some tiles to be drawn over objects it must be on the map object layer to assure proper ordering
If I were you I'd gut object layer or make it only information and implement a proper draw ordering,because stored objects just evaporate once you load a new map because that object doesn't exist anymore in the data structure as an object on a object layer
That or I'm doing something wrong or there are big bugs
What I was trying to do is make the Guy from desert example survive multiple maps

[Kadoba]

Then how do I render another layer on the sprite?

A map's draw_list is simply an array of functions that are called in order when the map is "drawn". By default those function are the tile and object layers' draw functions in the order they appear in Tiled. You can manipulate draw_list however you want to and add, remove, or switch around any function. This includes draw functions that aren't layers, or really whatever you want.

If I were you I'd gut object layer or make it only information and implement a proper draw ordering,because stored objects just evaporate once you load a new map because that object doesn't exist anymore in the data structure as an object on a object layer

Old objects still exists after you load a new map, but in the old map. As I said before maps are self contained and do not share data (actually saying this made me realize they don't even share image data. I should probably cache that). This doesn't stop you from moving over the objects that you want to keep to the new map. Moreover, there's nothing stopping you from only using the object layer for information. Just remove the layer from the map's draw_list and read what you want from it.

I think the biggest confusion here is that you don't realize that the draw ordering is completely customized through the map's draw_list.

Here's an example on how to do this:

Code: Select all

-- You have two layers "ground" and "overhead"
-- map.draw_list[1] is ground
-- map.draw_list[2] is overhead

-- Let's insert a sprite's draw function inbetween those:
table.insert(map.draw_list, 2, sprite.draw)

-- Now the sprite will be drawn between the two layers

-- What if we don't know the specific number of the layer, only the name?
-- You can search for the layer number using the function map.drawPosition(drawitem)
table.insert(map.draw_list, map.drawPosition(map.tl["overhead"]), sprite.draw)

-- So there's nothing stopping you from implementing your own layers

I hope that answers your questions. If you're still having trouble let me know.


EDIT: I'm sorry but I got the names of my variables mixed up here. draw_order is actually what I was referring to above.

[adrix89]

I decided to use a different system so I can't give you any more feedback
I just can't get it to work properly and to solve things I'd have to go into the library itself and look how it works
And if I would decided to do that then it would make more sense to move to a more familiar library instead

[Kadoba]

Okay, good luck with your project.

[Kadoba]

I looked over sprite batches again. The concern from the start was that there's just no way to make them work with multiple tilesets on the same layer unless the tiles are all the same size or smaller than the map's tile dimensions. Even with multiple sprite batches for each tileset it will break the draw order in a bad way. I could combine the image data from all tilesets used into one big image but that would take a lot of work and would surely induce P02 syndrome and lots of unused image space.

At the same time, the potential performance gain is too great to ignore. So I am going to try and add in optional sprite batch support. If all goes well expect a new release soonish.

[adrix89]

LOVE 0.7.2 [Game Slave]
-----------------------

* Added Framebuffer:get/setWrap.
* Added love.event.clear.
* Added support for any number of arguments to love.keyboard.isDown, love.mouse.isDown and love.joystick.isDown.
* Added SpriteBatch:setImage().

* Fixed fused games not working.
* Fixed ParticleSystem:setSize ignoring the variation argument.
* Fixed some file-opening exceptions not being caught.
* Fixed files loaded by libmodplug being too loud.
* Fixed paths with periods in them not working.

Aham...
Note that you would still have to draw them 2(or multiple) times for different tilesets,it also might be easier to just limit it 2-3 tile sets per map anyway

[Kadoba]

I don't see how that helps. You would have to switch out the quads between images too. You might as well have multiple batches.