2d Tile Rendering Order

OpenGL OpenGL: Basic Coding
1

So this is more of a general question but I believe it can be solved using OpenGL.

My system at the moment, renders Two layers, Bottom and Top and in between the player, so that when the player moves, anything on the top layer is above him and hides him and anything on the bottom layer is above him(he looks like hes standing on it). You know, basic 2D RPG 101.

Now suggest for a minute that I want something in the top layer to be behind the player, but it’s transparent so I dont want it in the bottom layer.

My question is, is there anyway I can render to memory, then display things in a specific order? Like it’ll render

Bottom(+things in top that are transparent)
Player
Top(-things that are transparent)

I was thinking FBOs but I’m not quite sure if they are what I want and it would need a bit of an overhaul to use FBOs.

Cheers

2

Huh? Where’s the camera? Above him? He’s in between both layers but both cover him up? You mean the bottom layer is below him?

So you want the top layer to every once and a while draw a tile that falls below the player? What does transparency have to do with it? Do you want a given tile to be between a player and the ground and blend with the ground (bottom layer)?

3

When translucency is involved an approach that usually gives ‘good enough’ results is to do the following (it is a 2-pass approach):

First render only the translucent objects in your scene and prevent writes to the depth buffer. (use glAlphaFunc and glDepthMask).

Second draw only opaque objects this time using the depth testing (again by modifying glAlphaFunc and enabling GL_DEPTH_TEST with glDepthMask(1)).

I hope I understood your problem correctly.

4

Alright I guess my question wasn’t that clear(posted at 2am :P)

So I’ll pose a simpler question,

Let’s say that I have a map, each map has multiple layers,
Layer 0 = Ground
Layer 1 = Transparent Objects Player Can Walk Over
Layer 2 = Transparent objects Player Walks Behind

Each layer is stored in an array

My rendering loop is such

for (int X = minX; X < maxX; X++)
{
for (int Y = minY; Y < maxY; Y++)
{
layer0draw
layer1draw
playerdraw
layer2draw
}
}

Now the problem is that when the next tile in layer0 or layer1 gets drawn, the player gets clipped behind it when they are moving because its being rendered on top of the player.

So my question is, is there anyway I can basically say
All the vertexes in layer0draw are to be drawn at the back,
all the vertexes in layer1draw are to be drawn at the back,
all the vertexes of the player are drawn in front of both layer0 and layer1, etc

I’ve tried vertex arrays(put each set of tiles into a vertex array) but I couldnt get it to work with Ortho for some reason.

5

And what is wrong with that :


for (int X = minX; X < maxX; X++) {
  for (int Y = minY; Y < maxY; Y++) {
   layer0draw
  }
}
for (int X = minX; X < maxX; X++) {
  for (int Y = minY; Y < maxY; Y++) {
   layer1draw
  }
}
for (int X = minX; X < maxX; X++) {
  for (int Y = minY; Y < maxY; Y++) {
   playerdraw
  }
}
for (int X = minX; X < maxX; X++) {
  for (int Y = minY; Y < maxY; Y++) {
   layer2draw
  }
}
6

Your best option is to unroll your functions into two loops for each layer so the bottom layer is completely rendered, then the second, then the third. This is required if player spans or crosses more than one tile.

7

I did have it like that before, but isn’t it inefficient to loop through the same map 4 times when you could possibly do it in one loop?

Wouldn’t it be quicker to go through the X and Y once and draw each layer(e.g. for each layer, tile[X,Y] goes into buffer[layer]) to some sort of buffer then draw it using opengl?

Obviously I could just loop through 4 times but I may have upwards of 32 layers(possibly) to check so optimisation is something I’m trying to focus on.

8

About the optimization thing, you are serious ?

Because, even doing 100 loops instead of one will not change that the only costly parts are the layer*draw, which get called exactly the same number of times …

9

for-loops are pretty zippy. Yes, having multiple loops is a little slower, but it’s negligible. As ZbuffeR notes, it’s the OpenGL parts that are the bottleneck. There are literally hundreds of details that will slow your program down more than multiple loops. Just break them up and move on.