Tiled / Sidescroll brainstorm

Someone recently asked about importing tiled levels created by “Tiled” or an app for iPad that creates the same thing. These programs allow you to visually drop in tiles to make a 2d game level, then it exports an XML document describing the blocks and their locations.

I am thinking of creating a basic game engine with Codea that uses these Tiled levels and am trying to figure out how to do it (I have never created a side-scrolling game before.)

My first idea is to create a mesh, then add rectangles to it to make a grid with the appropriate images as textures. I could then, theoretically, slide this mesh around so that the part I want to show would be centered on the screen (for a side scroller, I would slide the mesh left and right.) To go with this, I could then create physics bodies over platform tiles and slide these in tandem with the mesh.

The problem with this approach seems to be that I would be drawing this entire mesh even though only a small portion of it is visible on screen, so this may be inefficient. Anyone have any ideas on a better approach?

Funny thing is I was just working on this idea about 10 minutes ago. I was trying to generate a 2d tiled landscape, much like a mix between minecraft and terra. So far, I can generate the tiles and I’m starting to add in the procedural generation side based on the other blocks around it. I’d be glad to put up the code once it is cleaned up a bit. Right now it is fairly basic.

Hi @Vega, the post about tiled was mine, and I’m working to a tile engine too. There’re a lot of different ways to handle this problem, depending also on the size of your levels. If the map is too large, yes it will be inefficient to draw the full map at once even if the most of the map is out of the screen.

I can suggest you 2 way to work (I assume you’re using one single textureatlas):

1 - use “quadrants”, so subdivide your map in different sectors, and draw only the subsectors that you really see on screen. The number of drawcalls increase but the numbers of points per mesh decrease and you have not to update the meshes on runtime, only apply matrix and draw them.

2 - use only one mesh with an area greater then the game screen, and combine uv map switch, position of the quads and applyMatrix to create a scroll effect.

Yeah, @shrike, option 2 is basically what I had in mind, with the exception that I said I would move the mesh, and you said I should apply matrix instead. (You are obviously right here, not sure what I was thinking.)

I guess the thing I would wonder is: if most of the huge mesh I am drawing is off screen, does Codea still process the drawing of the whole mesh? Or are non-visible polygons automatically culled?

If not, then I have to go with option 1, which will require some logic figuring out how to split the level and then deciding if any part of each mesh is visible on every draw call. Not rocket surgery, but complication I will avoid if possible.

sorry @Vega, i was in a hurry before and I was not clear.

First yes if you pass a huge mesh you’re wasting performance. Invisible polygons are not culled, you have to manually collide quad vertices to gain back performances

Second what i meant with options 2 was totally another thing, and now I try to explain better :slight_smile:

Consider a game screen area of 100x100 pixel, tile of 10x10 pixel and a linear right scroll movement (just to make it easy with calculation), like for an endless game.

If you create a mesh with a grid of 12x10 quad, where each quad is 10x10, you have 11x10 quad covering the screen area and a column of quad (1x10) always outside of the screen. when scrolling right, a column of quad exit from left of the screen, while a column at the right enter. At that point you can uv map again the 10 quad offscreen, move them at right and cicle with that logic until the end.

Things are obviously more complicated to handle 4 direction movement with different speed ecc…

Hope to be more clear now, if you have doubt ask.

Non-visible stuff is culled by the GPU which is quite fast and possibly faster than having the Lua part rejig the mesh. The meshes in my roller coaster are very big, but as they don’t move (only the camera moves), the rendering is very fast.

Yeah, I misunderstood, @shrike. But I anticipate that using that option would cause it to not have a smooth scroll effect, it would appear to jump when scrolling. You could possibly overcome this with a tween, but it seems unnecessarily complicated. (call me lazy)

Thanks for the info, @Andrew_Stacey. I think I will make one big mesh for the level and see how fast it runs. From what you are saying, should be fast. BTW, the roller coaster demo is pretty impressive, nice work on that.

And, as always @Deamos, I would love to see your code. I’m sure I would learn from it.

I don’t understand what you mean @Vega, about the not smooth scroll effect, it would be as smooth as you wish: the smoothness of the movement depends only on how you decide to move the camera over the map. Anyway this solution at this point seems to be useless :slight_smile: Sorry for the wrong info about offscreen quads codea optimization, and thanks to @Andrew_Stacey. I don’t know why but I was pretty sure about having read about that in some other discussion and I had a wrong idea in mind.