The source has been released but was there any interest to speed up the software renderer in Quake? The BSP stuff is killer on 486 processors, and right now I can only think of these ways to improve performance on older machines:
- Doom-style double sized pixels, or virtual resolution (using the screen water warp code, sans warp effect)
- Delaying the lightmap animation update
- Removing the lightmap smoothing (for blocky, early PREY-like/CyClones-like lighting)
- Vertex lighting (not in the terms of a pro quake3 player as a synonym for 'turning off shadows')
Speeding up Quake engine on 486s
You can double the width of the pixels, their height, or both. Doubling the height is much faster, since all you need is to memcpy each line, but then you'll end with a resolution of (for example) 640x240, and this messes up with the height of the particles.
There's some code in the particle renderer to compensate for double-height resolutions like 320x480, but none for double-width resolutions. This is easy to add, anyway.
Also, it should be decided if the virtual resolution will be used in the whole screen (HUD, menus, etc.) or just in the 3D renderer.
Disabling lightmap animations would be much faster than delaying them. And on that note, you could also disable dynamic lighting as a whole (like in stock GLQuake).
The lightmap smoothing doesn't take too much CPU time because it isn't calculated on each frame. I didn't understand exactly how it works, but from what I've read in the code every time a new BSP surface appears on the screen the renderer creates a cache for it, calculates the lighting from the lightmap, blends it with the diffuse texture and draws the resulting texture to the surface cache. By the way, my English language skills got a bit rusty as of late, so I don't know if this whole paragraph made any sense. Thanks for reading.
Dunno about vertex lighting, haven't learned about it yet.
There's some code in the particle renderer to compensate for double-height resolutions like 320x480, but none for double-width resolutions. This is easy to add, anyway.
Also, it should be decided if the virtual resolution will be used in the whole screen (HUD, menus, etc.) or just in the 3D renderer.
Disabling lightmap animations would be much faster than delaying them. And on that note, you could also disable dynamic lighting as a whole (like in stock GLQuake).
The lightmap smoothing doesn't take too much CPU time because it isn't calculated on each frame. I didn't understand exactly how it works, but from what I've read in the code every time a new BSP surface appears on the screen the renderer creates a cache for it, calculates the lighting from the lightmap, blends it with the diffuse texture and draws the resulting texture to the surface cache. By the way, my English language skills got a bit rusty as of late, so I don't know if this whole paragraph made any sense. Thanks for reading.
Dunno about vertex lighting, haven't learned about it yet.
regarding pixel doubling, interleave it. one frame draw one set of scanlines, next frame draw the other. this way the screen is visually always refreshing and updating, and the eye accepts additional latency, but it looks smooth.
if you have a 64*64 texture, then the renderer generates a 64*64 cache for it, scaled up to the number of repeated images you have on that wall.
the lightmap is noticably lower resolution, but the cache is still 64*64 while the lightmap is more 8*8 (no idea what the actual figure is).
But yeah, the blending is in the cache, not per frame.
use r_drawflat?
if you have a 64*64 texture, then the renderer generates a 64*64 cache for it, scaled up to the number of repeated images you have on that wall.
the lightmap is noticably lower resolution, but the cache is still 64*64 while the lightmap is more 8*8 (no idea what the actual figure is).
But yeah, the blending is in the cache, not per frame.
use r_drawflat?