Quake issues with DxWnd

[BEEN_Nath_58]

WinQuake is the official id Software port of Quake for Windows. Released in 1996, you can use it by putting the files on the original DOS release, or a separate WinQuake CD release. Regardless of what you use, the issue should be visible.

1. When running in DxWnd, if you select a "windowed mode" inside the video options, the colour palette gets corrupted. Natively this doesn't occur.
2. When running in DxWnd with Colour emulation, if you select a "windowed mode", the game gets scaled outside the screen. Natively again, this doesn't occur and the game actually creates a window and restores to my original Desktop resolution.
3. If you use the parameter -dibonly, the game gives an error, i.e. it can't run in DIB mode.

[gho]

To me, the original Winquake from the CD works well, no palette problems neither in window or fullscreen mode.
DIB mode seems working too.
Instead, I have big problems with GLquake, both with glide emulation or native OpenGL.
But the game was released and patched too many times. I think we should fix a release: where did you get your game from? (I made some tests with Internet Archive sources ...)

[BEEN_Nath_58]

I patched WinQuake on top of Quake for DOS. Everything works fine natively, but not in DxWnd windowed or Color Emulation.

The WinQuake patch was from here: https://community.pcgamingwiki.com/files/file/420-winquake/

DIB mode seems working too.

DIB mode fails for me natively as well... I think I will do better with your profile that works for you.

GLquake, both with glide emulation or native OpenGL.

I tested Glide in GLQuake long ago so I don't remember. In OpenGL I had the melting screen issue which gets fixed by disabling the Scale wGl context or whatever that setting is. I see some flickering in HUD elements, but they are present in native mode so I will try to get into that later

[gho]

I got now the Glquake working by deleting the mini-gl driver (the OpenGL32.dll file in the quake folder) and Glide2x.dll so that the game now uses the system openGL32.dll.
Here is my profile (in attach)
Curiously, the options to change the resolution (by setting "glquake.exe -width 800" in the argument line) crash the game ...
But running it with the default 640x480 resolution in color emulation mode (with OpenGL that scales the graphic with bilinear filtering) is a joy for the eyes.

[BEEN_Nath_58]

Can you send your WinQuake profile?

[gho]

Here it is. Were you using the game windowed or fullscreen modes?

[BEEN_Nath_58]

I checked WinQuake, apparently the Windowed mode isn't resetting the display mode. That is, if I am at 640x480 fullscreen, the game at 320x240 windowed will make the game go out of screen, because the desktop is at 640x480 already.

If I do this with 1280x1024 fullscreen, and then 320x240 windowed, the game will be stuck at the corner (which is normal) but with the desktop resolution at 1280x1024.

In any scenario, no window is created as it should and desktop resolution isn't reset

[BEEN_Nath_58]

Tried your profile. It doesn't seem to have the palette issues. However it has the scaling issues in DIB mode. I saw you are using -dib parameter, which doesn't exist! I guess you tried to use the -dibonly parameter. Here's how it looks with a changed resolution.

Edit: Oh to add, dibonly doesn't work with color emulation. Run in window DISABLED solve both of these problems

Edit-2: without dibonly, in color emulation, windowed modes in game have the same issue as in the attached screenshot with palette issues

Update: This same glitch with scaled windows is present in MechWarrior 2 Titanium Edition (Software renderer) installation

edit-3: I didn't notice: palette has issues in windowed mode of general directzdraw mode too

[gho]

When you refer to "WinQuake" do you mean the ddraw version Winquake.exe or are you talking about the OpenGL version Glquake.exe?
The first one doesn't give me too many troubles, it seems to work also with -dibonly argument.
The OpenGL version instead has a behavior that depends heavily on the 3DFX emulation. In origin it was supposed to work with a miniGl driver based on the Glide2x library, but things go much better if you delete both the local OpenGL.dll file (that would require a 3DFX card and Glide2X installed) and rely on the system OpenGL.
Here both they work with and without the "-dibonly" flag. Is it possible that the argument should be uppercase or written in some other way?

[BEEN_Nath_58]

WinQuake means Quake for Windows. WinQuake supports the following:
1. VGA8.DRV: Standard VGA
2. LINEAR8.DRV: VESA Linear Frame Buffer for direct to VRAM write/read.
3. ACCEL8.DRV: VESA Accelerator Function
4. WINDOWED
5. DIB
6. DDRAW8.DRV: Only available if DirectX is installed.

1-3 is available of course when:
1. You successfully make a wrapper for SciTech WinDirect based on MGL.
2. You successfully manage to get a BIOS and manage to hook into the video INTs correctly and emulate the BIOS from the Windows.

