Discussion for Tutorial 6 - Tiled Map Class

[jonny]

The next installment of the 71Squared iPhone Programming tutorials is now available. This tutorial covers a tile map class which can consume configuration files created using the Tiled map editor.

[cyoung_mi]

Perhaps this is more of a Tiled question,
But I'm looking at properties.

I see Tiled allows for properties for Map, Layer, and Tile Icon.
I would like to put a property value on an X,Y tile. not all the tiles of that type.

So for example, in the current example all the wall tiles have a property of 'Blocked'
I would like to mark the tile at location at 5,3 with the property of 'hole'
But I don't want all the tiles of that type to have that property, and I don't want
to have to have duplicate type icons in the tile set.

Is TileD able to do this? or perhaps I'll have to do it by hand.

[mike]

Hi ya

This can be done by using Object Groups in tiled. There is not that much info on their website. But basically you can define an object group layer and then place objects anywhere on the map with any number of properties. These objects are positioned using pixel locations rather than tile locations giving you more choice on where things should go.

The current tiled implementation from the tutorials does not support parsing these objects at the moment. This is something I've only recently added to the code for the book.

Let me know how you get on and if you need any more info.

Mike

[tjfallon]

Hey. First I'd like to thank you for all the tutorials, some of them have been very helpful. I do have one question though, and maybe I'm missing something but isn't there an infinitely simpler way to handle your drawing of the screen?

Right now for every frame you are updating something like 80 tiles per frame right? Wouldn't it be way easier to pre render your entire tile map and then just move the camera around with transformations on the projection matrix? OpenGlES will throw out everything that's outside of the view, so you aren't losing GPU power by having everything prerendered, and you save a ton of operations by not moving your entire world around.

You know what I mean, move your camera, not the world?

I'm working on a super simple side scroller right now and that's what I'm trying to use. I'm a total openGL beginner though, so I wouldn't be surprised if I was totally wrong.

[mike]

Hi tjfallon

You are absolutely correct

That is exactly the approach I am now taking in Sir Lamorak's Quest. I set up a Vertex Buffer Object for each layer in the tile map when the map is loaded and when I want to render one I simply render the entire VBO for the layer I want to render after translating the camera coordinates.

As you say, OpenGL ES is able to drop fragments that are not going to appear on screen very early in the pipeline which means there is little overhead to rendering the entire map. I only render each layer separately so that I can change if blending should be used. Rendering the first map layer containing things like the floor and walls without blending i.e. I don't need to see anything underneath the first layer, really saves cycles.

Thanks for the post and I look forward to seeing your scroller soon

Mike

[Sumaleth]

Mike, I think you might be talking about a different approach to that described by tjfallon, but both are interesting. I think fallon's idea is to render the whole level to one big 2D texture, so then you effectively have just the four verts to do the whole background.

--

I've been re-watching your vids, and I got up to the particle emitter video yesterday, which makes use of VBOs. So I started reading up on VBOs, and I came across this page (it's worth reading all the comments too):

http://www.kevindoolan.net/blog/post/20 ... mance.aspx

It sounds like VBOs have no benefit on the iPhone, although they don't seem to say that they have a negative performance either. But it does sound like they get re-copied each frame, so it's only the vert-making loop that you're saving using the approach you describe (if I understand it correctly).

--

This idea of moving the camera interests me too. All the stuff I've been reading seems to suggest that you should leave the camera at 0,0,0 and move the scene. I guess the calculations are the same in the end (every vert still needs to be run through the matrix), but I wonder why the common approach is to leave the camera alone.

[mike]

Hi Samualeth

Your right, VBO's on the iPhone don't really make much difference as there is no real dedicated video memory to copy the data too. The key behind the VBO is putting the data as close to the GPU as possible making it easier to keep it fed with information. Whilst the current iPhone models don't really have this concept, I believe through rumours that future devices could make use of dedicated video memory. Using VBO's would automatically allow your game to make use of that feature if it was ever released.

When it comes to rendering to a texture, that is actually restrictive. Rendering all layers to a single texture would not allow me to make changes each frame without re-rendering the texture. Also the map I am using in Sir Lamorak's Quest is 40k tiles square and is 8000x8000 pixels. The largest texture you can have on the iPhone is 1024x1024 so I would need multiple textures requiring them to be bound and therefore introducing state changes.

