support for depth sorting of sprites within tiles based on y value and/or dynamic layer generation:( mte.addLayer(props))

Million Tile Engine
#1

I am writing a game in which there are a number of lanes(). How I implement the z sorting at the moment is that I define a layer for each lane in tiled.

 

Below describes how each lane is defined in a level. let each x represent a tile, and each line of tiles represent a lane:

 

zindex1:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

zindex2:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

zindex3:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

zindex4:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

zindex5:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

zindex6:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

zindex7:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

zindex8:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

zindexn:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

 

you can imagine the zsorting being much like that in double dragon with sprites being able to be sorted based on their y coordinate (http://www.intomobile.com/2011/02/11/aksys-games-reveals-updated-double-dragon-for-iphone-releasing-in-march/)

 

as the user navigates the map I insert him into the correct layer that is representative of the lane he is on. Based on a max/min y value. this is quite an optimal solution for depth sorting (in this game).

 

for lanes that have objects (like trees etc) i simply add further layers in tiled. one for foreground object, one for background objects. en example of an individual lanes layer setup: 

backgroundLayer:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

       middleLayer:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

foregroundLayer:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

 

So in our game there can be three layers for any given lane: a foreground layer, a middle layer for the player and a background layer, with the player always navigating between game lanes via the middle layers

 

 

What would be great is that we could set up depth sorting within a layer based on a sprites y value like in cocos2dx.

 

but even with y based sorting above solution is pretty optimal for our usage case as it is only really the player that changes its depth (all other sprites move exclusively in the x dimension). The problem lays with huge maps. In a map where i need to define 100+ lanes this can get pretty tedious to define all the layers within tiled. So what we need is the ability to add new layers on the fly via mte in the form of a new api function similar to

 mte.addLayer(props)

 

thoughts? 

 

/S

#2

Hello steve3,

Good idea about the depth sorting! 

I’ve added two new MTE parameters to my current development build; enableSpriteSorting and spriteSortResolution. The first is a boolean which enables the feature, the second defines the resolution of the depth buffer in terms of a fraction of one map location(A resolution of 10 creates 10 depth positions for each Y location). Adding sortSprite = true to a sprite’s setup table will put it into the buffer and update its depth position each frame.

I’m planning on updating MTE by the end of the week with this, the new PhysicsEditor support, and the expanded TMX encoding scheme support.

#3

Hey dyson,

that sounds like a great addition. i’m just thinking about the processing overhead this may add to my game in which there can be at times over 200 vehicles and potentially as many static objects. The vehicles only need to be depth sorted when they are initially added to the scene as their movement is limited to the x dimension.

in above case I guess it would be great idea to be able to add an additional property to sprites “depthsortonce”  alongside a function that dirties the sortied state and forces a depth sort in the next/current update cycle.

I just realised that due to the way our static world objects are defined, within a tile set with static objects potentially spanning multiple tiles, the solution we have at the minute (with sorting based upon layers) is really the only way to go. This does not detract from the overall utility of above. 

#4

Good thoughts on overhead. The above was just a quick job to get something into this latest update for you, the rest will be easy enough to work out after I get this current update posted.

I’ll see what I can do about adding new layers programmatically. Adding new layers to the top of the stack shouldn’t be too troublesome, but inserting layers beneath currently existing layers would be a different story. Considering this, what you would probably want to do is start with the lanes furthest away and use this hypothetical API call to add successively nearer lanes until your map is populated to your liking.

I’ve been looking into the engine rewrite in my spare time. The new system will be able to load multiple maps in the same instance, each one contained in it’s own group object. Even currently MTE supports adding group objects as sprites. Taking this to its logical conclusion, it will be possible to load maps and insert them into maps as sprites, and insert those maps into yet other maps as sprites containing sprites, containing sprites. Because the maps are sprites within parent maps, one could in theory apply physics bodies to them. Of course, people will have to carefully monitor the performance demand of maps inside maps inside maps inside maps, but the new culling system is agnostic of the maps’ current positions inside other maps- if a map is offscreen (or outside of a user-specified screen space) it will cull its tiles.

In the future, the issue you describe of positioning multi-tile “objects” in a map will be a non-issue. Each multi-tile object could be loaded as a map and positioned as a sprite.

#5

Hello steve3,

Good idea about the depth sorting! 

I’ve added two new MTE parameters to my current development build; enableSpriteSorting and spriteSortResolution. The first is a boolean which enables the feature, the second defines the resolution of the depth buffer in terms of a fraction of one map location(A resolution of 10 creates 10 depth positions for each Y location). Adding sortSprite = true to a sprite’s setup table will put it into the buffer and update its depth position each frame.

I’m planning on updating MTE by the end of the week with this, the new PhysicsEditor support, and the expanded TMX encoding scheme support.

#6

Hey dyson,

that sounds like a great addition. i’m just thinking about the processing overhead this may add to my game in which there can be at times over 200 vehicles and potentially as many static objects. The vehicles only need to be depth sorted when they are initially added to the scene as their movement is limited to the x dimension.

in above case I guess it would be great idea to be able to add an additional property to sprites “depthsortonce”  alongside a function that dirties the sortied state and forces a depth sort in the next/current update cycle.

I just realised that due to the way our static world objects are defined, within a tile set with static objects potentially spanning multiple tiles, the solution we have at the minute (with sorting based upon layers) is really the only way to go. This does not detract from the overall utility of above. 

#7

Good thoughts on overhead. The above was just a quick job to get something into this latest update for you, the rest will be easy enough to work out after I get this current update posted.

I’ll see what I can do about adding new layers programmatically. Adding new layers to the top of the stack shouldn’t be too troublesome, but inserting layers beneath currently existing layers would be a different story. Considering this, what you would probably want to do is start with the lanes furthest away and use this hypothetical API call to add successively nearer lanes until your map is populated to your liking.

I’ve been looking into the engine rewrite in my spare time. The new system will be able to load multiple maps in the same instance, each one contained in it’s own group object. Even currently MTE supports adding group objects as sprites. Taking this to its logical conclusion, it will be possible to load maps and insert them into maps as sprites, and insert those maps into yet other maps as sprites containing sprites, containing sprites. Because the maps are sprites within parent maps, one could in theory apply physics bodies to them. Of course, people will have to carefully monitor the performance demand of maps inside maps inside maps inside maps, but the new culling system is agnostic of the maps’ current positions inside other maps- if a map is offscreen (or outside of a user-specified screen space) it will cull its tiles.

In the future, the issue you describe of positioning multi-tile “objects” in a map will be a non-issue. Each multi-tile object could be loaded as a map and positioned as a sprite.