ProQuake 4.43

[Baker]

Hmm.. the football map on RA seems to crash my D3D. I'm running Win7.

I'll take a look at it. This is d3dpro and not dx8pro, right?

Add: Just checked ... it sure does crash d3dpro every single time. I'm running XP. dx8pro runs it fine.

[Wolv]

Err, I'm not sure what happened, but it seemed to work after I ran GLPro, connected to the server and came back with D3D. But I noticed when I get runes that have a glow around me (eg, 10 second invulnerability or get frozen), my screen goes completely green. Not sure if that's my hardware or D3D. I didn't have that problem when I played Qtag, which is the same effect, but I'll double check it in a sec.

Edit;

Nevermind, it still crashes. Only works if I'm in the spawn room.

Edit 2;



There's another rune that makes it go black, but I can't remember off the top of my head.

[Baker]

Download: ProQuake 4.48 - 1.5 MB (Source)

1. Several dx8pro improvements. I thought I had the problems nailed down in 4.47 --- I didn't. Only differences I can think of from the glpro build ... no support for setting video mode frequency (refresh rate), vsync isn't shift on the fly but command line parameter enabled (-vsync). And for some reason switching to windowed mode from fullscreen, the Quake window is always "topmost". I've done tons of reading Windows API to see if I could "cure" this issue, so far to no avail.

2. WinQuake build (wqpro) supports .pcx skyboxes.



3. WinQuake build (wqpro) supports "FTE stains". Will be making this a cvar in the future, but I've always been curious about some of the features in FTEQW's software renderer.



4. gl_ringalpha cvar is now r_ringalpha ... I plan to come up with some "transparent" weapon equivalent in wqpro just for the sake of completeness.

Likely 4.49 will be out in the next 8-12 hours with possible features including:

- Map/demo name completion and such.
- Reloading the sbar pics and console graphic on gamedir change.
- Uploading lightmaps when gl_overbright changes
- Possibly some Quakespasm fixes.
- Maybe adding ALT+ENTER fullscreen to windowed capability to wqpro
- Big skyboxes like 1024 x 1024 crash glpro. Fixme. (back2forwards moon skybox)

Err, I'm not sure what happened, but it seemed to work after I ran GLPro, connected to the server and came back with D3D. But I noticed when I get runes that have a glow around me (eg, 10 second invulnerability or get frozen), my screen goes completely green. Not sure if that's my hardware or D3D.

I'll look into those and fix them for sure. RuneQuake uses content blends for the shield (invulnerability) and a couple of other ones.

I will fix.

Not sure if that's my hardware or D3D.

No, it is totally my fault. I forgot about d3dpro's handling of view blends and made it the same as glpro and dx8pro. It did this maybe in 4.47 without considering that d3dpro needs it slightly different.

[MH]

SetWindowLong (hWnd, GWL_EXSTYLE, 0);

This might cause the D3D device to become lost, I honestly don't know, but there is code there to reset it if so. Probably best to modify it inside the wrapper during the mode change instead of in your main code.

[metchsteekle]

2. WinQuake build (wqpro) supports .pcx skyboxes.



3. WinQuake build (wqpro) supports "FTE stains". Will be making this a cvar in the future, but I've always been curious about some of the features in FTEQW's software renderer.

[Baker]

SetWindowLong (hWnd, GWL_EXSTYLE, 0);

This might cause the D3D device to become lost, I honestly don't know, but there is code there to reset it if so. Probably best to modify it inside the wrapper during the mode change instead of in your main code.

Sigh ... I've tried that plus several other things.

Just the day and time that I give up on whatever the heck is causing this problem will be the moment I solve it on accident or the solution reveals itself to me.

Little things like this bug the heck out of me.

See it already does that actually ...

	winexstyle = 0;
		winstyle = COM_CheckParm("-fullwindow") ? WS_POPUP : (windowed_ ? WS_OVERLAPPED | WS_BORDER | WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX : WS_POPUP);

	// reset stuff
	SetWindowLong (d3d_PresentParams.hDeviceWindow, GWL_EXSTYLE, winexstyle);
	SetWindowLong (d3d_PresentParams.hDeviceWindow, GWL_STYLE, winstyle);

As you can see, your wrapper sets winexstyle to 0 and does exactly the above. It's strange. Not a big deal, I suspect it has something to do with vid_wgl.c in "GLQuake" setting up the window and something not getting cleared.

Therefore, it isn't the wrapper at all. I know "GLQuake" sets HWND_TOP for fullscreen mode, but I've tried setting HWND_BOTTOM even to clear it and it just doesn't do it.

Something small and subtle is at play here.

[R00k]

i used to have this poster, it was used as a memorex commercial, for cassette tapes.
"Is it LIVE or is it MEMOREX?" was the caption... ugh now i feel old

[Baker]

Small annoying issues always bother me quite a bit:

