@NightFright - ;-)

@dumptruck_ds - Until I get my hands on a non-Xbox controller like a PS4 one, I'm going to force non-Xbox controllers to be ignored (if I can, and I believe I can). In theory, I could code the axis/button remapping without having a controller, but I know from practice that "on the blind" coding usually is a quagmire.

Eventually, I'll get my hands on a PS4 controller ... but I'd like to ask you this.

Is getting a PS4 controller to work with Windows as easy as plugging a USB cord in (it is that simple with the Xbox One Controller S, as an example). 

I looked through your list.

First 2 items resolved. #1 already fixed. #2 - sound stutter on vid_restart that occurs on some machines (I've witnessed it first hand on a couple) should be fixed.

I looked at the sky in GLQuake vs. Mark V vs. Quakespasm with gamma 1 and contrast 1 which shouldn't be setting neutral.

The sky does indeed not look quite the same as GLQuake! But ironically appears to look about the same as WinQuake.

So now, I'm not quite sure what to think. WinQuake is kind of the baseline that GLQuake was supposed to look like. Still, maybe an option will happen.

Other things: tga fonts + alpha masking for replacement fonts. Older replacement fonts supported FuhQuake/JoeQuake which has less flexible rules. The newer ones tend to be oriented towards DarkPlaces which has different rules regarding the alpha masking (more proper rules, I would say).

The main issue that has caused me to do nothing is that the replacement fonts for DarkPlaces don't tend to be a 1:1 drop-in replacement but rather really need larger resolutions or they look terrible in resolutions like 640x480.

I had once drafted up a solution been eyeing a solution which is to determine the minimum scaling when loading the replacement font. But the fact I didn't do it bothers me --- I may have run into an issue like HUD replacements and font replacements might require the same base scale under certain circumstances.

WinQuake: A 16-bit renderer would be a massive undertaking. Mankrip lives and breathes the software renderer. My level of interest in the software renderer is very close approproximation to the original WinQuake feature set + modern maps. I would eventually like to get alpha masked textures working (I've made several runs at it). As for HUD scaling, FitzQuake has a ton of canvases and scales all over the place. Mark V's software renderer isn't actually based on WinQuake, especially not the placement and canvasing. A dedicated WinQuake-only engine like Engoo or super8 need not worry about canvasing consistency with a Direct3D/OpenGL version, but one of the main features of Mark V being able to switch between the WinQuake/hardware versions on a whim and get nearly the same experience. Re-writing all that canvasing would take far too much time, especially when the less capable but fairly accurate approximation "stretch mode" is available in video options.

Also looked at bloom. Then realized that at the moment I cannot bloom to work in the Direct3D build but I believe it is fault of something on my end (as opposed to the wrapper). I'll probably look at in the future.

Likewise, multisample isn't supported in the Direct3D version at all and to some extent I'm not 100% that multisample is relevant these days because simply using a higher resolution with a larger scaling factor typically gets approxiamately basically the same results. Multisample with modern very high resolution monitors on 3D renderering is going to be mighty tough to notice, but on older hardware like 640x480 crt modes yeah you can easily tell.

The Direct3D 9 wrapper's level of performance (rendering speed) and stability (AFAIK not even a botched NVIDIA update can mess with it, so it may be totally immune to those kinds of problems). 

Direct 3D supports multisampling but the details are interesting.

The OpenGL philosophy is "the programmer can go nuts and the driver will do it's best to sort out something that works".

The Direct 3D philosophy is "the programmer absolutely positively cannot go nuts, and that sorting out something that works business is on your shoulders, matey".

In a native D3D application this is actually easy. You just enumerate the supported formats and follow the rules.

In an emulation layer that has to translate from the GL spec (and oh lordie if it's pre-3.0 stuff) to the D3D rules the path of least resistance is to just not advertise the extension.

Sure it can be done. But time, patience and sanity are finite resources round my way. 

I have yet to actually game with a PS4 controller on a PC. Or a PS3 for that matter. When I plugged in the PS3 controller via USB drivers were installed but I don't think they were with the PS4. I do know Steam supports PS4 and you can use them with Sony's streaming setup. I have zero experience with Bluetooth on my PC so that may be the ticket. No idea and doubtful.

So using those controllers is NOT plug and play. That makes sense to me as Xbox controllers are native for the most part in Windows and Sony interfacing with PCs has been historically clunky - usually their software is pretty wonky there. 

The following will be available for the installer. Needs run through your series of tests, I'm rather confident it will pass them all.

1. Forced to specific gamedir:

install elek_neh_episode4 nehahra // a Nehahra expansion
install thehand quoth // A Quoth map
install qt_pre02 travail // A Travail expansion

OR

2. Special "self" keyword

install bnt self // Maps only release forced to its own gamedir quake/bnt

@dumptruck - Thanks for info, trying to plan out how long I need the controller and what could go wrong. 

Is there a functional difference between "install bnt self" and "install bnt bnt"?

Like, would the latter fail because the "bnt" directory doesn't currently exist, or stuff like that? I don't have a particular desired behavior here, just making sure I understand any specialness about "self". 

There isn't no functional difference, "self" is just automatic naming "bnt.zip" ---> "bnt".

The 2nd question: if it is a maps only install, using the override will overwrite files.

If it has more than maps (i.e. pak or progs), it should refuse to double install. 

Going to have to kick the can on the "ignore non-Xbox controller" until the next version, I want to test it on multiple machines first and don't fell comfortable putting in a beta without doing that. (i.e. I worry if the code works wrong, it will ignore a real Xbox controller). 

Got it, thanks.

Sounds good, this will make me delete a lot of code out those batch files. Which is a plus. :-) 

Download: Windows - Direct X | WinQuake (Direct X = fast!)

1) Xbox One Controller support tweaked
2) Should eliminate sound stutter on some machines (iriyap, parubaru)
3) In-engine installer tweaks (johhnylaw)
4) Linux versions refinements (todo: make available)
5) Other touch-ups based on input

