go-tiled
go-tiled copied to clipboard
lafriks
Renderer doesn't render ObjectGroups
I'm not sure if this is intended behaivor, I'm new to Tiled, but whenever I try to render this .tmx file
<?xml version="1.0" encoding="UTF-8"?>
<map version="1.4" tiledversion="1.4.2" orientation="orthogonal" renderorder="right-down" width="9" height="9" tilewidth="128" tileheight="128" infinite="0" nextlayerid="6" nextobjectid="24">
<tileset firstgid="1" source="../assets/kenney_tiles.tsx"/>
<layer id="3" name="Background" width="9" height="9">
<data encoding="csv">
...
</data>
</layer>
<layer id="1" name="Main" width="9" height="9">
<data encoding="csv">
...
</data>
</layer>
<objectgroup id="4" name="Trees">
<object id="15" gid="345" x="385.697" y="521.545" width="141" height="141"/>
<object id="18" gid="345" x="627.818" y="656.697" width="141" height="141"/>
<object id="19" gid="345" x="433.03" y="786.152" width="141" height="141"/>
<object id="21" gid="318" x="191.97" y="100.697" width="210" height="62"/>
<object id="22" gid="317" x="770.758" y="1100.7" width="210" height="62"/>
</objectgroup>
</map>
The ObjectGroup doesn't get rendered:
This is how it's supposed to look:
The tileset is in assets/kenney_tiles.tsx and the map is in levels/level1.tmx
To implement this it needs to rewrite how layers are parsed and represented in API so that there is single base layer type for all (layers, groups, objectgroup, image)
Something like "RenderableLayer" would represent layers that would draw down when calling RenderVisibleLayers(). This goes alongside some comments I had seen on another TMX parser where it was brought up that you can actually intermingle layers, objectgroups, etc. Effectively, it's not draw all layers, or all objectgroups, or all imagelayers in that order, you could have...a couple layers, an object group, another layer, an image layer, another object group, an image layer....well you get the idea!
Part of the complexity is incurred from the TMX format itself ensuring it's backwards compatible, otherwise I believe it would already be organized in a more conceptually easy manner.
So our map element would contain a list of "renderable" elements, which include layers, imagelayers, objectgroups and groups. Groups in turn can hold their own list of these renderable elements. We could create a "stack" as we go through the render process, maintaining a z-order of the renderable elements, and then after parsing and creating this stack in the correct order, then processing it. The stack of elements to render could potentially be created on file load, so we're not doing a whole lot of reparsing during the drawing phase. Or we could add in our custom "z-order" attribute to the required elements on the initial parsing and pluck things out that way during render, such that we can still maintain the loaded mapfile structure in case it should be used to maintain any application states.
Long story super short, it's almost a complete rewrite to do properly, as right now go-tiled is centered around simply rendering the layers collection. Not a horrible thing to do sooner than later, instead of hacking individual things to get them to work. It does however load up everything from the TMX file, so @fr3fou if you were so inclined in the meantime to get your game map working, can read the objectgroup layer and introduce the elements manually. Alternatively, if there's items you don't need it to interact with necessarily and are for view, obviously create as layer. Personally on a project I'm working on, I use an object layer for collision detection, simply using the elements in memory as needed, not requiring them to be rendered.
I actually am in the process of fasttracking my knowledge of xml parsing with the intentions of helping this project along so that I can use Tiled to the fullest extent possible too. Kinda gotta learn more Golang concepts too though, I'm a newb at the language right now...and interfaces are eating me for breakfast. :)
Problem with current xml parsing is that there is no way to know order in what layers are in as they are split to multiple properties (Layers, ObjectGroups, Images, Groups)
Conceptually on loading, we have to loop through the first level "children" under the map element, numbering them off as we come across them, regardless of what type of element. Coming across "groups" means to drill down into those elements and continue the numbering, so they are rendered properly too.
I'm sure there's other ways of of doing it, but I found a nice little package here xmlquery which allows to easily grab elements based on their relation to each other. I sandboxed a quick little test routine, and sure enough it's a step in the right direction.
Not sure how soon I'll have something polished, but my goal is to reimagine the xml parsing process, getting that done well, before reintroducing it to the rendering portion. Having that well formed proper structure will make all the other steps fall into place a bit easier.
I don't think xmlquery is needed, just need to make custom unmarshall function and refactor types:
type LayerBase struct
type Layer struct
*LayerBase
type ObjectGroup struct
*LayerBase
etc
Have to ensure that it doesn't group all the layers, all the objectgroups, all the imagelayers, etc so they can intermingle. I'm sure it can be done with the base xml parsing, I'm sort of bouncing between learning all these new things and trying not to complicate it either. I'm a big fan of if it's ugly, there's probably a better way. Often I will use something as a handhold until I fully grasp the concept and then can take off the training wheels so to speak.
can't really give any estimate, will be quite busy this month so most probably February
