We're trying to ascertain whether or not it would be feasible to implement a z-buffer for a 640x480 isometric game. (Technically it's an oblique perspective rather than isometric, but this shouldn't matter -- the main point is that the graphics are sprite-based rather than "real" 3D).

I should note that we DO have a working solution for depth-sorting our scene, I'm mentioning this in order to avoid replies such as "sort by screenspace y", "sort by grid position", etc: none of these simple solutions works for our scene, and our current solution is so complex and costly at runtime that I'm trying to determine if a z-buffer would be a better solution. Hence this post -- I'd like to make sure I'm not I'm not doing something very stupid with my initial foray into z-buffering.

Our scene is composed of primarily static shapes, with several dozen small moving objects circulating between them. This means that rather than having to redraw the entire z-buffer and framebuffers from scratch each frame, we can instead "bake" the static scene (graphics and z-buffer) into two 640x480 bitmaps and blit those into the frame-buffer and z-buffer instead of clearing them to black at the start of each frame.

Since the graphics are sprites, their z-image (relative to some point in objspace) can be precalculated and baked into a bitmap (a "z-sprite"). At runtime the depth of a given pixel in the sprite is simply the depth of the objspace point + the depth stored in the z-sprite, so that all we need to do to draw the object is to loop over the z-sprite testing each pixel vs the corresponding pixel in the z-buffer, and conditionally writing the sprite's depth and colour info into the z- and frame-buffers (respectively) if the sprite's pixel passes the z-test.

The two above simplifications to general z-buffering is what leads me to believe that a z-buffer should be feasible at game rates (a few ms/frame): we only need to do per-pixel work for maybe 50 16x32pix sprites, which is ~50k pixel reads/writes per frame (counting both z- and frame-buffers).

From what I've been able to find online, this seems at least somewhat reasonable -- there are many examples of flash processing hundreds of thousands of pixels at 30hz, i.e these posts and many similar examples:
http://blog.joa-ebert.com/2009/04/03...d-pixelbender/
http://webr3.org/blog/haxe/bitmapdat...-optimization/


My problem is that none of my tests come anywhere close to the performance I would expect from the above example!! For instance, just using getVector/setVector to iterate over all the pixels in the framebuffer is taking about 100ms.

So, my question is: What would be the best way to implement a sprite-based z-buffer?

I'm aware that moving to haXe would probably be a good idea; AFAICT there's no way to implement a z-buffer via Pixel Bender, but I'd love to be proved wrong about that. Basically I'm clueless about all the new-fangled stuff like byteArrays, flash.Memory, etc. which means I'm not sure how to use it properly.

There's also a chance that I'm crazy and that a z-buffer is not going to be feasible

Any help/suggestions or useful links would be much appreciated!

thanks,
Raigan

p.s - thanks very much to anyone who managed to read this far -- I really tried to keep things as brief as possible as per the forum rules, but I felt that some background was warranted since i.e a z-buffer for a proper 3D scene at 640x480 is obviously not going to be feasible.