This is in addition to Big Sepulcher support (@pulsar, @qmaster) and the NightFright r_shadows 3 w/higher verts replacements models fix and Direct X decal workaround (DabblingSquidward) plus other items outlined in post #2037.

Alternate Builds:
1. WinQuake GL (killpixel)
2. SDL "zero dlls" build with mp3 sound track + all controllers support

Looks like all bugs and standard usability feedback issues have been addressed, clearing the queue.

Needs verification of resolution of issues.

Thanks to all the feedback to get this very polished! Always consider feedback even if it is not possible to immediately act on it (@iriyap). 

Spot checks on the install stuff look good. I'll see if I can run through them all tonight. 

A non-install-related thing:

If I launch Mark V using the -game option, my base video settings from id1 don't get carried over.

(Other settings do seem to get carried over properly from id1.) 

If there is a config.cfg in the gamedir (say quake/travail), it will supercede what is in id1.

And with -game is how it should work.

For instance, I run quake/travail and then set a video mode and exit and then restart travail ... it saved the config.cfg to quake/travail and that is the one it should read the settings from.

I have thoughts on how to enhance that to accomodate what I think you are describing (and do it in a traditional way, not doing something crazy).

/If I am understanding you right ... 

There's no config.cfg in the gamedir. It's a fresh mod install. I launch Mark V using the -game parameter, and I don't get my normal video settings... it's back into 640x480 windowed and I have to set all the video stuff again.

Other things like mouse invert and key bindings are handled OK though. Whatever I have set in id1 for such things is carried over, as usual/correctly. 

Maybe it was that way with the 2017 stable release too? Feel free to ignore me if I've lost it. 

Nope, you found something. What it doesn't do is fall back to id1 when there is no config on the early read if a gamedir is specified.

It just tries to early read from Travail, and if it finds no file it just stops.

This only affects things thing vid_width and vid_fullscreen that are read early, hardly anything is.

Nice catch! 

Hm. #203 #215

(heh, sorry, just had to point that out because my mental file pings me when I hear an issue that I may have heard before....) 

I'm a bit confused about the three different download links. Which build should I use? I play Quake (and map) on an old Windows Vista Laptop and stayed away from Mark V because it performed sub 60 FPS even in id1 maps, so I just stayed with QS for now. 

The Direct3D. 

Sorry for my ignorance but does this build (1.99) address the non-XBox controller conflict? I have 2 controllers attached to my Win 10 machine. The first is a Hori controller set to PS4 and the second is an Xbone controller. I still have the spinning on the spot issue. I have to unplug the dinput controller before I can use the xinput...

Sorry if this issue is still to be addressed and I'm just repeating what you already know. :) 

I'll do an update later today with the missing gamedir config issue and also put in something that should ignore your Hori controller but let you use the Xbox controller. 

That'd be great. Thank you. :) 

Yeah, I'll need your feedback and from dumptruck_ds since I don't have a non-Xbox controller available. ;-) 

I don't have a PS4 controller, but the guides I've seen online about using them on a PC all talk about using a driver called ds4windows, which presents the controller to games as an Xinput device (emulating an Xbox controller). With that driver installed, I'd expect it should work with no extra configuration through MarkV's Xinput support.

My understanding of DirectInput is, it should probably be disabled by default unless you have a match from a mappings database like https://github.com/gabomdq/SDL_GameControllerDB/blob/master/gamecontrollerdb.txt because the axis mappings are going to be random otherwise, so you'll have spinning on the spot problems etc. Winquake had it disabled by default for the same reason. 

I can loan you a PS4 controller to test. I have two and we rarely play split screen. Since we're in the US. Shipping would be no big deal if using ground. LMK.

Ericw I'd offer but IIRC customs is a drag on your end right - or has that changed?