News | Forum | People | FAQ | Links | Search | Register | Log in
Quakespasm Engine
This engine needs its own thread.

Feedback: I like the OS X version, but I have to start it from the terminal for it to work and can't just double-click it like a traditional OS X app. I'm sure you guys already know this, either way great engine.

http://quakespasm.sourceforge.net/
First | Previous | Next | Last
Quakespasm-0.93.0-rc2 
http://quakespasm.sourceforge.net/tmp/93_RC2/

Release candidate #2 for the next QS release 0.93.0. Note that
the above link is temporary and will only be around until we do
the official release, which should happen possibly this week. 
Here's The Changelog... 
from the RC2 readme:

6.1. Changes in 0.93.0

o Raise default "joy_deadzone_trigger" cvar to 0.2.

o Raise console buffer size to 1MB.

o Raise MAX_STATIC_ENTITIES from 512 to 4096.

o Raise MAX_STACK_DEPTH from 32 to 64.

o Raise command buffer size from 8K to 256K to support large configs.

o Remove MAX_EFRAGS and MAX_MAP_LEAFS limits.

o Remove "Loadgame buffer overflow" limit, which could happen when
loading DP or QSS saves.

o Adjust "exceeds standard limit of" debug warnings to include the
actual QS limit.

o Change "game" command to now exec quake.rc.

o Change "games" / "mods" commands to list all subdirectories.

o Restore vid_refreshrate from fitzquake-0.85 for SDL2 builds.

o Alpha-masked model support. (MF_HOLEY: 0x4000).

o Change default screenshot format to png. The 'screenshot' command
now supports optional format (tga, png or jpg) and quality (1-100)
arguments.

o Revert "always run" changes from 0.85.9; move the QuakeSpasm
customizations to a new "cl_alwaysrun" cvar. Set to 1 to scale
forward/side/up speed by "cl_movespeedkey" (usually 2),
and make "speedkey" act as "slowkey".

o Change "always run" menu option to offer
"off" (cl_alwaysrun 0, cl_forwardspeed 200, cl_backspeed 200),
"vanilla" (cl_alwaysrun 0, cl_forwardspeed 400, cl_backspeed 400) and
"quakespasm" (cl_alwaysrun 1, cl_forwardspeed 200, cl_backspeed 200).

o New "r_scale" cvar. Set to 2, 3, or 4 to render the view at 1/2,
1/3, or 1/4 resolution.

o New "r_viewmodel_quake" cvar. Set to 1 for WinQuake gun position
(from MarkV).

o New "find" / "apropos" command, searches for commands/cvar names
for the given substring (from Spike).

o New "randmap" command for loading a random map.

o New "gl_cshiftpercent_contents", "gl_cshiftpercent_damage",
"gl_cshiftpercent_bonus", "gl_cshiftpercent_powerup" cvars for
tuning the strength of specic view blends.

o Fix macOS startup delay (avoid calling gethostbyname() for ".local"
hostnames).

o Fix memory corruption in PF_lightstyle with out of bounds
lightstyles.

o Fix crash in BoundPoly with polygons extending beyond +/-9999.

o Fix QS window to stay on the current monitor when changing video
modes (SDL2 only).

o Fix possible freeze in SV_TouchLinks regardless of what QC does in
the touch function.

o Support for Open Watcom compiler.

o Update the third-party libraries. 
F11 And Mouse Speed 
This is not a big deal, since arguably the zoom function isn't integral to the game, but whenever I press F11 to zoom, it resets my mouse speed -- i.e. when I zoom out, my mouse speed is unbearably slow (default speed, I guess?) and I have to reset it before I can continue playing (I always play with mouse speed set to max). Is this intentional?

It would be nice not to have it happen and to be able to use zoom from time to time... 
F11 
F11 is just using an alias command from default.cfg. This is not an engine issue.

I suggest you set up your own zoom script. E.g. mine is similar to Quake 3's behavior:

alias +zoom "inc fov -10; wait; inc fov -10; wait; inc fov -10; wait; inc fov -10"
alias -zoom "inc fov 10; wait; inc fov 10; wait; inc fov 10; wait; inc fov 10"
bind MOUSE2 +zoom

Just make sure to save it to autoexec.cfg, as config.cfg does not save user aliases. 
 
The changelog was slightly out of date, these are the last few changes in rc2:

- Invalid skin index now draws skin 0 (WinQuake behaviour) instead of blue checkerboard.

- GL2 renderer: use a GLSL shader for world faces. Fixes reports of integrated+discrete GPU laptops having inconsistent fog rendering.

- Fix for maps with empty strings for vector keys (e.g. "origin"); don't read uninitialized memory.


The GLSL shader is mostly a copy+paste of what we were already using for drawing MDL's, so it should be solid, but let me know if you see any issues.

btw I know there were some requests recently I didn't reply to like m_filter and lastweapon etc., will consider them for the following release :) 
FYI 
The .exe naming is changing in this release:
quakepasm.exe is now the SDL2 build
quakepasm-sdl12.exe is the SDL1.2 build (legacy / compatible with windows 9x, supposedly?)

You should use quakespasm.exe; it has advantages like raw mouse input, refresh rate control, "desktop fullscreen".

