Idea to get better performance on slow processors

[viti95]

I've made some testing to see if is possible to render the scene with resolutions below 320x200, with corrected aspect ratio. The main idea is to reduce the number of pixels to copy from the backbuffer to the VRAM, in the same way Doom renders with Low detail (and FastDoom potato detail). VGA Mode Y allows to render two or four contiguous pixels with a single byte written to VRAM and it pretty much doubles or quadruples the framerate in most cases (low detail has a bit of extra cost since it's needed to change the plane to render via OUTP instructions).

Setting the resolution to 160x200 runs fine with good aspect ratio and the game is still very playable, but the game crashes whenever the HUD or the menu is presented. The 80x200 resolution crashes directly, no image is rendered at all (maybe something related to the same problem?).

The Quake code is very complex for my tiny brain, I hope this idea could be implemented without much trouble.

[goshhhy]

out of curiousity, does setting d_subdiv16 0 change anything as far as the crashing goes?

[viti95]

The d_subdiv16 didn't make any difference, but I was able to reduce the crashes by disabling the main menu drawing. And still have some crashes when the game tries to show some text in the screen or the hud itself. I guess the code isn't designed to handle resolutions lower than 320x200, that's why it crashes.

Is there any variable that allows render the scene with half or quad horizontal resolution?

[goshhhy]

there is not, but i'll investigate this after i'm finished with my current round of changes and made another release. it seems like a good way to reduce the rather dramatic effect that video bandwidth has on lower-spec systems.

[leilei-]

Back when Engoo could compile for dos and before it ventured into graphical featurecreep madness (~2010), I also tried to explore speeding it up on a 486 (in non-ASM ways). Using the D_WarpScreen function as a base to render lower was my only way into that idea with meaningful results. Half-Life does similar for the software renderer whenever a screen fade or fog's done (underwater) since it's faster than doing an entire read of the screen buffer to perform a color blend while you have a little 320x200 warpbuffer to kick around.

I also considered using the obscure lcd_x rendering functions to make low detail modes, but this wasn't faster and also disturbed the aspect of the particles too much.

[kmehltretter82]

Reducing vertical resolution rather then horizontal resoltion should help more with Quake, due to the scanline rendering. So it is probably best to keep the full-size status bar.

Maybe it is easily possible to add some empty black horizontal bar at the top of the screen where nothing is rendered ?

[Darkcrafter07]

There must be a way to introduce an effective low detail mode like in doom. As soon as the renderer is a horizontal scanline wouldn't it be possible to draw the game in a lower vertical resolution (320x100) and do so in an interlaced manner? Like alternating even and odd fields a frame to frame so the hud woudn't get much hurt and all the scaling ratios stay the same.

I also wanted to tell that Duke3D really messed up the low detail mode because when screen sizes are decreased, the main renderer resolution is from the biggest possible window and then scaled back to lower wasting CPU power and thus making low detail mode in smaller windows sizes worse.

Engoo's low detail mode only seems to work properly in dosbox and not in pcem.

Some people on vogons talked about getting the rendering code ported from descent, some even replaced the float divide with integer but nobody making it "faster on 486 and slower on pentium" but I think nobody would want to do that now.

@viti95 also made a feature for his fast doom port to replace floor and ceiling textures rendered as shaded flat colors. What if it was possible to implement a partial "r_drawflat 1" for quake, like some textures drawn with colors averaged from "diffuse + lightmap"?

[goshhhy]

There must be a way to introduce an effective low detail mode like in doom. As soon as the renderer is a horizontal scanline wouldn't it be possible to draw the game in a lower vertical resolution (320x100) and do so in an interlaced manner? Like alternating even and odd fields a frame to frame so the hud woudn't get much hurt and all the scaling ratios stay the same.

sure. i'm not sure how i would go about implementing it myself, i'm not sure i could get it to run faster than the code i already have written for handling horizontal spans, but i don't think that means it can't be done, and i'd be happy to see a pull request that implements this. ideally i'd want it to be a cvar that can be toggled.

Engoo's low detail mode only seems to work properly in dosbox and not in pcem.

for the record, while i do use tools like dosbox for rapid feedback while developing, i always test my changes on real hardware as well, usually with a variety of CPUs with different behaviors. i wouldn't feel comfortable committing something that doesn't work on real hardware, and i never use data from the likes of dosbox to validate performance-related changes. if something in 486quake behaves oddly in emulators, it is likely a bug in the emulator.

What if it was possible to implement a partial "r_drawflat 1" for quake, like some textures drawn with colors averaged from "diffuse + lightmap"?

stock quake already has an "r_drawflat" cvar, and so 486quake does have this, but it uses random colors, not colors derived from the texture. it shouldn't be too hard to alter it so that this is the case. this would potentially be useful for a variety of other targets as well, e.g. a hypothetical port to SGI GL on IRIX, or certain early PC 3D cards that can't do texturing (or can't do it quickly), which is something i've been investigating support for over the past few months.

[Darkcrafter07]

In order to simulate FastDoom flat visplanes I thought about "r_drawflat" could be partial and applied to the surfaces whose normal vectors are (perpendicular or almost perpendicular to the player's bounding box) OR (parallel more or less to the z axis of the world). If that's too hard to do, then maybe at first it can be done in such a manner that only some certain surfaces become flat with an option to randomize the selection at the runtime per some time or before the level starts. Liquids like water, slime and lava texture to be always flat that way.

Maybe then the skybox rendering could also be simplified with flat colors, just like in FastDoom. Explosion partilces seem to also slow down the renderer significantly, there must be a way to disable them entirely or get less of them.

The screenwarp for underwater effects may also be disabled.

Then that bilinear filtering for lightmaps over the map geometry could possibly be nearest-neighbour.

Perhaps you could also look at how descent renderer works since it's been open source as well, it works on 486 sx2-66 at quite playable framerates, especially with 320x100 resolution set in the descent.bat file. Albeit, there's an interesting thing happens as soon as 320x100 resolution was set - the hud disappears and the fonts get stretched twice as much as before vertically, in order to compensate for the 50% loss of resolution.

[Darkcrafter07]

So I tried to find where resolution video modes are set in Descent, can not be of a much help I think? There are two files:

1) /MAIN/INFERNO.C

2) /2D/GR.C

[goshhhy]

Do keep in mind that Descent's source code is not released under a free or open source license, and is still considered proprietary and incompatible with the GPL license that Quake is licensed under - we cannot use code from Descent in Quake-derived engines.

[Darkcrafter07]

Well, I discovered that ChatGPT4 and GPT4all can code. I tried to feed it a d_draw.s file from r_stdt\486\ a segment by segment with a request to generate a code that would execute on a 486 without an FPU, then asked to find errors and bugs, fix them, sometimes to add optimization and etc... I don't know what the results are if it works and maybe somebody out there will laugh so hard at that.

d_draw16.zip