New ones I've discovered:

1. I've unlocked the "WinQuake" (wqpro) build from being locked to the primary desktop monitor and made the positioning mirror glpro. Unfortunately, if you move the window to monitor #2 and have this 2nd monitor to the "left" of the primary screen, non-DirectInput mouse input goes haywire. It's fine if the monitor is to the "right" of the primary screen. You'd need dual monitors to know what I'm talking about regarding the positioning. Without DirectInput Quake relies of locking the mouse cursor to the current window bounds and moving the cursor to the middle every frame and measuring the travel distance. Apparently Windows can't handle negative values for some of the API or rejects them.

2. If the Quake window loses focus without being in the menu or console while in windowed mode and you try to click the "close button" or move the window, this fails. It is a long story of why this happens, it wouldn't be all that difficult to address but I don't want to waste my time on such a rare event at least right now.

[MH]

According to the info I could find, GetCursorPos and SetCursorPos are both capable of handling negative coords, and the POINT struct they use specifies it's members as being of the LONG type, which is a signed type and so should be capable of coping with it.

I wonder is it the in_win.c code that's messing you up here? Some breakpoints or Con_Printfs in VID_UpdateWindowStatus might help.

[Baker]

According to the info I could find, GetCursorPos and SetCursorPos are both capable of handling negative coords, and the POINT struct they use specifies it's members as being of the LONG type, which is a signed type and so should be capable of coping with it.

I wonder is it the in_win.c code that's messing you up here? Some breakpoints or Con_Printfs in VID_UpdateWindowStatus might help.

I'll end up doing some tests. Might be ClipCursor that apparently doesn't support it. It'll get solved one way or another.

[Baker]

Download: ProQuake 4.49 - 1.5 MB (Source)

glpro/dx8pro/d3dpro

1. Overbright lighting now switches in real-time without need to restart the map.
2. r_shadows actually work if interpolation was off. It was broke.
3. A couple of minor fixes from aguirRe's Enhanced GLQuake.

wqpro

1. ALT-TAB now switches between windowed mode and fullscreen.
2. r_novis support.
3. wqpro in windowed mode can be positioned anywhere on-screen including a dual monitor and centers just like glpro and every other non-wqpro does.
4. Some miscellaneous changes to make it similar to glpro regarding video mode switching.
5. r_wateralpha "stippling" support from the Makaqu engine (read about the Makaqu engine) ... Makaqu is a highly advanced WinQuake engine that supports cell shading and better flames and so forth.

When I get time, I really need to create some "credits" documentation for where external features originated from. In the past, it was mostly me and R00k exchanging ideas and doing things like adding video mode switching or direct input switching in at nearly the same time or R00k or aguirRe giving me bug-fixes, heh.

But lately, I've been incorporating features from a number of different sources very rapidly. So with the next update, I'll add a credits.txt text file to keep track of that.

[MH]

Source linkee no workee?

Never actually tried WQPro before but I'm hugely impressed by it. Superlative performance. Could I suggest making -startwindowed the default behavior with it? Rationale: if you want a fullscreen mode, starting windowed and switching to fullscreen is tolerable. If you want a windowed mode starting fullscreen and switching to windowed is horrible. (Using the same HWND for the splash screen as for your main window, and switching into the full mode after loading the configs would be better still.)

Oh, and values of r_wateralpha > 0.6 didn't work with it. Otherwise, superb as always.

[Baker]

Source linkee no workee?

Works now. I named the file wrong.

Never actually tried WQPro before but I'm hugely impressed by it. Superlative performance. Could I suggest making -startwindowed the default behavior with it? Rationale: if you want a fullscreen mode, starting windowed and switching to fullscreen is tolerable. If you want a windowed mode starting fullscreen and switching to windowed is horrible. (Using the same HWND for the splash screen as for your main window, and switching into the full mode after loading the configs would be better still.)

Oh, and values of r_wateralpha > 0.6 didn't work with it. Otherwise, superb as always.

I'll play with the value ranges. I agree with the starting in -window mode, eventually I'll probably make the default behavior. Might not happen "soon" because I may end up re-writing the video code.

I see no reason that the WinQuake video mode selector screen shouldn't be near identical to the GL version.

[Wolv]

D'oh. Crashes on DM6 too.

[Baker]

Wolv, give dx8pro a try. dx8pro at this point is pretty much the successor to d3dpro as the FPS is equal (in my testing) and dx8pro is superior to d3dpro in every way (doesn't ever crash, better features, better looking, etc.).

I won't ever be dropping the d3dpro build, but I'd encourage you to give it shot.

And --- if you don't like dx8pro for some reason or you can't kick as much ass with it, tell me why, etc.

[That being said, I will be fixing the blend issue in d3dpro. However, d3dpro crashing on certain maps is hard to address, it is based on d3dquake which was always fragile].