Also, quakepasm-sdl12.exe has broken mouse input on Windows 10 Fall Creators Update. 
@ericw 
Does this version support AD-Sepulcher? 
Yes (and Orl's Map Pack) 
 
@ericw 
In quakespasm-admod, I`ve founded the "mods" command on the main menu very useful. Do you plan an equivalent menu also for the next release 0.93?

Because of the simplicity of this function, I was able to convince a couple of friends to play Quake and its mods again. 
 
Adding extra main menu options is probably too much, in my opinion. It would require replacing the main menu graphics (there's no main menu font, it's a single image), so say what happens if a mod has its own main menu graphics? Do some check and fall back to vanilla behavior which might confuse the user? Or what if the check fails for some reason? More bugs to iron out later?

Just bring down the console and type "game modname". Or use an external mod launcher, like this one:
http://www.celephais.net/board/view_thread.php?id=61069 
#3056 
Its not too much work. They already did it in the admod version of Quakespasm released with Sepulcher. 
@mukor 
Indeed, I'm aware. And that particular version causes bugs like this:

admod:
https://i.imgur.com/hS07r5x.jpg

vanilla QS:
https://i.imgur.com/0QR3BCL.jpg 
@iriyap 
I'd take that minor bug over not having the menu. I'm for adding it to QS. I use a launcher but I think we should all want Quake to be easier to use for newbs. 
@dumptruck_ds 
The main menu is a single image, not a font. To add a new option, you have to replace the whole thing. There is no way to add extra options without sacrificing compatibility with mods that use custom main menu graphics (e.g. Rubicon series, Malice, Shrak, X-Men, many other TCs, etc). This is the reason why very few source ports ever touch it (JoeQuake only?).

Not to mention that we already have so many options for launching mods, like using shortcuts, .bat files, external launchers and also console commands. I'm sure even the most casual of the players can figure out how to use a launcher. It's just a program with a bunch of dropdown menus where you choose your engine, mod folder and what map to launch, if any.

If we wanted to accommodate newbies so much, we could also start adding regenerating health and such. I'd rather QS retains its full vanilla compatibility, it's the main reason the engine is the number one choice for Quake in numerous retro gaming communities. 
 
If we wanted to accommodate newbies so much, we could also start adding regenerating health and such.

Arcane Dimensions, arguably the best mod in years, has respawning ammo and health. So there's that.

Back on topic, there are very few TCs compared to straight up mods. I still think adding a mod menu would be more beneficial than not. And I'm sure there's a way to make it work with TC's anyway. 
 
"If we wanted to accommodate newbies so much, we could also start adding regenerating health and such."

That has absolutely nothing with the subject at hand but ok.

Having the Mods option was more about getting more people to play Quake that arent comfortable with setting up folders. The same crowd of people that Quake Injector is made for.

But yeah that kind of sucks it breaks things. I need to wake up more before i start func_ing. 
 
Yeah, I might have gone a bit off tangent with that comment, got carried a way a bit, didn't mean to preach.

Point is, yeah, it breaks things. In theory, you could break up the original image and add another image just with the "Mods" part, but the font will be clashing with the TCs. Maybe add this new menu under the options screen? This would work, that one is all text.

Still, I'd rather this was external, maybe via some official QS launcher or such, if you want everything in one package. 
 
I was also thinking it could be a menu item in the "options" menu - that would avoid issues with custom graphics. The only downside is it's one more thing in the "options" screen which has a tendency to keep growing. 
New Menus 
stuff like this is why I gave FTE the ability to query a file's depth.
eg if the menu artwork is in id1 then replace it with a new menu with a mods option etc. otherwise a mod has replaced it and the vanilla layout+filename should be used. it gives the best of both worlds. 
More Skin Issues 
Found another broken skin in Shrak:

QuakeSpasm r1532:
https://i.imgur.com/AuaZ5kI.jpg

Mark V:
https://i.imgur.com/BVq71Pe.jpg

It's a Pentagram replacement, just load dm3 to see it.

WinQuake and DarkPlaces display it properly as well, but it's black in QuakeSpasm, DirectQ and FitzQuake 0.85. 
@Spike 
Don't really want to be the bad guy on this idea, but one last point, hear me out. Consider this, the "mods" option is mostly for the newbies sake, right? So they use it to load some mod which happens to have custom main menu graphics, and bam, the option is suddenly gone. Cue all the false bug reporting and complaining. Not to mention that the lack of consistency is not good UX. 
Shrak Skin Issue 
Thanks for the report. It's caused by Mod_FloodFillSkin (commenting that out in Mod_LoadAllSkins fixes it).. I think the flood fill breaks on solid color skins. Might wait until after this release to investigate how MarkV fixed it. 
 
Just put mods and maps in the "new game" menu 
Also, Re: #3049 
Here's an example of a zoom script that is agnostic to your current sensitivity cvar. This modifies m_pitch and m_yaw instead of sensitivity.

alias +zoom "fov 105; wait; fov 72; wait; fov 53; wait; fov 34; wait; fov 15; m_yaw 0.004; m_pitch -0.004"
alias -zoom "fov 15; wait; fov 34; wait; fov 53; wait; fov 72; wait; fov 105; m_yaw 0.022; m_pitch -0.022"


Of course it does assume a specific fov. Use iriyap's suggestion and use inc command to make it relative to any starting fov value. (though it could break if it tries to go below the min value.) 
@ericw 
Just noticed that the 3D crosshair for the RL in Shrak is also solid color and also affected by this bug. 
32 Bpp 
Not sure if posting in the right thread, but I'm having trouble running QS in 32-bit colour. Highest available setting is my native resolution (1600x900) and 24 bpp. Any hints on how to troubleshoot? 
 
The version is 0.92.2-admod-win32 from sock's Arcane Dimensions page. QuakeSpasm 0.92.1-win64 runs 32-bit colour fine. 
It's Fine 
24 and 32 are pretty much different names for the same thing (they're both 8 bits per channel). It's probably just a naming difference between SDL2 and SDL1.2 . 
 
OK thanks. 
@ericw 
There seems to be a gamma shift (lower, brighter) when I switch refresh rate to match my desktop refresh rate. If you cannot reproduce, I can make a video after work tonight. Or is this expected? 
Dumptruck 
Hm, that's not good. I'll see if I can reproduce it. 
@dumptruck_ds 
Can't reproduce on my system (latest windows 10, nvidia 650); tried 800x600@60 and 800x600@75 hz.

I can't think of an explanation, but a couple questions: do the QS brightness/contrast sliders work in both video modes? If you still get a gamma shift with both "gamma" and "contrast" cvars set to 1, it's likely something outside of QS causing the gamma difference.

Is it possible there's a different gamma setting for that video mode in your graphics driver control panel? I'm not sure if that is a feature, just guessing here.
Does it happen in any other game? 
@ericw 
I am still at work but will do some more work on this tonight. I doubt it's an external nvidia thing. I switch refresh rates a lot with QS and QS Admod etc. as I am working on the Xmas jam at the moment. I map and test at 72hz and then play for fun at 144. Will report back in a few hours.

I will check the sliders in both modes. And other games. 
@ericw 
Tested this. Happened again. But here is the weird thing: I took screenshots and they match. However, I am def noticing an increase in overall brightness.

Will keep exploring this but did not happen with .92x and Admod versions. Very strange. The brightness isn't horrible just noticeable. Here's a PDf with the screens for reference - you will not see any diff between them but thought I'd include for further discussion.

https://adobe.ly/2AQ2JDI 
Thanks, Appreciate It 
Will keep exploring this but did not happen with .92x and Admod versions.
One thing is, 0.92.x and the admod build did not have refresh rate control. (I only added it in august.)

Something that might be worth checking is Fitzquake 0.85, if you don't have it already; it has the same refresh rate cvar and option in the video menu:
http://www.celephais.net/fitzquake/

I also did a bit of searching and it sounds like gamma changes can be an side effect when high-refresh rate monitors switch refresh rates - so I wonder if it could just be that?
http://www.mmo-champion.com/threads/2098378-Asus-24-quot-LED-A-Sync-MG248Q-brightness-at-different-refresh-rates 
 
okay, so not trying to be a proud c0ck in any way, yet, hear me out. I try to to a timedemo demo2 in QS newest, and get around 631.4fps yet in Qrack in the classic settings (which is standard quake) im getting 2200fps yet Qrack uses stupid opengl 1.3...
i'm not trying to tug a war just wondering if your glsl is batching per frame or per model? 
 
im using windows 10 pro 64bit nvidia 960gtx
btw 
 
quakeone.com/qrack test it yourself 
 
screenshots will not show hardware gamma correction, that correction happens only as the framebuffer is drawn to the screen. (which is why it affects the whole screen when playing quake in a window, rather than just the game window.) 
 
rook: yeah, I get similar results, though not as extreme, 850fps for qrack vs 500fps in QS for timedemo demo1. this is 1920x1200 on a 650gt. I don't have a good explanation. QS does well when the maps get bigger and/or there are lots of MDL's on screen, but there must be some reason it's worse on "easy" content. IIRC, DirectQ on the other hand was blazing fast on id1 content. 
 
Is QuakeSpasm still sleeping every frame, even in timedemos? That would cause it. 
 
Tested using latest source, in main_sdl.c, line 184:

if (time < sys_throttle.value) 483 fps

if (time < sys_throttle.value && !cls.timedemo) 1228 fps 
 
Set sys_throttle to 0 on your console before running a timedemo. 
 
ya setting sys_throttle to 0 im pushing 2000fps now. 
Eric 
Could you add an "r_viewmodel_fov" cvar from mark_v 
Spy: 
it's something I want to add but didn't get to for this release. The RC does have r_viewmodel_quake (also from markv) where 1=restore winquake gun position. 
Been Wondering 
Is there any technical reason why water etc liquids textures are not mipmapped in QuakeSpasm? It's usually not very noticeable, but maps with large bodies of water (like Orl's shib1) have a lot of aliasing. 
 
does the water textures have TEXPREF_MIPMAP flag set? 
Re: #3094 
It's probably unchanged from Fitzquake. In Fitzquake it was done for two reasons: 1. it's not mipmapped in the software renderer (so +1 for authenticity) and 2. since the water texture is rendered every frame (when using r_oldwater 0) this means the mipmaps would also have to be recalculated which I didn't know how to do at the time (and still might not be fast enough even if I did know how.) 
Yay Authenticity 
But in the interest of algorithmic nerdiness...
Could you generate the mipmaps at level load and cache them? 
 
vkQuake (a fork of QS on Vulkan API) does support water mipmapping. Not sure how much of the Vulkan code can be translated back into OpenGL, but I suppose it could be helpful as a reference. 
 
Yeah - I saw that vkquake does it. It sounds like it is doable in OpenGL 1.4+ with GL_GENERATE_MIPMAP, and is done in by the GPU (if it was done on the CPU it would kill performance because the warp textures are updated every frame):
https://www.khronos.org/opengl/wiki/Common_Mistakes#Automatic_mipmap_generation

The other thing I was going to investigate was doing the warp in a fragment shader, but need to investigate whether it's faster even on lower end hardware, and if it can be made to look identical to the current warp. 
 
hmm odd i thought even glQuake mipmapped all textures including
water and sky textures? 
 
Warp in a fragment shader is faster, even on lower end hardware, and can be made look identical.

Visually it can even be superior, because normally with mipped warps the texture can shift between different miplevels as it warps, even if nothing else changes. But by taking the screen space derivatives of the unwarped texcoords and using a tex2DGrad (or equivalent) lookup, you get to avoid that and get a nice solid warping image. 
MH 
cool, thanks for the tip on tex2DGrad, will look into that.

I dug out a quick hack of RMQEngine's warp code to GLSL that I was experimenting with a year or so ago.

Snapping the texture coordinates to the nearest 1/512 (fitzquake renders the warp image into a 512x512 texture by default) seems to approximate the look of fitzquake's warp very closely:

vec2 texc_input = gl_TexCoord[0].xy;
texc_input = floor((texc_input * 512.0) + vec2(0.5, 0.5)) / 512.0;
rest of the shader

screenshots:
fitzquake render-to-texture warp
the above shader
above shader with the rounding-to-nearest-1/512 commented out

The timing is slightly off between the fitz and shader versions but they look pretty close to me otherwise, so this looks promising. 
Quakespasm 0.93.0 Released 
Congrats On The Release! 
Also maybe it's a good time to mention that a lot of links on the QS page are broken, like the id software link on the "Being" page and most of the links on "Other Worlds" (just link them to Quaddicted, Kell's page has been moved here). 
Cl_alwaysrun 
Well hey, that's a neat early-morning surprise. Might've noticed a minor mistake in the patch notes, though:
Revert "always run" changes from 0.85.9 and move the QuakeSpasm
customizations to a new "cl_alwaysrun" cvar: Set to 1 in order to
scale forward/side/up speed by "cl_movespeedkey" (usually 2), and
to make "speedkey" act as "slowkey".

So far as I can tell, cl_sidespeed isn't actually affected by any of the settings and remains at 350 (the Quake default) regardless of Always Run setting, while _forwardspeed and _backspeed work as intended (400 for Vanilla, 200 for Off, 200 [* cl_movespeedkey 2 to equal 400] for Quakespasm). 'Walking' also only affects forward and back speeds, not side speeds, the same as the old behavior. 
About The Quakespasm.pak 
Is the quakespasm.pak file up to date from the sourceforge link ?

The version that comes with the link above has date

2 march 2016 00h00,

while the version I already have (from somewhere I don't remember) has date

27 june 2017 21h46.

So what is happening with this file ? 
RE: Is The Quakespasm.pak File Up To Date 
Yes, it is. 
That QS Version And Spike Effects In AD Sepulcher... 
I tried QS 0.93.0, and there's no rain effect in Sepulcher. I understand that the Spike effects aren't included in that version of QS, but why?

If it's because some people don't like to see "modernized" effects into Quake, why not a "Spike FX" button in the graphics menu ? 
@Barnak 
I believe that this was already answered up-thread? 
Spud 
the patch notes are correct, the reason it doesn't look that way is quake's default cl_sidespeed is already running (350), so increasing it further with the new cl_alwaysrun cvar (or shift key) doesn't make you go faster sideways. It does affect the angle you move when holding forward+left or forward+right.

Barnak: the newer quakespasm.pak is from the admod fork, it has the mod menu graphics. I probably should have renamed admod's pak file so they didn't conflict, but it doesn't matter, the contents are the same besides the mod menu graphics. 
Eric 
So if I understand clearly what you said, it doesn't matter which version of the Quakespasm.pak file I use? Is that right? 
 
hmm i got a crash to desktop when doing a rimedemo demo2
will try a debug build later to find the error.
all i did before the timedemo was change my game dir
so it might be a cfg conflict somewhere

loaded qs
game custom
timedemo demo2
crash 
R00k 
thanks for the report. I cam't reproduce with "game quoth", so maybe be QS crashes on something in your "custom" dir. 
 
I'm experiencing a very strange behaviour of the mouse. There is a kind of a lag between the movement of the mouse and what I can see on the screen.

I’ve this problem only with the Mac OSX universal app and NOT with Mac OSX (SDL2 version).

Can you image any possible cause?

Thanks 
Burp 
I noticed input lag on some sourceports if I had vsync enabled, though it's never been an issue in Quakespasm. 
 
I think I can reproduce that, at least, for a few seconds after entering fullscreen mode the mouse seems especially laggy (macOS 10.13 / SDL1.2 build).

Use the SDL2 version. I'm not sure specifically what is happening here, but SDL1.2 has a hacky way of doing mouse input where it's constantly teleporting the mouse (afaik). This happened to break on the latest Windows 10 update so I'm not surprised there are macOS issues too. The SDL developers officially say 1.2 is abandoned, although they still apply patches now and then, but there supposedly won't be any more releases. 
Spike FXs Are Dying ? 
I'm wondering about the lack of support for the nice Spike effects. I think they're working great and add alot to the atmosphere in Quake (I'm NOT asking for other "modern" graphics and high res textures stuff).

Should I conclude that all Spike effects are abandoned in QS? 
@Barnak 
I believe the "Spiked" build was standalone for a reason, same goes for the admod build. I'm not sure how Eric and co feel about this, but IMO FitzQuake/QuakeSpasm was always about staying faithful to vanilla as much as possible. I'd wager a guess and say that it's more about historical preservation and accepting Quake as is than trying to remake it. Adding new gfx is a slippery slope. First you add some optional particles, then you add bloom and HDR, then some fancy shadows, and before you know it you've got a huge codebase with many issues out of your control. And besides, why reinvent the wheel when users interested in extra gfx can always use FTE or DarkPlaces which have more focus on this. 
 
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. 
Hmm 
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 :( 
Cool 
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. 
#3121 
TB fails to close the compilers if you dont hit stop before exiting. 
@ericw 
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. 
@r00k 
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 
R00k 
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. :) 
@rook 
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. 
@pritchard 
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/ 
Lel 
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. 
And Again I Am Totally Mistaken... 
 
I Should Be More Specific... 
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 
Also Worth Adding... 
...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. 
@ericw Video Is Blurry Sorry 
 
basically the video shows
game custom
timedemo demo2
host error: progs/player.mdl not found
q{tab}
crash

reload
game custom
exec config.cfg
timedemo demo2
host error: progs/player.mdl not found
game id1
crash 
 
weird my other machine doesnt do it :/ 
Ah Good. 
I reproduced the crash here on windows with the 32 bit QS build, so it's indeed just those 2 config files that are doing it. thanks, will investigate. 
 
...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.

Looks like it was first exposed to the programmer with textureLod in GLSL 1.30 / OpenGL 3?

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/textureLod.xhtml 
 
You could probably brute-force it on older hardware by storing each miplevel as a separate texture. Performance would be horrible though. 
Speaking Of Texture Aliasing 
Supersampling makes unfiltered textures look gorgeous and not flicker at all. Consider adding such an option.

https://imgur.com/a/jumoZ 
Supersampling 
Up close or far away?

The thing about far way textures sparking is that it's basic mathematics. You have one pixel on the screen, and when the texture is sampled - either via nearest or linear, doesn't matter which - you're sampling more texels than will fit in that one pixel. Then when the scene shifts a little (like with regular Quake idle movement, or water warping, or whatever) the texels being sampled jump around.

This is basic sampling theory stuff; it shouldn't be necessary to explain it, it's been mathematically proven for donkey's years. 
 
The supersampling in vkQuake works both up close and far away. The far away flickering was always bothering me and I would begrudgingly turn the texture filtering back on, but with this kind of supersampling you get the best of both worlds, the textures never flicker at the distance, and at the same time don't get blurred up close. Works great even at 4x supersampling with little to no performance hit. Black magic! 
 
Just to clarify...

Far away flickering is not caused by texture filtering or no texture filtering.

It's caused by not using mipmaps.

You can disable texture filtering and use mipmaps.

gl_texturemode GL_NEAREST_MIPMAP_NEAREST will disable texture filtering but use mipmaps, and will hugely minimize far-away flickering. This is the nearest you'll get to software Quake without custom shaders to more closely replicate it.

gl_texturemode GL_NEAREST_MIPMAP_LINEAR is slightly higher quality. It also disables texture filtering but will interpolate between miplevels, so you don't get jarring transitions between different miplevels as you move about a map.

I'd strongly encourage you to use the built-in modes properly and see if they actually do meet your requirements. It's an unfortunate piece of Quake "lore" over the past 20 years that gl_texturemode GL_NEAREST is the correct "software Quake" mode, and Quake "lore" is full of flat-out wrong bullshit like this. 
 
I'm sorry that I didn't make this clear, but of course I'm using mipmaps (GL_NEAREST_MIPMAP_LINEAR). Still, it causes quite a bit of aliasing compared to GL_LINEAR_MIPMAP_LINEAR, e.g. when looking at the textures with horizontal lines (like base walls) at an angle and moving back and forth. Supersampling seems to fix this issue. 
Iriyap 
You can just enable DSR (nvida) or VSR (AMD) in your video card control panel. 
 
I'm sorry that I didn't make this clear, but of course I'm using mipmaps...
Ah, OK, my apologies.

I guess this is one of those "different things drive different people nuts" things then. I personally accept a bit of aliasing as part of the tradeoff to achieve the crunchy pixel look, and even expect it as a feature of that look. 
 
Yeah, I can understand that. WinQuake has tons of aliasing, all over the place, and maybe that's part of its charm, but having crisp sharp unfiltered textures with zero aliasing is also very, very appealing and it's something that couldn't be achieved on the hardware back then, so it feels more like an upgrade than a step back. Just my personal preference, at any rate. 
Aliasing 
Is merely a result of using a screen with too low a resolution at too close a viewing distance (dpi vs viewing distance). 
 
yeah just get a 4k display! 
@mh 
thanks! GL_NEAREST_MIPMAP_LINEAR is the perfect balance i was looking for. Too long i was using gl_linear_mipmap_linear and the scene on large maps just looked blurry far away, (thought might feel like GTA-V), lol

small maps like the dm maps it looks perfect like standard true grit Quake :) 
Quake Grit 
Experiencing A Bug 
On the map E1M3(The Necropolis) at the end right before the fight for the exit gate, the lift has a bug. About half way up the lift I get hurt for no apparent reason(HP going from 100 to 45) and the lift goes back down.

I am running Windows XP x86, Intel E6550, 2GB RAM, Geforce GTX 550 Ti 
 
host_maxfps is probably set above 72 - setting it back to 72 should fix the physics glitch. 
@ericw 
Feature list sounds great, congrats!

Find ;-) WinQuake gun pos ;-) Alpha .mdl texture masking, not that anyone will ever use it because about no one is capable of making models these days but should someone arise, it is available which is nice. PNG shots ;-) Having actually Quake-correct always run ;-)

1. gethostbyname -- has no purpose in the engine at all.

2. Steal r_viewmodel_fov -- sheesh! It's been nearly 6 years Mark V has had that barely 8 lines of code feature -- maybe be slightly more complex in QS, but seriously. No excuses. It's rather unacceptable Quakespasm does not have that feature, in all seriousness.

3. Maybe make a Con_Print when someone changes maxfps away from 72 do a message "This may cause physics glitches, missed triggers and killer elevators". Because clearly people post the same damn thing 80 times per year.

Anyway, I quite like the change list! 
No Idea 
What r view model fov does 
 
if (sv.active) Cvar_SetValue ("host_maxfps", 72);

Obviously it would be nice to fully decouple the timers, then work over the client code and fix up all the FPS-dependent stuff properly, but in the absence of that surely we're past the point where the disadvantages far outweigh the advantages? 
 
Decoupling these things is a huge task if I recall which is why no one has done it yet 
Mark V? 
recent release attempted this IIRC

Could you tweak the physics (or damage) code to behave better at those higher rates? 
 
Could you tweak the physics (or damage) code to behave better at those higher rates?

This isn't something that's a simple tweak otherwise it would have been done long ago, everybody would be using it now, and we wouldn't be having this conversation.

This is something that we've all been aware of for almost 20 years - at least ever since the Quake source release and early attempts at implementing maxfps. But yet people still continue to report it as though it were a new bug several times per year. 
Mh 
But yet people still continue to report it as though it were a new bug several times per year.

Well that's because we're not omniscient. 
QuakeSpasm 2 
Hello. There is any plans to do the same port for Quake 2? I'd like to play it very much, cuz there is no such a port for Quake 2 like QuakeSpasm. There is only unofficial patch, but it's not enough - the mouse input is very shitty, no support for all keybuttons in controls options etc. I hope you will do it, as I know, the Q1 and Q2 engines are very similar. 
#3171 
Here you have similar project for Quake2: https://www.yamagi.org/quake2/ 
Flashblend 
Can you make QS default to gl_flashblend 0? Unless you already have... 
 
Yes, it's been the default for several versions (iirc since 2014-ish) 
Slightly Confused 
This may have already been discussed to death, but I'm just returning from not having played Quake in a few months and saw QS got to 0.93.0. How similar is this release to QSS? I've been using QSS or the AD version for pretty much everything since Sepulcher came out. Can 0.93.0 do pretty much everything QSS does? Which should I use for normal play? 
Only One Teleporter Effect? 
I'm running latest SVN code on Linux. I notice that when several enemies teleport in, only one teleport effect is displayed, while the other enemies just pop in. Is this normal? 
 
QSS is a separate fork/experimental build and QS 0.93 doesn't include any of its features. Perhaps for the best. 
 
I'm running latest SVN code on Linux. I notice that when several enemies teleport in, only one teleport effect is displayed, while the other enemies just pop in. Is this normal?

You would get this result on virtually any Quake client, going back to the original engines from 1996.

The teleport splash spawns almost 900 particles, whereas the engine by default will only support up to 2048. I suggest that there's something else spawning particles, or an enemy teleporting behind you where you can't see it's particles.

Run with -particles ### where ### is some number higher than 2048 to support more particles. 
 
@SavageX certainly not an intentional change. Could you try 0.92.1?
https://sourceforge.net/projects/quakespasm/files/Source/quakespasm-0.92.1.tgz/download 
Running Into Particle Limit 
@mh: Thanks, that's it! Increasing the particle limit fixes this!

@ericw: Tested this in 0.92.1 as requested. It behaves the same (and according to design).

I wonder if bumping the default particle limit makes sense. Are particle emitters sorted by player distance regarding priority or is it "random" which emitters starve? 
 
Quake doesn't really have a concept of particle emitters as such. Particles are just moved from a free list to an active list as required, then returned to the free list when they expire, with no sorting.

Individual particles in an effect may expire at different times, and when you run out of free particles that's it, no more particles until enough expire.

So if there are, say, 5 teleport splashes spawned, the first two will get 896 particles each, the third will get 256, the last two will get none.

It's easy enough to extend the number of particles to effectively infinite engine-side: just Hunk_Alloc (and initialize) another batch when you run out. Add some tidy-up code for map changes and it's done.

It's always seemed odd to me that QS hasn't already done this, particularly given the number of effects even in stock ID1 Quake that use up so many.

By comparison, Quake II bumps MAX_PARTICLES to 4096 but IIRC even that isn't enough for stock ID1 Quake; there are some scenes in demo1 that can go over 5000. 
#3175 @sevin 
http://triptohell.info/moodles/qss/
I've updated the windows builds of qss to merge in the latest qs changes... And FINALLY fixed a couple of bugs in qss-r7, so quoth shouldn't bug out any more (is the theory). 
Whoa 
And I thought Spikedspasm was a dead end fork.

Cool. 
"And I Thought Spikedspasm Was A Dead End Fork." 
I HOPE NOT!

QS_Spike version is my Quake version of choice. Long live Spike! 
#ericw 
we need an MacOS version of QSS!!! :-) 
Quick Query 
And FINALLY fixed a couple of bugs in qss-r7, so quoth shouldn't bug out any more (is the theory)

That's cool, but were we doing something especially weird or dodgy that provoked this? Like the ultra-high fps "bug" that keeps being reinvented, if it happened to your engine it might happen to others, and I'd like to programme defensively if so. 
@Preach 
sorry, I should have phrased that better. That bug was totally my fault, and it happened on more maps than just quoth's ones.

(I was trying to be clever by auto-precaching any model named by a model field, so that mappers could do interesting hacky things. the real issue being that I got the code wrong and the server ended up reading random tempstrings instead.
Even without that it would have broken saved games though, so now you need '_precache_model' instead, or alternatively you can set modelindex to a non-numeric value, which might be useful if you're trying to bypass the lack of a setmodel. its nice to have options, or something) 
Vore In The End Bug 
https://i.imgur.com/Ye09ueS.jpg

WTF?! :) Sometimes (often) last Vore teleports in the player at the end titles. I don't remember this bug in original game. 
Killing The Vore 
You've probably just got faster at completing the level, and leave a vore alive more often. The teleporter at the end isn't flagged "player only" so if the vore's alive on the final ledge then it can walk towards the camera and hit the tele. 
Can "qss-r7" Fully Replace AD Sepulcher's "quakespasm-spike-admod"? 
Before I overwrite I'd like to know ;)

Thanks in advance. 
Afaik No 
I think qss-r7 is older and lacks some fixes needed to run ad_sepulcher.
btw QSS homepage is http://triptohell.info/moodles/qss/ and there is an r8+ released recently. 
I Meant R8+ , Grrr... 
Thanks. 
QSS R8+ 
I quicky tried it yesterday and AD Sepulcher seem to run as good as with the ADMod version of QSS. Unfortunately no chance at the moment for a deeper test session.
Only thing that is missing is the possibility to select the mod to play directly in game main menu. 
Changed Controller Settings? 
I haven't been able to play QS in a while. I play with a controller but it seems that movement is more twitchy than it used to be.

Of course, Windows 10 has updated a million times since I last played which broke my controller until I updated its drivers - SCPToolkit. Thus, I'm not sure if the change is in the drivers or Quakespasm...

Just so you know, behaviour hasn't changed in any other game. :) 
 
The only default that has changed since June 2016 is L/R trigger deadzone, because the shoot/jump keys were getting stuck sometimes.

Maybe try deleting the joy_* cvars from you config.cfg's in case they got changed at some point.
Here's the manual section on the controller cvars if you need to tweak them:
http://quakespasm.sourceforge.net/Quakespasm.html#ss3.2 
 
Any idea why SDL 1.2 and SDL 2 treat mouse buttons differently? Between the two versions my mouses thumb buttons are 4 & 5 in SDL2, but 8 and 9 in SDL1.2.

Not a big issue, it just means another rebind, was just curious about the logic. (am using linux btw) 
3195 
Thanks for the reply, Eric. I tried your suggestion but to no avail. That put Quakespasm being the issue to bed. I uninstalled SCPToolkit, installed DS4Windows and all is back to normal.

Again, thanks for your help. :) 
More Granularity In Analogue Movement? 
Sorry to harp on about controller stuff, Eric, but I have a request if it's possible.

Though there is change in player movement speed depending on how far one pushes the left analogue stick it would be nice if there was more nuance to it.

I don't know the technical term for it but I feel the movement should ramp up smoother across a greater range of the stick. Right now, it's a little twitchy for precision jumping and the like.

The right stick for looking is great though.

A slider in the menu would be perfect but even a CVAR (or is there already one that I've missed?!) would be nice.

Hope you're having a lovely Christmas. :) 
 
Hmm.. it looks like the only cvar for controlling the movement stick is "joy_exponent", default 3. But, that also affects the look stick as well.

Try lowering it to 2 or 1. 1 will give you linear mapping from stick travel to movement speed.

I can probably split this into 2 cvars if it turns out you need different values for the move and look sticks. There is no menu page for any of this, would be a good idea probably.
Thanks and merry Christmas as well! 
Thanks. :) 
Setting the joy_exponent to 1 made a big difference to movement. However, like you suspected the effect is too heavy handed for looking. Would it be possible to split it into 2 CVARS?

I reckon setting them to 1 and 3 would be pretty perfect in terms of map navigation and aiming. At least, for me.

Also, I just want to say thank you for always responding in an interested and polite manner. I can't tell you how refreshing it is not having a dev respond with eye rolling or "code it yourself, noob". I enjoy playing another old FPS and I dread asking questions about that source port. Again, thanks for allowing me the space to 'just' be a player and not a mapper, modder or coder. :) 
 
Hey guys, thanks for the great work you're doing.

I tried running heavy mods like AD with Quakespasm, experienced not-so-high-fps. Which features can I disable (or use some commands) for any fps boost? 
Options: 
• Reduce video resolution
• Play on a computer made after the year 2010. 
Also 
Be aware that the physics breaks above 72 fps. So if your standard is ultra-smooth 144 fps you're going to be disappointed. 
 
Can't find the tools thread (I suck) ... didn't want to kill joy in a new release thread.

"Fix MarkV .lit rendering (do the color->greyscale conversion in a way that forces MarkV, FTEQW to render identically to Fitzquake, Quakespasm) "

That's is completely inaccurate description. The external .lit file is just covering up the evidence.

If you would load a map that suffers the issue in GLQuake or WinQuake it would look all wrong too, so there was a majorly serious issue there with the .bsp having lit data that didn't resemble the data in the external .lit file.

I am hoping you already know this and expect you do.

Back a few years ago when Spike explained the rationale behind FTEQW's .lit method, the logical was so sound and impactful that it was clear it was the "right" way to do things.

Posted here so I don't killjoy your release thread.

Pritchard should get beta tester MVP trophy. 
Most Valuable Pritchard 
What, for noticing that the lighting was buggered?

I don't know what the best solution is for .lit compatibility is but it might still be this one - having maps look different in different engines sucks so being able to make everything look the same is very valuable. It would be a lot harder to coordinate this between each individual engine I imagine... 
#3201 
In AD you can try disabling the custom particle system. QS doesn't sort or batch sprites so this can be still a bottleneck.

IIRC there's an impulse command for it docemented in one of the readmes.

Be aware that at some point in the future a version of QS might exist that does batch sprites, so this bottleneck might go away and "disable particles for higher performance" would no longer be good advice. 
#3203 
Can't one set vid_refreshrate "144" and host_maxfps "72" for a smooth frame rate without tearing and breaking the games physics? I thought that's what these CVARS were for... I could be wrong, though, as I'm pretty ignorant to most settings for Quake! 
FYI 
Interesting comparison of model light levels across WinQuake, QS and FTE:

http://www.celephais.net/board/view_thread.php?id=61351&start=121 
Possible Bug 
Nice port, I'm really sorry that my first post is gonna be a bug report. Previous Weapon doesn't seem to work, no matter what I assign to it. Next Weapon does work though. Also, when assigning a key to an action (when the equals sign appears) moving the mouse acts as if using it to point (as in moving the camera). Besides that, it's a great port, really faithfull to GLQuake. 
 
The "Previous Weapon" feature is a function of the gamecode in your pak files, not something that the engine does (normally). It sounds like your pak files are not the final ones that were released for Quake. Sooooo... where did you get them from? Is it from the Quake demo, or an early run of the Quake CD? 
Which Mod? 
 
 
True, it could also be from playing an old mod. 
 
The .paks are from my CD. Someone else told me about the .pak thing today elsewhere. The weird thing is the same using the same .paks in MarkV doesn't give me this problem. 
 
MarkV can add "previous weapon" (impulse 12) even if the mod doesn't have it / you are not running the latest patch version of the pak0.pak/pak1.pak. 
FireNX 
Replace pak0.pak (the one that's the same in shareware and regular Quake) in your Quake directory with the latest version (1.06, available here) and you should be good.

Pak1.pak shouldn't need to be updated to the best of my knowledge. 
Solved 
It was indeed the pak0.pak. Man, my CD must be old. 
 
Collectible! :-) 
 
0.93 "has stopped working" when trying to load death32c.bsp 
Thanks 
reproduced it. 
Getting Stuck On Buttons 
64-bit builds (tested on windows, probably linux/mac also) have a bug where the player gets stuck on buttons that move at an angle:
https://sourceforge.net/p/quakespasm/bugs/26/

I don't have a fix yet, but it's 99% likely the same as past 64-bit bugs (code assuming x87 math with 80-bit temporaries for floats) and should be quick to fix.

We'll do a 0.93.1 bugfix release sometime soon with this, a fog bug fix - https://sourceforge.net/p/quakespasm/bugs/24/ , and the death32c.bsp crash (vis data overflow). 
Does That Allow For Alpha Values Below 0.666 On {fence Brushes? 
 
Qmaster 
Do you know if any engines with fence textures implement it?
I'm assuming it would just need to use (0.666 * entity_alpha) as the alpha mask cutoff, instead of always using 0.666? 
Not That I Know Of, Twould Be Great For Ground Fog 
Currently you can have a func_illusionary using a fence texture and set the alpha to any value between 0.666 and 1.0, but below that it just dissappears.

I think it is just an arbitrary hardcoded threshhold. If it is necessary to have a threshhold, having it at 0.09 would be preferable. I haven't done an engine comparison for it.

Could be the thresshold has something to do with support for alpha channels (e.g. on png) instead of just the pink palette value 255, but not really sure on that point. 
 
My understanding is, the 0.666 threshold only comes into play when you use texture filtering - the actual pixels of the fence texture only have alpha of 0 or 1, the texture filtering interpolates between these, and then the fragment shader converts the interpolated value back to 0 or 1, depending on whether it's less than the threshold or not. So the specific threshold will control how big the fringe is around spites / fences.

The "(0.666 * entity_alpha)" sounds right to me, it's just something that should have a test map + screenshots, maybe with 0.25, 0.5, 0.75, 1.0 entity alpha on a fence texture. 
 
Lower alpha values will cause edges of fences to become faded, blurry or hazy, which is a very undesirable artefact. If you want to achieve a specific effect it's better to open a discussion about it, rather than trying to overload an existing effect in unintended ways. 
Quakespasm Gamepad Problem With Menu 
I am trying QuakeSpasm with a Dualshock 4v2 connected to Steam Link (so it appears as an xinput device to the game, afaik). The controller works, but there is a very odd problem: there is seeminly no way to "enter" any menu. I can enter/exit the main menu, navigate it, but not actually enter any of the menu options with any gamepad buttons.

And a feature request if I may: would it be possible to add an in-game mod and map browser/launcher? 
 
https://github.com/bangstk/Quakespasm

Suggestion:implement Quakeworld style HUD option from this branch. 
HUD Request 
I enthusiastically second this idea. Even if it's just a console cmd and not in the menu I prefer this HUD to NQ version. 
Transparent {fence Textures 
Please see this: http://www.quaketastic.com/files/misc/testing/test_trans.jpeg

I had the idea one day to mix alpha and {fence to make ground fog. It looks neat in the editor, but it doesn't work in-game. It would be really cool to mix this type of effect with some non-solid func_train's, func_bob's, etc.

I still don't understand why it doesn't work below 0.666.

Cross Engine Testing:
FTE: Does not support alpha on {fence textured faces. Side note: fence rendering has weird ugly black edges.
Mark V: Same as QS. Side note: the Pixelated/Rough mode looks best for fence edges (not related to the alpha). Not sure if this is just disabling mipmapping or what.
DarkPlaces: The old version I have doesn't support either {fence or alpha.
All other engine versions are the most current. 
Jago 
I can enter/exit the main menu, navigate it, but not actually enter any of the menu options with any gamepad buttons.

The A and B buttons are hardcoded to select menu items / go back a screen. If A/B are not working, it means something failed at a lower level than Quakespasm (probably SDL2's controller mapping).

Does it help if you download this file and put it in your quake directory?
https://github.com/gabomdq/SDL_GameControllerDB/raw/master/gamecontrollerdb.txt
It should enable more controllers.

re: mod menu and bangstk's changes, both things I have been meaning to get to 
 
I still don't understand why it doesn't work below 0.666.

Because GLQuake sets this at startup:

<p>glAlphaFunc(GL_GREATER, 0.666);</p>

Meaning that when the alpha test stage is enabled, anything with an alpha of less than 0.666 is discarded.

Fences are drawn with alpha test enabled, so that's why it doesn't work. 
 
Is there still use for the SDL1 version? Just curious about why that variant is still included in the package. 
 
Not much significant - audio CD support, win 9x support. 
502 Bad Gateway? 
Hey Eric. I periodically update through your nightly builds page found here:

(http://quakespasm.ericwa.com/job/quakespasm-sdl2/)

but the page has been giving a 502 error. Just thought I'd let you know in case you were unaware. :) 
Thanks HipnoticRogue, Fixed 
 
Screen Refresh/FPS Question 
If I set the game (in-menu) to 60 or 120 the game runs smooth as butter. If I use the built-in FPS counter the game reports 60 fps. All well and good.

If I set the game to 144 (my monitors refresh rate) the game hitches ever so slightly every few frames. When I check the FPS counter it only reports 71 fps. I have Host_maxfps set to 72. Shouldn't the game report 72 fps?

Regardless of what I do I get screen tearing unless vsync is on. At 60 fps there's a very noticeable lag in movement (I use a controller). The lag's not so bad at 71 fps but, like I say, there's that slight hitch which drives me insane!

I've tried using gl_triplebuffer set to "0" and "1" but neither seems to make any difference regardless of whether vsync is on or not.

Is there an issue with 72 fps or do I just have to live with the slight stutter?

I haven't reported it as a bug because nobody else has mentioned this 'issue' and I'm not sure if it's user error or an engine limitation... 
 
You're not the only one. A lot of people experience the same thing at 72. Even at 250 it feels like shit. Chew it down son. It's the recommended quake experience. 
 
You're not the only one. A lot of people experience the same thing at 72. Even at 250 it feels like shit. Chew it down son. It's the recommended quake experience. 
 
can u fix the double click thing? 
@Hipnotic Rogue 
I think QS's vsync implementation is broken, in that it doesn't disable the regular frame throttling code so sometimes you will get stutters. I would recommend avoiding vsync right now.

It sounds like you get hitching with vsync off as well, at 144Hz?

One hack you can try is "sys_throttle 0" - this will make QS use 100% CPU instead of sleeping (the default is 0.02).

If there's stuff we can do to make this better I am interested. I'm hoping to get a 144Hz monitor some time this spring as well. :-) 
@Hipnotic Rogue 
I think QS's vsync implementation is broken, in that it doesn't disable the regular frame throttling code so sometimes you will get stutters. I would recommend avoiding vsync right now.

It sounds like you get hitching with vsync off as well, at 144Hz?

One hack you can try is "sys_throttle 0" - this will make QS use 100% CPU instead of sleeping (the default is 0.02).

If there's stuff we can do to make this better I am interested. I'm hoping to get a 144Hz monitor some time this spring as well. :-) 
@ericw 
I've set sys_throttle to 0 but there's no change that I can discern.

It's not hitching as such at 144 Hz with vsync off. The 'hitched' frame (for want of a better term) tears instead. It's regular as clockwork just as the hitched frame would be with vsync on.

Is there anything else I could try for you or any more info you need just now? 
 
sounds like you want SDL_GL_SetSwapInterval 2 instead of 1, or ideally -2 (to enable swap_tear when timings slip a little).
The interval in question is measured in terms of buffer swaps, so 2 means that it'll run at 72fps on a screen running at 144hz.

Regarding host_maxfps timings - quakespasm uses milliseconds for timing - and rounding down means it needs to wait a little longer before the next frame.
This alternative will give more accurate host_maxfps:
double Sys_DoubleTime (void)
{
return SDL_GetPerformanceCounter() / (long double)SDL_GetPerformanceFrequency();
}
But do note that it might misbehave on certain/old dual core machines that lack drivers to resync cpu timers.
And ideally you'd rebase the counter to 0 to reduce fpu precision problems, but they.

Regarding nvidia, (at least for me) vsync is broken in their opengl drivers when the program (otherwise) runs at about 1000fps. Crossing that boundary (relative to the previous frame) results in a noticeable stutter. Enabling something wasteful like bloom seems to help, thanks to it no longer drawing frames in 0ms...

tl;dr version: timers suck. 
 
host_maxfps has lots of subtle little interactions beyond just wonky physics and killer elevators.

Particle trails have been touched on before; here's another one that many people might not be aware of.

Record a demo of you running around in a map for a minute or so at host_maxfps 72.

Record another demo of you doing the same run-around in the same map at host_maxfps 1000.

Compare the file sizes.

Interesting, isn't it? 
Quakespasm On Steam? 
For free. Why not? 
 
There's probably some legal shenanigans about distributing shareware Quake as part of another piece of software. Do you really want to read 17 pages of people who installed a sourceport without a game to play and are all copypasting the same gfx.wad not found error? 
@spud 
I'm assuming there's a way to ensure Quake is installed before launching. Similar to DLC. I dunno. 
 
Can anyone explain why Quake monster models occasionally turn black? I'd guess it's a lighting bug in the Quake engine but if anyone could give more detail as to why. I remember seeing this especially with the Scrag model. 
#3248 
Quake models get their lighting from the ground directly below them. If they pass over a bit of ground in total darkness, they go black.

Scrags sometimes fly over pits with pitch black bottoms far below them, and they thus turn black. Which is ugly. 
Following From That 
I kinda wish Quake used a 3d "light grid" like Quake 3 does for model lighting. People would probably be more inclined to make mdl props if the lighting was more accurate. 
 
And if there wasnt a 256^3 unit limit on size per frame. 
 
Don't models also only poll light from a fixed distance down? If they're too high up in the air they won't be lit regardless of what's below, iirc. 
I Thought Flying Monsters Used Lightsource Data Same As Viewmodels 
 
 
I'm not sure if you're actually looking for a solution to it, maiden, and maybe this belongs more in Mapping Help, but there is a workaround for dark flying enemies.

At the very bottom of the area in question, use an ordinary texture, and light it adequately, for example with the texture light option in ericw's compile tools. A short distance above that put a brush entity, like a func_illusionary or func_wall, that has the visual you want, like the solid BLACK texture. Enemies will pick up the lighting info from the solid world geometry underneath the fake surface, but players will only see the brush entity. A func_wall will also have the effect of making the surface solid, so if a player dies their head camera won't fall through.

I used this trick in my Xmas Jam map, xmasjam_tens, and although I used a solid gray texture, the principle is the same. I did have to tweak the lights to prevent the lower edge of the world from being brightly lit, but with eric's light options I was able to set the surface light's '_surface_offset' key to a negative value (in my case -2048). The surface got enough light to make entities above it visible, but the lower edge of all my rockwork is no more prominently lit than the rest of it. I almost didn't expect it to work, but it seemed to, so I'm not going to look a gift horse in the mouth. If you want to take a look, my source .map file is included in the Jam release like everyone else's. The light entity I used for the surface light is sitting just atop the starting crate, at 296 248 -112.

There's also sock's ad_sepulcher. There's a cavern area with a bridge, which triggers a mini earthquake when you walk over it. Search for a bunch of entities with the targetname "cavebridge_setup", they're all in that space. Look down at the bottom of the pit and you'll see an approach similar to mine. First is a func_detail_illusionary to provide the visual impression of a bottomless pit, but underneath is just regular world geometry, with ordinary textures. There's a few lights with their 'mangle' key set to make them spot lights, pointing down, so they only illuminate the extreme floor and don't break the illusion of endless blackness.

I'm sure other mappers have examples of this too, it's an old trick, but those two are the only ones I can remember off the top of my head. 
@3252,3253 
 
Winquake traced up to 2048 below the mdl, QS traces 8192 units. The code is in R_LightPoint: https://github.com/id-Software/Quake/blob/master/WinQuake/r_light.c#L248

@Tens
First is a func_detail_illusionary to provide the visual impression of a bottomless pit, but underneath is just regular world geometry, with ordinary textures.
Weird, I don't know why this worked, because the raytrace in R_LightPoint should have hit the func_detail_illusionary and picked that up instead of the lighting below it. Regular func_illusionary is safe though.

Btw, with my tools, you can set _minlight and _minlight_exclude on world brushes with func_group or func_detail - this could be a handy way to make the hidden brushes have the desired light value, without having to bother setting up spotlights pointing down. 
 
Thanks for the feedback mates. I was just curious what causes the ugly-looking effect. Good to know it's not a bug at all.

@ItEndsWithTens
If I ever dab at mapping I'll be sure to employ your workaround... :) 
 
@eric
I'm just going by what's in the 1.70 source files. Though looking at the map again in QS 0.93.0, Scrags flying over the pit do look kind of dark, so maybe it doesn't actually work? Hard to tell, honestly. You'd have to ask sock for more info, maybe there's more to it than meets the (or at least my) eye.

I'll be sure to fiddle with that minlight exclude key, sounds intriguing!

@maiden
Glad I could help! More Quake mappers is always a good thing, you'll certainly be welcome if you decide to join in one day. 
Controller Movement Tweak 
I added a "joy_exponent_move" cvar for controlling the move stick's mapping curve. Previously it was hardcoded as linear.. which translated to feeling twitchy (as Hipnotic Rogue was mentioing in ##3198)

I went with a new default of 3 (matching the "look" stick).. now you have to press the stuck further to get full speed, but it's easier to move slowly. The "look" stick is unchanged.

Wonder if any controller users could give me a second opinion on this in the dev build?
http://quakespasm.ericwa.com/job/quakespasm-sdl2/240/artifact/quakespasm-r1556.zip 
Cool Beans! 
I'll give it a test run after work and get back to you. :) 
As Will I 
 
Huge Improvement! 
I've been messing around and setting the joy_exponent_move CVAR at lots of different values just to see the difference. I reckon you were on the money with setting it at "3" though. :)

Slow and small movements now feel much more manageable.

Good job. :) 
Thumbs Up From Me Too 
 
Awesome Thanks 
 
 
The scrag example is one of the reasons the lightgrid was invented for Quake 3. 
When Will The Quakespasm Page Be Up Again? 
 
 
Does QS support .scale? I wonder if it would be fun to make tarbabies merge when they touch each other, forming a bigger tarbaby with each merging, all the way up to becoming a huge shambler-sized tarbaby. 
Awesome Idea! 
That would be an horrible "the thing"-like experience! 
If Barnak Likes It, It Must Be Wrong 
 
@mankrip 
I'm fairly confident that if you tried to use DarkPlaces .scale on an Ogre...

If you doubled his size, his feet would be in the floor.

Also you know Quake hulls (collision) ...

Maybe for Quake 3 map format .scale would work, but any feature using the Q1 map format shouldn't be called ".scale" but rather ".broken_scale". 
 
Hmm, that would require a protocol change then. Or a modified model, or CSQC.

The protocol method would send the mins&maxs from the QC physics bounding box to the client, so the renderer can offset the position of the model correctly. It's the most general-purpose solution and would make .scale more intuitive to use. 
@mankrip 
scale is supported by the rmqe/999 protocol, as well as fte+dp's protocols of course.
QS supports 999, I don't recall if it supports the scale part but QSS definitely does.

.scale is just as 'broken' on q3bsp as q1bsp.
For it to work properly, you need to bias the mins_z value to compensate. Obviously this will look seriously broken in engines that don't support scaling...
On q1bsp you need to refrain from changing mins_x and mins_y though, which limits the range of sizes you can get away with (otherwise a large monster will walk through walls in one direction, but not its opposite, and values that differ from the hull's size will make it more extreme).
maxs_z can be changed freely, at least. the monster might ignore ceilings but that's not a problem if you just avoid placing upscaled monsters in places with low ceilings. 
 
I don't think .scale is a good idea for reasons outlined by Spike, with which I'm in full agreement.

It's important to remember that the RMQ engine was a tech demo. One of it's purposes was as a semi-experimental test-bed for new ideas, not all of which should be expected to work well. Another of it's purposes was to become obsolete as ideas that did get bedded-in and nailed-down were picked up by other engines. It's a natural consequence of those two purposes that sometimes the implementation might be a bit wonky, or might simplify to a special case, or whatever. The point is: RMQ engine's implementation of .scale might not be a great model to work from. 
Scales 
RMQe's behaviour is fine, and is consistent with DP_ENT_SCALE, so that's a good thing.

But yeah, the hull issues make automatic scaling unworkable, so scale without qc is generally a bad idea.

So imho RMQe's scale is fine, and more robust than hexen2's... 
@mk -- Actually No 
"Hmm, that would require a protocol change then. Or a modified model, or CSQC."

Nope. Neither.

1) Open up, say, QME and double the model size.
2) Change the .qc setting the box -- you might need to add a new monster. This would at least get the Ogre's feet touching the ground appropriately.

3) If you decided to make a monster too big for a Quake hull (Shambler size?) -- you better add some invisible func_walls to box the bastard in too hide the lack of proper collision.

You can do what you want to do today and it would work in any Quake engine including and be done in 30 minutes.

Just don't get forget the asterisks. ** Any proper map using a "too big" model like the QTest dragon (Once Upon Atrocity, for instance) needs to "no clip block him in" to his area and close the door behind the player so he can't be sticking his dragon wings through the walls.

The Kurok engine actually had a special brush type "monster_clip" for special clip brushes that instead of blocking the player would block only the monsters instead --- in the case of Kurok, it was a helicopter shooting missiles and the monster clip kept it in a defined box.

The Quake map "Source of Power" https://www.quakewiki.net/archives/underworld/quakerev030624.html ... had baby Shamblers in GLQuake -- and I can't remember the name but some map had a 2x sized fiend or Rogue gremlin or something like that. It was also a map that ran in WinQuake/GLQuake just fine.

The short version is that ".scale" is and always was ".completely_broken_scale" that sounded cool unless you knew how broke it was.

It doesn't solve any problems and creates false newbie-sauce visions of grandeur -- and you can manually create a double sized or half sized fiend that works in WinQuake/GLQuake.

/Someone should find the guy who came up with the idea for ".scale" and slap him with a wet fish. 
 
You can do what you want to do today and it would work in any Quake engine including and be done in 30 minutes.

My idea was to use .scale in an animated way, and with non-arbitrary sizes. There would be a maximum size, but the tarbaby would also have any size between the minimum and the maximum.

Using multiple models would kill the model interpolation and wouldn't provide non-arbitrary sizes.

The animated shadows in Fightoon were created using animated scaling. The higher in the air the player gets, the larger (and more transparent) the shadow gets. This would be absolutely impossible to create in a regular engine. 
 
And here's another example of animated scaling usage. This effect dynamically resizes the model to the intensity of its entity's lighting.

I just didn't try figuring out uses of .scale for solid objects before. But for purely visual effects, it's a clear improvement. 
 
Using multiple models would kill the model interpolation and wouldn't provide non-arbitrary sizes.

You could author a new animation of "growing" from size N to size N+1, in each model. Play in reverse to shrink. This means he can't do anything else while he grows/shrinks, though. 
 
Also, the vertex compression would still cause the transition from one model to another to be jittery.

Using multiple models would still be a hacky & inefficient method. But the bigger issue is that the physics would likely end up even more hacky.

A proper solution for the physics would probably be to use the Q2 BSP format, which uses raw brushes for collision. But this means that such gameplay ideas aren't suited for Q1 anyway. 
Malice Issues 
why does the minigun skin in malice get messed up in both quakespasm and glquake?

also the probe wont fly about in quakespasm either... 
Small Idea / Request Thing 
Would you consider a "devkill" command? (short for "developer kill")

It would function like "kill", in the sense that the map and entities are all reloaded. However, it would preserve:

player position
player view angle
the current state of god, notarget, noclip.

When doing a lot of very rapid iteration on part of the level design, I realise most of my time is spent noclipping over to the place in question to test out the changes :/

I could fudge this in QC but then I think it would better if the feature was available engine side so you can use it in all mods.

For world geometry changes only, I can fudge it by just using save/load, but that doesn't work for any entity changes.

Just an idea. Would anyone else find it useful? 
Sure 
 
Pretty Cool Idea Yeah. 
I'd use it. 
"devkill" 
Save the state of the player entity only, minus dynamically referenced fields like entity and model references, and overwrite the current player state with it.

This could be implemented as "saveplayerstate" and "loadplayerstate" commands, giving the advantage of retaining the player state between engine sessions. 
Mankrip 
I like the cut of your gib. Sounds like an elegant way of doing it :} 
@Kinn 
I would use this as well. +1 
@Kinn - Noclipping To A Place 
Quakespasm has an setpos command to teleport you to a specific spot in the map, if I recall.

Type viewpos to get an x y z or you could type r_pos.

Those commands happen to work in Mark V. In Mark V, type viewpos and then typing setpos without the x, y, z will teleport where viewpos was last typed.

Short version: I think you can do what you want to do in Quakespasm already. 
Yeah, I Started Out Looking At That Actually. 
Turns out it didn't help too much because it's not really a case of me needing to teleport to the same specific area a lot, it's more to preserve the player's current arbitrary location and view during reloads when doing very rapid design iterations, where my location is jumping around all over the place.

The time it takes me to type r_pos, then note the coordinates, then type setpos X Y Z, means it's something you only want to do occasionally, and probably bind it to a key, which only really makes sense if you're spending a lot of time in that same area. But I zip around rapidly working here there and everywhere like a nutter.

If I just wanted to set up shortcuts to a bunch of fixed locations, it would be better to create a testing hub with teleporters to ten or twenty key areas in the map I reckon.

Without someone looking over my shoulder watching exactly how I work, I'm not sure if I'm really selling this to be honest :{ 
Hold Your Biscuits! 
Sorry I didn't read the critical bit here:

Those commands happen to work in Mark V. In Mark V, type viewpos and then typing setpos without the x, y, z will teleport where viewpos was last typed.

Ok, that's actually pretty useful. 
Custom Gfx Images 
Does the engine support custom images for the player HUD? It's for a mod. 
 
Is the issue with the Probe in Malice and engine side issue? Or something that could be fixed with QC? The probe won't move when activated in quakespasm.

Also wondering about the skin misalignment on the minigun mentioned earlier. 
Sorry I Forgot / Lost Track 
Can you link the post?

Skin misalignment: Not sure if it's this, but there is a half-texel offset in mdl skins in GLQuake relative to winquake, we discussed changing it to match WQ a few years ago but the consensus was to keep it as-is because there's a lot of content designed for the buggy GLQuake standard.

-- here's the current status on bugs in TC's I'm aware of:

1. the Xmen start map has a meditating guy telelporter, the teleport trigger is tiny due to setmodel() using a size based on the mdl rather than a fixed size like winquake. This was a change metl made in Fitzquake that I think he said was inadvertent. Not fixed - my feeling is we should revert to Winquake's behaviour, but there is a risk of breaking mods that were built for FQ's behaviour, so it may need a gameplay fix cvar to get the FQ behaviour back, which are a pain.

2. Malice (I think it was) has blue checkerboards on gibs, this was meant to highlight the mod being buggy since the skin number was invalid, but we changed it back to winquake behaviour and added a developer warning. 
 
Sorry, I don't know how to link to the original post in this thread. I'm pretty new here. Here's the original text though:

"Malice Issues
#3280 posted by [86.131.50.80] on 2018/02/25 19:40:30
why does the minigun skin in malice get messed up in both quakespasm and glquake?

also the probe wont fly about in quakespasm either... "

I know the minigun thing is some sort of vsync/resolution issue. I tried playing with setting and it would eventually work. But would have to set vsync on/off each time I start.

The probe won't move at all when fire key is pressed. I did find something about MarkV engine fixing this or making a work around.

http://quakeone.com/forum/quake-help/quake-clients/5863-proquake-4-43/page8 
 
@kinn - I'm glad that helped, ericw is free to copy the implementation if wants, obv. During testing I often need to go to the same point in a map frequently to examine an area doing engine stuff, obv.

@legend - Malice should play essentially perfectly in Mark V. NightFright really liked Malice and clubbed me over the head with Malice. If I recall, it is bounding box issue that FitzQuake simply has different behavior than WinQuake and the solution is something like sv_gameplay fix original Quake bounding boxes (I can't remember cvar name off hand but it sv_ something.) 
How To Invert Look On Quakespasm. 
Please help. All I want to do is invert the y axis for my ps4 controller. everything else works fine. Where is this default.cfg? I do not see it anywhere in my quake folder. I see dosbox_quake and dosbox_quake_single in the root directory. Where do I put joy_invert? 
 
@pfraktal:
Default.cfg should be in the main folder. If not, try in your ID1 folder. Also, try changing settings inside your config.cfg in the ID1 folder or inside the folder of which ever mod/mapset you are trying to run. 
 
You can open the console with the `/~ key and type "joy_invert 1". This is an archived cvar so it will be saved to id1/config.cfg. 
Please 
Restore the vanilla Quake startdemos functionality. 
-fitz Commandline Argument 
You might already know this, but you can get the functionality by adding the commandline argument -fitz when starting QS. 
 
That does muck with a few other minor things tho. 
 
Yup, one of the more noticeable ones is by default QS's tab-menu status bar has kills, secrets, and skill level, while -fitz reverts it to kills, secrets, and time elapsed. 
What are the other effects, exactly? 
-fitz 
Ooh what other scary effects are there? 
-fitz 
Going off memory here, because the readme only includes "o To disable some changes, use "quakespasm -fitz" which is less than helpful for finding exact changes:

-QS by default drops the player straight to the console screen with a new grey background, -fitz enables the old id background and demo reel (vanilla Quake behavior)
-Status bar info changed (mentioned previously)
--fitz re-enables the 'Press Y to quit' prompt, while QS will otherwise let you immediately exit. Note it's just a plain 'QuakeSpasm 0.9.whatever by <author list>' message even with -fitz enabled, not a full credits list with 'press Y to quit' all the way at the bottom like WinQuake, or the various Doom-style insulting quit messages ("Are you gonna quit this game just like everything else?") of DOS Quake.
-Possibly changes updated entities, although this one I'm not sure of; Quakespasm's own .pak file still includes .ent files for five maps, but I don't know what they change offhand and it's not listed in the readme. QS does include an external_ents cvar for loading of external entity files, but it's set to 1 by default with and without -fitz. I also thought one of the changed entities was E1M1 to get rid of the obvious Z-fighting on the lift for the quad secret (by moving the lift down slightly, as original Quake always drew world brushes in front of brush entities so there was no Z-fighting there), but that's not included so maybe I imagined it?

Also of note is that the console background is in the .pak where it should be, but the HUD layout itself (the time/skill switch up) is apparently hard-coded. 
Wierd. 
Who is the QS curator anyways? I get the impression it's a community effort. 
 
Judging by the source code, -fitz prevents loading of the whole quakespasm.pak, which includes alternative default keybinds, conback picture and ent files.

Speaking of features, it would be cool to refactor the menu in such a fashion that menu controls could be anything else than arrows. But damn, this looks like a lot of manual labor. What are the chances of breaking something important in case of menu controls altering, I wonder. 
So When I Deleted My Quakespasm.pak... 
I basically always run in -fitz mode? 
#3307 
No, because there are hard-coded behaviours in the engine that don't depend on content. 
 
Going through the source code, the exact and only differences -fitz applies are:

- Don't load the custom quakespasm.pak
- Run the normal demo loop (QS otherwise goes straight to the menus at startup).
- Pop up the Quit prompt (QS otherwise just quits immediately).
- Revert some changes to the solo scoreboard layout.

If you delete the quakespasm.pak you'll get the first of these; you will not get the others so you will not be always running in -fitz mode just by doing this.

It's also the case that future revisions of QS may add more.

Don't let this become one of those stupid items of "Quake lore" where the entire Quake community becomes religiously convinced of something that's actually flat-out wrong. 
 
startdemos is called by quake.rc. If QS has its own .pak to overwrite settings, it can ignore startdemos by simply omitting it from quake.rc. Does QS actually ignore startdemos in the engine itself? 
@mankrip 
Hardcoded in the engine 
 
Does QS actually ignore startdemos in the engine itself?
Yeah, QS disables the "startdemos" command, unless -fitz is used.

MarkV's approach seems better to me; it has an archived host_startdemos cvar default to 1, if you want to disable startdemos for all mods you can add "host_startdemos 0" to your id1/autoexec.cfg or launch with +host_startdemos 0. 
QS/Quoth Bugs 
Not sure if this is solely related to QuakeSpasm, due to it being the only port I use, but there are some bugs when playing Quoth, such as the Trinity/Reflection flashblends not getting cleared after loading a quicksave or the view offsets and roll being misaligned when quickloading during an earthquake effect until either restarting the engine or letting the effect play out in its entirety. Also, is it intentional that monsters aren't interpolated when they are on a moving platform, or is this not implemented yet? Last thing of note is that the "give a(rmor) x" command is bugged in QS and Mark V when playing with Dissolution of Eternity. The amount entered is properly set, but the armor icon doesn't update and for some reason it makes you able to fire lava nails without having the SNG. 
Buggy Mouse Look In 0.93.0 
I just downloaded 0.93.0 after using 0.92.1 for a while without any issues and my mouse is skipping around a lot. I'll be looking straight ahead when suddenly I'll do an instant 180 and be looking behind me. Sometimes I end up looking at the floor or any other random direction, and it often leads to blowing myself up when using an explosive weapon.

Apparently I seem to be the only person experiencing this but after doing two fresh installs, I can't seem to get rid of the problem. The only resolution is to continue using 0.92.1, but any help or suggestions would be appreciated. 
@Poorchop 
Do you experience this on both the SDL 2 and the SDL 1.2 .exe? 
#3314 
A Windows 10 update broke that. The SDL2 version should still work though. 
#3314 #3316 
@Poorchop
Funnily enough, I get the same mouse problems with Doom 64 EX, which also uses SDL 1.2, but not with Quakespasm SDL 1.2.

@Kinn
Sorry for getting off-topic, but ironically, regarding Doom 64 EX, there is a Windows 10 fix for the mouse issues, but I have Windows 7 and mouse issues anyway. The fix doesn't work for me either. 
 
Also, is it intentional that monsters aren't interpolated when they are on a moving platform, or is this not implemented yet?

This bug existed in Fitzquake as well, I never could figure out why.

Also falling scrags in demo1.dem seem to not interpolate their fall. 
 
Last thing of note is that the "give a(rmor) x" command is bugged in QS and Mark V when playing with Dissolution of Eternity. The amount entered is properly set, but the armor icon doesn't update and for some reason it makes you able to fire lava nails without having the SNG.

This command doesn't exist in the original Quake engine and the bug is inherited from FitzQuake. The Rogue/DoE mission pack uses different defines for armour, and the original defines are instead used for some weapons.

In your specific case, the original IT_ARMOR1 define has a value of 8192; in the Rogue mod that's actually RIT_LAVA_SUPER_NAILGUN, so hence the behaviour you see.

Engines implementing a "give a" command should test for "if (rogue)" and use RIT_ARMOR1, RIT_ARMOR2 and RIT_ARMOR3 instead of IT_ARMOR1, IT_ARMOR2 and IT_ARMOR3. 
 
@Poorchop, which .exe did you experience the bug with in 0.93.0?

The naming convention changed so quakespasm.exe is SDL2.0. This one should be mouse bug-free because it uses raw input, and the other one - quakespasm-sdl12.exe (and all SDL1.2 apps) have known broken mouse input since the Windows 10 Fall creators update. 
 
I know we had a brief Q&A about this upthread, but it really does seem like something needs to be done with that SDL 1.2 version. If not getting rid of it entirely, then isolating/renaming it so that people only use it if they really need it (i.e. are playing on Win95). 
 
something needs to be done with that SDL 1.2 version. If not getting rid of it entirely, then isolating/renaming it so that people only use it if they really need it (i.e. are playing on Win95).

The bad thing about SDL-1.2 on Windows is that no one has backported the bug fix for Fall Creators Update (Win10 v1709) SetCursorPos() bug to it yet: someone should -- I tried myself but got lost in the mess and gave up.. Other than that it still works OK, and it's still good for systems where SDL2 is not available. 
@mh 
Give commands suggestion:
The mod should be able to define the give commands in the quake.rc file or default.cfg.
Something like:
set give "1", 2048
set give "2", 4096
set give "3", 1024
set give "0", 16384
set give "n", 256
set give "s", 512
Etc. Etc.

This would also add ability for any char to give specific mod ITems. Well, except for .items2 or .moditems that is.

I'm okay with having builtin give overrides for the mispacks, but any more and it gets ridiculous adding in a bunch of mod specific checks. At least this might provide support for these cheats to future mods or allows enterprising Quakers to make their own mod quake.rc updates and share them for different mods. 
 
ericw and DabbingSquidward, thanks for your help. I was wondering why one of the executables was called quakespasm-sdl12.exe instead of *-sdl2.exe. I read the changelog yesterday but I guess I somehow missed that part. That explains why I wasn't having issues in 0.92.1 - I was using SDL 2.

I've been swearing off Windows 10 for years but I finally decided to give it a shot, and of course it's the root of many of my problems, not just with Quakespasm. Go figure. Anyway, I tried the standard .exe with 0.93.0 (SDL 2) and it's working perfectly. Thanks for your help. 
 
The mod should be able to define the give commands

In that case, aliased impulses would work better, because they're compatible with any engine.

The "give" command is for end users, not for mod authors.

A middle ground would be to make the "give" command accept raw bitflag values. Accepting raw bitflags only would make the code even cleaner. 
 
Speaking of which, what are all the items that the 'give' command is able to grant? The ones I know of are:

3-SSG
4-NG
5-SNG
6-GL
7-RL
8-LG
H-Health
A-Armor (Fitz, Spasm & Mark V)
S-Shells
N-Nails
R-Rockets
C-Cells
L-Lava Nails
M-Multi Rockets
P-Plasma

Is there anything I missed? To add to the suggestion, it would be nice if the command accepted whole words or classnames, like in GoldSrc or every engine beginning with id Tech 2. Such as "give weapon_supershotgun", "give ammo_shells_large" or "give item_artifact_super_damage". 
 
That's pretty much complete, aside from some Hipnotic weirdness in the weapon give commands (0 = hammer, 6a = proximity gun, 9 = laser cannon). 
 
The "give" command is for end users, not for mod authors.

I'd go one further and say that the "give" command is a cheat, so it shouldn't be expected to be 100% robust.

it would be nice if the command accepted whole words or classnames, like in GoldSrc or every engine beginning with id Tech 2

On the surface this seems a reasonable and sensible proposition.

However, Quake 2 fully moved the "give" command into the game DLL, meaning that mod authors were responsible for writing up it's behaviour.

Would Q1 mod authors be willing to accept something similar?

This is a more general issue with proposals of the "Q2/HL did it so why can't Q1?" nature; making such changes can involve architectural changes which may break compatibility. Of course Q2 and HL didn't need to be compatible with Q1. 
 
Yes, something like that in the Q1 architecture would be a massive hack. And imo, hacky features are the main responsible for feature creepiness in such projects, dragging the projects to a slow death.

The less silly code to maintain, the better. 
I Don't Mind The Idea Of Direct Bit Value 
give muh-bits 
 
Just use [krimzon_]SV_ParseClientCommand.
Then the mod can provide whatever it wants without needing the user to do weird stuff etc, and without the engine changing quite so many random fields and breaking stuff by doing so... 
@mh; @metlslime 
mh: In your specific case, the original IT_ARMOR1 define has a value of 8192; in the Rogue mod that's actually RIT_LAVA_SUPER_NAILGUN, so hence the behaviour you see.

Haha, just when you think there are no more quirks.

Also falling scrags in demo1.dem seem to not interpolate their fall.

Haha. mh and Spike explored/explained that one years ago --- it is a horror story of vast cruelty related to monsters and lifts.

Basically --- it cannot realistically be fixed.

Which I think that means mh might have tried in DirectQ, haha ;-) 
 
