That's just how it was, the fonts/menu were fixed resolution and didn't get scaled.

Well, access to the VESA BIOS is probably very slow if it uses INTs to handle SVGA video, because that API type requires a lot of work to just process the service request, and switching to a different working 64k bank might require over 1,000 cycles. Also, other features available through VESA would probably require similar. Standard VGA can work directly, and most such functions only need a direct memory or I/O access. If I'm wrong, I ask somebody here to correct me.

The menu uses a lookup table and reads every pixel from video memory before making it brown and then drawing the menu over it. 1.07/8 (from the mission packs) changes this to a black mesh pattern that doesn't read.

leileilol wrote on 2024-09-05, 05:24:

The menu uses a lookup table and reads every pixel from video memory before making it brown and then drawing the menu over it. 1.07/8 (from the mission packs) changes this to a black mesh pattern that doesn't read.

Harry Potter wrote on 2024-09-04, 23:40:

Well, access to the VESA BIOS is probably very slow if it uses INTs to handle SVGA video, because that API type requires a lot of work to just process the service request, and switching to a different working 64k bank might require over 1,000 cycles. Also, other features available through VESA would probably require similar. Standard VGA can work directly, and most such functions only need a direct memory or I/O access. If I'm wrong, I ask somebody here to correct me.

But then why fps decreases from 60 to 2-3 becoming a pain to move and select options in the menu? That doesnt feel normal.

Maybe there is a corrected version? Which is the best version can I download for a retro computer with windows 9x?

psaez wrote on 2024-09-05, 06:04:

But then why fps decreases from 60 to 2-3 becoming a pain to move and select options in the menu? That doesnt feel normal. […]
Show full quote

leileilol wrote on 2024-09-05, 05:24:

The menu uses a lookup table and reads every pixel from video memory before making it brown and then drawing the menu over it. 1.07/8 (from the mission packs) changes this to a black mesh pattern that doesn't read.

Harry Potter wrote on 2024-09-04, 23:40:

Well, access to the VESA BIOS is probably very slow if it uses INTs to handle SVGA video, because that API type requires a lot of work to just process the service request, and switching to a different working 64k bank might require over 1,000 cycles. Also, other features available through VESA would probably require similar. Standard VGA can work directly, and most such functions only need a direct memory or I/O access. If I'm wrong, I ask somebody here to correct me.

But then why fps decreases from 60 to 2-3 becoming a pain to move and select options in the menu? That doesnt feel normal.

Maybe there is a corrected version? Which is the best version can I download for a retro computer with windows 9x?

I would try the latest release first (1.08, AFAICR) . It is pretty much a given that the oldest version will have the most bugs. While newer releases might be slower in some cases on really old (slow) hardware, there can also be optimizations/improvements. My personal approach is to try the newest release first and move back to older releases only if necessary.

psaez wrote on 2024-09-05, 06:04:

But then why fps decreases from 60 to 2-3 becoming a pain to move and select options in the menu? That doesnt feel normal.

Rendering a scene to a video buffer, then reading video memory, letting the CPU work on it, and then writing it back always has been a slow process. It's no programmable pixel shader where the GPU can do this job. It's the same deal when you play other 3d games in software rendering and a blended effect drawn on screen brings the frames down (like translucent smoke trails, glass windows, etc), exponentially slowing down in higher resolutions. This is normal behavior.

Third-party source ports are all based on a newer codebase (1.09) that removes this brown menu fade and won't exhibit the same behavior.

darry wrote on 2024-09-05, 06:40:

I would try the latest release first (1.08, AFAICR) . It is pretty much a given that the oldest version will have the most bugs.

Not the case with Quake... because they forgot to test the later builds without a sound card present.

jmarsh wrote on 2024-09-05, 07:12:

darry wrote on 2024-09-05, 06:40:

I would try the latest release first (1.08, AFAICR) . It is pretty much a given that the oldest version will have the most bugs.

Not the case with Quake... because they forgot to test the later builds without a sound card present.

Good point, though in that specific case at least, -nosound will bypass the issue.

leileilol wrote on 2024-09-05, 06:45:

Third-party source ports are all based on a newer codebase (1.09) that removes this brown menu fade and won't exhibit the same behavior.

Is there source available of the original effect, so it could be optimized/rewritten as a shader? (without reverse engineering the old executable)

Sorta.

The source release lacks the menu drawing fade functionality, BUT there's one obscure spot in the source release of an unused 'gelmap' rendering mode for models and it's the same exact color lookup calculation the menu did (but on a different row of colors) so that's adaptable to reproduce the menu fade.

To 'optimize' the effect in software rendering, you would have to reserve system memory for a video buffer, get all the spans to draw on that instead (just for the menu only), and then pull that through the fade lookup and it would be much faster.

leileilol wrote on 2024-09-05, 18:51:

To 'optimize' the effect in software rendering, you would have to reserve system memory for a video buffer, get all the spans to draw on that instead (just for the menu only), and then pull that through the fade lookup and it would be much faster.

Maybe I'm missing something but for software rendering why not just use a different palette to "brownify" everything? There were a few other games that used that trick to desaturate the game screen when pausing.

Quake doesn't really 'pause' when you enter the menu. The game still renders in real-time

That doesn't matter though, the effect could still be done simply by switching the palette.

jmarsh wrote on 2024-09-05, 21:50:

That doesn't matter though, the effect could still be done simply by switching the palette.

If you changed the palette to make the game visuals brown, the menu would also become brown and would no longer stand out very well, likely defeating purpose of the whole thing. Unless there was part of the palette which was reserved just for menus.

A lot of palette fade tricks you might've seen in dos games (i.e. that indiana jones game, omf2097, etc) usually have a lower range of colors for palette effects so they could do weird fun tricks like alleged smooth alpha fades of text and screen crossfades. Quake renders on all the color indexes so there's no room for palette trickery. Maybe it'd be different if this were a PC-98 port. Also Quake supports a variety of video modes (VGA,ModeX,VESA2) so whatever VGA trick you may think of from the demoscene likely cannot apply.

bakemono wrote on 2024-09-06, 13:27:

If you changed the palette to make the game visuals brown, the menu would also become brown and would no longer stand out very well, likely defeating purpose of the whole thing. Unless there was part of the palette which was reserved just for menus.

Years ago I modified winquake's software renderer to work in 32-bit mode with 8-to-32-bit palette lookup made in software. This was to workaround the broken palette bug in Vista and Win7 (Win8 fixed that). It should be easy to have multiple palettes at the same time this way.