Why does Quake2 v3.20 not work fullscreen mode in the software renderer? The frame from the Quake 2 window for some reason remains even on fullscreen (Win 10 x64).
I tried to run different versions of Quake2 (for example unofficial patch v3.24). In Windows 8, this is also observed. Can this be somehow corrected ?
put this in the quake2 folder
Guardian of the Sacred Five Terabyte's of Gaming Goodness
did it work ?
Guardian of the Sacred Five Terabyte's of Gaming Goodness
Thanks! It's worked!
Another alternative would be to use a sourceport. I recommend Yamagi Quake 2, because it is based on the official sourcecode of the latest patches but greatly improved, but it doesn't alter the gameplay and sticks to the original look and feel of Quake 2. You could call it an unofficial Quake 2 7.01 patch, if you want.
My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)
wrote:. You could call it an unofficial Quake 2 7.01 patch, if you want.
But there's already a sourceport called that 😖
The problem with Quake2 sourceports are generally three things:
- Many break compatibility with mods and expect the user to recompile them on their own, which is not always possible as there's many great closed source mods out there. These source ports often invasively provide their own new game modules specific to their port, breaking in others. History revisionism has happened as a result of this (i.e. claims that the cut disruptor weapon was always in Ground Zero, which just got its balance ruined by reintroducing it)
- descend into look-i-can-code-into-a-particle-system madness without actually solving q2's long-standing gl renderer bugs and quirks; general ignorance of the common issues the software renderer doesn't have (npo2 tex, overbrights, proper gamma) and often ends up dropping the software renderer. These engines tend to be the most recommended/popular, even a certain source ports that look as old as 2002
- Mouse acceleration is still forced by default.
wrote:without actually solving q2's long-standing gl renderer bugs and quirks
What are those?
general ignorance of the common issues the software renderer doesn't have (npo2 tex, overbrights, proper gamma) and often ends up dropping the software renderer.
Once I thought it would be cool to implement colored lights in Q2's software renderer (which as I understand were dropped due to low CPU performance of the time), but unfortunately I have no time to do it nowadays...
wrote:Fortunately I've already done that. 😀
Nice. Is this still within 8-bit palette?
Since I convert 8-bit rendered framebuffer to 32 bits just before displaying (to avoid problems with paletted modes in some versions of Windows), I think I could just do the lighting in full RGB. Cheating, yeah.
I dont know if this still applies but from the unreal readme
"Some video drivers do not properly support DirectDraw full-screen
in 16- or 32-bit color at any resolution."
Guardian of the Sacred Five Terabyte's of Gaming Goodness