I tried, I failed, I crashed, I burned.

The problem is movement (*NOT* animation) interpolation is done differently for the two different classes of entity, resulting in minor differences and oscillations in positions.

I don't think there's a 100% robust one-size-fits-all solution for this. 
 
On lifts? Dead bodies could use MOVETYPE_FOLLOW.

On demo1.dem, where a dead scrag falls in the GK water pool? I'm not sure. It seems to be more of a general problem with far away entity movement being not interpolated correctly, since in some engines it also happens with the living fiends walking at the bottom of the water pit in the beginning of E2M2. 
Scaling Up 
Is there a way to scale up lower resolutions similar to Mark V WinQuake in order to get the classic chunky pixel look? Mark V WinQuake allows you to play at modern resolutions but scale up from 320x280 or 640x480 and it looks pretty true to the original even when playing at something like 1080p. It also preserves the original HUD scale.

WinQuake is great for closely approximating the look of the original game while still playing on modern monitors but I can't get the music to work and a bunch of new maps/mods utilize Quakespasm features. I feel like at least part of the original look could be recreated with upscaling. I tried setting r_scale to a higher number but that just makes everything look really blurry instead of crispy and chunky, and I can't find any other scaling settings apart from scaling the HUD. 
 
gltexturemode gl_nearest_mipmap_linear helps Quakespasm look a bit more WinQuakey. 
Music In Mark V 
I'm assuming you have your music in ogg-format. Mark V (infamously) doesn't support it (or at least I think it still doesn't). MP3 works at least. 
 
Mark V has native Mac and iPhone ports. Apple API does not do OGGs.

Apple API decodes mp3 via hardware acceleration and stop and start music at the drop of a pin including on Windows. Other engines cannot do this and have to do things like restart the map and such.

Mark V also does not need any DLLs to do what it does.

Also mp3 decoding via hardware uses almost no CPU, especially important on a portable device like an iPhone due to battery.

mp3 > ogg simply because all Intel and ARM chips have MPEG accelerated decoding built into the chip.

This is why your DVDs play fast. This is how music on your iPhone or Android phone plays.

Try playing an ogg on an Android phone and watch what it does (hint --- it says "converting to MP3"). 
 
Disabling texture filtering certainly helps but it still looks quite far from WinQuake without being able to scale up while preserving the aspect ratio. Also thanks for the advice regarding the music. I'll try the mp3 files instead so that I can have some music alongside the chunkiness of WinQuake when playing through vanilla stuff. 
Mark V Winquake FTW! 
I also like to play the id1 episodes on Mark V Winquake. :) Same goes for the early custom maps that don't have lits and stuff.

