This is somewhat of a TB issue rather than a QS issue but... SDL2 versions of the engine simply don't work if you launch them through the TB2 compiler dialog. You get game sound, no window appears and no icon on the taskbar.

Does anyone have a workaround? I'm still using SDL1.2 for the time being but the mouse input bug is pretty awful, even if it is a major step up from "not even displaying anything at all".

I might try raising an issue on the TB github if no one has any ideas. 

my first attempts are failing to reproduce this.
TB2.0.0RC4, QS 0.93.0. Latest windows 10 (fall creators update).

I'm not setting any commandline flags in TB's launch dialog. Tried with both vid_fullscreen 0 and 1 in my config.cfg.
My QS is installed directly in my quake directory, not using -basedir.
Anything that might be different from your configuration? 

https://i.imgur.com/f0hSVBj.png That's how I run the engine. If I don't use the -basedir option it complains that my game is unregistered (my .maps directory is the basedir).

Something interesting that I've noted is that when I run the SDL1.2 version, it spawns as its own application under Task Manager. If I run the SDL2 version, it's spawned underneath the TB application, right next to... a lot of instances of qbsp.exe, actually: https://i.imgur.com/2xOE02r.png

I think TB2 might sometimes have trouble cleaning up after itself...

Do you think reworking my compilation recipe to change my working directory away from the map's directory would be a good idea? It's a lot of work, sadly :( 

I can reproduce it now - the key is launching the engine through the "Run Tool" feature in TB.

If I launch it through TB's "Launch Engine" feature, it works normally. So that might be the workaround to look at; in the "Launch Engine" dialog it says you can use variables to refer to the map name.

Still weird that SDL1.2 works when launched via "run tool" and SDL2 fails, I will look into why that is the case. 

TB fails to close the compilers if you dont hit stop before exiting. 

seems like its not a specific QS bug, but my 'custom' folder has my Qrack config, and trying to exec my autoexec.cfg QS runs into many keys and cvars that it doesnt recognise. Now, thats when things get weird. It will read the whole config, then if i type timedemo demo2 it says it cant find progs/player.mdl even though using the path command it finds id1. then pressing q then tab it fails at Q_strncmp strings not equal. So, my only assumption is that reading a config full of unknown cvars is polluting a string buffer.
again probably not a QS specific bug. Using a clean config i get no errors. 

mind emaling me or uploading the configs from your "custom" folder? 

http://quakeone.com/qrack/dev/autoexec.cfg
this isnt the actual cfg (not at home atm) but its still should be close enough 

i can upload the **actual** config later tonight if you need 

thanks. No luck so far, I tried loading that config and doing a "timedemo demo2" followed by "q", tab.
Could be it needs the combination of config.cfg + autoexec.cfg to reproduce 

ok when i get home i can upload the configs
i can even make a video im using the win64 build also
if that makes a difference.
i know its not a big issue but if your like
me i hate when something breaks without knowing why ;) 

Shame about having to use the Launch Engine feature, since it's many more clicks than just Run Tool... I might just deal with the mouse snapping unless this is never going to be fixed, since I usually just jump into the game to check lighting and entity placement anyway...

Perhaps in the future a Launch Engine operation can be added for the Run Tool recipes... 

@pritchard roll back to a version that works?
@ericw quakeone.com/qrack/dev/ config.cfg and autoexec.cfg yet i tried on my laptop winXP no crash so please dont lose sleep over this. :) 

if you know how to roll back a Windows 10 update, please let me know :P

I decided to open an issue on the TB2 github, but I'm doing it as a feature request for making an engine launch part of the compilation process options as I get the feeling that running it as a "tool" is not ever going to be properly supported. 

Necros' compiling GUI requires no clicks.

Leave GUI running in BG
Save map.
Alt+Tab to GUI
Ctrl+C to compile.

https://imgur.com/YgIacZt

If you dive in, it's quite powerful:

https://shoresofnis.wordpress.com/utilities/ne_q1spcompilinggui/ 

Do r_scale 4, then gl_texturemode 6. Enjoy your bleeding eyes!

What do I do, so the pixels don't dance around on the further away objects, when using texturemode 1 and r_scale 2,3 or 4? 

What do I do, so the pixels don't dance around on the further away objects, when using texturemode 1 and r_scale 2,3 or 4?

gl_texturemode 1 is the equivalent of GL_NEAREST, which disables mipmapping and which therefore causes the pixel dance. You can't do anything because you asked for mipmapping to be disabled, and you got what you asked for.

You can try setting it to 2 or 3 instead. 

My problem is that mipmapping makes everything washed out. This is probably the obvious reason for usinge MORE pixels instead of less🙃 Duh, then Winquake look might not be my favorite... 

WinQuake used mipmapping too. 

 

Win/Software Quake used mipmaps on world/brush surfaces; it didn't on water or MDLs. Typically Fitz/QS replicates this behaviour.

Mipmapping was specifically coupled to the lighting/surface-cache engine and 4 miplevels were stored for each texture.

There's more discussion of all of this in chapter 68 of Mike Abrash's Graphics Programming Black Book: http://www.jagregory.com/abrash-black-book/#chapter-68-quakes-lighting-model

And software Quake's mipmap code is here: https://github.com/id-Software/Quake/blob/master/WinQuake/r_surf.c 

winquake's mipmapping was based purely upon the distance (and texinfo+screensize+d_mipcap).

on the other hand, opengl decides which mipmap to use based upon the rate of change of the texcoords - or in other words surfaces that slope away from the view are considered more 'distant' and thus get significantly worse mipmaps.

you can work around that with anisotropic filtering, but that requires trilinear filtering in order to be well-defined (some drivers just bug out, some force it, some ignore it).

This is a significant issue in FTE's software-esque rendering, and for now FTE uses only 3 mip levels to avoid the worst of it.
note that the original/sw mipmaps retain their proper palette instead of being a blury mess, but this means that sloped surfaces like the side of health boxes just end up with about 4 random pixels or whatever.
there's a few ways to work around this with recent glsl versions, but I've not tried to so so yet.

tldr:
glquake and winquake have _very_ different mipmapping rules, and glquake just looks blury in about every way possible... 

i prefer GL_NEAREST and gl_texture_anisotropy 8
that way it still looks pixely but less glitter at the distance. 

doh! spike just said that while i was typing :O 

...that in hardware accelerated versions of Quake, mipmap level selection is not normally something that the programmer has control over; this is done by fixed function components in the graphics hardware.