On Thursday, 23 May 2019 at 06:07:53 UTC, Robert M. Münch wrote:
On 2019-05-22 17:01:39 +0000, Manu said:
I mean, there are video games that render a complete screen
full of zillions of high-detail things every frame!
Show me a game that renders this with a CPU only approach into
a memory buffer, no GPU allowed. Total different use-case.
I wrote a very flexible generic scanline prototype renderer in
the 90s that rendered 1024x768 using 11 bits each for red and
green and 10 for blue and hardcoded alpha blending. It provided
interactive framerates on the lower end for a large number of
circular objects covering the screen, but it took almost all the
CPU. It even used callbacks for flexibility and X-Windows with
shared-memory, so it was written for flexibility, not very high
performance.
Today this very simple renderer would probably run at 400-4000FPS
on the CPU rendering to RAM.
So, it isn't difficult to write a decent performance scanline
renderer today. You just have to think a lot about the specifics
of the CPU pipeline and CPU caching. That's all. A tile based one
is more work, but will easily perform way beyond any requirement.
I'm not saying you should do it. It would be CPU specific and
seems like a waste of time, but the basics are really very
simple. Just use a very fast bin sort for the left and right edge
in the x-direction, then use a sorting algorithm that is fast for
almost-sorted-lists for the z-direction (to handle alpha
blending).
Basically brute force, no fancy datastructure. Brute force can
perform decently if you use algorithms that tend to be linear on
average.