Interesting stuff, Baker. I didn't know how well MP3s are supported all the way down to the hardware level. I'm starting to see, why you're defending it over ogg so vehemently. c: 
@esrael 
Yeah, most people don't know (nor care) about the implications of music play on all platforms. I did some engine modding a Playstation Portable Quake. It had a hardware mp3 decoder and also a software decoder libmad. The hardware decoder ran like lightning. Libmad software decoding ran like total foobar with 19 fps.

I try to study the proper way to do things and know exactly why I am doing them.

I have literally watched Quake engines crash and burn that did not know why they were doing what they were doing.

And what's funny is common factor tended to be doing "what most people want" (at the time!) against long-term "health" without understanding "what most people want" is fickle and subject to change at a moment's notice. 
Palette Wank Incoming... 
Poorchop, big crunky piskels is one thing, and I'm somewhat of a fan of that, but for me by far the #1 thing that gets the "WinQuake look" is if the lightmapped textures are drawn via the quake colormap, to get the proper 8-bit palette colours.

Now, FTE does this accurately with its r_softwarebanding option. I don't know of any other GL engine that does it properly, but FTE does. Of course, software engines all do it, but I also quite like having double digit framerates in modern maps, so a GL engine is the only option for me.

With r_softwarebanding on, just firing up start.bsp and looking up at those wooden boarded ceilings, letting myself melt into those rich chocolatey shadows, is enough to give me a proper Quake boner.

