Hey all,
I'm creating a 2d sidescroller, but quite different one. Every stage in my game has a fixed area on z axis and x axis that character can walk on. So that it's not like super mario that you can walk only right and left but you can also walk up or down. So I have 3 positions: on x axis z axis and y axis.
I'm facing now some problems connected with z buffer. I've got some obstacles in the stage that character can jump on. And there may be as many obstacles placed on each other as you want. So that in specified Z axis position there mgiht stand a tower consisting of 5 crates for example. And here's the problem. Every crate that is placed higher than former crate in such tower should be displayed closer to screen and character which is standing on it must be also displayed as it was always closer than the chest(though it doesn't have to be true becouse every obstacle has its Z axis walking area). In order to solve this I've done this:
1. I've created a variable for every object called obstacle_area and this variable is added to object's z buffer value before displaying it.
2. When any object collides with crate, I assign to this object's obstacle_area:
- the crate's value of walking area on z axis
- and this carte's own obstacle_area variable value

Thanks to this every crate is located higher in the tower than former one and displayes as it was closer and a character that jumps on the tower is displayed closer in every point that belongs to obstacle's walking area on z axis. Character standing on obstacle might have lower z position than the obstacle but is displayed as it was closer.
But due to this appeared one issue. Now the crate that is being on the top of all has its z buffer value increased by all the former obstacle_area values and its own walking area on z axis. In result towers that consist of 1 object but are as high as towers consisting of multiple objects are displayed behind those objects.

Here's normal image showing that crates display properly and character can stand even on the edge of top crate but it still displayes closer.


Here's picture showing that if the red tower(which is only 1 object) is placed on the lower z position (behind crates tower) everything's displayed good too


Here's picture showing the even if the red tower is placed on the higher z position crates(anything) being on top of the tower are displayed first which is very bad


I guess this issue is a bit complex so sorry if something is unclear. If so, please ask me and I'll try to provide more accurate info.
I would be really extremaly grateful if anyone could advice other solution or help me solve this issue!

bump

Thanks for everyone that has looked on my thread but I still haven't managed to solve the problem and I'm running out of ideas on how to implement good z buffer functionality in my game. I wasted so much time on this issue . If anyone experienced in this field would be able to help me I would be very grateful!

Shortly: Each obstacle in my game has its vertical width and horizontal width and height. It's the area, on which character can move while standing on obstacle. The problem is when I stack a few obstacles one on each other (as in pictures above). Obstacles placed higher must appear closer so that lower obstacles don't cover them. If they all have same z buffer value sometimes one obstacle is bugged and even if its placed lower it is displayed as closer. I guess it's becouse the priority is set accordingly to displaying order. But if the z buffer of every single obstacle is growing more and more together with height of obstacle then it affects also objects that are normally standing on ground in front of the "object's tower".

Have you tried sorting your objects by whatever coordinate is pointing out of the screen first, then those sorted objects by whatever coordinate is up?

Maybe I'm misunderstanding here, it sounds like you're trying to arbitrarily set a z value for 2D sprites to achieve a 3D effect. I think you could get a better effect if you stored a depth offset for each pixel of the sprite. Or used 3D in orthographic mode.

hmm actually I've been thinking of some kind of sorting too lately... I hope it will work but I'm a bit tired today so I'll tell you the result tommorow. Thanks a lot for answer!

edit:
Jeffreytiitan yeah It's some kind of 3d effect but I would not like to use 3d technics atm. Anyway could you explain what do you mean by storing depth offset in each pixel of sprite? I don't seem to get it. Thanks for answer!

As far as I understand, you are using the z order for a purpose it's not really intended. You have objects that should be at the same depth being created at different z orders to solve a draw order bug. This accumulates until you have a high object in front of a low but near object. Maybe you just need to have it that crate fronts are in front of crate tops for a given depth, and characters are in front of both for a given depth. You could do it with the z order, e.g. make the base z order a multiple of 3, and add 0, 1 or 2 depending upon whether you're drawing a crate top, crate front or a character.

hmm that might have been quite interesting solution but fortunately I don't have to contrive that much . It turned out that sorting the order of displaying all objects on stage is enough. Though I had to reimplement some functionalities of my engine. Thanks a lot for answers!

Sorting is what most of the games did before 3D acceleration, especially tile-based games, where at best they had a kind of hardware-based priority system for sprites. Basically the priority system sorted the Z-axis (draw the highest priority/Z objects first, then the next, etc) and usually had a fixed number of priorities (i.e. the GBA had 4 for both backgrounds and sprites, and drew in background then sprite order giving essentially 8 layers).

In fact, most 3D games still do sorting by distance from the camera to either draw alpha correctly (because of the way the math works) or maximize the efficiency of using the depth buffer (i.e. draw the stuff closest to the user first so the card doesn't do all the calculations to draw a pixel only to find the next object covers it up anyway) so getting used to sorting before drawing is still a good idea.