Reply 40 of 54, by Scali
wrote:The Quake renderer may not be elegant underneath the surface
Depends on what you consider 'elegant' I suppose. I think the renderer is elegant in the sense that it reaches pretty much optimal performance on the Pentium architecture by firing off FPU instructions that overlap with the texturemapping innerloop.
wrote:but I think it would be difficult to improve upon, as you noted, without losing too much visual detail.
Yes, it's a difficult situation.
On the one hand we know that a Quake-ish game should be possible on a 486, since Descent has a very similar engine, but more 486-friendly.
On the other hand, Quake is designed from the ground up to target Pentium, which results in better image quality than Descent (although Descent is certainly still very acceptable).
Where is the right balance between the two? That is difficult to say. Quake levels are larger and more complex than Descent-levels. Would it be possible to have a Descent-like engine that renders Quake-levels? And would a 486 still perform about as well as it does in Descent now?
Or should the Quake level-code be used as-is, and just a more Descent-like renderer plugged in? And if so, how close can you get to Descent-performance with that?
In an ideal world, I would just write a 486-optimized BSP-renderer from scratch. Something that is compatible with the Quake level-data, but designed from the ground up to work on a 486.
But a more realistic course of action I think would be to do what I already suggested before: I think it's a safe assumption that the biggest bottleneck is in the texturemapper, since that is run for every pixel on the screen.
So replacing that with a 486-optimized one would be a good start.
Once that part is optimized, one can look at the next bottleneck, which might be in the handling of the BSP and the transform/lighting code.
So, basically you'd do a 486-rewrite, but stage by stage, going for the biggest bottleneck first.