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! 

Finally got the Mac build basically caught up ...

Travail screenshot

Except I have some keyboard surprises to iron out.

Still, was a relief when I typed "install travail" and no surprises there ;-) I tried to code the downloader as platform neutral, but wasn't quite sure it would work first time, but it did which is unusual when coding in C).

Think I'm going to get back to QMB particles before I mess with the Mac input code more. Also didn't test out ipv6, "connect lan" or such and I want to rework startup. 

I doubt this is involved because you posted part of log before and it looked right, but its 44100 (-sndspeed 44100).

Just pointing this out since you typed 41k. 

shwing 

Open GL Mac with QMB option

Quake level networking and direct Quaddicted install (i.e. "install travail" or what not in console) and about everything else is rock solid.

But for some reason a couple of enhanced networking items like IPv6 had to be disabled (need to read docs, see if wrong headers or need to manually add some defines).

Also, took a pass (for now) on rewiring the keyboard input for international keyboard and never anticipated WinQuake stretch as a feature so unavailable for the time being. 

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.

Ultimately, of course, this is your call. I think it's a bad call, and I think your reasons for making it are actually more theoretical than pragmatic: a whole bunch of "what if"s, in other words. 

Well, I will say this. And no obligation or anything ...

If you were ever interested either in upgrading the wrapper or writing a new one using Mark V, FitzQuake 0.85 or Quakespasm as the base (*) to do Direct 3D the way you think it should be done.

Or implement water warp in whatever way you see fit ...

I would acquire it into Mark V.

If I had a huge chunk of time --- and I don't really have time to be doing even this, but it is lifting the regret of non-completion which was a large burden to carry ---

I'm more interested in the Spike-like networking things like compression, prediction and peer-to-peer downloads than I am rendering.

That's just the kind of thing I have been fond of over time as I have learned more about it.

I know you love rendering and performance in a hard core way.

So anyway, permanent offer that never need be redeemed nor made with any kind of obligation. Door is always open.

(*) Mark V is intermixed with the software renderer. It may or may not be easy or ideal as a modding base. I've also partially reorganized code to be easier to work with (from my perspective) but it also makes it harder to work with (from other's perspectives). 

Add: Part of this, to me, was reduce all the accumulated bug-fixes ever known from Inside3d, QIP, Enhanced GLQuake/WinQuake, the Quakespasm thread, this thread, plus maybe 2 others I independently discovered (lerping of brush models that get moved in Quake immediately, interpolation immediately after load game) -- into a living engine.

Plus raid all remaining features from the well established classic engines of the past.

Add some extra level of compatibility, then throw in a software renderer that can play everything ... throw in some Nehahra support and some extra level of backwards compatability for QRally, Malice, any other crazy stuff.

Then most of the very nice engines of the past, with very thoughtful and intelligent authors each with their own specialities and point-of-view (aguirRe, Jozsef, JPG the ProQuake author) ... have their additions coded in a backwards looking but future-forward engine.

/Already then! Back to coding! This lines of code aren't going to write themselves ... haha 

"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."

Just wondering about this -- what old computer would still be running DX8? My XP laptops are both using DX9c, and Mark V won't even run on my Win98 computer (I tried! -- Mark V only complains about needing a newer OS).

From what mh said, it seems the DX8 is already obsolete for any old computer that will actually run Mark V. I mean, I guess it works for the most part... but... I get the crashes.

But I guess it would take a lot of work for someone to change it in Mark V.... 

The neat thing is that Direct3D 8 and 9 are very very similar APIs. A large amount of the work is just changing the number '8' to '9' in types; do that and you're maybe 80% of the way there. 8 has combined texture stage states and sampler states, 9 separates them, but that's not hugely different. That's 95% of the way there, and everything else is just cleaning up. 

Tried the macOS version just now...

I have a folder named "id1" with the pak files inside it, right next to the Quake and GLQuake applications. When I run Quake it says it can't find the pak files. First I get a dialog that says this:

Your Quake folder should contain a folder named id1 with pak0.pak and pak1.pak.
Opening folder...

When I press ok, it opens a Finder dialog with the folder that does indeed contain id1 and the Quake/GLQuake apps.

Then it raises another error dialog with the usual "W_LoadWadFile: couldn't load gfx.wad" error, and also:

Is Mark V in the proper folder?
(/Users/iOS/Desktop/Quake)

That path isn't where I have Mark V installed, and doesn't really seem appropriate for macOS. :-)

Just for double-sanity-check I opened pak0.pak to see that gfx.wad was in there.

Not sure where the problem is here. 

Ha OK, I went ahead and created a folder /Users/iOS/Desktop/Quake and moved id1 there, and it works.

From a quick code check, I think you compiled this with DEBUG active and that forced an unusual basedir. 

uhexen2/Quakespasm hit this recently: http://lapcatsoftware.com/articles/app-translocation.html

The short version is, you have to use Finder to drag-and-drop the .app to a different directory (this clears some security metadata), in order for the application to load things from its current directory (i.e. find an id1 directory along side the .app).

Could be related.. 

Interesting! I'm on 10.11.6 though, so that's not hitting me, but might affect other people. 

the video mode setting is not saved. At start, it is always set to 640X480 no fullscreen.
My Logitech G13 is not working, while the normal keyboard works. No error or warning message. 

 

Within 24 hours there will be a far better Mac version than the early 2015 build.

I'll double check the 2 items (folder, resolution) during testing.