Knowing that 1-3 is a task, I haven't even imagined about it, but trust the other 3 modes that are supported. By default, Quake works on Windows for 4-6 natively. By default, when DirectDraw acceleration is available, DDRAW8.DRV is used.

Using the -dibonly flag will use the DIB mode instead of DDRAW8.DRV. Windowed is available in both DDRAW8.DRV and DIB modes.

The benefit of DIB mode is it supports video modes in any condition: 320x240 will go fullscreen even if the driver doesn't support it.

As I wrote previously, PCGW hosts WinQuake 1.09. You could better download it and just paste it on top of your current game and it should just work

[gho]

My current game is version 1.09

[BEEN_Nath_58]

Use -nodirectdraw parameter to force DIB mode, since Windirect is disabled on NT version check

[gho]

I started to find some problem when setting "color emulation" and the game windowed mode.
But I need some time to locate what could be wrong ...
On the contrary, I got no problems with either the -dibonly or the -nodirectdraw parameters.

[BEEN_Nath_58]

Okay you can continue with work on the problem since they have some similar nature.

Btw, onr problem that you could face: with -dibonly or -nodirectdraw parameter, using Color emulation will produce a Couldn't set DIB fullscreen error. With Run in Window disabled again, everything seems fine

[gho]

I made some fix to the logic, but there were still problems when switching resolution from the in-game video options panel. So I started to read the logs and found something interesting.
Starting the game without DxWnd (I just turned it off and set the 8 bit compatibility mode) even in the window mode the game sets the screen for FULLSCREEN mode. The effect is that the desktop becomes black for a while, then returns to the usual desktop image with a small window where Winquake runs. This is a strange behavior (usually in window mode the programs don't set the FULLSCREEN mode).
When the game runs with DxWnd and the "color emulation" mode I would expect an identical behavior, but in effect it goes quite differently, it turns the screen resolution to the game size, so for instance you have a desktop set at resolution 320x200. I think this is the source of our troubles.

[gho]

I found the problem.
When starting in window mode, WinQuake sets anyway the screen in 320x200 fullscreen mode for a quick instant (maybe it is a check, or maybe Id guys just forgot ...) and then immediately reverts to the desktop video mode.
But the operation is made with a ChangeDisplaySettingA(NULL, CDS_FULLSCREEN);
Here https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-changedisplaysettingsw Microsoft wrote this:

Passing NULL for the lpDevMode parameter and 0 for the dwFlags parameter is the easiest way to return to the default mode after a dynamic mode change.

but they didn't say that you can do that also with flags = CDS_FULLSCREEN, so in my wrapper the condition was not recognized.
Now I got a release filled with changes, most of them likely useless or dangerous, but in any case it seems to work with WinQuake. You can use it while I polish the code a little bit.

[gho]

Some profiles. You can change the video mode and set the arguments in the "Hook > Command line" edit box

[BEEN_Nath_58]

Impressive... noDirectDraw is working very fine. While you are active, I should add a note.

You used NO SHIMS. The game may have shims, but I didn't check it but regardless NOSHIMS has 1 single issue. In Daikatana and Quake, resolution changes don't work properly. For example: in both games, changing the fullscreen resolution would resize the screen and incompletely change the game res,

I tested Quake now with the same issue and the same fix.

Update: Winquake.dxw isn't working properly

[BEEN_Nath_58]

Phew, done with the cooperative level issues. What remains now is the in-game windowed mode in DDraw mode. The colours are wrong.

Well this is probably an unmaintained case, because scaling fails as well, the screen size overflows

[BEEN_Nath_58]

Looks like the same solution should fix the CZERO scaling issue too

[gho]

I am puzzled. I never got wrong colors on WinQuake in ddraw mode (that is WinQuake.exe with no extra argument, am I correct?). Could it be because I don't have any DDRAW8.DRV file in the game folder? Maybe a solution could be to delete the file?

[BEEN_Nath_58]

I shot a video with my phone. I have show both the scaling and the colour issue.

DDRAW8 is a part of the game engine, hence inside winquake.exe to my knowledge .

Update: easier method to reproduce. Go to Video tab, choose HD resolutions only. So game will only have 720p.highest resolution. That mode has colour issues already in fullscreen

[gho]

Sorry, I don't have color problems also setting the game as you suggested. I got a screenshot in color emulated mode at 720x576 and colors seem correct. It must be a problem with your video card, maybe.

[BEEN_Nath_58]

720p as to 1280x720. The issue happens on Windows XP as well.

[BEEN_Nath_58]

In case you want to, WinDirect source code was release very recently:
https://github.com/kendallb/scitech-snap-graphics/tree/master/private/src/obsolete/wdirect