A lot of people instinctively dismiss the idea of Quake pallettisation in the modern age of coloured lighting and fog, and indeed if you just did the pallettisation as a post-process effect, then yes, it looks like total arse because of that...

However, FTE neatly avoids this by just doing it on the Quakey bits, and then the coloured lighting and fog just tints the colours "on top of" all that, and it just works and looks absolutely great. Best of both worlds.

(All well as a reply to Poorchop, this post is also a thinly-disguised plea to ericw to do FTE-style r_softwarebanding in QS, but I think I've been fairly subtle about it, mwahahah). 
 
It's not difficult to do, just that it absolutely needs fragment shaders, which might be a step too far for some. 
 
I used to prefer WinQuake's distorted colors too, until playing enough maps with custom textures to realize that it looks like ass in way too many cases.

It's only aesthetically safe to use in vanilla Quake textures, because they were carefully designed for it.

Try playing maps such as SEWAGE.bsp, nar_cat.bsp or dwmtf.bsp in a standard software renderer. Instant vomit. 
#3344 
Yeah, custom textures that rely too heavily on the terrible grey line will look like toss in software mode.

But I think it really makes well-designed textures come alive. The default GL-style lighting makes it all look a bit flat and sterile in comparison. 
 
Yeah when designing textures for quake's software renderer, there needs to be a a lot of noise and roughness, grimy/crusty materials looks best. Wide areas of a single color look really bandy and bad (but are fine in opengl) -- so you have a generation of custom textures made for glquake where people never even looked at it in software mode.

Also the voodoo cards which everyone had in 1997/8 to play GLQuake had its own dithering/grittiness/muddiness that actually enhanced the look of Quake. 
 
To come back to the pixel-scaling thing for a sec, in Quakespasm you can try different values for r_scale. I don't remember off the top of my head if this is also reflected in one of the GUI menus. 
 
@Poorchop:
setting r_scale to a higher number but that just makes everything look really blurry instead of crispy and chunky, and I can't find any other scaling settings apart from scaling the HUD.
This should make QS render to a half-sized framebuffer (for r_scale 2) and scale it up with nearest interpolation, so each original pixel becomes a 2x2 square. There shouldn't be blurring in the upscaling. If it is actually blurring the pixels together, mind posting your system info / screenshot?

It's not difficult to do, just that it absolutely needs fragment shaders, which might be a step too far for some.
QS 0.93's world faces and alias models go through fragment shaders, so just water, sprites, particles, sky, and anything else I'm forgetting use fixed-function at the moment.

I do want to implement this at some point! (I tried a quick hack a year or so ago, that postprocesses the final 32-bit rendered frame. What I did was make a lookup table from rgb565 to the nearest Quake palette color, then just feed in a 32-bit pixel, decimate it to 16-bit (565), then lookup the nearest Quake color and output that). As Kinn was saying, palletizing a 32-bit rendered image that has fog already baked in tends to look like mud, so this needs to go into the fragment shader before fog is added.

The faster / more natural / software faithful way of doing it is to ignore colored lighting and use the colormap.lmp just like software, having the fragment shader read the textures as 8-bit. Another option is to support colored lighting by blending with the lightmap in 32-bit, the using the rgb565 lookup table to convert that to paletted. 
 
Oops you actually mentioned r_scale!

Hmm I haven't had any blurriness issues with that, assuming the necessary setting of gl_texturemode. 
Wrong Word Choice 
Maybe saying that it looks blurry was the wrong choice of words because it does appear to be doing exactly what you mentioned. It just doesn't look like upscaled WinQuake, which is what I was kind of hoping. I guess I went with blurry because when moving around, it kind of looks like what you would see if you were playing in biting cold wind and your eyes were watering.

Here is r_scale 1:
https://i.imgur.com/jJBlmWr.jpg

and here is r_scale 5 (went with a much higher value to better demonstrate what I'm talking about):
https://i.imgur.com/UUCZLV0.png

The few rows of pixels going across the screen around where the shotgun model ends exemplifies what I mean when I say it looks blurry. This is especially true when moving.

The only pertinent visual setting that I'm using is gl_texturemode GL_NEAREST_MIPMAP_LINEAR but I think that I also tried this with gl_texturemode 1 with pretty similar results. This is on Windows 10.

Also interesting stuff Kinn. I haven't really put my finger on what exactly it is that captures the original look but it probably has more to do with what you said rather than just chunky pixels. I haven't tried FTE yet but I'll give it a look to get an idea of what you're talking about. Granted newer maps that take advantage of the fog and colored lighting still manage to look really beautiful in Quakespasm - trying to preserve the original look probably would be more of a detriment in this case. I'll have to look at FTE to get an idea of how the fusion of new and old holds up. To be fair, I'm not too hung up on retaining all of the old visuals because I do like the frame interpolation with animations in modern engines and I like the feel of modern engines especially with regard to the more comfortable mouse look. 
 
The few rows of pixels going across the screen around where the shotgun model ends exemplifies what I mean when I say it looks blurry.

That is a problem with the way that GPUs choose mipmaps. WinQuake uses the nearest vertex distance to determine which mipmap should be displayed on the polygon, but GPUs uses the farthest vertex distance, therefore choosing lower-res mipmaps.

I recall someone explaining this in another thread here, and that there's no solution because there's no API to finetune this behavior on GPUs. The only way to minimize the problem is through anisotropic filtering, but afaik it only works in GL_LINEAR_MIPMAP_LINEAR. 
 
I am pretty sure that in Quakespasm (or GL Mark V) the gl_texture_anisotropy setting does affect even gl_nearest_mipmap_linear texturing in some way. Don't have the details handy though. 
 
GPUs uses the farthest vertex distance

That's not true.

With a GPU, mipmap level selection is (1) per fragment, NOT per vertex or per polygon, and (2) based on the screen space derivatives of each fragment.

For fixed pipeline hardware selection is described in the GL spec, e.g for GL 1.4 on page 145: https://www.khronos.org/registry/OpenGL/specs/gl/glspec14.pdf 
 
By "per fragment" you mean trilinear filtering?

I'm on mobile, can't easily search for the specific post where I saw the info.

(2) based on the screen space derivatives of each fragment.

Which means that for polygons that aren't parallel to the camera plane, the texels farther away from the camera gets smaller, so the texel on the vertex farthest away will determine which mipmap to use. That's how I understood it.

What I'm talking about is a comment about the differences between trilinear filtering, anisotropic filtering and why the walls on hardware-accelerated engines gets blurry when seen from an angle. I don't remember the exactly thread, but the comment was somewhat recent. 
 
Okay, here's the exact quotes:

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. 

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

Also Worth Adding...
#3143 posted by mh [137.191.242.106] on 2017/11/22 18:29:07
...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.
 
 
The first quote is the #3140 posted by Spike [86.151.115.97] on 2017/11/22 17:55:03. 
 
No, forget about vertexes, they're not relevant. Likewise distances: Not relevant.

Per fragment is not trilinear.

In OpenGL a "fragment" is a collection of values used to produce a final output; please read https://www.khronos.org/opengl/wiki/Fragment for more info.

Texture coords (NOT texture lookups) are linearly interpolated between the per-vertex and per-fragment stages. Those interpolated coords are then used for mipmap level selection and texture lookup, which may have linear or nearest filtering applied.

In shader speak,

in vec2 texcoords;

Vec2 ddx = dFdx (texcoords);
Vec2 ddy = dFdy (texcoords);

Vec4 color = textureGrad (texcoords, ddx, ddy);

And that will give you the same result as the GPU's automatic miplevel selection.

The important message however is that miplevel selection in hardware is NOT per-vertex or per-Surface, because the fragment shader stage just doesn't have access to that info. It's per-fragment; per-pixel if that's easier (even if not 100% correct) terminology.

This is all public information; it shouldn't need to be explained. 
 
mh: Yes, I didn't try to learn exactly how it works, but it was enough to give an answer that despite being not technically correct, points to the right place where the cause is: the GPU mipmap selection algorithm. This way Poorchop knows that it's not a fault of the texture mode or screen scaling algorithm used by QuakeSpasm.

I was just trying to help so the guy won't waste his time messing around with every cvar trying to fix it. In this sense, my answer should give the proper results.

And yes, I recognize I'm way more dumb than I should be when it comes to hardware rendering, but it's not my field. There's no future for me in it. I only learn what I need to know about it from an user perspective. 
Render Gun In Lienar Or Nearest 
Problem Solve ! 
Yet Another Controller Question! 
Is there a way to designate a specific controller in QS?

I just got a lovely Hori Fighting Controller that I use for old d-pad based games and emulation.

Problem is that it's plugged in whereas my analogue controller is wireless. It seems that QS only reads the first controller recognised by Windows or something.

When I boot up QS it only responds to my plugged in controller and I can't find a way to get QS to read what has now become my 'second' controller.

PS: Just a FYI that the Nightlies page has a 502. :) 
 
At the moment it's hardcoded to use the "first controller in the list" returned by SDL.. agree this would be a good / easy thing to improve.

I don't know what would be a good way to store it in a cvar - just the controller index would work I guess, as long as the OS returns them in a consistent order across reboots.

re: Nightlies, thanks.. rebooted. 
 
Do you think that sometime in the future you'll create a menu for controller options? Maybe if players can easily change things in a menu it wouldn't be such an issue if they did have to occasionally change the CVAR.

Of course, I've really no idea how much work it is to add menu stuff in Quake... Just curious. :) 
Potential Code Snippet Donation 
in_sdl.c -> IN_StartupJoystick ...

Replace "for (i = 0; i < SDL_NumJoysticks(); i++) { ... }" block with following.

{
qboolean do_second = COM_CheckParm ("-controller2")
qboolean found_first = false;
for (i = 0; i < SDL_NumJoysticks(); i++)
{
const char *joyname = SDL_JoystickNameForIndex(i);
if ( SDL_IsGameController(i) )
{
const char *controllername = SDL_GameControllerNameForIndex(i);
gamecontroller = SDL_GameControllerOpen(i);
if (gamecontroller)
{
if (do_second && !found_first) {
found_first = true;
continue; // skip to the next one
}
Con_Printf("detected controller: %sn", controllername != NULL ? controllername : "NULL");

joy_active_instaceid = SDL_JoystickInstanceID(SDL_GameControllerGetJoystick(gamecontroller));
joy_active_controller = gamecontroller;
break;
}
else
{
Con_Warning("failed to open controller: %sn", controllername != NULL ? controllername : "NULL");
}
}
else
{
Con_Warning("joystick missing controller mappings: %sn", joyname != NULL ? joyname : "NULL" );
}
}
}


Hipnotic Rogue could just add -controller2 to the command line. 
... 
Someone in the QuakeDroid thread asked for controller support for Android ...

Was about to implement controller support from a SDL2 development blog, then realized if it didn't use the same key names, behaviors and such as Quakespasm would be a missed opportunity.

Short version is that I spent some time researching the differences between the initialization in Quakespasm vs. what I read on the SDL2 development blog, and ended up reading this section of code several times. 
 
Cool, I hope the QS controller code is useful. I'm biased but I really like how it turned out (pretty clean integration with the engine, playable out of the box, defaults went though a lot of player testing - i.e. cubic easing, the deadzone implementation.)

Here is the initial commit that shows the changes outside of in_sdl.c: (mostly just adding K_ABUTTON and K_BBUTTON to the menu code.)
https://sourceforge.net/p/quakespasm/code/1293/

I made some further tweaks which I think were restricted to in_sdl.c. Let me know if anything is unclear.

(Thanks for the -controller2 code snippet, that seems like a good starting point for multi contorller support) 
 
Should you have use for it, @insideqc I posted something for "Quakespasm Ticket #27" (Unix path) that isn't rocket science but perhaps will save you 5-10 minutes.

Go to sv_main.c line 1432 (SV_SpawnServer) and applying that to the sv.model_precache[1 + i] (modifying it) *should* in theory solve the problem for models.

Might need to hit pr_cmds.c PF_precache_sound and pr_cmds.c PF_precache_model. And sv_main.c @SV_StartSound and sv_main.c @SV_ModelIndex

Rough blue print.

/If you decide that is worth addressing at all. The counter-argument is that this falls at the doorstep of the mapper -- the mapper fixes the map and re-releases the map. There are myriads of ways a mapper can foobar a map, perhaps the right answer is "Not going to protect mapper from self". 
Thanks 
Yeah, it's a grey area. If winquake.exe and QS on Windows accept it, that's a good argument for accepting the backslashes on Unix OSes, but it should be a developer warning on all platforms (realistically most maps are only tested on Windows before release). 
 
If winquake.exe and QS on Windows accept it,
that's a good argument for accepting the backslashes
on Unix OSes,


I disagree, we shouldn't have to fix mapper screw-ups.

Not going to protect mapper from self

This is how I see it. 
 
Plus what about mixed case filenames -- say some guy does a upper case file name that happens to match a lower case on in a pak on accident and Windows ignores it ... but Linux should do what?

Trying to protect mappers from their own choices ultimately leads to choices with unexpected consequences.

/Anyway, just throwing out a thought. 
 
fair point, I guess this kind of compatibility hack also indirectly forces other engines to apply the same patch. A developer warning would be good though. 
Ericw 
I do want to implement this at some point!

Zomg, sorry I seem to have missed this post, but that is great news :D

The faster / more natural / software faithful way of doing it is to ignore colored lighting and use the colormap.lmp just like software, having the fragment shader read the textures as 8-bit

I'd happily live without coloured lighting just for the true software look, although it's worth having a gander at how FTE does it, which somehow does the proper 8-bit palette look, but then it can still get tinted by coloured lighting afterwards, which neatly avoids the colours getting mangled. 
@ericw 
The way Quakespasm's SDL2 controller support works totally doesn't work on Android (at least not as of SDL2 2.0.8 - March 1 2018).

That being said, SDL2's controller support for Android appears to be better than in the past.

I think SDL2 used a "Steam/desktop computer mentality" to the controller support for Android, and then started to gravitate towards using the existing controller support already that is part of Android (which from accounts I have read, works outstandingly well).

I may yet get some sort of Android SDL2 controller support to work (I have 6 buttons working, no axis working, several buttons not working).

I think SDL2 has done a tremendous job on Android.

Now I think I understand why the SDL2 blog and your code were different.

Anyway, just wanted to provide some feedback to as to how that went. Should I get it to work, having your skeleton of cvars/deadzone stuff will have been very useful even despite SDL2 Android wiring differences. 
 
I've got a question about an issue that is suuuuper minor -- but I'm curious so I'll go ahead and post it.

When quitting the game, or when using the menu to start a new singleplayer game while you already have a game active, Quake will pop up an "are you sure" dialog that waits for you to press Y before continuing.

Something I've noticed when using Steam streaming with Quakespasm is that the dialog will be visible on the monitor of the PC that is running the game, but it won't be visible on the TV that the game is being streamed to (through Steam link). On the TV it looks as if the game has frozen up. But you can still of course press Y (or ESC) and things work as expected.

(I'm not sure if this happens with other Quake engines too.)

This is not anything I'm losing sleep over, but do you have any guesses off the top of your head why that dialog doesn't make it to the streamed display? 
 
might be drawn to the back buffer and then the buffers aren't getting swapped before the game stops to wait for input?

Does the same thing happen if you try to start a new game from the single player menu while a map is loaded? 
 
oh, reading a bit more closely... maybe the streaming to a TV doesn't update the most recent frame? It's one frame behind somehow? 
 
Nah, what is likely going on is that the screen is blocking in Quakespasm, like it was in FitzQuake and original Quake before it.

So anything that depends on a normal frame or normal event process isn't going to happen.

(A counter-example: in Mark V very recent builds, the dialog screen is not blocking -- you could stare that the dialog screen all day and, for instance, not disconnect from a server. It might be like that in FTE also, I wouldn't be surprised. I may have even got the idea from FTE and then forgot.) 
Although Actually ... If It Is One Frame Behind ... Here ... 
Although ...

If the issue is "one frame behind" ...

Quakespasm source ...

scr_drawdialog = true;
SCR_UpdateScreen (); <---- I don't draw twice!
scr_drawdialog = false;
...
do {
..
while }

If the stream expects double buffering, it isn't getting it in SCR_ModalMessage.

The test for a solution would be doubling it up ...

scr_drawdialog = true;
SCR_UpdateScreen ();
SCR_UpdateScreen (); // Double buffer it.
scr_drawdialog = false;

(My first reply was on gut instinct about the event queue/not having a normal frame ... because I've experienced a fair number of headaches before due the blocking dialog so I had the blocking dialed in as public nuisance.

But gut instincts aren't always right ...

and although I've run into instances of the blocking dialog not drawing specifically because it is blocking .... may not mean anything at all in this situation ...) 
 
not all systems even support explicit *SwapBuffer calls.
Eg, webgl takes away control of your main loop, redrawning only when your redraw function returns.
There's other systems that do the same sort of thing, including Android's GLSurfaceView or MacOS's cocoa api.

Plus there are drivers that violate the GL spec and force triple-buffering, so you're never sure how many swaps you actually need to make to ensure that its actually swapped.

As a result, its imho easier to just keep redrawing the screen regardless (which is required on many systems anyway, where the system doesn't repaint unless the app explicitly does so - like windows).
But its best to avoid modal things entirely. Sometimes you don't really have a choice though (like QC debugging).

Regarding video capture, the recording program probably set up some code injection that copies the backbuffer to a pbo (or a compute shader) before the swap. Such things generally check the response the frame after that, which avoids forcing the cpu to sync with the gpu. This requires a couple more swaps before the data is available to encode, which of course makes loading screens really messy.
Hurrah for threads!... 
GNU/GPLv2 Question 
Am I allowed to sell a mod on steam, using quakespasm engine ? I need some guidance with GNU/GPLv2. 
 
Here is an example of someone selling something on Steam using a Quake engine: https://store.steampowered.com/app/793670/The_Wastes/

Here is a mod on Steam for Half-Life: https://store.steampowered.com/app/225840/Sven_Coop/

The engine source code license agreement does not have much to do with any of this. 
 
As long as I give credits to quakespasm creators, and if the mod doesn't include quake materials (models, textures, sounds...) it's ok ? 
 
You should read this: https://partner.steamgames.com/steamdirect

But then also ask the question: are there people who are going to pay for a Quake map/mod in 2018?

Probably not. 
 
It's not about the engine, but the vibe (Thirty Flights of Loving, DUSK...)

Thank you for the link. 
 
In the mapping help thread, you asked about WAD3 (Half Life 1 texture format).

FTE is the engine used in the first link I gave you (to the best of my knowledge) and it supports the Half Life 1 map format, which is like basically Quake map format except for the texture format is different which is why J.A.C.K. can easily do both Quake and Half-Life 1 maps.

I mention that because you referenced something with tons of color, and it is basically impossible in Quake because of the color count restrictions. 
 
I stick with Quakespasm. Quake palette haven't much "blue" colors, right. I haven't yet looked into customizing palette.lmp

Do ya know PixaTool ? 
 
Is there any way to smooth out jerky monster movement while they ride platforms or elevators? 
Suggestion: Autocomplete On Load Game 
I tend to store a ton of savegames with crazy names. I really like how the "map" command has auto-complete on the mapname.

Might it be possible to do a similar autocomplete on the "load" command for the savegame names? 
 
just a brainfart, not terribly important of course 
QSS Frame-rate Fix? 
Are there plans to add Spike's frame-rate/physics fix to QS any time soon?

I'm just curious as I've found that it has fixed my issue with intermittent stuttering on my 144Hz monitor. :) 
Yes 
QS has been on the backburner for me, but when I get back to it that is something I want to add. 
Great Stuff! 
It's kinda surprising that Spike's 'little' breakthrough hasn't caused a bit more excitement. I suppose that's to be expected in such a small community. :) 
 
that and that anyone who actually cared already had a choice of other engines that already had fixes for it. 
 
I implemented compute shader water warp (one pass) in vkQuake. Feel free to steal it, can easily be translated to a fragment shader with a triangle over the texture. 
 
I have troubles running "Eargasm" mod for Quakespasm. It seems the engine doesn't accept the new wav files, at least some of them.
For instance :

guncock.wav is played in the engine, but it seems to be filtered/emulated in 11025hz/8bit.

buzz1.wav isn't played at all (I've checked with the command "snd_show 1", the engine doesn't play the sound at all).

I tried x86 and x64 Quakespasm.
I tried to re-encode the files using different wav format settings.

Latest Quakespasm update : 20th Nov 2017.
Eargasm was released on 16th Dec 2017.
Would it be possible to make an update ?

https://www.moddb.com/mods/quake-eargasm/downloads/quake-eargasm 
>moddb 
says it all. 
 
Suggestion: Add option to disable auto weapon switch on pickup 
Makr0n 
That's the realm of QuakeC, and not something that can be done in engine without the hideousest of hacklets. 
#3395 
Not sure if this helps but all non-music sounds must be mono in Quakespasm. Maybe there are some stereo files in that pack designed for use with other less compatible Quake engines. 
Really? 
That explains why some of my sounds from a few mods fail in game. 
@qmaster 
As far as my tests this is the case with QS. I don't have a PC at work today so I can't confirm. But as I see in the DP docs stereo support is mentioned. "Stereo sound file support (useful for cd tracks)" I'm assuming that this was added, some mods were created with stereo files that break compatibility with Fitz variants. Which mods are messed up? I'd like to pursue this further and if you want I can mix the tracks down to mono for you. 
@qmaster 
I read a bit further in the docs and I am right -- DP added stereo sound playback for mods. 
 
stuff like this is why I made QSS convert stereo to mono on load.

also, change sndspeed to anything other than 11025 and that will disable quakespasm's low-quality filter. 
I'll Have To Check 
To save myself the headache of changing precache file paths in the qc when merging in from mods, I kept the files in the same folders.

This had the drawbacks of not being able to tell which files came from which mods as well has name conflicts.

So...might be a while before I can tidy up and get a comprehensive list to find those again. 
@qmaster 
Don't sweat it. I can peruse the files and check on my end if they are included in keep. 
Quakespasm 0.93.1 Released 
What About A Spike Version, For OS X? 
And what about that old quakespasm.pak that have date 1 march 2016, while the newest version (?) is 27 june 2017? 
PNG Screenshot File Sizes 
It seems like the PNG screenshots that QS writes are larger than they have to be? If I resave them in Paint or Paint.NET the file size is halved with no apparent difference in quality.

Also, I would greatly appreciate an option to disable the "wrote xxx.png" message. 
 
Also, I would greatly appreciate an option to disable the "wrote xxx.png" message.

And why does that bother you? 
 
speaking for myself:

When taking multiple screen shots in a row to perhaps catch a monster in a specific position, for example, you have to wait for that message to go away or to use host_timescale to slow down monsters.

When I have r_drawviewmodel 0 and crosshair 0 for screenshots, itd be nice to have some sort of way to avoid all on screen prompts and such. 
Freezeall 
You can freeze monsters at will. Mark V has the freezeall command and other engines have sv_freezenonclients 1 
 
The large PNG's are intentional to try to limit hitching. They're compressed in the main thread of the engine, and default settings of png libraries I tried caused unacceptably long freezes in the game (like 0.5 seconds - 1 second depending on the resolution.)

If we moved the PNG compression to a background thread, we could use good but slow compression settings - this is just more work to set up.

Agree with a cvar for hiding the "wrote" message. 
#3409 
Sometimes I like to take multiple shots at once, but then the best "takes" have the message printed on them which isn't too good aesthetically. 
 
There is a cvar called "con_notifytime" or similar which controls how long the console text appears at top of screen. Try setting it to zero, maybe even make a alias that sets it to zero before your screenshot and then back to default after? 
 
Thanks, metl. That works. Doesnt show on screen but still shows in the console so one can confirm screenshots have been taken. 
@otp 
What mukor said. I've never seen a screenshot with the message showing. Maybe an older version of QS? 
 
Screenshots And Messages 
One way of handling this is, rather than taking the screenshot immediately, just flag an "scr_screenshot" qboolean to true, then run SCR_UpdateScreen and if scr_screenshot is true selectively suppress certain UI elements. Finally glReadPixels and capture the screen. 
@3417 
 
yes, taking one screenshot wont display the message in the screenshot.

spam the screenshot key and youll get the message in the screenshot.

some people implement real world photography concepts into screenshots and one of those concepts is to take a quick series of images to then pull the best one from.

Think of skateboarding where they use shutter speeds to capture the whole trick then pick one of the pictures to use on the cover. 
 
heres a GIF with this in action:

https://i.imgur.com/Xe2Jd1U.gifv 
Here Is Another One 
 
Uuuhhhh 
are these last few posts just one big troll?

you know the "clear" command is a thing yeah? clears the console?

bind F12 "screenshot;clear"

does what you want I think? 
 
metlslimes suggestion of "con_notifytime" is better than using clear, imo. 
Sorry For The Tone 
reading that back again sounds a bit patronising, but I think it's a valid solution for now.

Maybe the fact it clears the console history doesn't make it a perfect solution. 
Con_notifytime 
lol, I skimmed past that.

Yeah that's even better. 
Lol 
yeah, i changed the binding now too.
no trolling intended. 
And Btw 
that rrp gif is 5 yrs old now, i just remembered making it was such a chore not knowing how to disable the message. 
 
It would be neat if QS allowed for changing the actual layout and functionality of the hud. I think stuff like that would be very cool esp for big mods like AD. 
Huddage 
That requires support for CSQC hud code - I think QSS has this supported, but I haven't had time to check it out yet. 
 
I always get warnings when I try to get QSS. 
You Mean 
the website? It's fine FYI.

http://triptohell.info/moodles/qss/ 
Because Spike Injected A Packet Sniffer!! 
j/k i get the same warnings, idk what windows doesn't like about qss, it is annoying. 
 
 
Yeah, getting a virus warning from that. From the zip as well. Wonder why that is exactly. I reckon it is some funky code which gets picked up by heuristics? 
I Was Wondering 
How hard would it be to get temporal dithering, similar to that of Inside, into a quake engine?

The banding that the fog generates, esp in dark areas is pretty harsh. With good temporal dithering, that is limited to the fogged areas, things would look a lot nicer. Obvs this is not important as it is not a gameplay thing at all, but it would be neat. 
 
Also, thanks Kinn for the hud linkage :) 
Cool Idea 
The main roadblock for Quakespasm is the renderer is not fully converted to shaders; mdl and lightmapped faces are, but water, sprites, sky and anything else are still using fixed-function OpenGL.

Dumping some links on dithering I found:
http://loopit.dk/banding_in_games.pdf
https://www.shadertoy.com/view/MslGR8 
 
Ah, I see.

Here's a good talk about what they did in Inside here.

https://www.youtube.com/watch?v=RdN06E6Xn9E

I also think they gave away the plugin, or whatever they wrote for Unity to do this stuff for free. Not that that would help a lot with QS. 
Isn't Fixed Opengl Faster Though? 
 
 
On any hardware from the past 15 or so years, fixed function OpenGL no longer exists: it's emulated with shaders in the driver.

Maybe "fixed function is faster" was true in the GeForce FX era, but time and technology have both seriously moved on since then. 
Classic Settings And Weapon View 
Aside from being unable to get an accurate weapon view like winquake/mark_v I think the features here are almost perfect.

r_scale, cl_sidespeed etc fix any minor gripes I've had.

Any ideas if this will be fixed outside of scr_ofsz -2 would be good. 
@Fifth 
What about r_viewmodel_quake regarding the weapon position. Setting that to 1 does the job pretty good I think.

I personally really would like the oldschool underwater effect in QS, but yeah, shaders, etc.

That and a way to actually have accurate colormap lighting rendition, because a lot of older levels do look a lot better with the harsher lighting, imo at least. 
@Fifth 
Yep r_viewmodel_quake should do the trick.

btw check out the >60Hz monitor support in QSS if you haven't http://triptohell.info/moodles/qss/ - host_maxfps 0 means unlimited, and it keeps physics running at 72fps.

btw thanks for that video ptoing, when I get back into engine coding I'd like to do more with shaders, and the temporal dithering sounds like a cool project. 
@ericw 
Cool :D Would love to see how that looks if properly implemented. I think it would be very nice :) 
 
ptoing, if Vulkan is an option for you vkQuake solves the banding issues by using 10 bit frame buffer precision. 
Bug Report / Replication 
Please note that this bug occured in my IRC fork of 0.93.0

I just got a: "TexMgr_ReloadImage: Invalid source for player_0"

Error occurred in the middle of a game whilst quickloading and quicksaving a lot, also while recording demos.

This bug caused the save file list to disappear, it also caused loading saves from disk to fail.

video of failure: https://www.twitch.tv/videos/280904822 
@Axel 
Just tried vkQuake. That indeed solves most of the banding issues. Also like that it has classic water. Thanks for this tip :) 
 
