OpenGL ES API Spec Released

[drgoldie]

it called: "Graphics for the Masses: A Hardware Rasterization Architecture for Mobile Phones"
by Tomas Akenine-Möller & Jacob Ström

[Kzinti]

I just finishing reading the paper. Interesting stuff, but unfortunately I don't think anything in it applies to software rendering. The texture compression and multi-sampling things would kill a software rasterizer.

I am not even sure tile-based Zmin culling could be done efficiently in software. It could of course be used for scanline rendering. But then why not use a S-Buffer if the overdraw is low (<=4).

But for a hardware implementation? Cool stuff.

[Dan East]

If you're using a traditional planar BSP then you can of course do perfect front to back sorting for free (which allow the use of coverage spans). However you still have to handle polys / particles / sprites that are not part of the BSP. That is where with Quake they threw up their hands and used a z-buffer (ie the easy way out ). My testing with PocketGL, which uses an interleaved color / depth buffer, is that the addition of the depth buffer reduces performance around 33%, even when the depth buffer is not actually used (ie the penalty of extra cache loads, plus the inability to do more efficient hardware blits because of the hybrid buffer, causes the performance drop). Even if a span based system is somewhat expensive, there still may performance to be gained relative to z-buffers.

Dan East

[DooMer_MP3]

[Digby]

If you want to improve upon your current performance, profile your code and look for the bottlenecks.

Guessing (or asking for others to guess) is one way to go about it, but it's often not the most effective.