When I create the VBO for a tile layer, it is at that point that I work out the vertices locations for each tile. From that point on I don't change those vertices ever, I simply perform a glTranslate on the world coordinates based on where the player is in relation to the map and also render the other game objects as well. I then pop the matrix before the glTranslate and render the GUI.

As the VBO data is never changed from when it is created I mark the VBOs as GL_STATIC_DRAW which tells OpenGL ES that the contents of the VBO will never change, as apposed to GL_DYNAMIC_DRAW. This helps OpenGL ES optimise how it stores/accesses the data in the VBO. As you say, not a massive advantage if any, but its clean and will make use of any new features in that area Apple introduce later . Whether using VBOs or Interleaved Vertex Arrays, it does mean I only ever calculate the vertices of all the tiles on a map layer once and then never change them. OpenGL ES can process this data an insane speeds as well.

I have played with moving from GL_TRIANGLES as well to using a GL_TRIANGLE_STRIP, but I have problems with the degenerate triangles needed to move from the end of one strip to the start of another without actually drawing any triangles. The performance improvement I was seeing would suggest that this method would be a HUGE advantage, so something I will continue to play with layer

Your right about the coordinates, it does seem better to statically render objects and then move the world around them. That becomes a problem though when you are batching up your rendering. When rendering a batch of vertices its not possible to change the world coordinates until that batch has completed. So for things like the baddies etc I do update their vertices each frame and put them all into an Interleaved Vertex Array which is again rendered as a single batch. For everything other than the tile map I have a single large texture for all entities including animation etc, so I can render an entire scene using just two textures which helps keep the state changes down as well.

The render loop is pseudo code looks like this:

- Clear the screen
- push the matrix
- glTranslate to the players location keeping the player in the middle of the screen
- render the castles base layer (no blending)
- render the castles objects layer (with blending)
- render the axe
- render the player
- render entities (baddies)
- render the doors
- render the transportation portals
- Render the current batch i.e. everything above except the map layers that use VBOs
- pop the matrix
- render the HUD graphics
- Render the current batch

Hope that helps. I think these discussions are excellent as it does make you think about how you have implemented stuff

Mike

[Sumaleth]

Mike,

That approach actually sounds pretty good. I like the idea of working with the future hardware already in mind, though only if it doesn't have a performance hit for current hardware (which it sounds like it won't for what you're doing).

it does seem better to statically render objects and then move the world around them.

I was actually saying the opposite of that, so what you describe in your pseudo code looks like what I had in mind.

I'm a little puzzled by the push and pop though. So this whole loop is acting on the MODELVIEW matrix, right? You save the state before the translate, then draw the game scene, and then pop to add the hud? I don't have much experience with OpenGL yet, so it's a little unintuitive at this point, but wouldn't the HUD need to be rendered with the game content?

Hmm, thinking about it some more I wonder if I might get it now. If you render stuff, then those pixels are done, and when you pop back to (presumably) 0,0,0 and render the HUD it gets added over the top of the already rendered pixels. Is that right?

In that case, I'm not sure why you need the push and pop still. You could render the HUD without the pop couldn't you? Perhaps it's easier to get 1:1 pixels when it's rendered at 0,0,0 instead of off in some unknown place?

[mike]

Your almost there

I pop the model matrix before I move to where the player is on the map, render the map and player etc and then pop back which does move me back to an origin of 0, 0. I do that so that the HUD images are always rendered in the same place i.e. based on a screen origin of 0, 0. If I did not push and pop the matrix I would have to work out where to render the HUD images so that they can be seen in the current scene. If I had translated to say x = 5000 for the map rendering and then rendered the HUD at x = 0 it would be dropped as it would not be visible.

So I basically pop the matrix back so I can simply render the HUD images based on an origin of 0, 0 every frame.

Mike

[Sumaleth]

But isn't everything relative to the current matrix?

So if you glTranslatef(5000,0);

And then draw the HUD quads as though you're still at 0,0 you will still actually see them on the screen.

I think I will have a play with Xcode. Worth getting this clear in my head.