scratch that last bug report. It occurred again last night without the "TexMgr_ReloadImage: Invalid source for player_0" message. I'm inclined to believe that the bug I'm facing caused that error rather than being caused by it.

either way, with my shoddy coding it could be anything XD 
 
I have a feature request. The following binding doesn't work properly in Quakespasm while it does work in a few other source ports like Qrack:

alias +movejump "+jump;+moveup;"
alias -movejump "-jump;-moveup;"
bind space +movejump

Jump works just fine but when underwater, the player moves up as if holding the jump key rather than the move up key. It makes swimming up slower than it should be. 
 
In Qrack or Mark V, type pq_moveup 1 and you don't need any of that.

Feature originated in original ProQuake and spread to about every engine both of the Quake and Quakeworld variety including FuhQuake/ezQuake/FTE/FodQuake (in QW engines and JoeQuake the cvar is called "cl_smartjump" instead). 
 
Thanks Baker. It turns out that pq_moveup is 1 by default in Qrack, which would explain why the binding seemed to be working when it was really just the cvar. However, setting it to 1 in Mark V causes weird issues - it will stay locked swimming up when I press jump until I press the moveup key. Even pressing movedown won't cancel swimming up and staying at the surface. 
Water And Music 
Is there any way to get the classic software "wavey" water warp when underwater? I don't remember in which engine, but I seem to remember some of them did this. Maybe I am wrong though.

Another thing is, when reloading a game of the same level it restarts the music track, this is probably correct "vanilla" behavior, but is there a way around this? Maybe some CVAR that controls this behavior so there's an option not to restart music track.

And some maps have no music track info or have it set to "0" which results in no music playing. Maybe introduce a CVAR for random music track start (and/or override the map setting)?

Would be so nice

