Is there a way to count polygon drawn after culling to enforce nintendo DS style limitation?

The Unity engine is able to show triangles count in editor, and that seems to take into account backface culling too. Is there a way to access that count to enforce strict detection of triangles/vertex budget to emulate Old console graphics behavior? Any extra information like fillrates, video memory, etc ... is great.

 

That kind of information is not really available through consumer graphics APIs. You can holy get stats on actual clipping using vendor specific debuggers. I'm not sure even RenderDoc can give you those numbers.

You specifically mentioned the Nintendo DS, and it's a system I'm familiar with.

It was a strange piece of hardware. It rendered things more or less like this:

- The CPU would prepare a command list for the GPU, with commands like setting render state, MVP matrices, and drawing triangle lists. Not too different from fixed function OpenGL 2.0 commands.
- The 3D coprocessor would go through these commands, calculating the final vertex coordinates and performing frustum and backface culling. The triangles which passed the test would be written into a geometry buffer which is limited to up to 2048 triangles. Excess triangles are discarded.
- Note that no actual rendering took place yet. That's because the GPU will then read the geometry buffer on the fly as each scanline is rendered, rasterizing the triangles directly to the LCD.

It's similar to how old school consoles rendered tiles and sprites, but drawing textured perspective correct triangles instead. It will also just stop rendering the current scanline and move to the next one if it takes too long (lots of thin vertical triangles or too much transparency overdraw in a single scanline).

If you want to go really hardcore you could kinda replicate it's renderer using compute shaders, culling and clipping by hand and appending the triangles to a buffer. Since the amount of geometry and draw calls was low, you could load your textures into an Atlas to simulate VRAM and have a single shader which replicates the fixed function pipeline.

Ah, the hardware had no support for floating point either, it was all fixed point. You could quantize your floats into different fixed point formats before passing it into your simulated renderer.

 

Thanks for the extra info, but yeah I asked to not reinvent the wheel, I figure out that, as a fallback, even the cpu would be fast enough to work at such low level of rendering and could process the necessary data in brute force.