I get a very consistent crash when trying to switch back to DX Mark V after alt-tabbing away, when I am running full-screen with vid_hardwaregamma 0

It does not occur with the GL version, or when using vid_hardwaregamma 1

It also does not occur if I am just sitting in the console before loading a map.

It also crashes if I am running it in a window and I try to adjust my windows gamma settings under the same circumstances above. 

there are at least two ways for a model tweaked for GL to be screwed by software rendering.

That's both hilarious and sad :/

@spike - that is interesting. given quake's initial low resolutions and non-interpolated animations, they might as well have just used sprites. They would've been better looking and probably easier to do. I suppose they pushed the tech knowing that appropriate hardware was just around the corner. 

The skin application in GLQuake and WinQuake are different. See the argument in the Quakespasm thread (it's buried), the different viewpoints and the final consensus reached by the developer types and mappers.

@re: GL runs fine

Awesome! Provides me with a little bit more incentive to build a Windows "WinQuake rendered via Open GL" like the Mac WinQuake Mark V. 

WinQuake rendered via Open GL

that has a nice ring to it. aside from the mac version, is that a first of its kind in terms quake ports? 

As someone who is exceedingly detail oriented, I give myself an F-- on the DivX download.

I'm very upset that I didn't investigate the current download (I trusted them!).

That download is complete trash, I just assumed since I always used that page that the downloads were quality and not corporate bloatware.

I am sorry.

When I release Build 1010, I will be updating the Mark V page with 2 proven reliable codecs (Google WebM) and the *real* XVid minimal (fast as hell).

On a positive note --- 2 Windows 10 machines --- capturedemo runs with flying colors with a proper codec installed.

/Why do some machines --- using Quake 11025 sound hz sound terrible and need 44100 just to sound ok? While other machines original Quake 11025 sounds just fine? Peeve of the day. 

Not exactly, haha. Read the "Mac Version Based On Fruitz of Dojo" on the Mark V page.

They invented it ages ago (2002?). It's a wicked idea and I've always liked it. 

I'll check it out. 

I wrote engine tutorials on demo rewind once and made working examples. qbism used it as reference to add demo rewind in Super8.

In Mark V, I went a bit obsessive and redesigned the FitzQuake 0.85 animation interpolation on just the client side to be completely reversible.

/Let's just say I like demo rewind 

Can't reproduce. I used vid_hwgamma 0 and did several different things with ALT-TAB with maps running.

I use Alt-TAB and ALT-Enter all the time.

Does happen with clean install? What map is running? What mod is running? What does the Dr. Watson report say is complaint (if that applies in this case)?

I don't know too much about the internal wiring of the Direct3D wrapper.

Something to keep in mind, may or may not apply here, the Direct3D wrapper has been in use for ages in ProQuake (and it got a lot of use for "Open GL crashes/bad drivers"). I think I always kept the -gamma texture command line parameter allowing opt out of hardware gamma.

I'd recommend "developer 2" and then upload qconsole.log and maybe I'll see something. What I do know is this ... if vid_hardwaregamma 0 is in config.cfg and you start Mark V, Mark V never so much as touches system gamma even once.

Does this happen when you start game in id1 when there is already vid_hardwaregamma 0 in quake\id1\config.cfg. 

In windowed mode, with vid_hardwaregamma 0 and gamma set, I can't think of anything obvious.

Windowed. ALT-TAB little different than using the menu or pulling up the console except the loss of keyboard focus. On Windows in really rare situations. Do you have 2 copies of Mark V open? I could possibly see something as possible there, yet I've done that a hell of a lot.

Fullscreen. There are more potential things that could happen with ALT-TAB. Are you connected to fvf.servequake.com or running -FVF or can this happen with clean id1? As far as I can tell, in fullscreen mode it would always need to reload all the textures ... and this means recoloring all skins and external textures too. I've not had a problem thus far, not even connected to FVF an hour ago trying to cause a txgamma + DX8 + ALT-TAB crash and I was doing game -FVF for thoroughness.

/But you say this happens in windowed mode. It doesn't need to reload textures or recolor skins or anything in that scenario. 

This sounds like lost device handling somehow got broken.

In D3D terms, a "lost device" is what happens when you Alt-tab away from a fullscreen mode, but it can also happen under other circumstances (power-saving transitions, etc) and Microsoft don't document them all - primarily because it's actually impossible to (3rd-party software/drivers/etc may trigger a lost device for internal reasons of their own).

Changing Windows gamma while running in a windowed mode sounds like one of those other circumstances. Changing the screen resolution while in a windowed mode would be another.

The important take home is that naively detecting if an Alt-tab has happened is the wrong way to go about this. Instead you check the HRESULT from your Present call, if it's D3DERR_DEVICELOST you issue a bunch of TestCooperativeLevel calls until you get D3DERR_DEVICENOTRESET, then you release all default pool resources, Reset the device, then issue another bunch of TestCooperativeLevel calls until you get D3D_OK at which point the device is no longer lost and you can recreate the default pool resources.

Typically you'll get a crash if there is a default pool resource not released (more typically the Reset call will fail).

Hopefully that's sufficient info for Baker to troubleshoot. A good test to reproduce might be, like I said, try changing the Windows display resolution while running in a windowed mode. That should trigger a lost device, then trace through the code with breakpoints on the TestCooperativeLevel and Reset calls. 

MH: Hopefully that's sufficient info for Baker to troubleshoot.

Baker: Gunter ... MH say "don't play with Windows gamma control when DX8 version running."

He also say for best laptop maintenance, you should run laptop through dishwater once a year to clean keyboard. 

The drivers I have on Win 7 don't seem to care if I play with the gamma in Windows while DX8 is running. Fullscreen or windowed, vid_hardwaregamma or not. 

I even changed the video mode in Windows after ALT-TAB out of dx8 both in windowed and fullscreen -- it didn't care at all and continued on.

My DirectX drivers would be quite different on Windows 7 vs. Windows XP, I would imagine. 

Ok, more testing.

Started Mark V DX clean, no config.cfg, no external anything. It defaults to a 640x480 window, and the standard demo starts playing (though I find if I stop the demos this behavior doesn't change). Then I click away from the window and adjust my windows gamma = crash. Dr. Watson says "Access violation." If you can tell anything from this, the chain of things Dr. Watson lists are:

dx8_mark_v.exe - iglicd32.dll - igldev32.dll - uxtheme.dll - etc.

Last couple lines in qconsole.log:

Accessibility keys enabled
Hardware change detected ... Gamma system set

But those things happen as I switch focus away from the window.

Repeat experiment with GL version = no crash.

Repeat experiment on older WinXP laptop, and no crash, but I notice a difference -- on my Netbook I am using a system tray icon that lets me select a pre-saved scheme for my gamma (and probably other settings). When I apply that, the whole screen flashes black for a moment. My older WinXP laptop doesn't seem to "Reset" everything like that when I just adjust the gamma. And I find that if I actually go into the video control panel on my netbook, I can simply adjust the gamma slider without anything bad happening too....

So it's not really gamma, but when my display settings get... "reset."

I find I get the same screen flash + crash if I alter my color depth or resolution (yep!).

Doing all these things on my older Win XP laptop = no crash.



Now for alt-tab in full screen testing.... I'm finding that now any alt-tabbing of fullscreen DX (not the more specific circumstances I previously mentioned) is crashing it.


And once again my older WinXP laptop handles it fine, as does the GL version.


So it seems that my netbook is doing some kind of harder reset of the display settings perhaps? Along with that stuff mh said. 

Small chance that if you turn off Themes in Windows XP, may avoid the over-protectiveness.

http://www.pcauthorities.com/windows-xp/disable-themes-in-windows-xp/ 

I forgot/neglected to mention - the Direct 3D driver model is very different on both OSs. Remember back in the dark days of Vista and Direct 3D 10, when Microsoft wouldn't make it available on XP? The different driver model is the reason why.

So it's XPDM (XP-) versus WDDM (Vista+) and WDDM is going to be more robust against crap like lost devices.

To make things even more interesting and fun, AFAIK D3D8 or lower don't even natively exist on Windows 7/WDDM (don't know if the same is true for Vista) - they're instead emulated through a D3D 11 layer. Likewise the old fixed pipeline doesn't natively exist anymore but is instead emulated via shaders (this is true even of D3D9 on XP).

So bottom line is that of course certain behaviours on XP and 7 are going to be different, and 7 is not a good testing platform for XP clients. 

microsoft tweaked their video memory routines for vista. before that they'd purge video memory on a whim - without even telling the gpu driver iirc. with vista, their compositor required them to not randomly wipe all gpu memory, which also means that earlier versions of d3d are less aggressive at randomly wiping memory, at least when running on vista+.
opengl drivers worked around it by retaining a copy of all their textures in host memory as well as on the gpu (which comes in useful when there isn't enough gpu ram), hence how they're able to recover properly on xp.

you can still get lost devices. opengl has an extension for it (and may still tell you about task switches so other programs can use video memory while you won't need it), and its part of the vulkan spec, but its much rarer that its fatal, enough so that you can afford the extra time taken by a full vid_restart (though you should probably not destroy the window itself).
typically it only happens (in vista+) when a driver is uninstalled or reset (the gpu crashed/stalled for 2 secs). Its also quite easy to crash a gpu with dodgy vulkan api use... 

To be honest, you would at this stage get better compatibility lifting the wrapper to D3D9.

I know that sounds counter-intuitive, I know that you're all about compatibility, and I know that you view the D3D wrapper as a means of providing compatibility in the face of deficient GL drivers, but using a lower D3D version is not necessarily the best way of doing this. It's not necessarily even a good way of doing it.

Take note of what I wrote above, paying attention to the part about D3D8 or lower no longer natively existing. That's hurting you and it's hurting your users.

Reality is that D3D8 was only a short-lived stopgap version between 7 and 9 whereas 9 was the mature, well-supported version that had a lifespan of over 10 years.

Lift it to 9 and you still get compatibility with XP, Vista, 7 or higher. Stick with the fixed pipeline on 9 and you'll get compatibility with hardware that even pre-dates D3D9. A lot of crap like your testing not being valid or your inability to reproduce bugs will just go away. 

Yeah, why you wanna hurt me with D3D8 Baker??

Heh, well, disabling themes seems to make no difference. But I get inconsistent results in testing....

Now it seems like if I alt-tab from just sitting in the console, it will crash, but if I alt-tab while a map is running, it works?

I was trying various things, like toggling the value of vid_hardwaregamma and sometimes it seemed like that was making a difference.... But now I'm not sure if that was it.

It works sometimes, and sometimes it doesn't.

Currently it seems like trying to do stuff (gamma change or alt-tab) either in console or with the startup demo running = crash, but if I load a map, then stuff works.

But I'm certain it has crashed before even when a map was running and I tried to do stuff....

So yeah, this is probably some back-end, obscure DX stuff which mh seems to know a lot about. 

I fall in the Applied Sciences camp (build bridges, highways). Knowledge for the purpose of building something and only for a specific goal, almost always must be part of the plan. Live by 90/10 rule.

I'm not going invest 6 months of learning Direct3D for (mostly) 1 computer that is 10 years old.

Many, many times I do fall into agreement with the Pure Sciences camp (you and Spike) ... like for instance Mark V has single point once-per-frame mouse code -- best maintenance free concept ever. It probably has 25 design principles that both of you would agree with, that I have forgotten -- like Mark V literally has automatic detection of transparent water -- not something close or can figure it out in any single frame, but the real deal. Or how Mark V does not have different source code for Winsock vs. BSD sockets (Mac/Linux) on the network side.

The Open GL is the main hardware accelerated build.

The nicest thing about the Direct3D 8 wrapper for old computers ... these old computers -- the drivers will never be updated, so the Direct3D 8 wrapper can never become obsolete.

I'm not a pure knowledge guy, I'm a "I have well-defined goals" guy. Plus I'm just one guy. My goal is single-minded pursuit of finishing.

"Real Artists Ship!"

I know that must drive you a bit crazy as a perfectionist, who is probably doubly annoyed that some of these things are your speciality (Direct3D, optimized rendering) ;-)

/And those like Gunter will be pretty happy with the results, even if he can't play with Windows gamma while the DX8 version is running. The other nice stuff (next update QMB) will make he not really care that much ;-) 

Is finally being updated. 

I would lean towards it being a sound driver or Windows bug.

I hit a similar problem with SDL2, with just one of its audio output backends (xaudio2) producing distorted audio at 11025Hz; the others (winmm, directsound) were fine. https://bugzilla.libsdl.org/show_bug.cgi?id=2551

I know that's not directly helpful..
Bloughsburgh - if you are up for more testing, it might be worth giving Fitzquake 0.85 and the original id winquake.exe a quick check - both of those will also output at 11025 by default, and I expect they will have the same distortion that Mark V does, if it's indeed a windows / driver issue. 

I know that's not directly helpful..

Sure it is. Your knowledge of audio vastly exceeds mine.

Tells me I'm not going insane when I test on a random Windows 10 machine and that specific one, the audio is horrible and the others aren't. 

I tried winquake.exe and it appears to have distortion but I felt it to be less pronounced than Mark V. That could be placebo it is hard to tell.

The worse problem is the echo/airy sound when sndspeed is set to 41k. It is hard to explain through text so perhaps I will record a video and you can hear from there!