Then again simpler workaround would be having a Quake OST playlist on shuffle in some media player in the background. 
#3454 - Underwater Warp 
FTE does (r_waterwarp 1).
DirectQ does, if I remember right.
And I think vkQuake does too, but it might just be surfaces.
(don't expect them to have the same scale as the software-rendered engines - higher resolutions result in far too many repeats in the vanilla software renderer) 
Mark V 
has water warp as well. 
Quakespasm 0.93.1 Bugs And Suggestions 
bugs
-
>sometimes the player can get stuck going down/up ramps/angled brushes, touching obtuse (convex) corners. See the images for examples
https://ibb.co/mm18p8
https://ibb.co/jVdop8
>sometimes monsters teleport-in without particle effects

suggestions
-
>increase the limit of the number of particles. Sometimes, particles vanish from launched rockets during very chaotic battles 
 
sometimes monsters teleport-in without particle effects
i guess it's a 'spawn silent'/no gfx mode

increase the limit of the number of particles.
there's a command line option -particles 
 
Getting stuck on those corners is not an engine bug. It's an issue in the map, or the compilers to be precise, and occurs during the QBSP stage.

Particles can be increased manually using the commandline option like спы says. 
Sticky Corners 
Its an engine bug in SV_RecursiveHullCheck.
FTE+DP+ezQuake all have fixed(and more efficient) versions, and porting FTE's over to QSS fixes the issue for me.
However there's a potential risk for things to fall out of one of the thousands of possible maps out there. Its probably not a huge risk, but its still there, hence why I was too paranoid to make that change.
Paranoia is a really bad thing. :( 
 
Hi, I think this is my first post...

In this port, is it possible to make the ogre and the zombies take into account your height when they shoot their projectiles?.. 
Nope 
it's not the engine feature, it's QC thingy

i believe it's called z_aware monsters behavior

AD has that feature, some mods too 
 
Port/Engine - runs mods and sometimes has extra features to help with mods.
QC code - allows monsters, weapons, etc. to work properly. All engines already support angles and vectors so adding z-aware enemies for, e.g., ogres, zombies, flak ogres, etc. has been a thing for a while already. AD does the best job in my opinion because it uses a flag on the monster that allows for mappers to choose whether they want particular enemies to be z-aware or not giving mappers the most power. 
I Stand Corrected 
I was under the assumption that the sticky corners (always only 45° it seems) was some QBSP mess-up. Tbh I didn't even know it occured in the stock maps, too. Only ever came across it in custom maps... maybe because the id maps are mostly boxy. 
Textures Are Broken In 0.93.1 
I've been looking around for a while and can't seem to find any info on this. In quakespasm and quakespasm spiked as of 0.93.1 and r10 respectively I can't start a new game and if I launch a map manually the textures all look corrupted and the the lighting seems messed up as well. this only happens in 0.93.1 and r10 but not in 0.93.0. Any help would be appreciated. 
Textures Are Broken In 0.93.1 Screenshots 
https://imgur.com/a/O1ECIKz

The first two are from 0.93.0

The second two are from spiked r10. Its the same in 0.93.1 
Looks Like That Epsilon Mod 
 
@A_COC0NUT 
Weird, not sure why that would happen with 0.93.1.

Can you type "condump" at the console and then upload the id1/condump.txt that is saved?

Does adding "-noglsl" to the command line fix it? 
@ericw 
adding -noglsl to the command line does fix it but it still refuses to start a new game.

here is the condump without the -noglsl thanks for the quick help

IPv4 UDP Initialized
IPv6 UDP Initialized
WIPX_OpenSocket: Address family not
supported by protocol family
WIPX_Init: Unable to open control
socket, IPX disabled
Exe: 11:02:38 Jun 3 2018
256.0 megabyte heap
Video mode 1920x1080x24 60Hz (24-bit
z-buffer, 0x FSAA) initialized
GL_VENDOR: Intel
GL_RENDERER: Intel(R) HD Graphics 530
GL_VERSION: 4.4.0 - Build
20.19.15.4549
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture
GL_MAX_TEXTURE_UNITS: 8
FOUND: ARB_texture_env_combine
FOUND: ARB_texture_env_add
FOUND: SDL_GL_SetSwapInterval
FOUND: EXT_texture_filter_anisotropic
FOUND: ARB_texture_non_power_of_two
FOUND: GLSL
Intel Display Adapter detected,
enabling gl_clear

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: directsound - Speakers / Headphones +SSE3 (Realtek Audio)
Audio: 16 bit, stereo, 44100 Hz
CDAudio disabled at compile time

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
execing autoexec.cfg
3 demo(s) in loop
]condump 
@ericw I Think I Fixed It 
Since -noglsl fixed it I decided to test out the uncoupled frame rate that spike offers and noticed in the condump that it was using the intel integrated graphics so I went into the nvidia control panel and forced it to use the 1070 I have and now it looks fine and launches a new game gust fine, even without -noglsl. Thanks for the help and I'll provide any additional info I can to fix the intel graphics if you want. 
Thanks For The Info! 
That helps, I'll see if I can reproduce on a system with Intel graphics 
Quakespasm 0.93.1 Bugs And Suggestions 
What is the particle limit currently set at?

For the "teleport-in without particle effects", Are you certain it's a map issue? For example, sometimes when a group of monsters tele-in, only one or two will have the particle effect, while the rest only play the tele sound

bugs
-
When going up, on an elevator, sometimes the player 'sinks into it' then 'pops out', even multiple times in longer rides. Especially if you look up while the elevator is going up 
Delete Video Modes. Zdooms Doing It 
People Seem Reaaaal Happy About That Change 
 
 
Mark V and FTE you can resize the window on the fly.

FTE has had the ability for a decade.

Note: It is NOT easy to implement at all. Especially with the FitzQuake canvas system for several different reasons.

Plus since FitzQuake never had doesn't have screen-resolution independent settings, it would look exceptionally stupidly trying to do it ... unless you code screen-resolution independent settings in. Which is also a metric ton of work.

And you have to be able to handle unusual FOV situations and unusual aspect ratios (with these, you must pad!). Mark V and FTE can do this only because of screen resizing. Yet even more fun ...

(I enjoying taking concepts that Spike does and trying to take the concept a little further than Spike did, mostly because I think it entertains Spike a little. Plus most of Spike's user interface have been refreshing in a world chalked full of the dull ..) 
 
What is the particle limit currently set at?

There shouldn't be a particle limit at all in 2018.

This made sense in 1996 when Quake had to run on an MS-DOS PC with 8mb of RAM. In 2018 I don't see any reason for it.

So if free_particles runs out engines should just Hunk_Alloc another bunch of them and eventually everything will settle down at the highest number that the map needs without any artificially imposed constraints. 
 
Id love to see screenshots take the "message" field (name) of the map to use for naming rather than spasmXXX.png. 
 
errrrr...

a more reasonable idea would be to use the file name of the currently loaded bsp, but at any rate, ditching the spasmXXX.png naming scheme sounds like a good idea to me. 
Speaking Of Names 
longshot but thought i'd just check first...is there an option to suppress the (filename) display when you press Tab whilst playing?

e.g. so player just sees

"The Mouldy Castle of Mould"

instead of

"The Mouldy Castle of Mould (qmouldy014_final_final_rev03)" 
 
Run QS with the -fitz command line. 
Cool 
What other things does -fitz change from 'spasm? 
 
ok i found i think the only place where this is documented:


#3309 posted by mh on 2018/03/23 11:33:29
Going through the source code, the exact and only differences -fitz applies are:

- Don't load the custom quakespasm.pak
- Run the normal demo loop (QS otherwise goes straight to the menus at startup).
- Pop up the Quit prompt (QS otherwise just quits immediately).
- Revert some changes to the solo scoreboard layout.


Would be cool to add this info to the QuakeSpasm documentation. 
Bah 
not sure about this because I still kinda want the first 3 things -fitz turns off, but not the 4th thing :/

first world quake problems.txt 
Hmm 
On second thought, that won't fix it. I saw the linebreak and my mind instantly thought of the difference in the bottom row of the sbar, but that was just func's doing. 
Probably Overthinking This 
but maybe it's time to deprecate -fitz, and just have commands you can throw into a config file to restore old behaviours individually, such as the Quit prompt, the original sbar info etc. 
 
The PAK file is loaded before the configs run (all PAK files are, and if you think about it that makes sense because a PAK file might contain config files). I guess the game-changing code could be tweaked to handle it. 
 
It would be nice to have a separate cvar for the quit prompt just for the classic feel but you can already get the original sbar by setting the sbar alpha to 1 I believe. Isn't there also a startdemo option for enabling the normal demo loop? 
 
What I did years ago was pop up the prompt if you quit from the menus but suppressed it if you quit from the console. That may be default Quake behaviour and I may be misremembering if it was a reversion from a prior change or not.

The intent is that if you quit from the console you almost definitely want to quit, whereas if you quit from the menu it might be a slip of the finger on the keyboard.

Another possibility might be to suppress the quit prompt if you've recently saved, otherwise pop it up. The intent here is that if you've not recently saved you may wish to before quitting.

Of course this all falls down because there will always be someone who will say that they don't want the prompt under any circumstances. 
 
In which case....cvar ftw. 
 
Other ports list the current and default values for cvars when typing them in console. Would it be possible to add this feature to Quakespasm? 
 
I've lost count how many times I accidentally quit QuakeSpasm when trying to quick load. F9 and F10 are just so close together. 
Unbind F10 
 
Poorchop 
you can already get the original sbar by setting the sbar alpha to 1 I believe

I'm talking about not showing the map filename (which is basically dev info) in game, which I don't think has anything to do with your suggestion. 
@3473 
Yeah and everyone gave the dev shit about it in that thread. Maybe not the best example to use when trying to ask for a feature request :P I didn't know about this change myself because I haven't updated my GZDoom in a while and now I am reluctant to :/ 
 
Yeah, I've long been of the opinion that in the Doom/Quake technology generation, there are only 2 resolution options that make sense: fullscreen at your desktop mode or some kind of lower res windowed mode.

To be more specific, I don't see how any other fullscreen mode makes sense. Why on earth would you want to switch to a lower res fullscreen mode that might not even be the correct aspect ratio? In Quake? And excluding a specialist 1996 retro-kick engine?

Somebody give me a reason, convince me, I'm listening and willing, but it better be a bloody good reason. 
@mh 
Edge case maybe - but I record video at 720p fullscreen for my videos. My monitor is 1080 native of course. I use a hardware recorder over HDMI and cannot do 1080p at 60p. At 720 60p the videos look pretty good.

I'm glad I have the option of doing this. 
 
I play at fullscreen 720p in Quake these days. Just like the way it looks. 
 
On CRTs it makes a lot more sense to choose different resolutions. They can actually display them properly unlike LCDs and you might get better frame rate on your video card of the era. 
Speaking Of Resolutions, 
I currently play Quake on my laptop, which native resolution is 1200*800, but the closest match available in the video options is 1280*800. Would it be within the realm of possibilities to add a 1200*800 mode in a future update? 
 
Why on earth would you want to switch to a lower res fullscreen mode

The absolute maximum res I'd play quake on is 720p.

Old games like quake often look better when played at lower resolutions.

The original id levels for example, really don't improve with resolution: after a point, all the higher-res does is look increasingly incongruous with the level art. At 720p, you are already way past that "wall" for old-skool quake maps.

720p is pretty good for AD-style modern maps.

/opinion. 
I Have A Problem... 
No matter what I do, I can't seem to get non-blurry textures in the latest QS (and QSS, for that matter). I do have gl_texturemode set to GL_NEAREST_MIPMAP_LINEAR in my config and I even duplicated the line in an autoexec to be safe, but to no avail. Thoughts? 
Try Disabling Anisotropic Filtering 
gl_texture_anisotropy 1 I think? (can't check easily, on mobile) 
Ah, Yes, 
it worked. My config was actually saved from a previous install, I suppose one that I used with hi-rez textures and linear_mipmap_linear. Anisotropy was set to 16. Thanks Eric! 
I Just Discovered Something Weird... 
When you play a demo and press tab to show the stats, the skill displayed is not the one the demo was recorded with but the one selected (or not) by the watcher. Is this normal behavior? It would make a lot more sense to show the actual skill set for the recording. 
 
Mark V is the only engine that currently can do that it (and has done it for 5 years?). When the skill level changes, it broadcasts a hint. This is stored in the demo because it is part of the network code, so it is displayed during demo playback and cooperative players status bar is updated in real time.

And it is done in a way that non-supporting clients just ignore. (A Spike trick).

Otherwise, it is impossible. A demo does not normally know what skill level is selected. That information is ordinarily lost. 
 
good bug though, the scorebar should probably display no skill at all during demo playback, if it is not known. 
 
one thing i noticed on older engines is that stuffcmd gets sent to clients when playing demos. may have been fixed in newer engines. i supressed it in mine. 
@R00k 
one thing i noticed on older engines is that stuffcmd gets sent to clients when playing demos. may have been fixed in newer engines. i supressed it in mine.

"bf" is a stuffcmd.

You sure want stuffcmds in the demos ;-)

That's just one example, but removing stuffcmd from demos isn't a fix. Yet at the same time, stuffcmd can do toxic things in demos too.

I get what you were wanting to address -- especially a demo where server is sending key binds, but removing stuffcmd from demos isn't how to resolve it. FTE has things sandboxed some. Mark V less than FTE, but views keybinds not done by the user as temporary until disconnect (and that includes demos), and stored in different field that never saves to config. 
Resolution 
Though I must admit i don't typically do this for quake, I play a lot of older games 'pillarboxed' on my widescreen monitor with a 4:3 resolution. Letting users choose things like this is important for edge cases likr that.

Maybe i should try some 4:3 Quake, actually... 
@Baker, Whoops My Bad 
"Fixed: Alias commands are not stuffed to the client when watching demos."

i dug back through my whatsnew.txt It's where i was watching some old demos and noticed i had these weird alias commands; cant remember what demo (runequake?) but kinda annoying. Stuffcmd isnt specifically blocked.
``
void Cmd_Alias_f (void)
{
cmdalias_t *a;
char cmd[1024];
int i, c;
char *s,*n;

if (cls.demoplayback)//R00k dont stuff alias commands when watching a demo.
return;
``
trivial. 
 
aye, aliases in demos is annoying.
as is the engine silently ignoring the alias commands that you're typing simply because there's a demoloop playing in the background...
ignoring aliases completely means that mods that use them to slightly reduce network traffic cause error spam.

urgh, now I have to resist the urge to make a 'trap' demo that uses aliases to prevent any attempt to stop playing that demo. 
 
Hmmm, I see your point; 'silently' confuses the end user. For example, loading up the game, demo is playing, type exec frikbot.cfg..
"Where's my frikbot aliases?!"... 
Mod Sounds Not Playing? 
Wanted to make a coop server for ad_sepulcher, got into the same issue as ericw up there: lots of "packet overflow", some sounds weren't playing, etc..
Are there plans on making the unreliable message limit something changeable on the server configuration or something? Elsewise, what could I use to host a coop server reliably? I've never hosted one before, what do you guys use? 
@newb 
Netquake is just not reliable enough for mods like AD. You should turn particles and shell ejection off (read the AD readme for how to do this). You should try playing coop with QuakeSpasm-Spiked, which has improved networking.

Ideally the Quake community should have rallied around the QuakeWorld protocol when the source was released, and backported compatability with the netquake progs. Alas we have a shedload of NQ engines which are pretty useless at multiplayer. 
 
Yeah, if you want to play AD coop then you really ought to upgrade from QS to QSS.
FTE has all the same networking improvements but I accept that its also much easier to configure wrongly...
DP also has many of the same improvements, but its insistence on float coords combined with its inability to split baselines means that its unable to run ad_sepulcher. Configuring it to use the bjp3 protocol would theoretically work if its support for bjp3 was not buggy.

The vanilla QuakeWorld protocol was quite poo and quite incompatible with NQ, yes it would have been nice to have a single protocol that everything else was compatible with, but really that's just wishful thinking. It would have broken more than it would have solved.
Do note that the FTE stuff I ported over to QSS is not like vanilla quakeworld at all - its more like dpp7. It won't cope with packetloss quite so well, but it will cope MUCH better with massive entity counts, and without requiring serverside translation of QC's writebytes (this is one of the more annoying things I had to add to FTE to get it to run NQ mods properly, and I'm very glad other engines don't need anything equivalent, and no way was I going to add that mess to QSS too). 
Misaligned Lumps? 
@spike @c0burn:
Thanks for the pointers. I've tried using QSS for the server but the following happens: https://pastebin.com/kc54XVpM. Apparently even with the dedicated flag it still tries to capture mouse? The SDL warning message is repeated constantly, every line omitted is that exact message. Trying to enter ad_sepulcher crashes the clients (both QS and QSS) at the tune of https://pastebin.com/dfK1c4s9, both of the clients outputting this, and they get stuck at the "loading" screen, so I have to kill them. dpkg -l *libsdl* outputs this: https://pastebin.com/4vnHjrNz, so I gather I have installed SDL2 correctly (?). Other maps also output warnings about misaligned lumps but they are playable.
I've found this problem on Ubuntu, if I'm not misremembering 16.04 (not "my" PC), and on a Debian 9, both fairly vanilla installations. The misaligned lumps problem seems separate from the SDL warning (apparently it's just the program trying to grab mouse and keyboard input, but since it's running in -dedicated mode it's pointless), and the former is what I gather is causing these problems, rendering the map unplayable.
I've also tried running the server from QSS (not dedicated, in-game), but a friend couldn't connect either; same misaligned lumps message was seen on his end. This was all using the version downloadable from http://fte.triptohell.info/moodles/qss/, didn't try compiling the latest in the repo nor patching QS with the change @ericw posted. Will probably try tomorrow, if I have the time (but I gather that @ericw's change is undesirable in some way, if I didn't misinterpret @spike's comment, but I can't say I internalized quake's protocol). 
 
ignore the misaligned lumps. that doesn't affect x86 at all (but is fatal for other cpus).

Sorry about the grabs spam. It seems the linux version still uses SDL1 for some reason, while the win32+SDL2 build doesn't show that there's anything stupid happening. Should just be a problem due to the spam, but yuck, sorry.

I've no idea why its locking up for you.
Obviously its not meant to do that... 
@spike 
In the end we ended up playing with ericw's patch for vanilla QS. No issues there.
All in all, that patch was a gateway drug! :P The code is easier to read than I first thought it'd be, so now I'm adding 6DOF. If I'm not mistaken this is something that can't be implemented at a qc level, right? I have but a passing familiarity with quakec, so maybe this could be less client-dependent and I'm not realizing it.
Either way, having much fun with this, keep up the good work. 
 
Any hope for incorporating some of the additions to the Arcane version of Quakespasm/QSS? Like the mod menu. 
 
So is pampa the anon mystery guy that wrote the 6DOF version of FitzQuake several years ago and then Spike added the modification to FTE? 
@Baker 
Huh, seems someone stole my idea and went back in time, right? :P
I wasn't aware such a thing had been done before, but will def. check up on it. 
 
https://www.youtube.com/watch?v=w8aUI9flEvc

https://www.youtube.com/watch?v=djb-KVxcih4

The source code was on the dead Google repo, but as I understand it there is often some way to find it using the URL and some ingenuity.

Dead source link: https://sites.google.com/site/quakeconfig/6dof-quake 
 
Trippy, but man that guy plays slowly. 
Quakespasm Crashing On New Laptop ;~; 
So I just switched my quake dev folder over to my new laptop and it has apparently decided it doesn't want to run :( I am using v0.93 on Windows 10 Home 64 bit btw. Here is some info about the error I got from event viewer


Faulting application name: quakespasm.exe, version: 0.0.0.0, time stamp: 0x5a1299a0
Faulting module name: ig9icd64.dll, version: 23.20.16.4973, time stamp: 0x5a96b1e5
Exception code: 0xc0000005
Fault offset: 0x0000000000196be5
Faulting process id: 0x2c2c

Neither the normal or SDL version work. Is there a newer version I can try? This will be somewhat of a hindrance when it comes to testing my maps in the future if I can't run them in the first place... 
And here is a stdout console dump from the SDL version, there doesn't seem to be anything wrong with it but maybe you can find something?

Found SDL version 1.2.15
Detected 2 CPUs.
Quake 1.09 (c) id Software
GLQuake 1.00 (c) id Software
FitzQuake 0.85 (c) John Fitzgibbons
FitzQuake SDL port (c) SleepwalkR, Baker
QuakeSpasm 0.93.0 (c) Ozkan Sezer, Eric Wasylishen & others
Host_Init
Playing registered version.
Console initialized.
UDP Initialized
WIPX_OpenSocket: Address family not supported by protocol family
WIPX_Init: Unable to open control socket, IPX disabled
Server using protocol 666 (FitzQuake)
Exe: 11:56:35 Nov 20 2017
256.0 megabyte heap
Video mode 640x480x32 60Hz (24-bit z-buffer, 0x FSAA) initialized
GL_VENDOR: Intel
GL_RENDERER: Intel(R) UHD Graphics 600
GL_VERSION: 4.5.0 - Build 23.20.16.4973
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture
GL_MAX_TEXTURE_UNITS: 8
FOUND: ARB_texture_env_combine
FOUND: ARB_texture_env_add
FOUND: SDL_GL_SWAP_CONTROL
FOUND: EXT_texture_filter_anisotropic
FOUND: ARB_texture_non_power_of_two
FOUND: GLSL
Intel Display Adapter detected, enabling gl_clear

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: dsound, 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz
SDL detected 1 CD-ROM drive
CDAudio initialized (SDL, using E:\)
CDAudio_Init: No CD in drive

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
couldn't exec autoexec.cfg
3 demo(s) in loop

FITZQUAKE 0.85 SERVER (51103 CRC)


Introduction
Using protocol 666
Couldn't find a cdrip for track 4
jl entered the game 
 
This came up in google when I searched for that dll: https://communities.intel.com/thread/125368

Try updating your intel graphics driver.

Also 0.93.0 is not the latest version of QS (it still shouldn't crash, but might as well update to 0.93.1) 
Hm, I had an Intel graphics driver update the other day and installed it, or at least it supposedly installed... maybe it is a crappy HP custom one, I'll try to find the latest generic version for the hd 600 and try again 
Still Didn't Work :( 
I just ran the update for the latest intel hd 600 update on August 9 (https://downloadcenter.intel.com/download/27894/Intel-Graphics-Driver-for-Windows-10?product=126787) and it still won't run :( I mean I know my laptop is pretty low spec but don't tell me it won't run a game from over 20 years ago... GZDoom will run but QS won't, great. I guess I'll have to use FTE or something for the time being, unless QSS is still being updated? 
Update 
So I might have discovered part of the problem on accident. I was trying to compile what I had done on my underwater jam map (which I wasn't able to complete by the deadline unfortunately) and I somehow managed to give the wrong wad path so qbsp wasn't able to texture my map and to my surprise, my untextured map loaded :O BUT when I tried to go to another map it crashed. So it is something to do with the textures, I'm not sure if the gou doesn't have enough vram (that would be my first guess though honestly I would be surprised if that's the case given how old quake is and the low res textures typically involved) or the way they are rendered or what, but it definitely has something to do with that 
@therektafire 
unless QSS is still being updated?
Yes it is. Latest version (r10) is following the changes made to QS 0.93.1. But if your laptop is too old your framerate will be loooooow: I installed both engines on a Dell Inspiron 9400 (Core2Duo T5500, 2Gb RAM, ATI Mobility Radeon X1400) and QSS is pretty much a slideshow while QS runs fine. 
That's Annoying. 
Couple more debugging ideas:
- could you check the QS console output again to confirm the GL_VERSION, just want to confirm it's the 24.20 driver that is still crashing.
- Launch with -noglsl to switch back to the GL1 rendering code. By default it will use OpenGL 2 if available.

QSS will probably behave the same because the renderer is mostly identical to Quakespasm. ( @Mugwump if QSS is slower it's probably because a mod like AD is using the hd particles. ) 
@ericw 
Yes, the framerate drop is quite drastic in AD, but I also noticed a lesser difference in non-AD maps. 
It Does Work With -noglsl 
But now the mouse pops up on the screen after a couple of seconds in fullscreen mode which is *really* annoying because it causes the window to minimize :/ I'll try QSS to see if that helps but I'm not holding out any hopes.

Also the laptop isn't old per se but rather new and cheap so it has some less than stellar specs, but the gpu does have opengl 4.5, DX12, and vulkan 1.0 support so I don't get why QS would be crashing with GLSL enabled since it should be supported? Also Mark V works without any console fiddling if that helps 
:( 
Spiked gave same result, only works with -noglsl but in -noglsl the mouse stays above the window and clicks out of it. I wish I could tell you what exactly is going wrong with the GLSL rendering that is causing the crash but I'm not sure how to get that information particularly. 
FTE And Mark V Work Though 
FTE and Mark V both work with OpenGL though, trying to use vulkan in FTE caused it to have a freaking seizure which is more or less what I expected would happen if I tried to run a game with vulkan on here LOL, it just isn't good enough for that even if it has it. I also apparently get over 400FPS in FTE with the vanilla/"spasm" graphics settings which is always good. So maybe I'll switch to FTE for the time being until QS gets its crap together with the GL renderer. 
 
until QS gets its crap together with the GL renderer

You might consider that ericw does what he does for free and that engine development is hard and involves many combinations of operating systems, graphics cards and equipment.

@ericw - I have Mark V log the command line in the log. That way if someone posts the log, you don't have to ask what command line they are using. 
 
well, ok, what I meant by that was "until ericw can find the problem and it gets fixed". Like I said if I could figure out what the problem was exactly I would give more helpful info but he is probably in a much better position to do that than I am since he is the one developing it. I guess the best advice I could give is buy a cheap crappy $300 or under laptop like the one I have with intel HD 600 or similar GPU and profile it and see what part of the renderer is causing it to get angry, the one I have in particular is this one

https://support.hp.com/us-en/document/c05987723 
#3537 
Translation:

"I'm having an issue running a 20+ year old game on my laptop! Go spend hundreds of dollars tracking down an esoteric issue I can solve by using other software."

This makes zero sense to me. It's good to ask for help, but to suggest that Eric spend hundreds of dollars to help you out is pretty wacky! 
 
As engine developer, if my engine didn't run on a popular computer running a popular operating system using a popular graphics card I'd be irritated. But "we cannot safely draw that conclusion yet".

All that is seen so far is someone appearing to have an issue exclusive in the universe to their computer (but it might not be -- re:poorchop + Mark V).

Whether or not the suggestions by individual having a problem are feasible, there is still a problem.

And so goes engine coding. Which is why engine coding is hard. Engine coding is being the frontline for unwanted situations/knowledge. And you are always better to know about them! 
Laptops 
I have a laptop with Intel graphics. Actually I have 2. They both run Mark V and QS fine. The only issue is that the 4k laptop is a bit choppy. 
@dumptruck 
I see, what model of intel hd is it? And is it "HD" or "UHD", mine is a "UHD" 600. Also maybe you should try lowering the resolution of the game to increase the FPS, playing quake in 4K doesn't really make much sense especially on a weak gpu, my max res for quake would be 1080p personally 
 
I've one with an Intel UHD 620.

It easily hits over 1000 fps in ID1 timedemos.

It plays Doom 3 at over 60 fps.

It runs QS and other engines flawlessly.

So I guess you need to give more info about what you're doing to cause QS to have a meltdown. You mentioned something about a map you're making - is your problem confined to that map only? Can you run other content? Can you share the map (or a minimal example that reproduces the problem)? Single-stepping the texture loader in a debugger seems a good place to start, based on other info you've provided. This is going to be something like a 0-sized texture causing a code path to trip over itself. 
 
It isn't occurring with the map technically. Basically what happened with my map is that I accidentally compiled it without textures and it loaded up fine. But when I compile it with the textures it crashes. BUT it doesn't just crash on MY map, it crashes on EVERY one, even vanilla id1. It also won't load the demos on the start screen either. But FTE and Mark V both work fine with all the maps I have including id1 (in opengl mode anyway, FTE doesn't have such a fun time with Vulkan let's just say that :D). So it's a Quakespasm specific problem that is effecting every map. What debugger would you recommend I use to check it? The only debugger-Like program I've ever tried to use on games is Cheat Engine and it wasn't for actually debugging things hehe. 
#3543 
I'm suggesting that the Quakespasm developers could debug it, not you, but from the extra info you've provided it does seem a larger problem with your setup for sure - crashing on vanilla ID1 maps is not a good sign. 
 
Hm I'm not sure what it could be. My drivers are up to date and it only happens in quakespasm in particular. It can handle other ports and even other games just fine, I've just started playing Eve Online recently and it is at least playable albeit with almost everything on low settings. So not sure what is going on there since everything else works as expected. What do you think it could be? 
#3545 
OpenGL vs Direct3D - most games don't use OpenGL.

A suggestion: try a totally fresh, vanilla Quake installation, with unmodified PAK0.PAK and PAK1.PAK, and nothing else.

I'm not suggesting this as a solution, it's a troubleshooting step - just trying to carve up the problem and see where the cause might be. 
 
I have a sneaky suspicion that you've managed to get a bad opengl32.dll into your Quake folder is what I'm saying. 
@therektafire 
A suggestion: try a totally fresh, vanilla Quake installation, with unmodified PAK0.PAK and PAK1.PAK, and nothing else.
This would be helpful, and if you don't mind, please post the console log again as I'd like to confirm what driver version the engine is picking up (iirc I've seen intel driver installs seem to work and then not actually end up being used.)

We did have report of corrupted textures in July with:
GL_RENDERER: Intel(R) HD Graphics 530
GL_VERSION: 4.4.0 - Build 20.19.15.4549

http://celephais.net/board/view_thread.php?id=60452&start=3466&end=3471

Unfortunately the only Intel graphics I have handy is HD4400 which runs a a different driver, and the latest drivers work fine for ne, 
Console Log 
LOG started on: 08/14/2018 15:25:00
Playing registered version.
Console initialized.
UDP Initialized
WIPX_OpenSocket: Address family not supported by protocol family
WIPX_Init: Unable to open control socket, IPX disabled
Exe: 16:04:16 Jun 6 2018
256.0 megabyte heap
Video mode 640x480x24 60Hz (24-bit z-buffer, 0x FSAA) initialized
GL_VENDOR: Intel
GL_RENDERER: Intel(R) UHD Graphics 600
GL_VERSION: 4.5.0 - Build 24.20.100.6229
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture
GL_MAX_TEXTURE_UNITS: 8
FOUND: ARB_texture_env_combine
FOUND: ARB_texture_env_add
FOUND: SDL_GL_SetSwapInterval
FOUND: EXT_texture_filter_anisotropic
FOUND: ARB_texture_non_power_of_two
FOUND: GLSL
Intel Display Adapter detected, enabling gl_clear

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: directsound - Speaker/Headphone (Realtek High Definition Audio), 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz
CDAudio disabled at compile time

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
couldn't exec autoexec.cfg
3 demo(s) in loop

FITZQUAKE 0.85 SERVER (51103 CRC)



Introduction
Using protocol 666
Couldn't find a cdrip for track 4
=====================================================

The same thing happens with a fresh quakespasm install and a fresh copy of the paks, it launches but the demos don't load and it crashes when I try to start a new game. And it would indeed appear the 24.20.100.6229 drivers are being used. So it isn't that unless there is something wrong with the drivers themselves in which case I don't think I can do anything about that... 
Putting -noglsl Works Though 
Running it with -noglsl does work though, so I guess all this bickering is for nothing :D But when I do -noglsl the mouse is stuck on top of the window which causes the game to lose focus and minimize itself whenever I click, this behavior was the exact same on 0.93 as it is on 0.93.1 and I actually pointed it out yesterday as well. But, why would I need to put -noglsl when the card has GLSL and other engines accept it? Ugh. 
Thanks For The Confirmation 
It does sound like a driver bug to me.
If anyone else has an Intel laptop that is compatible with this latest driver, it would be interesting to hear if you can reproduce the crash:
https://downloadcenter.intel.com/download/27894/Intel-Graphics-Driver-for-Windows-10?product=80939
(there's a long list of supported model numbers there, includes HD Graphics 500 and 600)

But when I do -noglsl the mouse is stuck on top of the window which causes the game to lose focus and minimize itself whenever I click, this behavior was the exact same on 0.93 as it is on 0.93.1 and I actually pointed it out yesterday as well.
I have no idea how switching the rendering code path could trigger this. :(

btw another engine worth trying is vkQuake:
https://github.com/Novum/vkQuake/releases 
 
The mouse going over the window instead pf being attached to it only happens in fullscreen, I'm wondering if it's part of the same driver issue. And it's also only a quakespasm problem as far as I can tell... 
 
Intel UHD 620, driver version 24.20.100.6229 (latest), Quakespasm 0.93.1, clean configs, no command-line args, Windows 10 1803 fully-patched.

Tested various windowed modes, as well as fullscreen at both 1920x1080 and 640x480; runs without crashing.

NOTE: the mouse pointer thing does not happen at 1920x1080 but does happen at 640x480. This is caused by Windows, not Quakespasm - specifically the "Optimal resolution notification" warning. To stop it, you need to set your Windows resolution to something lower than native, then click on the warning when you receive it, where you will get an option to disable it. This option is probably also buried somewhere in the Settings app.

Alternatively play at your native resolution - I seem to recall that Quakespasm has a video-scaling feature to emulate lower resolutions but I can't remember the cvars to use.

For completeness, here's the stdout:

Command line: C:\Games\QS\quakespasm-sdl12.exe
Found SDL version 1.2.15
Detected 8 CPUs.
Quake 1.09 (c) id Software
GLQuake 1.00 (c) id Software
FitzQuake 0.85 (c) John Fitzgibbons
FitzQuake SDL port (c) SleepwalkR, Baker
QuakeSpasm 0.93.1 (c) Ozkan Sezer, Eric Wasylishen & others
Host_Init
Playing registered version.
Console initialized.
UDP Initialized
WIPX_OpenSocket: Address family not supported by protocol family
WIPX_Init: Unable to open control socket, IPX disabled
Server using protocol 666 (FitzQuake)
Exe: 16:01:39 Jun 6 2018
256.0 megabyte heap
Video mode 640x480x32 60Hz (24-bit z-buffer, 0x FSAA) initialized
GL_VENDOR: Intel
GL_RENDERER: Intel(R) UHD Graphics 620
GL_VERSION: 4.5.0 - Build 24.20.100.6229
FOUND: ARB_vertex_buffer_object
FOUND: ARB_multitexture
GL_MAX_TEXTURE_UNITS: 8
FOUND: ARB_texture_env_combine
FOUND: ARB_texture_env_add
FOUND: SDL_GL_SWAP_CONTROL
FOUND: EXT_texture_filter_anisotropic
FOUND: ARB_texture_non_power_of_two
FOUND: GLSL
Intel Display Adapter detected, enabling gl_clear

Sound Initialization
SDL audio spec : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: dsound, 65536 bytes buffer
Audio: 16 bit, stereo, 44100 Hz
SDL detected 0 CD-ROM drives

========= Quake Initialized =========

execing quake.rc
execing default.cfg
execing config.cfg
execing autoexec.cfg
3 demo(s) in loop
]playdemo demo1
Playing demo from demo1.dem.



the Necropolis
Using protocol 15
Couldn't find a cdrip for track 2
You got the shells
You got the Grenade Launcher
You receive 25 health
You get 2 rockets
You got the rockets
You got the nailgun
You got the nails
You got the nails
You receive 15 health
You receive 15 health
You got the rockets
You get 2 rockets
You got the nails
You got the nails
You receive 25 health

You need the gold key

You got the gold key
Shutting down SDL sound 
 
That was me, by the way. 
@mh 
I see, well I wanted to play on a lower resolution than native for performance reasons (never really tried playing at native res but I just wanted to be safe) though I suspect the CPU would be more of a hindrance to fps than the GPU, it's only a dual core @ 2.6ghz :( Also I'll disable the "optimal resolution" bs ASAP, I knew that it popped up every time since I would see it in the notifications after I exited but I didn't know it was causing the focus pro len :o. 
 
Yeah, it seems to be trying to steal the focus and having a good old fight with Quakespasm over it.

I'm sure that there's probably a more general solution to this.

Regarding performance, Quakespasm should be considerably less CPU-limited than other Quake engines (and certainly less so than the original FitzQuake base, which was very CPU-limited and contained a high number of pipeline stalls per frame), but for Quake content you should get decent performance at almost any resolution. 
Thanks Mh 
Good to have confirmation that the latest intel driver doesn't crash for you.
Still at a loss as to why the QS OpenGL 2.0 renderer isn't working for therektafire. Could be we're doing something unusual that triggers a driver bug with his specific hardware (UHD 600 vs your UHD 620).

also thanks for the reminder about the "optimal resolution" thing, now that you mention it, I remember seeing that as well. 
Pardon My Noobness But... 
could it be possible that another program like TB messed with something? I know TB's min. OpenGL requirement is 2.1... 
@mugwump 
Well TB runs surprisingly smoothly on it all things considered, at least with the smaller maps I've given it so far. There aren't any errors with it or Wally or any other quake related app tat I've tried so far. Also the hd 600 supports opengl 4.5 so I don't see what the requirement of opengl 2.1 would have to do with anything unless you are implying that it changed some driver setting? Does/can it do that? If so that's kind of problematic since it shouldn't exactly be doing that to begin with... 
I Was Replying To Ericw 
<Q>Still at a loss as to why the QS OpenGL 2.0 renderer isn't working for therektafire. 
Oops, Borked The Quote Tag... 
 
Antialiasing 
Antialiasing is not working for me.I try FSAA command and its not working.What am i doing wrong? 
2 posts not shown on this page because they were spam
First | Previous | Next | Last
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.