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.
First | Previous | Next | Last
IIRC the only reason for -quoth is to allow it to support the Hipnotic HUD, together with Quoth content, together with an (optional) additional gamedir for a mod which requires Quoth.

-quoth is just a hack, in other words. But it's a hack that the community has come to accept and expect.

This is clearly a "survival of the unfittest" situation. A simple-to-implement, adequately robust, but not necessarily full featured solution will always win over an elegant, extensible, more correct solution but that is significantly more difficult to implement. 
@spike Re:EF_STARDUST 
EF_STARDUST in the DarkPlaces source looks nearly identical to EF_FLAME, except that it uses pt_static instead of pt_flame.

Is EF_STARDUST needed for a model to emit, say, sparks?

Is or EF_STARDUST redundant because the same effect can already be achieved through other means? Hence its non-inclusion in "Spikespasm".

/I'm looking at smc and thinking about extracting an effect or of it for a tutorial later in the week or on the weekend. 
its either '-quoth' in an engine that hardcoded a specific mod, or '-hipnotic -game quoth' for vanilla, but yeah iiuc its just for the hud.
DP didn't add 'double-gamedirs', it has multiple gamedirs, because limits suck. As does FTE. of course, when you have more than one, order matters. I handled 'game foo -quoth' by parsing the list twice and then re-ordering. And if you want to mess everything up for everyone, all you have to do is to put a space in the subdirectory name! yay!

EF_STARDUST is what exactly?.. Its a specific effect that you wouldn't have a clue what it really looks like until you've actually used it so that you can see. I don't see the point of it because its a specific effect. Its just not significant compared to the more generic stuff like r_effect or traileffectnum.
Iiuc, it predates custom effects and stuff, dating back to the time of hardcoded effects. Same with all the extra TE_ effects.
Yeah, it might be simple enough to rename it to 'ef_customeffect1' or something lame, but that's just lame.
So yeah, you might want it for compatibility, but moving beyond that its probably not very useful, so I didn't see the point of implementing it. 
If I remember correctly, it's an effect used on slipgates that displays star-like sparkles floating upwards. I don't think it would do for, say, electric sparks coming from a broken panel. 
That's what I thought! (It's obsolete, artifact from more primitive days). Thanks!

@mugwump - the particle system lets you set the origin and the velocity and other things. the originoffset could be instead of above it could be to the side and instead of sparkles, sparks. It's just an emitter. 
Myst, Sparkle, Smoke, Decal, Trail, Model Light 
Simple effect videos

1) Sparkle:
2) Smoke:
3) Flame:
4) Myst:
5) Rocket Trail:
6) Decal:
7) Model Light:

To be followed up maybe this weekend by tutorials. 
Classic Weapon Offset? 
Hey there,
I recently dug around a bit trying to find out how to get some popular source ports including Quakespasm to look as close to the original DOS Quake as possible. Changing texturemode, particles, lerpmove, lerpmodels, etc. one can get Quakespasm to look nearly identical, but the weapon offset is still problematic, it's just too low. Using scr_ofsx gets you somewhat closer, but it's not ideal. I've seen that Tarvis/bangstk made some effort here earlier this year to change that with an unofficial fork, but I guess that wouldn't work for the most recent release. Or can that somehow still be included without official support?

Otherwise, is there any way to change the weapon offset to really get the original look, or isn't that possible right now? And if it isn't, can anybody give me some insight into why exactly that change is there in the first place?
Thanks :) 
There's a comment in the source explaining this removal:

//johnfitz -- removed all gun position fudging code (was used to keep gun from getting covered by sbar)

I believe that Baker's FitzQuake Mark V fork restores that code, but QuakeSpasm doesn't. 
Original gun is available as an option in mark v. Default is still the FitzQuake norm that Quakespasm uses but yeah you can go menu ... preferences ... set gun position to classic. 
I'd like a cvar for that.. we had a patch contributed that enables the classic gun position:

It's on my todo list to review and compare to how MarkV implements it. 
You might as well take "fov doesn't affect gun" option too when the time comes. 
Ironically, if I recall, Mark V doesn't have gun fudging code. Original Quake did fudge the gun position. Classic weapon in Mark V calculates the right gun position for the gun to appear on top of the status bar based on FOV and HUD settings and screen aspect ratio. This calculation also has to take into consideration FOVy adjustments for screen aspect ratios.

When you think about the gun fudging code in original Quake, it sounds newbiesauce easy.

But just see what happens when you change the resolution to something with a weird aspect ratio or set an irregularly sized window resolution of 600 x 600 or 400 x 600.

The original weapon position fudging code breaks down terribly in situations deviating far from a 4 x 3 aspect ratio or with enlarging the HUD (hudscale).

(If I recall correctly, it's been a while since I worked on that.) 
Speaking about FOV, I think this option should have a threshold of sorts. Right now it always draws the gun the same, even with a very narrow FOV, which makes zooming very weird. Maybe it should take a value (in degrees) beyond which the gun stops changing. 
Hehe, I noticed that once but thought that I was only the person that actually created such a bind.

You could actually modify your zoom bind.
+zoom "fov 70; r_viewmodel_fov 70; wait; fov 50; r_viewmodel_fov 50"
-zoom "fov 50; r_viewmodel_fov 50; wait; fov_70; r_viewmodel_fov 70; wait; fov 90; r_viewmodel_fov 90" 
Good to know, thanks. 
Question For Dummies 
will Spike's code be integrated into the next Quakespasm release or it is intended to be a stand-alone piece of software? 
Thanks for the explanation about the weapon offset. I hope the patch or another kind of fix finds its way into a release eventually :)

Regarding Mark V, I noticed that it's better there, although unfortunately the beta release of the mark_v.exe crashes on my computer, unlike the latest stable release. However, I've used the WinQuake port of Mark V for playing through Quake the first time only recently and it worked flawlessly :) Now onto Arcane Dimension with Quakespasm. For the time being I'll stick to scr_ofsx -2.8. 
For The Few Mac Users Out There 
Mousewheel weapon switching is broken on macOS 10.12 due to a SDL2 bug:

The SDL1.2 version seems to be unaffected.

Icaro: I'm not sure.. For the time being, it's a fork / branch. 
Hey Guys 
If I were to modify gl_model.c to allow for more animated textures (beyond 10 per surface) would I also need to modify the compilers to save the extra textures (beyond +9) to the bsp file? 
You can add the textures the manual way by including a brush in the void with the desired textures. That's how we used to do it in the old days before compiler did it for you. 
Is this a change that the guys would be willing to see incorporated into the engine? I don't want to fragment the engine ecosystem for such a small change.

Especially with spikes modifications being released too. 
OGG Music Has Stopped Working In Quakespasm 
My music has spontaneously stopped working in quakespasm. I have the tracks as ../ID1/music/trackXX.ogg, which used to work fine. But now I get no music and a message in the console saying

Findfile: can't find music/trackXX.mp3
Findfile: can't find music/trackXX.flac
Findfile: can't find music/trackXX.wav

Any ideas what might have caused this? 
animated textures ... beyond 10 per surface

It is 20 per surface already according to this ...

Which was written by metlslime, hehe. 
Pretty sure that 20 is regular + alternate anims. 
0-9 for regular animations. a-j for alternative animations. the limit is due to the base animations using digits, although the alternative anims could be bumped to 26 chars.
more than 10 (or 26 for alt) requires getting people to agree with a single consistent naming system within the 16-char name limit, and that all gets far too political... 
What I was thinking was expanding the frames by a factor of 10 for the numbers and leaving the alternate animations alone. +00 to +99 is what I was thinking.

If nobody cares for it that's cool too, I won't make this change unless the QS authors are cool with it. Like I said engine ecosystem and all. 
Slimealpha Worldspawn Key Does Not Work In Quakespasm 
slimealpha worldspawn key does not work in Quakespasm

The value seems to never be honored. Unless I'm doing something

Put in worldspawn:

"slimealpha" "1" // Nope, uses r_wateralpha

All the other ones work like "telealpha" and "lavaalpha". 
It's working for me.. tried "slimealpha" "1", as well as "slimealpha" "0.1" in worldspawm.

Does the r_slimealpha cvar work for you? The interaction between the cvar and the worldspawn key is a bit confusing.. when the map loads, if the worldspawn key is set, that gets used until the next time you change the cvar. So the cvars behave like the fog command.

Also if the cvar or worldpsawn key is 0 (the default), that is interpreted as "use r_wateralpha" 
Here is an example of misbehaving, although apparently in different way.

1. Empty Quake folder, just pak0.pak + pak1.pak
2. This start.ent in quake/id1/maps

Mainly featuring ...

"lavaalpha" "0.5"
"telealpha" "0.5"
"slimealpha" "1"
"wateralpha" "0.7"

3. Result: No water transparency but the other 3 settings are used. 
I *think* that might just be un-water-vised transparent water? QS defaults to gl_clear 1 so you get grey tinted instead of a HOM. 
No -- It's Slime Alpha 
I type r_novis 1 in console. Now water is transparent like it should be.

And although I specified slimealpha 1 in the worldspawn, it is not being used.

Slime is transparent but I said 1! (which is not transparent)

Slime is under medium bridge. I typed "fov 10" to magnify.

Test was that start.ent, no config (I deleted every time to make sure it couldn't be config) and just the pak0/pak1. 
Are You Sure There's Slime In Start.bsp? 
under the "normal" bridge? It's not burning if I noclip into it.. 
Major fail on my part.

I suck. Haha. Sorry. 
This one isn't imaginary. :)

I wanted to check out Spike's skyrain in Quakespasm Spiked on E1M1. To make sure it was using the external ent file I changed the name in worldspawn. Never worked.

Tried other engines with external ent support = worked.

The Z fighting fix in quakespasm.pak apparently takes priority over an entity file for those maps like id1\maps\e1m1.ent

Just wanted to point this out. 
@Shamblernaut sorry for not responding earlier. I hate always to be grumpy; but I'm not keen on extending the number of animation frames just for engine fragmentation reasons.

Baker - thanks! Not sure what to do at the moment but that is an unfortunate behaviour. 
Load the quakespasm pak as third ticket in the priority for the id1 folder. 
Priority (for id1 folder):
1) Pak files (pak0.pak, pak1.pak, ..)
2) Free standing files
3) quakespasm.pak

/Mark V just patches the entity string if it passes a "is it right map?" check, but I understand why you guys chose a pak file. 
the path command shows all. first displayed has highest priority. 
Priority (for id1 folder):
1) Pak files (pak0.pak, pak1.pak, ..)
2) Free standing files
3) quakespasm.pak

For standalone ent files on the OS filesystem to take priority,
that order you mentioned needs changing to 3, 1, 2 (using your
numbers.) That may (or may not) have unwanted side effects, and/or
break things, which I don't know at the moment. 
changing to 3, 1, 2 (using your numbers.)

Well, that should be 3,2,1 to be correct. But I _think_ that would mess things. 
continuing from the jam thread..

what's the history behind qs
The QS changelog is the best summary of what was changed versus Fitzquake. Likewise, the Fitzquake changelog summarizes what metl changed versus GLQuake

Also worth mentioning, QS started as a continuation of SleepwalkR's port of fitzquake to SDL (for mac/linux support):
It also shares some code and maintainers with uhexen2 
Thanks for the links, good stuff. Not quite what I meant with my question, though; I'm more in learning about the circumstances behind QS's adoption by the community as a "Standard" engine. Was it just momentum carried forwards from the popularity of fitzquake, or something like that? Mostly just asking because I wasn't around in the community at the time, so it's all a bit of a mystery to me as to how we got to where we are today. 
is there plans to add some of the graphical features shown elsewhere on the forum, about flames rendering and other special effects ?

And what about the OS X version ? 
Pritchard, I'm kind of curious to hear how other folks answer your question, but from my POV... yeah, Fitzquake had established itself as the "better version of GLQuake" that was the standard for making/testing/playing custom Quake maps. Fitzquake stopped development after a while and then Quakespasm sort of carried that torch forward. 
Special FX: Try the Spiked version. It's not the goal of regular QS. 
What is the Spiked version ? Is it available on OS X ? 
Fitzquake Already Was The De Facto Standard 
QuakeSpasm took over because it was more actively developed and cross platform, I would say. 
A fork of QS made by Spike that supports fancy stuff like particles and weather effects. There's a tutorial thread here:
Additionally, here: is an example of effects for E1M1. You'll find the download link for the latest revision either on top of this page or in post #25 of the previous link.

I have no idea if there is a Mac version, though. I'm sure some people here would know. 
QS-Spiked is a version of quakespasm that'll get you drunk faster than you expected...
it still looks+feels the same, unless someone actually uses one of the new features (which is imho why quakespasm is the more accepted / neutral engine).
and annoyingly people focus on only the particles rather than the other things intended to stop it from being crippleware. grr.

there's no prebuilt mac build, no linux build, no win64-specific build. the only prebuilt build is for win32, on account of it being intended as an updated patch rather than an engine in its own right, and me being too lazy to make 4 different builds with all their dependancies and crap.
its still based on sdl, so you should be able to compile your own version if you're determined (but you might need to grab any missing files from vanilla quakespasm).

Heh, well at least there are people interested in your work... 
How To Trigger Spike 
Aren't you also the man behind FTE? Considering that, I find your comment very surprising. At any rate, the people who come to QSS for the pretty-shiny can discover its other features afterwards. 
I'll make a mac build of qs-spiked soon 
Spike is all about the QuakeC. What would really need to happen is some single player modder using the QuakeC extensions available in the modified engine.

Like use the magic ear extension in QuakeC to create a shrine area with different statues and you have to say a magic word like "Klaatu Barada Nicto" to open the entrance to the tomb.

Like those games where the vault combination "4398" or the computer password is scrawled on a wall, possibly an alert player could use it to get a secret item.

Or have computer be able to do different commands like "airlock" to open a door on a base map. 
See? I've just discovered something! I admit that my interest in QSS resides primarily into said pretty-shiny, because I'm a DP fan and "normal" QS looks a bit too vanilla and I want to play maps/mods that have issues with DP but still get the bling, but what I've just read is AWESOME SAUCE! 
The actual extension is KRIMZON_SV_PARSECLIENTCOMMAND and QSS totally has it.

Which let's QuakeC intepret chat knowing what player entity said it and where they are. 
Krimzon? An easter egg referencing King Crimson, perhaps? 
Krimzon was a community member from ancient times. 2001/2002 or so; don't ask me to be any more specific.

Considering that, I find your comment very surprising.

If you use Linux you should be able to compile yourself. If you're not able to compile yourself maybe you shouldn't use Linux. 
Barnak has a Mac which can only run 10.6 (32 bit or something). Spike doesn't have a Mac, gotta have a Mac to compile Mac version because Apple wants it that way and sells hardware. SleepWalkerR has a method to compile for old Mac OS versions, it's obscure as hell and requires frameworks no longer available from Apple. Ericw has those frameworks/files.

Ericw = only guy on planet who can make binaries for Barnak's Mac. 
Krimzon was a community member from ancient times.
Oh, OK. Just asking because Crimson is one of my fav bands.

If you're not able to compile yourself maybe you shouldn't use Linux.
I don't. I tried a S.u.S.E. distro a long time ago but Linux is not user-friendly enough for me. I wasn't talking about the build part but about your jaded/angry tone. 
Barnak's Mac
Heh, that sounds funny. Try repeating it as fast as you can. 
I personally tend to play quake with vanillay setting. Pretty stuff like rtlights is not what I personally favour, which is why I've not gone completely crazy with that stuff. For instance, FTE has a number of presets, and only ONE of them has fullblown rtlights enabled.
Pretty stuff sells (yay screenshots), hence your interest in DP, which is why FTE has the effects that it does, but its not my personal focus. I'm more about letting people do what they want without extra barriers (bug-willing), hence csqc etc.
Note that QSS has a whole load of ssqc extensions, such that mods like SMC can run. I'm not saying that its worth playing SMC with QSS, only that its content-loading limitations that really holds it back (well, okay, a couple of extra things that I didn't bother to network up because I couldn't be bothered to implement the various clientside parts).
The point is that QSS should no longer feel like crippleware to an aspiring ssqc modder.
And hopefully FTE+DP users won't be left with horrible clunky mods that comprise of 60% hacks that were needed to work around QS limitations.
The particle system is useful to mods+maps, in much the same way as fence textures or strcat (though you're likely to need to use the more limited DP-defined effect definitions if you want compat across all 3 engines). My personal justification for including the particle system was because Sock used custom particles in AD, demonstrating a need, but that his particles made the game totally unplayable in coop - using the engine's particle system, this problem goes away.
Anyway, that's my reasoning.

@ericw, I *really* need to get off my arse and do that bugfixes-and-polish-only r5 build, then start harassing you or the other guys to get it merged into vanilla QS... but meh, lazy.

@baker, numberic combinations like 4398 could easily be done with impulses, but yes that would generally imply breaking weapon switching in certain areas.
I'd like if someone made a proper map-scripting language some time, but I'm too lazy myself. 
-Triggers targets when a given magic word has been said
--------- KEYS --------
-message: message to wait for (can start or end with * for wildcards)
-netname: replacement text (by default, no replacement is performed if empty)
-radius: radius in which the player has to be for this to match
-target: all entities with a matching targetname will be triggered.
-target2: all entities with a matching targetname will be triggered.
-target3: all entities with a matching targetname will be triggered.
-target4: all entities with a matching targetname will be triggered.

/Xonotic QuakeC source code 
My OS X 10.6 is full 64 bit.

If Quakespasm runs well on it, then it should run well on all newer OS X's. 
such that mods like SMC can run
Ooh, I wonder if Seven knows about this...

The more I read about QSS, the more it looks interesting to me beyond the scope of playing maps/mods that DP breaks. I'm an aspiring mapper and one of my main concerns is compatibility with at least the most popular engines. Something that seemed hard to pull of with regular QS vs. DP/FTE, according to a discussion I had a few days ago on the map jam 8 thread.
Lately I had noticed a trend among mappers to only care about QS anymore because having to juggle the different behaviors of engines became a PITA, while a few years ago they often tested their maps in 3 or 4 engines. I was even considering making 2 versions of my maps, one for engines that support graphical enhancements and another for the QS/Fitz family. Hopefully QSS will level the gap between those engines, be adopted en masse by QS users and I won't have to resort to that if I want QS purists to play my maps. 
This is going to sound really crazy, while testing my start map for the last jam I realised that blooms or similar would work really well for the streetlights.

Normally I think such features in a game like quake would be OTT (and I do think a lot of the features in DP are OTT). But standing under a streetlight looking up at it, you shouldn't be able to see the texture of the light itself, just brightness.

Anyway, I know this was only sort of tangentially related to the discussion at hand, but I thought it was interesting none the less. 
Spike lacks enthusiasm because he isn't being stimulated by an exciting challenge like writing a Vulkan renderer. Spike is in it for the puzzle solving.

So ... Spike here's a challenge you might enjoy thinking about.

Challenge: Take DPMaster source code
1) Implement connect mechanism that the client sends to DP master to tell it that it wants to connect to a server.

Client to DP Master: "I want to connect to, I will be using the current IP:port"

DP Master to Quake Server: " wants to connect to you with (client ip:port)"

DP Master initiates some STUN/ICE/TURN server action with the client/server to punch a hole.

*BAM* You don't even need to mess with port forwarding on your router any more.

Complete server freedoms for all! Casual player just starts server and it work for all.

/I wonder if Spike has thought of this before. I would guess that he HAS. 
I already implemented ICE with fte's xmpp plugin (including STUN, but not TURN because I'm too much of a cheapskate and I'm too lazy to deal with public TURN servers). You can use it for either voip calls (compatible with eg linux versions of pidgin) or for playing quake.
The only real limitations are that it doesn't really show any serverinfo nor ping, just the server's 'nick', and that servers/clients don't auto-join any chatrooms (iirc chatrooms are still kinda awkward to get going, at least compared to one-on-one chats - xmpp isn't like IRC in that regard).

Starting such a connection basically requires that both the client and server use some sort of identifier such that they can resume the connection if their IP changes (notifying the peer of new candidates).

Getting that secure enough to block hijack attacks would require tls or something... in which case dpmaster kinda becomes obsolete.

Either way, there's no way that bloat would get merged into QS, so you'll just need to stick with the existing fte plugin if you want that sort of thing.
Its not going to happen so any more discussion on that subject is kinda offtopic. 
... gotta have a Mac to compile Mac version ...
... Ericw = only guy on planet who can make binaries for Barnak's Mac.

None true. I suggest that you look at the cross-compile scripts
in the qs source tree. 
@szo -- re: build script contents --- that's very interesting. 
@szo -- re: build script contents --- that's very interesting.

Read them along with the associated makefile.

Setting up the cross-toolchain requires some getting used to,
but once that is done, it becomes heaven on earth. 
There's Also This

Never used it myself, though. 
Baker, you don't need anything special to build a 10.6+ 32/64 bit Intel .app using the latest macOS and Xcode, just checkout Quakespasm svn,

cd MacOSX
xcodebuild -project QuakeSpasm.xcodeproj

The only Mac configuration of quakespasm that isn't so easy to build is the 10.4 PowerPC one. We have a separate Xcode project in svn that builds on xcode 2.5 on OS X 10.4 so you can actually run and debug on a powerpc mac if you have one. 
A Horrific Texture Problem 
I recently updated my Nvidia graphics drivers to 375.70, Windows 7 64-bit. As a result, Quakespasm 0.92 shows some terrible texture problem that must be seen.

As you can see, its like some weird texture overlap on one another, and even weirder is it mostly affects floors, it rarely affects walls or ceilings and models are untouched by it. The problem is present in all texture modes, the one I use is gl_nearest_mipmap_linear.

Obviously the easiest solution is to revert back to older drivers, but is this affecting anyone else? 
anistrophy without linear filtering is basically implementation-defined. The driver is free to ignore your attempt to use nearest filtering, or even to only partially obey it, resulting in bluring between mip levels.

you can tell that its anisotropic filtering at fault, because it only really happens on surfaces that are at an angle to the view, as opposed to any surface merely between mip levels.

side note: for the highest texture filtering quality with the lego look, you probably want the minification filter set to linear, the mipmap filter linear, and the magnification filter set to nearest. unfortunatetly most engines do not allow using independant settings for the min+mag filters. this results in aliasing that is visible on maps the width of eg dm4 
Hm. I've never seen those black lines through lava at 0:36.

try disabling anisotropy with:
gl_texture_aniostropy 0 
unfortunatetly most engines do not allow using independant settings for the min+mag filters.

It's worth noting that this setting is legal in both GL and D3D.

However, GLQuake's gl_texturemode just selects the min and mip filters, then assumes that mag is going to be the same as min.

It's probably worth bouncing around suggestions for how to cleanly handle this without breaking compatibility. Add new filters to the end of the list? Add a separate command to specify mag (and a "revert to default" option)? Accept breaking compatibility and chuck out gl_texturemode, adding new commands for gl_min|mip|magfilter? Some combination of these? Something else? 
Ooops, Double Post... 
However, GLQuake's gl_texturemode just selects the min and mip filters, then assumes that mag is going to be the same as min.

It occurs to me that this may have been a constraint of 3DFX and other contemporary video cards but which is no longer relevant. 
the gl_texturemode list currently has 6 enumerated items, i don't think it breaks compatibility to add more at the end.

I think it merely doubles the length of the list to support mismatch of min and mag filter, which isn't that bad. 
Well I would love to tell you if this worked, but Quakespasm simply refuses to turn it off. Whether it be through the command line, or the autoexec.cfg, Quakespasm decides gl_texture_anisotropy must always stay at 1.

When the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is equal to 1.0, the GL uses an isotropic texture filtering approach as described in this section and Section 3.8.6. However, when the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is greater than 1.0, the GL implementation should use a texture filtering scheme that accounts for a degree of anisotropy up to the smaller of the texture's value of TEXTURE_MAX_ANISOTROPY_EXT or the implementation-defined value of MAX_TEXTURE_MAX_ANISOTROPY_EXT.

A value of 1 is off; unfortunately the stock code contains assumptions that are inconsistent with the spec. 
I tried updating my nvidia driver to 375.70 and I don't see anything wrong (tried all the texture modes, gl_texture_anisotropy 1 and 16.) I am on Win 10 64-bit and a GT 650m, so I imagine it's a case of a different hardware generation behaving differently.

Would you mind uploading a full resolution PNG screenshot? The youtube compression makes it a bit difficult to see. 

I am using an Nvidia GTX 970.
I would hate to think its the cause of the newer hardware generation, but hopefully its not a complicated issue. 
I'm still on 372.54, so I can't say if I'm having the same issues or not. I can say however that the 9XX series of cards are a real pain for compatability compared to older generations... The example that sticks out to me was NFS Shift 2, which would frequently display black frames that made the game basically unplayable.

You could try rolling back and seeing if that helps, unless you desperately need whatever new game support the latest drivers have... 
Even forcing Quakespasm to use no anisotropic filtering through the Nvidia control panel, the issue still persists.

I feel like I really screwed the pooch by updating, but it I haven't in so long and felt it was time to do so. 
Have you tried rolling back the driver update? 
Just Did 
Rolling back the driver to version 364.72, dated march, fixes the issue. 
So Now 
You could try the second to most recent drivers and see if the issue is there. Basically once you find where the issue first appears, you need to investigate the patch notes and see if any setting had been added or defaults modified from a previous version.

I don't know, that's the best I can think of when tackling from Nvidia's perspective.

I use a 980ti and I believe I have either the latest or second latest driver and do not encounter this issue using the latest non-spiked QS. 
I'm Almost Certain This Has Been Asked Before 
But why does QS have different strafe jump acceleration to darkplaces, and others? 
I'm gonna go out on a limb and suggest that it's darkplaces that has the different-from-quake movement code, and not QS. 
I remember hearing that in vanilla quake, "always run" had different (slower) movement than holding Shift, and that QS changed it so "always run" is the same as holding Shift.

I think this is the patch that changed that (while adding QS's feature that pressing Shift while "Always run" is enabled slows you down to walking speed): 
edit: load the entire Fitz Mark V thread and search in the page for "always run" - Gunter talks about it.

I'm not 100% sure about any of the above, but it sounds plausible after a quick glance at the code. 
Thanks Ericw 
That was exactly what I was looking for. I plan to expand my quakespasm-irc port to include speed running features, and "fixing" the strafe jump to the accepted standard (by the speed running community) needs to happen for runs made with the engine to be legitimate. 
Isn't that just console variable manipulation? 
I'm not sure if QS inherited the code from fitzquake. Gunter explains it in post 1149 in that thread.

What I might do is enable caps lock to be used for +speed. That way you don't need to physically hold down the key in order to always run and get the bonus strafe speed. 
@ericw --> 
Dear Ericw,

... I�m converting myself to pixels (read --> gl_texturemode GL_NEAREST_MIPMAP_LINEAR), but on the other hand, I don�t want to delete my collection of HD textures.

My idea is to put all the HD textures in a HD directory.

With DP is then possible to recall the HD texture when needed with a command like: GAMEDIR HD AD.

has QS a similar command line? command line like "-hd -game ad" does not work, while command line like "-quoth -game 5rivers" does ... why?

I'm Not Ericw 
The stock Quake engine only supports -hipnotic and -rogue, and these commands have other effects besides just loading a new game dir - they also change the Status Bar layout, for example.

Quoth requires the Hipnotic status bar layout so many engines add -quoth as another option to allow players to more easily specify this. Otherwise players would need to use -hipnotic, thus creating a dependency on the Hipnotic mission pack being installed, and with a side-effect of making it more difficult to split the Quoth content from a mod that uses it.

The big take-home from this is that a game dir that functions in a manner such as Quoth, Hipnotic or Rogue must be explicitly hard-coded in the engine. You cannot specify "-hd" and expect the "hd" game dir to load, because it's not been hard-coded in the engine.

Multiple game dir support - such as "game hd ad" - is trivial to add to the console but slightly more difficult to add to the command-line. 
Otherwise players would need to use -hipnotic, thus creating a dependency on the Hipnotic mission pack being installed, and with a side-effect of making it more difficult to split the Quoth content from a mod that uses it.

You don't need hipnotic to be installed to change the HUD with -hipnotic. You don't even need the directory to exist.

The second point still stands though. 
Thanks ... But Then 
would it be possible to hard-code "-HD" just for textures?

hard-coded in order to allow command lines like:

-hd (for ID1 and/or generic maps)
-hd -hipnotic
-hd -rougue
-hd -quoth (-game 5rivers)
-hd -game ad


The (sloppy) DarkPlaces multi-game dir system that has 3 major flaws also depends on the same system that allows DarkPlaces to crash if you have a start.lit file for a different start.bsp

Quakespasm, on the other hand, has the "Quakespasm content protection" system to prevent that.

Implementing a "hires" folder capability as a separate cvar like "cl_replacementfolder" (name?) would be the right way to do it, but might not be trivial to implement due to the above. It would need to be placed at the end of list.

The (sloppy) DarkPlaces way is not the right way.

If it were, a lot of engines would do it that way --- case in point Quakeworld loves replacement textures --- but ezQuake would never do such a thing because the (sloppy) DarkPlaces way breaks the QuakeC precache system and cannot tell replacement content from the original content.

(Also would happen to mess with physics in a FitzQuake engine in some circumstances due to FitzQuake using the model bounding box instead of -16, -16, -16 to 16, 16, 16 ... so your replacement content could actually affect the in-game play in some situations).

The right solution for people like Icaro is a separate cvar for the use of such a folder, and then maybe adjustments as uncommon problems crop up. 
If it were coded as a separate cvar or a command like option like -hd as Icaro suggests, it would be easier to tune and get users to have the right habits.

I've seen notes in Quakespasm Spiked where Spike was at least thinking about the vastly enhanced networking code provide for automatic download for coop (and even the start of commented out prediction code).

Implementing something that separately specified a replacement content folder for the client would be compatible with not breaking such ideas.

(But the DarkPlaces (sloppy) multi-game way would totally break it. ... you would no longer know the user's intent and whether a folder is the game data or if a folder is intended as client-side replacement only.) 
fte has a 'gl_load24bit' cvar that can be set to 0 to disable replacement textures.
it has a similar cvar for alternative model extensions to try to load (screw s_light.<mdl|spr>).

this means that mods can provide one set of content for chunk pixel style stuff, and another set for people that weirdly crave shinies and a lack of clear boundaries...
imho, that's much cleaner than lots of different extra directories all over the place.

the easy way to fix the +/-16 issue is to just have setmodel use +/-16 for ANY model with .mdl as an extension. This fixes md3s replacing ammo boxes or whatever other issues that plague DP's replacement models, and also means dedicated servers don't even need to load all of those .mdl files, giving slightly faster map loading in multiplayer. Really its a win/win situation!

regarding downloads, both gamedir switching and downloading paks/pk3s have issues if not handled properly / explicitly. Which files to use/download/cache/reuse/delete is an entire subject in its own right. Avoiding the transmission of personal or copyrighted data makes things fun, and *which* network protocol to use just makes things that much more political.
So yeah, QSS doesn't do downloads, which saves me a massive headache. Besides, download code is annoying to test. 
@Icaro ... "hdfolder" 
I have a working solution to this problem in a version of Mark V that will be released in the next 30 minutes.

There is a command called "hdfolder" where you can specify the content replacement directory and change it, it saves to config.

So you can have different sets. A fair number of things that have been proven to be good ideas have gone from Mark V to Quakespasm or Quakespasm to Mark V.

/I'll save explaining to Spike why this is a needed feature or how it avoids every downside of DarkPlaces multi-gamedir for some other time. 
Looks Like One Of My Fans Disappeared In The Final Build
... but only in QS... weird.

Weird. what QS version / OS / 32/64-bit, etc? 
I'm a version behind at 0.92.1
I'm running ubuntu 16.04 64bit 
Mouse Acceleration On Windows 
First of all, thank you for great port!

I'm wondering, is it possible to disable mouse acceleration on Windows 10? It looks like sensitivity in game depends on pointer speed in Windows. 
Try quakespasm-sdl2.exe, it should use raw mouse input on Windows. 
Thank you very much, it indeed helped! 
What's the reason for having two binaries anyway? 
SDL1.2 supports older OSes (back to windows 95? and the mac version, back to 10.4/powerpc), but it's no longer under development.

SDL2 has more features (raw mouse input, borderless fullscreen, better international keyboard support, etc.) but has had more bugs.

At this point I recommend using the SDL2 binary unless you need the old OS support. 
What Is SDL2's Oldest Supported OS? 
Win XP / Mac 10.6 
Model Loading Glitch 
I recently recorded some Youtube videos for Retro Jam 5, and in the process discovered a glitch with regard to model loading. I'd initially passed it off as an Nvidia driver problem, but I'm not sure. EricW commented on one of my videos to see if I could reproduce it, and he'll be happy to know I've managed to do so:

1.) Running Quakespasm 0.92.1 (I was running 0.92.0 for the videos, but 0.92.1 works the same way) and Nvidia driver 375.95, run quakespasm -game retrojam5, make sure the game is running at 1920x1080.

2.) In the console, load my RJ5 entry with 'map retrojam5_tens'.

3.) Hit Escape, and in Options|Video Options, change the resolution to 1280x720 and Apply Changes.

4.) Load the first map in the pack, 'map retrojam5_breezeep'. You should see two light fixtures at the far end of the room with flames in them, clearly visible, no problems yet.

5.) Drop the console and go back to my map with 'map retrojam5_tens'.

6.) Again in Video Options, switch back to 1920x1080 and Apply Changes.

7.) Load Breezeep's entry with 'map retrojam5_breezeep' and the flames should be invisible.

If you follow the same procedure, but replace retrojam5_breezeep with retrojam5_newhouse, you'll find not only missing flames but invisible enforcers, which makes for a bit of interesting gameplay. Not sure why it only affects some models, or how I might reproduce the glitchy blue polygons you can see in parts of my video for NewHouse's map, I'm sorry.

It's a bit of a convoluted procedure, but in prepping for the video recording I was toying with my settings, going back and forth between maps and changing resolution, so it's no wonder I stumbled over whatever's happening here. 
Possible Func_wall Problem 
Just to keep these two reports clearly separated, I'm using a new post for this one.

Also with regard to Retro Jam 5, and also in Quakespasm 0.92.0/0.92.1, my map has a hovering quad damage, using the trick of having a func_wall underneath it and firing killtarget at the map start, from a trigger placed over the playerstarts.

In one person's demos/video, namely khreathor's, the quad is instead sitting in the water underneath it. Some discussion with him revealed that when loading the map with 'map retrojam5_tens', the quad is suspended midair as expected, but subsequently using 'restart' means it falls down into the water.

While the map doesn't fall completely apart if one grabs the quad out of order, it is a bit less fun, and though adding a short delay to the trigger that kills the func_walls might have avoided the issue, it raises the question of whether this behavior is by design or is some sort of bug. Should this be happening? 
Second Bug 
Is this bug specific to Quakespasm? There have been other instances in Quake where the restart command doesn't behave like loading the map normally, e.g. 
Oh, it might just be my ignorance, then, sorry. I'm not intimately familiar with the subtleties of Quake and its various sourceports, so if this is standard operating procedure that mappers are just expected to accommodate, never mind the second bug report, I'll just get used to it. 
I reproduced the invisible flames, thanks for the detailed steps! 
ahh good to know. I'll use "map" instead of "restart" from now. I wonder if putting Quad higher above the func_wall will fix this behavior? 
Ok This Is Weird... 
QuakeSpasm 0.92.1 - I can't load E1M7, I get

"host error: mod_loadclipnodes: planenum out of bounds" 
If you talk about vanilla e1m7 it works fine for me on QS 0.92.0 
Works For Me On 0.92.1 Too 
maybe you have corrupted pak or something ? 
yeah vanilla, no mods or anyfink. SDL2 version if that makes any difference 
Just tested E1M7 in 0.92.1 with the SDL2 exe and it loads fine. 
Weird, I've never seen that error before.

Check the md5 hash of pak0.pak, it should be one of:

Combining Two Rogue Fixes? 
Today I played the MP2 (Rogue), and I ran into a problem.

We all know that elevator in R1M7 is broken, and while Seven made a fix, it was done via progs.dat file.

Few years ago, I asked someone to interpolate the Rogue buzzsaws movement, so Necros made a quick fix. The problem - it was also done via progs.dat file, but the game can use only one progs.dat file at a time.

I don't have any experience in QC, but is there any way to "combine" the two fixes? I have source files from both fixes - BUZZSAW.QC from Necros, and a folder with many QC files from Seven's fix. I hope someone can do this, here are the files: 
Instead of asking people "please do this for me", which will most likely be met with a resounding "no", ask "how can I do this?"

I've found an apparently very clear tutorial that will guide you through the process of making your own progs.dat. It seems quite simple. Looky here: 
Necros Did It On His Own 
I replaced the BUZZSAW.QC from Seven's folder with the one from Necros, and compiled using the default settings in FTEQCC GUI. Result is that Seven's fixes work, but Necros buzzsaw fix is ignored. It would seem there's more to this than just modifying BUZZSAW.QC file.

And I didn't actually ASK Necros (or anyone) to do this, I just reported the problem and Necros explained it and made a quick patch. 
Well pickle my pangolin, that was it - my pak0 was scrozzled, with a different checksum to what it should have. Which means some data on my hard drive became corrupted, which is worrying!

I re-downloaded from Steam and all works.

Cheers cheps. 
R1M7 elevator works fine WITHOUT the buzzsaw patch, but the moment I add it, the elevator breaks. 
I Can Do It 
All qc must be subsumed into the collective.

I can't open your zip, 7zip says its corrupt. Maybe try putting it on quaketastic. (see screenshots thread for login+password)

What's wrong with the elevator? I never noticed anything on my last playthrough. Granted I think I was 14 at the time.

Buzzsaws interpolation:
Do you mind sending me what necros said to you? Also, are both progs.dat files in your rar? I can decompile the progs to find out what all else he did to it. I've become a qc comparison junky of late what with AD absolutely doing everything better so of course I had to update my own personal mod to add some awesomeness. 
Weird Indeed 
Well honestly, "I hope someone can do this" sounds a bit like asking people to do it for you... ;) Anyway, this thread is dedicated to Quakespasm and people here are not too fond of off-topic, so you should move your problem to that thread instead:
I wish I could help more but I know about as much QC as you. 
To Qmaster: 
Check this out. Few hours ago, I tried compiling Rogue progs.dat from untouched Rogue source code (QC files). Guess what? Elevator doesn't work. I can't explain it, since the elevator DOES work with progs.dat located in original PAK0.PAK straight from the Rogue CD. Is it possible that Rogue CD contains different version of the PAK0.PAK file, with some kind of fix?

Necros said:
"The buzzsaw doesn't actually move in the normal way. What it looks like (only from looking at the QC) is you make a func_train or something that the player can't see. Then you target the train with the buzzsaw. Every 0.1 seconds, the QC sets the origin of the buzzsaw to the targetted train. This is why it doesn't interpolate, because it's not supposed to-- the QC call is setorigin."

Necros patch:

Seven's fixes: 
(Seven's fixes still corrupted, I don't know why, here's a direct link from QuakeOne) 
@ToMaHaKeR - Is This A QuakeC Help Thread? No It Is Not. 
Post your QuakeC questions in the following thread, which is a Quake help thread:

Your hipnotic buzzsaw issues have nothing to do with the Quakespasm engine. 
Told Ya... 
You'd better listen to Baker this time if you don't want to piss people off. 
Bug: Some Keystrokes Are Ignored In A Certain Situation. 
System, ubuntu 16.04, running latest quakespasm, quakespasm executable (does not occur in quakespasm-sdl2) lauched from terminal without any parameters.

Replicating the bug:

Upon load of the game, new game is selected. *Just* before the console retreats all the way to the top the tilde key is pressed and the console comes down again.

Here is where the bug occurs, the console, instead of staying down, goes back up. Now every time the console button is hit, the console will drop, then return back to the top.

This also affects other keys, if you then hit escape and go to "new game", when you're prompted "Are you sure you want to start a new game", the game will accept no input.

Alt-Enter is locked, so I can't quit the game, Escape is locked so I can't return to the menu. All I can do is change terminals (ctrl-alt-F1) and kill quakespasm. 
I reposted it to the bug tracker, hope you don't mind:

I have seen it before and IIRC it was SDL1.2 sending invalid key presses, but it would be good if QS behaved better if possible instead of locking up.
Good that SDL2 is working properly though, that was my experience as well. 
Heh, It Was Avoidable 
I've been using the 1.2 up until this point in time because for some reason my system (or quakespasm) wanted 32 bit SDL, vorbis and mad libs.

I didn't have them installed because I've been trying to avoid system bloat. I've installed them now though. Fingers crossed it won't break any of my other games :) 
weird, I'm having trouble reproducing it at the moment. The last time I saw the bug was a year ago or so, but I don't run QS on linux very often, just when testing releases really. I am also on Ubuntu 16.04 with all updates applied, and using the unity desktop.

Just to double check the SDL version you have, mind running this?
dpkg -s libsdl1.2-debian | grep Version 
The command you supplied tells me its not installed, the version I have installed is 1.2.15+dfsg1-3 according to synaptic.

I just looked up what dfsg meant, apparently its debian free software guidelines. Now I wonder if the dfsg version is behind the non-dfsg version. 
It Was I All Along 
I'd just like to make the following correction. Over a month ago , post #2571, I reported a problem with Quakespasm and the latest Nvidia drivers cause an ungodly texture blurring scenario, and I was curious as to why nobody else was experiencing the same issue.

As it turns out it was my fault. I did a complete uninstall/install of Nvidia's latest Windows 7 drivers, totally clean. The problem was gone, so I can only conclude it was a certain graphic setting I had used within Nvidia's control panel, but which one it was I don't know. Or it may have been something else entirely.

But either way nothing is wrong with Quakespasm, nothing (as far as graphics are concerned) needs fixing, and I apologize if I caused any time wasted trying to figure out a problem that was never there. 
Antialiasing - Transparency 
Is the culprit responsible for Quakespasm's blurry texture scenario when using the latest Nvidia drivers. Avoid using that setting. 
CPU Usage Goes Nuts When Minimised 
OK, when minimised, Quakespasm's CPU usage shoots right up to use over 20% of my CPU, and my fan kicks in to overdrive (happens the same whether I'm in fullscreen, then alt-tab to windows - or in windowed mode, then I minimise the window).

I'm using the SDL2 version. 
I implemented a lightmap format change that may help the AD start map performance on your Intel graphics system:

1. unmodified svn r1371
2. new lightmap format (GL_BGRA GL_UNSIGNED_INT_8_8_8_8_REV)

I wonder if you could test these two buildson your system and report what FPS range you get in ad1.5's start map for each build.

link to source code 
I can't measure any difference between those builds on:
-Intel HD Graphics 4400 (2013? laptop)
-Intel 855GM (2004 laptop) 
Back a few years, I tried that modification. Tried the binary on several machines, couldn't locate one where it made a difference (Intel, GeForce, Radeon, etc.)

I believe such machines do exist, but I just didn't have any of them. 
Baker, yeah.. MH mentioned in the insideqc thread:

This is only really important for Intels that have hardware T&L - say, the 965 onwards; it seems as though earlier generations are more tolerant.

I guess my old intel is the more tolerant earlier generation.. and my newer 4400 came out several years after that thread, so apparently Intel fixed the perf issue by that time. 
Yeah, I haven't tested this in a long time but I don't believe it's an issue any more either. GL_RGB should still be an issue, but GL_RGBA should be fine. 
Just for reference, I've tested these builds on a more recent Intel 520 machine without measuring any difference either. This supports my guess that with DX10+ class hardware (where Microsoft forced the vendors to standardise on RGBA) it no longer matters.

A more interesting benchmark would be gl_flashblend 1 versus gl_flashblend 0. That would really help determine if it's dynamic light uploads. 
Thanks. For reference, build #1 I posted above (and QS releases) are using GL_RGBA / GL_UNSIGNED_BYTE.

Question for Shamblernaut:
Can you still reproduce the console retraction bug with sdl1.2? I just tried again and can't trigger it (though I remember seeing it like 1-2 years ago).
I tried in the default ubuntu 16.04 Unity desktop as well as the "ubuntu flashback (metacity)" one. Tried both windowed and fullscreen. 
Further Comparison 
This time on an Intel HD2000, which is closr in performance to @QuakePone's, but still no measurable difference. 
You can disregard my question, managed to reproduce the console retracting bug 
I Didn't Even See The Question 
That's what I get for skim reading.

As an aside, is there any particular reason for console commands being case sensitive? I understand that filenames require it, especially in *nix based systems. Is this just a legacy code thing or are some commands actually case sensitive? 
in certain cases, yes, especially if you're exposing them to qc.
there's no good reason for case-sensitive tab completion though. 
I Honestly Can't Even 
I did test ad_start first by doing nothing and then b-hopping around until I catched those frame drops in each version. The more I tested the less times I encountered them and I usually got different results every time I restarted the map in 92.1 before this.

FPS go around 27 but in 92.1 I sometimes got the framedrops during late tests. It's very unconsistent.

You can't really take my word here, I am very confused about all of this and in the end I will probably need an engine that takes more advantage of unused GPU power. Sorry, I can't be of much help here. 
Ok, thanks for checking anyway. It sounds like the GL_UNSIGNED_INT_8_8_8_8_REV thing is no longer an issue.

My laptop with Intel HD 4400 is faster, but QS doesn't exactly fly on content like AD; some time I will have to look more closely at whether I get the same speed increase when switching to MarkV DX9. 
AD Content 
This isn't something I've sat down and analyzed. I'm just making general observations here.

Even with the fastest lightmap updates in the world, you'll still bottleneck on lightmap updates. In RMQ we had a scene with 20+ flickering candles; every lightmap in the scene would get updated and it would pull the NV 280 (I think) machine I was using at the time down to 20 fps.

GPU lightmaps are the future. Dynamics still have a cost but lightstyles are completely free.

FitzQuake's brush model renderer sucks. If you were to be actively malicious and deliberately set out to write a bad brush model renderer you might do worse but I doubt it. Ideally brush models should go through the same renderer as the world. A map with lots of brush models is always going to run slow.

FitzQuake's sky renderer sucks. If you were to be actively malicious and deliberately set out to write a bad sky renderer you might do worse but I doubt it. I had one of those "sweet baby Jesus" moments when I analyzed a scene in PIX and saw that 80% of the time was spent drawing sky. Any scene with sky in it is going to bog down on slower hardware.

What both of those have in common is per-polygon state changes. In the absence of batching in your own code the driver will make reasonable efforts to batch itself, but state changes will break that.

There are certain items of "Quake lore", such as Quake can't do big scenes, sky is slow, disable multitexturing, and so on. They're not true. The problem is in the implementation, and they can all be solved. 
In Quakespasm, the brush models are drawn with the world, if I recall.

As a general note, since I don't know if you are aware of this -- Arcane Dimensions is a bit less optimal than some other single releases in a couple of departments:

1) First, it uses sprites as particles. So each little floaty pixel is an entity. You can turn this off by doing "temp1 0" and restarting a map, if I recall.

2) Second, you know static entities like torches? Arcane Dimensions doesn't do torches as static entities. And Arcane Dimensions uses a lots of torches.

I haven't checked, but combined with the fact that Arcane Dimensions maps tend to have tons of details and complex geometry and generally the maps tend to have at 200-300 monsters and super-tons of items/books/etc ...

It's a bigger load than most maps tend to be.

And because of the torches and particles, I suspect puts more pressure on the QuakeC interpreter too.

The end result is very cool and creative.

Also: I have never checked, but in complicated maps with huge entity counts -- how much is vis helping? Engines with r_lockvis you might not be able to tell ...

(If I "r_lockpvs 1" in Mark V, then no clip outside the start map it looks like this ...)

Now, mh, look at this ...

On ad_mountain ...

I type "r_lockpvs 1" and noclip outside map .... <--- RED ALERT!!!

So ... whatever is going on ... vis is doing a very poor job ...

Imagine how many entities are drawn per frame with vis doing that? 500? 1000? I don't know, but frustum culling cuts some of that down.

So I wouldn't approach this this that the maps are optimal and the mod are optimal from a performance standpoint and the Quake tool are doing a good job.

Arcane Dimensions is a great experience, but there is plenty of room for performance. 
2nd opinion on "r_lockpvs 1" using DirectQ, just to make sure.

And let's throw ARWOP Roman1 into the mix which isn't Arcane Dimensions ....

^^^ With vis generating results like the above, well --- let's just say the wide open outdoors map thing sure doesn't vis very well. 
Vis On Big Maps 
Is a struggle.

In the old days mappers used water volumes to control vis as they were vis blockers. I asked ericw to add a vis brush to perform this task instead when compiling. Don't think it was ever implementedy 
Vis doesn't do its job all that well, not even on many of the original Quake maps.

But Sometimes it does.

But the real problem is even more insidious.

Vis is used to determine what entities Quake thinks you can see!

If it is drawing damn near the whole map, it's also drawing all those spritey particles and perhaps most of the monsters in the map. 
@mh ---- 
In Mark V, if I type sv_cullentities 2 in the console.

I get a significant frames per second boost. 15-20% on ad_mountain.

sv_cullentities 2 is a very strict "is the entity visible" check on the server side against all entities. It is otherwise known as "anti-wallhack".

It's also a somewhat cpu expensive, but I guess it is saving several hundred entities from being drawn at all so it is paying off here. 
That Ad_mountain Pic 
Could that be detail brush shenanigans? I remember a discussion once where it was concluded that detail brushes can sometimes mess up the PVS if they totally cover a world face. 
Try it in id1 Zendar and then ad_zendar?

I recall sock doing some hint brush fuckery, maybe that's the culprit. 
I wouldn't read too much into ARWOP behaviour, ARWOP is very much a special case.

The AD screenshots definitely indicate that something different is going on too. I'm going to do a bunch of testing on that and see can I figure what it is.

Re: VIS I'm amazed that no Q1 VIS tool has implemented area portals. Being able to lob off huge chunks of geometry just by closing a door is a win. I'd love to see Q1 VIS moving to legacy; engines can still load & use it for compat but let's standardize on Q2 VIS for the future. 
Hypothetical Question 
is there a different culling method that could potentially be written into a quake engine that would be better suited to big open maps? 
Vising Is Often On The Mapper 
designing as intelligently as possible. Don't make giant box maps (something I need to work on myself).

However it would be nice to have some extra toys to work with. 
Big open maps and culling are not the problem. The current culling is perfectly capable of handling them, a minor optimization to R_RecursiveWorldNode makes it a little better (software Quake has the optimization, GL doesn't).

The problem is in the renderer and server processing. QuakeSpasm now has the necessary renderer work to be able to handle big scenes. It could go faster by bumping the hardware requirements to GL 3.x and implementing array textures for lightmaps, as well as putting in some instancing for MDLs, but that might be too intrusive a change to the codebase.

Server processing is a problem and QC is just too slow for large entity counts. That's the next tree that has to fall. 
I agree with mh, it still works impressively well on big, open maps, and it matters a lot on AD maps. ad_tfuma was fastvised it right up until release, because Fifth and I both assumed vis would take forever and not be able to optimize much, since it's more or less a giant box with some underground areas. Just before release, one of the testers complained of low fps, so I tried full-vising it - took only 20 minutes (8 threads), and the wpolys visible from the start position were cut in half (30k to 14k iirc).

QS's brush model renderer was the first renderer thing I changed (this was ~2014 for RRP, ijed's map had some complex bmodels), they're not merged with the world, but each is drawn using the world renderer.

QS uses the Fitz sky renderer unmodified. (same for liquids).

GPU lightmaps: blending the 4 lightmaps per face sounds like a straightforward good idea. I'm wondering if it will be difficult to do the moving dynamic lights from rockets/etc. IMHO they need to be kept at the low-res of the lightmaps - when I was experimenting with high res lightmaps and LIT2, I remember noticing that rocket trails really stuck out like a sore thumb when they were over a high-res lightmap. @mh did you do any experiments with this part of GPU lightmaps? 
GPU Lightmaps 
I draw dynamics as additive blended extra passes over the scene. Full per-pixel quality. TBH it doesn't bother me but maybe this is one of those things that annoys different people in different ways.

I guess you could use a low res attenuation map texture but I just do the maths.

Optimizations: Eric Lengyels scissor test optimization is mostly designed for shadows but helps here too. Frustum culling the dlight. Only light surfaces that were drawn in the main pass.

I also add dynamics to BSP brush models using this scheme.

Light styles: I actually use 3 textures, one for each of R, G and B and encode the styles into the color channels. Animation is a 4-component DotProduct per channel and combine them to the final color. 
@mh - Just So You Have All The Information. 
Another side effect, not related to rendering, of the vis problems combined with spritey particles is huge demo sizes.

As you know, the vis information is used to determine what entities the server side thinks is visible to you.

If you record a demo in most of the Arcane Dimensions maps, the demo is going to be massive after 30 minutes of play (600 MB).

I ended up disabling the autodemo feature by default in Mark V because recording a demo in Arcane Dimensions became a performance issue ...

... Which users perceive as "this engine is choppy", hehe.

So anyway, the full deck of cards.

/The very nice thing about Arcane Dimensions is that it is open source. Sock is #1 in my book because he's always been open source.

Which also means it is possible for new optimizations to theoretically be written eventually to shift some burdens from the QuakeC to the engine (particles).

Arcane Dimensions merely exposes things that the map compile tools and the engine particle systems could handle better. 
particles - qss uses fte's particle system to support the effectinfo stuff that sock used in ad, as a result qss should have much more sane demo sizes with ad 1.5.

choppy - use a thread to perform the disk writes, then you don't get stalls from flushing happening on the main thread.
making that change reportedly solved multi-second stalls with fte on linux.

size - gzip it as you go (you don't rewind, right?...). 

the demo that i recorded for ad_magna is 2gbytes

i checked with r_showtris 1 and no particles-entities, the demos should be smaller 
making that change reportedly solved multi-second stalls with fte on linux.

R_drawworld 0 
All the FitzQuake derivatives support r_drawworld 0; fog 0 // fog 0 helps visualize distance entities.

The following screenshot demonstrates how map vis isn't helping much ...

Particles ... but as you can see there are tons of candles and monsters in the vast distance. It's a lot of unnecessary drawing.

All those monsters that have no chance of being seen ...

1) Get sent to the client by server.
2) So they get recorded in a demo
3) So the engine tries to render them on the screen

Rendering hundreds of entities that cannot be seen is a performance hit. 
"Which also means it is possible for new optimizations to theoretically be written eventually to shift some burdens from the QuakeC to the engine (particles).

Arcane Dimensions merely exposes things that the map compile tools and the engine particle systems could handle better. "

I was tinkering around with an idea, (well mostly because I found what I did wrong with bsp2), working on some AD stuff, and particles. I started with making little flames on the tops of candles, instead of the bouncy little polygons. But I could expand this to replaces the sprite emitters from AD and use QMB particles on the engine side. I'll post some results/screenshots when I get things rollin'. 
Weird Bug 
Hey, I'm getting a weird wateralpha bug


the lava (or any fluid) appears milky except for when the player is clipped into a wall?

the alpha is set to 0.3

the version is version 0.92.1 (SDL 2 build)

I'm running ubuntu 16.04 LTS using opensource radeon drivers.

Is this a configuration thing or a software bug? Cheers. 
the map isn't water-vised...
(combined with gl_clear) 
I thought that the vanilla maps worked fine with wateralpha 
only if you revis them yourself, or use get vis patches.
otherwise they'll just be transparent and reveal the void below.

if you were using a value of 0.6, you might not have noticed. 
R_novis 1 
Will work but I believe it affects performance 
I thought that the vanilla maps worked fine with wateralpha

No, they don't. This is actually called out in the original GLQuake readme:

Unfortunately, the standard quake maps don't contain any visibility information for seeing past water surfaces, so you can't just play quake with this turned on.

Note that r_novis will just let you see surfaces through water; it will not let you see entities (monsters, doors, pickups, etc) through it. 
Mark V and DarkPlaces (rather sure) and some other engines support external .vis files.

You put the .vis files in id1/maps and then all your Quake maps are vised.

It's pretty much the same thing as external .lit files. 
heh TIL

thanks guys :) 
I use this from BPJ wrote on an old thread on that just draws everything

byte *Mod_DecompressVis (byte *in, model_t *model)
static byte decompressed[MAX_MAP_LEAFS/8];
int c;
byte *out;
int row;

row = (model->numleafs + 7) >> 3;
out = decompressed;

if (!in || r_novis.value == 2)//BPJ
{ // no vis info, so make all visible
while (row)
*out++ = 0xff;
return decompressed;


it simply allows me to see all ents underwater, yet im sure it's not optimal :P 
It's definitely not optimal because it will also pull in ents that would otherwise not be visible in a properly watervised map.

The other thing it will do is increase server load and protocol traffic.

The latter is something you might be surprised about. We have a tendency to base assumptions and measurements only on things we can directly see. In a scene with 400 active and moderately complex entities, the bottleneck isn't the renderer - it's PR_ExecuteProgram (QC, in other words). 
Sky Far Clipping 
Some weirdness going on with the sky at high distances: back wall disappears when more than 8192 units away. 
Check Gl_farclip? 
I Did. 
It's at 16k as per default. With normal textures it works fine, just the sky brushes are affected. 
I bet it's a qbsp limit (BaseWindingForPlane). Someone reported this as a bug in tyrutils-ericw a while ago and I raised the limit, try the latest version of my tools. 
You really should just draw sky with glDepthRange (1, 1) - that way you can draw it as a tiny (but larger than nearclip) cube around the viewpoint and it will automatically position itself at the far clipping plane. The way Fitz & derivatives handle both the scrolling sky and skyboxes makes this very possible. 
I know most of the mods/maps have to be installed in the base Quake folder, but it really keeps that folder messy and it's hard to sort through if you have tons of maps/mods and when you want to delete a folder it's a hassle.

Is it possible to put all the mods/maps in a seperate folder and still be able to launch QuakeSpasm with enjector? I tried doing that but it won't let me because everything has to be in the basedir, is there a command i could use?

Is it possible to set a path to a different folder in quake injector? 
Elevators Etc. Working Funny Past Host_maxpfs 165 

Thanks for all the hard work you've put on this great engine. It wasn't until now that I was able to come across a bug that I'd like to report.

Fairly recently I got myself a monitor with a max refresh rate of 165 Hz, so to squeeze out all that juicy smoothness the monitor can offer, I decided to adjust the host_maxfps setting in the config to 200. However, this causes problems that can be seen most notably in elevators: all entities onboard the elevator seem to kind of lag behind.

For example, if I go down an elevator, the elevator goes down smoothly, but I go down in skips, as if I was Wile E. Coyote forgetting that gravity exists for a split second and then I fall on the elevator again only to forget gravity for another instant as soon as I touch the elevator again. And the pattern repeats.

The same happens going upward, with more severe consequences, as I end up slightly inside the elevator, which may sometimes cause the elevator to think that it's squishing me, which causes it to damage me and then reverse back down.

I did some testing, and the only influencing factor seems to be the value of the host_maxfps setting. (Fiddling with the V-sync settings didn't seem to do anything.) The threshold value seems to be about 165, above which the problem starts appearing.

Anybody else have this problem? Sorry, if this has been addressed before. 
Framerate Is Tied To Physics 
In most quake engines and wasn't really designed to go that high. Some engines have uncoupled physics from framerate and work better at higher frames. I believe dark places is one such engine. 
Quakespasm And Raspberry (again) 
I know QS is OpenGL while RPi is GLES, but, really, it would be great to enjoy Quake (or Arcane Dimensions)on a small, silent and low-power-consuming Raspberry Pi 3.
BTW Quakespasm is yet available in Raspbian Jessie repository, but I get a "Couldn't load video device" error when I try to run it in framebuffer mode (CLI).

So really no interest in a Raspberry support? :( 
there's actually a few engines that support gles2 nowadays.
Izhido(was it?) had one for ios, alternatively there's multiple engines that run on android with its gles1/2 limitations, including my own.

If you grab the source for fte, you should be able to use the following command for the original rpi (cross compiles, you might need to fix up some assumed paths inside the makefile):
cd engine && make gl-rel FTE_TARGET=rpi
If they've fixed up their egl support since the original, you can try and be more generic and just use the following:
cd engine && make gl-rel FTE_TARGET=linux32 CFLAGS=-DUSE_EGL
With that generic build line, you can switch between egl vs glx under x11 with setrenderer egl vs gl.
I don't actually have any sort of rpi, so I can't really help much more than that. 
Funny thing I just ran across...

Using the latest 64-bit quakespasm-sdl2.exe, with the latest NVidia drivers, there are certain POV points on the DM3 bridge where sections of the outside pentagram area are being rendered in my view.


and here's my config.cfg and autoexec.cfg: 
I think it's just r_wateralpha 0.5 in config.cfg + non-watervised bsp (QS has had gl_clear default to 1 for a few versions, so you don't get HOMs anymore, but you get that instead, which is less obvious what's happening).

So it's good that it's not some deeper bug in the renderer, but this is a common enough thing (it's been reported a couple times I think, happens to me fairly regularly) that we should probably do something about it...

IIRC, QS has had r_wateralpha be archived in config.cfg since an early version, and when you combine that with changing gamedirs with "game" you can easily launch something like AD, then change to id1 in the console, exit, and end up having r_wateralpha 0.5 saved in your id1/config.cfg.

There's also the option of having the engine detect watervis, etc. 
Ah hum. Yeah I clean-installed recently and I guess I picked up a default r_wateralpha of 0.5 from either QS or Mark V. Actually it's been so long since I messed with those settings for non-watervised maps I forgot that it even had an effect if r_novis was 0. 
320x200 Fullscreen Scaling 
I really wan't to play Arcane Dimensions in low resolution. Unfortunately mark v, which supports resolution scaling, doesn't support AD. The winquake version has problems everywhere and the opengl version can't handle some things like the fog in the necromancers keep. Apart from that performance is also really bad. mh explained how that has to do with mark v being cpu-bound while engines like quakespasm are fillrate-bound, which also means that downscaling would greatly improve performance in quakespasm while having close to no benefit in mark v.

I mainly wan't this feature because of the way it looks (explained in detail in my mark v post here: ), but the potential performance boost is also incredibly useful to me as I'm running quake on pretty slow hardware. Quakespasm is already a huge improvement over mark v in AD, but I still get occasional framedrops on 1366x768 (native resolution of my laptop) while 320x200 runs silky smooth. Of course not in fullscreen, but quakespasm will output that resolution in windowed mode if you specify it with -width and -height. That proves to me that the resolution I wan't to play on is at least technically possible in quakespasm, I would just need a feature similar to that in mark v which stretches a borderless window to fit the full screen without interpolation. You can even simulate something like this by using the windows magnifying tool, but it's horribly awkward to set up and doesn't allow you to use the mouse (more on that in my last post in the mark v topic).

So, getting to the point here, I will pay the developer who implements this feature in quakespasm. That's how badly I want this. I absolutely love quake, and the amazing lovecraftian environments in AD make me truly happy to experience, but I can't enjoy them as much on high resolutions as I would otherwise.

If you're one of the developers reading this, name your price for the time it would take you to implement this. I will pay you, given that the price is within reasonable bounds. 
Not sure I'd play on 320x200 but less detailed quake maps definitely look better in lower resolutions IMO. I tried setting QS to a lower res than my laptop screen, but my screen just blurs it and it looks terrible. It would be nice to have the option of playing on lower resolutions but with krisp krunchy krixels 
Yep. In vulkan quake i dont see an issue with 289. In quakespasm i get the gravity problem or when going up a lift it damage happens to health. 

You could try this workflow for your purposes.

The following link details a DOS compilation of super8. I'm not sure how recent it is, however it may support modern map limits and features.

If you don't have a DOS machine, you could try running it from DOSBOX or similar emulator or VM to achieve your desired results.

Good luck! 
Re: Scaling 
I am game to implement this - it shouldn't be much work, and it fits well with the "vid_desktopfullscreen" feature we've had for a while (If you set this to 1, the vid_width/vid_height cvars are ignored when you go fullscreen, it just uses you desktop res.) Another reason to do it is, one of my test machines (Linux) doesn't offer any fullscreen modes besides the native LCD res.

How does this sound, new cvars r_width/r_height, which default to 0 (use window size), but if you set them to something else like 320/240, Quake would render at that given resolution and then get scaled to the window size.

The remaining questions are, if you render to 4:3 but have a 16:9 window, should it be letterboxed or stretched, and should the stretching be always nearest-neighbour or respect gl_texturemode? I am thinking always letterbox rather than stretch if the aspect ratios differ, and always nearest for now? 
Off the top of my head, if I was doing this I'd repurpose the old vid_stretch_by_2 cvar and retain the aspect ratio. 
"The remaining questions are, if you render to 4:3 but have a 16:9 window, should it be letterboxed or stretched"

Imo horizontal letter box is the best option, stretching looks bad. Setting resolution to 320x240 (4:3) and then stretching it to 16:9, defeat the purpose. I guess someone who wants to play in 16:9 in super low resolution will set it to 320:180 anyway. 
would probably be a better resolution. 180 pixels tall is way too low res tbh 
Yeah, I just thrown this as an example.
I think hardware-wise minimum resolution available in modern cards is 640x480, so it will be scaled to closest minimum anyway (or to whatever resolution you have), so you could go with any resolution you like :D 
Weird Bug; Probably Not Important But Somewhat Amusing... 
Something weird I just came across by accident. If you give yourself 99999 (i.e. 5 times "9") health via the console (by typing "give h 99999"), the player's perspective tilts sideways like it does when you die, but you can still keep playing normally.

It doesn't happen when you type 4 x 9 or lower, nor when you type 6 x 9, but it does happen again with 7 x 9 and higher.

Any idea why this happens? Is this a known bug? 
#2706 I Think It's Not A Bug... 
Here is my theory, correct me if I'm wrong:

I think max health you can apply is 32767:
0111 1111 1111 1111

Why not 65534? Because leading bit is reserved for sign, so -32767 is:
1111 1111 1111 1111

Now if you type 99999 you get:
0001 1000 0110 1001 1111

but you can't keep 20 bits so 4 bits got chopped and you end with:
1000 0110 1001 1111

and leading bit is 1 which means you get a negative number of -1695
That's why camera is "broken" and you are still alive(?)

999999 gives:
1111 0100 0010 0011 1111

same story as above, too many bits, so we chop it to:
0100 0010 0011 1111

leading bit is 0 so it's positive, which gives 16959

Here is my theory, correct me if I'm wrong:
You're right.

There are two "views" of health in Quake: the value stored on the server and the value stored on the client.

The server is the master whereas the client is just used for determining if the screen tilts, whether the status bar displays, stuff like that.

So each frame the server writes it's current value for health to the client. The server stores health with full 32-bit precision, which is why movement and not actually being dead still works. The client stores it with 32-bit precision. However, and because saving 2 bytes per client was important in 1996 but bites us in the ass today, it writes it as a 16-bit signed short value.

So yes, it's losing significant bits in the transmission from server to client.

All happens in SV_WriteClientdataToMessage and a quick fix might be to bounds-check what's written. 
Yup, as a quick fix this appears to work fine.

I'm not sure of the utility of having values below 0 or above 999 on the client, because the client only needs to know (1) are you dead, so it can tilt the screen, change the sbar, and not draw the viewmodel; and (2) if you're not dead, what your health is to a limit of 3 digits because that's all that the sbar has room to display.

if (ent-> < 0)
MSG_WriteShort (msg, 0);
else if (ent-> > 999)
MSG_WriteShort (msg, 999);
else MSG_WriteShort (msg, ent->; 
I'm not sure of the utility of having values below 0

Isn't the negative magnitude used for gibbidy giblets? 
Oh "on The Client" 
ignore me 
ignore me

Have more beer. :)

Even if it was an issue you could bound it to signed 16-bit range instead. 
That's great news!

Concerning the stretch or letterbox question, I think there is a way to get around the issue altogether.

Create a console variable like "vid_scaler" which defaults to 1 and determines by which number your resolution should be divided before scaling. For example, you're running quakespasm in 1920x1080 and set vid_scaler to 4, which results in a new resolution of 480x270. The game renders this resolution and scales it 4 times without interpolation, fitting the screen exactly. Alternatively, you could have also set it to 3 or 2 which would give you 3x-scaled 640x360 or 2x-scaled 960x540.

That is the way mark v does it, and it looks really good. Even if the scaled resolution will always be somewhat higher than 320x240 depending on your native resolution, having no letterboxing more than makes up for it. And you could always create a custom resolution like 1280x960 to get 4x 320x240.

That's how I run mark v on my 1366x768 laptop. Since 1366 cant be properly divided by 3, I created 1344x768 for myself which has small black bars but can be 3x-scaled properly from 448x256.

Most people won't have that problem anyways, and doing it this way would also allow you to customize the chunkiness of the pixels to your personal preference. FifthElephant could play on 640x360, given that he has a 1080p display. 
Clamping health on the server message sounds like a bad idea because it assumes the client will never display values above 999 . Network code should clamp to the protocol maximum, display code should clamp to the display maximum. 
Also I agree that scaling only seems to make sense at integer scales so a single cave defaulting to 1 would be simplest for the user. Unless there's a desire to scale different let on each axis. 
Yeah, a single cvar like "vid_scaled" "vid_stretch_by_2" sounds better than what I was proposing 
PS4 Controller 
Hey guys
Apologies if I've missed something - but is it possible to use a PS4 Controller with Quakespasm? I'm using DS4Windows as a wrapper to the xinput. Any known issues?
Using latest version of Quakespasm with the controller .txt addon

It Should Work 
Use quakespasm-sdl2.exe which has xinput support (via SDL2). I have only tested a wired X360 controller and steam controller (in Xinput mode) but both of those worked.
There are some notes on config settings here: 
Xinput SDL 
Just wanted to say thankyou ericw - I wasn't using the SDL exe. Had a great day playing Quake on the couch! 
All my social events will be quake once 4-player splitscreen with pads is on one of the engines. Currently being dominated by Turok 2's splitscreen right now :P 
Split Screen Are For Console Pleb's 
Anon Dipshit 
Some of us have friends in real life and like to play games with said real life friends...

Post with your Nick next time asshat. 
About The Scaling Feature 
I don't mean to be pushy, but is this still happening? It's been radio silence for quite some time now. 
Sorry for the silence, I coded most of it and got sidetracked. Here is a built to test out:

windows build

The cvar I went with is "vid_scale", default 1, set it to 2/3/4 to get 2x/3x/4x scaling.
You have to do a "vid_restart" in the console after changing the scale (this could be improved later to have it live update).

I didn't push this to the main QS codebase yet, wanted to get some feedback / testing first but it seems good to me so far. 
I like this feature... I also turned off basically everything, lerping, shadows etc to get it really old school 
Had a quick look, works well! Screenshots are fubar'd though, looks like it's only screencapping 1/4 of the screen. 
build with fixed screenshots

Glad you like it Fifth - yeah, it seems good on id1 maps with square particles + lerping off. 
now... about that 4-player splitscreen. ;) 
Does this build have spikes weather code included?

I'm really curious as to what "vanilla" quake would have looked like with weather effects. 
Not in this build, the scaling should be straightforward to add to QSS though.

Fifth I know, hopefully at some point (or in MarkV :) 
This Is Awesome 
Seriously thank you so much!

Do you have a paypal link? I'd like to keep my word :) 
@Fifth :)

@Shamblernaut, at 320*200 rain-like effects will probably just look like a few sparkles occasionally.
slow moving comparatively large snow-like particles are probably going to be okay though. note that hexen2 had snow effects too. 
I like vid_scale....would it be a daft idea to hack in support to be able to scale the console and HUD differently to the main scene?

I like the chunky piskels but the screen-filling HUD less so.... 
can't get fte to work properly 
is it still too big with the "scale" slider in the settings menu at the minimum setting?

@boris appreciate it, my email is in my profile. 
is it still too big with the "scale" slider in the settings menu at the minimum setting?

Lolbiscuits, I didn't know about that setting. Seems to fix the issue, cheers :} 
Seconding what Kinn said. I was imagining it implemented along the scr_scale settings like;

scr_menuscale 3
scr_conscale 1
scr_sbarscale 2
scr_vidscale 4

As it is though, with all the scr_scales at 1, vid_scale 3, and scr_sbaralpha 0.999 running at 1920x1080, it looks wonderfully chunky. I'm loving it.

Another way around the screen engulfing sbar would be allowing scales below 1. So a vid_scale of 4 and a scr_sbarscale of 0.25.

I dunno, you're the one coding. Can I get you a beer? 
That would be cool but will probably be really hard to implement.

I think Quake basically runs at a really low resolution that is just being displayed bigger than it actually is, so it would be impossible to have scr_ scalers below 1 since that would require more pixel density than is available. At 0.25 you would need to display 16 different colors in what as far as quake is concerned is only one pixel.

This kind of feature only works if the 3D world and the ui elements are rendered completely independent from one another, so basically the ui would have to be running at desktop resolution while the 3D world runs at a fraction of it.

Can't guarantee you that's right though, just my understanding of it. 
Yeah, scr_sbarscale below 1 would not really work with the current set-up, as you would get pixellated and unreadable status bar.

Having vid_scale affect the 3d view only (drawing 2d UI after scaling) would be possible, main disadvantage is it requires another framebuffer copy (more VRAM use and fps hit), whereas currently I combine scaling with brightness/contrast at the very end of rendering.

On the other hand I can see how the current implementation is a bit confusing with how scr_vidscale is applied on top of scr_sbarscale/scr_conscale/scr_menuscale.

Not totally sure but maybe I'll experiment with the "draw hud after scaling" variant. That is also how FTE and DarkPlaces do this feature. 
Can This Be Fixed?

depending on your aspect ratio and scaler value the console text gets screwed up in a few places. there is usually either at least one horizontal or vertical line somewhere that is a copy of a line directly next to it. strange double dots also keep appearing in some words when typing in the input bar. i checked to see if this happens with winquake mark v scaling aswell, but it doesn't. maybe this problem is exclusive to hardware scaling?

you'll also notice that the console background image is scaled incorrectly (look at the row of holes near the bottom) since the source image is designed to span the width of 3:2 resolutions and is being upscaled slightly to fit 16:9. well, it's actually 683:384 in my case, which is essentially the poor man's 16:9. it's almost unnoticeable without downscaling, but it looks really jarring compared to everything else in scaled modes.

i tried to get around this by creating 1152x768 as a custom resolution that fits my native y exactly to play in 3:2 with letterboxing, the same trick that worked for me in mark v. doesn't work in quakespasm though, it doesn't seem to care about custom resolutions. they don't just fail to show up in the menu either, entering the mode manually into the console just yields the "that mode is not valid in fullscreen" error, even though the resoluton is recognized by the system.

well, since that solution is stupid anyways i'd like to propose the following:

scr_conaspect: 0 is scaled to fit the x of your resolution, 1 is a 3:2 overlay independent from it.

is the amazing ericw up for this incredible task? :)

oh yeah and while we're on the topic of ui related stuff, is there a way to get the sbar centered in multiplayer that i'm unaware of? couldn't find the cvar for that, apparently it's exclusive to mark v. i know it's faithful to the original quake but i'd still like it centered. 
depending on your aspect ratio and scaler value the console text gets screwed up in a few places

This happens because the console text is a single texture with each letter packed tightly against it's neighbours.

When rendering the text with linear interpolation a 2x2 block of texels is selected and a weighted average is taken (note: this behaviour is built into the txture sampling hardware); adjacent texels may be sampled, hence you see some "spill-over" from adjacent letters in the console text.


Always render the console text with nearest sampling. This is what the original GLQuake does but I'm not certain how well/nice it would look with various scaling modes.

"Pad" out the console text by adding a minimum 1 texel border to each character (in practice a 4 texel border will exactly double the size of the texture which may be required for old hardware that requires power-of-two dimensions) with repeated texels from the edges of that character so that the 2x2 sampling will work as expected.

Adjust the texture coords for characters slightly so that sampling always occurs from within the exact character we're drawing; this is what GLQuake does with the little status bar icons which it also packs into a single texture.

Unpack the characters to 256 8x8 textures and draw them individually with clamp mode. This might run slow.

Build a 256-slice texture array and draw them with clamp mode using the character number as the array slice. This runs fast but requires OpenGL 3.0 or GL_EXT_texture_array.

Don't scale them at all and accept having to squint to see them at higher resolutions.

Draw the 2D GUI stuff to an offscreen texture at the scaled resolution then stretch it over the scene to full resolution. Will run slightly slower.

Something else I haven't thought of? 
boristhesp1der, for the screenshot with the double lines, can I check your vid_width, vid_height, vid_scale, scr_conscale?

The way I implemented vid_scale, if the window size is not divisible by the value of vid_scale, it will just stretch the framebuffer to fit and I think you may get artifacts like that repeated line, I should double-check that.

- The "leaking" between characters is an old problem with QS's scaling, it would be nice to fix sometime using one of the solutions mh gave.

- multiplayer sbar centering: not possible atm, someone submitted a patch for it a while ago, and adding it as a cvar sounds good.

doesn't work in quakespasm though, it doesn't seem to care about custom resolutions
hm, interesting. The difference between markv and QS is we are using SDL (cross-platform library) whereas MarkV is coded against windows directly.. so maybe SDL is not noticing custom resolutions.

- re: the console background, by "scaled incorrectly", do you mean the aspect ratio isn't preserved? That seems like a bug. I'm not sure about supporting a narrower console as the UI code tends to be pretty complex / fragile and it may be messy to do. 
1366x768, Vid_scale Is 3 And Scr_conscale Is 1 
And scr_conwidth is 0, don't know if that is the default but it doesn't play nice with scaling.

I don't think the aspect ratio is the problem, it's just how the improperly scaled image looks through a rough pixel grid. the x resolution is what matters here, it needs to be either exactly 320 or a whole multiple of it since that is how wide the source file is. that's just the way it has to be when the image is forced to span the width of the screen exactly, other ui elements like menu and sbar are not affected by this problem since they are free from this constraint. 
I haven't tested the latest QS build, but I play with a 1366x768 res too. I seem to remember that earlier in this thread someone pointed out that this exact resolution is difficult to scale. I'll have a look with 'search' function. My english is really bad in the way I start every sentance with I. 
@brassbite That's Because 1366 Is A Real Bitch 
eric is right, that number is not divisible by 3 so scaling by that factor is bound to cause problems. 1344 is though, real bummer with that custom resolution allergy. :/

just checked winquake again, scaling seems to work differently there. check this out:

both are taken from 1366x768. Quakespasm has the framebuffer line while winquake does not, even though both are scaled 3x to very similar size. background is also differently ugly in both versions, interestingly enough.

by the way, I noticed the reduced color palette in software quake actually changes atmosphere in ad pretty drastically, would like to try this in quakespasm. the color depth option is stuck to 24bit though, is it just there for decorative purposes or can you actually change it? :P 
1366 is difficult to scale in this kind of way, yes.

Basically: 1366 / 2 = 683, and 683 is a prime number so nothing else will divide equally into it. 
#Previous Stuff 
how about black bars? For true 3:2 or 4:3 those are needed anyways? 
I've Always Wondered Why It Even Exists In The First Place 
Apparently this is why:

"The basis for this otherwise odd seeming resolution is similar to that of other "wide" standards � the line scan (refresh) rate of the well-established "XGA" standard (1024x768 pixels, 4:3 aspect) extended to give square pixels on the increasingly popular 16:9 widescreen display ratio without having to effect major signalling changes other than a faster pixel clock, or manufacturing changes other than extending panel width by 1/3rd. As 768 does not divide exactly into 9, the aspect ratio is not quite 16:9 � this would require a horizontal width of 1365.33 pixels. However, at only 0.05%, the resulting error is insignificant." -Wikipedia

yeah that's what i was trying to do with custom resolutions, for us those are 1152x768 and 1024x768. the latter is included by default but the other is not. i personally find 960x768 more interesting than 1024x768 though, it is not true 4:3 but is a whole multiple of 320 in width which means the sbar fits the screen exactly with 3x scaling. 
When Is The Scaling Feature Official?/ When Is The Next Official Build 
I tried downloading the testbuild for the vidscale feature but the link is broken. error 502 
Did a bit of experimenting..

Yeah, 1366 = (455 * 3) + 1, so with vid_width 1366 and vid_scale 3 you'll get mostly 3 pixel wide columns, but one column 4 pixels wide. For me it's right in the center of the window, and pretty difficult to spot..

However I think I see why the console looks so bad.. it's a case of doing nearest-neighbour scaling twice. The actual size that everything is rendered to is 455 pixels wide, which is a poor fit for a 320 wide console background. Then it's scaled up ~3x to 1366.. so all of the scaling errors are magnified 3x. If you do nearest-neighbour scaling from 320 directly to 1366, the artifacts are much less ugly. So this may be a good argument for changing vid_scaled to affect the 3d view only.. hm.. 
Yeah That Must Be What Mark V Does Differently 
when you look closely there is a hairthin line at the right edge of the screen where the desktop is peeking through. it sorta just pushes the problem away instead of dealing with it.

seems like our displays have digital down syndrome :(
here's the link:

@ericw how are the video modes determined? can you just change what it makes available to you by default in the source code or does it depend entirely on the system it's running on? i agree with brassbite, simply being able to set an aspect ratio to get a resolution based on your native height would be very useful and evade the problem alltogether. 
brassbite: sorry, the link in #2727 is fixed.. my server went down for some reason. When it's official: not sure, I think I might try redoing it to only scale the 3d view, as this will avoid the ugly artifacts on the conback / console text that boris reported.

@boris, regarding color depth, on some systems (usually old hardware / OS'es) Quakespasm will let you select 16-bit color in the video menu. Rendering to the quake palette would have to be coded explicitly, probably as a postprocessing effect. Can't promise it'll happen but I agree it would be a cool option to have aesthetically. 
Formula Reversal 
You are looking for a pixel magnification factor, but are instead inputing a pixel division factor.

Division doesn't naturally lead to an integral scale, and since a screen is 2D it may lead to situations where a number works for width but not for height.

i.e. scr_conscale magnifies the console
i.e. Sounds like you are using vid_scale to divide the resolution rather than magnify the pixels.

scr_conscale 2 in FitzQuake doubles the size
But you have vid_scale half the size.

If I am making any sense.

/Scaling is always enjoyable to work through and satisfying upon completion. If you like math problems. The auto-scaling HUD in D3D/GL uses magnification factor.

Like always, one opinion -- probably wrong.

There are different ways to do scaling, anyway ... heheh ;-) It is more important to enjoy doing it, than which of the various methods you decide to employ. There are lots of scaling methods and no right or wrong ways. 
i don't get it. how is magnifying helping the situation compared to division?

they way i understand it is that we have an image that is 320px wide, and we need to scale it to fit on a screen that is not a whole multiple of 320px in width. no matter whether you divide the resolution by a whole number or magnify the source texture by that number, it should be impossible to have a proper result.

let's take my case as an example, which is having 1366 horizontal pixels available. i created a custom resolution of 1344 to be able to divide by 3, which means i am now rendering 448 pixels that all occupy 3 horizontal pixels on my screen. otherwise i would have 455 x 3 + 1, but that doesn't affect the problem and just complicates the explanation.

now we need to display the console in a way that fills the entire width of my screen with 448 pixels available in that direction. this cannot work because the next whole multiple of 320 is 640, not 448. that means only 448 of 640 pixels can be displayed and 192 can not, resulting in an image where most pixels are being displayed at full size but some are displayed at half size.

do i have an error of thinking in that? if i don't, i can't see why magnifying would help since it is affected by this problem in exactly the same way.

i also tested 1280 which is a whole multiple of 320 in 2x and 4x, and both display the console properly.


can you take a look at this?

i would really like to play with 4x scaling, even though my display technically doesn't meet the requirements for that. the text in the menu gets scrunched up since it's running out of space, but this could be fixed by splitting the menu into two pages. is that something you can change? would be cool to have it automatically detect whether enough space is available and switch to split mode if there isn't, but having a cvar like scr_menusize is also fine.

there is also another problem outside of the menu, the text messages are affected aswell (look at the u and r), even though they have more than enough space available. the text in the map info is being displayed properly, which leads me to believe that fixing it should be possible. right? 

i was wrong, apparently there is something else going on. 1280x720 looks almost right, but not quite. the aspect ratio has an effect on how the texture is displayed, it needs to be 16:10 or else it gets stretched vertically even if the horizontal resolution is fine. 1280x720 is so close to 1280x800 that i didn't notice the artifacts at first glance. i don't understand why it's doing this though, the source file is tall enough that stretching shouldn't be necessary.

is it a bug or is this behavior intended? 
I started a rewrite of this yesterday that just scales the 3d view, and it's a lot cleaner as far as the code, and will avoid all of the UI scaling issues (at least, not introduce new ones :). So you'd be able to set "scr_viewscale 4" but "scr_conscale 2", etc. I'll post a build as soon as I fix a few things.

Baker, yeah this has been fun. :) I think I see what you mean, the naming is a bit strange for "vid_scale 2" - it does scale up by 2x, but also shrinks the rendered area by 1/2 at the same time. 
new build to try

Cvar is now "r_scale", and it only scales the 3d view, so you can adjust it independently of the console/menu/sbar scale 
Nice one Eric! :) 
Great Job Dude 
this fixes pretty much everything, i can even play on 1366 instead of 1344 now. you da man! :) 
Thanks for all the feedback & testing 
I'm assuming you figured out everything ;-)

And it sounds like you got the reward of the "Aha!" moment. 
A Different Way You Could Have Done It ... 
Use metlslime's oldwater method or what mh does for GL waterwarp

1. Calculate magnification factor + virtual resolution
2. glViewport 0,0,virtual screen width, height
3. eglCopyTexSubImage2D to capture that area
4. Maybe glClear the texture buffer if you aren't drawing full-screen, although there are ways to avoid this step entirely.
5. glViewport 0,0,real screen width, height
6. Render the texture captured but now to the full screen

Now draw the 2D like normal. No shaders. Maybe 10 lines of code. 
I think that's close to what I ended up with, here is the full patch:

No shaders, I think it only needs GL1.1. 
Did You Read #2754 ? 
i understand if im getting on your nerves with my questions and requests, and i sure as hell don't have the same technical knowledge like you two. but i do care about this stuff a lot and would greatly appreciate if you at least explain to me we where i'm wrong. seriously, i have huge respect for what you're both doing and try to learn from talking to you.

if you don't like the pitch about splitting the menu into two pages that's ok, i have a better idea anyways. the reason behind it was to allow for proper ui scaling for aspect ratios wider than 16:10, but there is something less invasive that can be done to display at least 16:9 properly.

as of now the text messages and menu are not being scaled all the way to 4x in 16:9, even if the cvars accept that input. the console background also gets screwed up but that has to do with something else.

i made some mockups showing how it should look using 1280x800 as a reference. for the text message you can see that there is more than enough space availabe, but the way it is being scaled is governed by some rules that should not apply when scaling to this extent. seems to me like there is an invisible frame around it that is not wide enough to fit the message at 4x, so the scaling is reduced to a number between 3 and 4.

the sbar is not affected by this rule, which means the text in the tab view is scaled properly, giving you a direct comparison in image 1.

the same thing is happening with the menu, only difference being that there is much less space availabe. as you can see it's still enough space to fit everything important on screen however if you were able to remove the frame restriction. proabably a good idea to change viewsize to 120 when entering the menu so the bottom of the options is more readable.

the console image probem is slightly different, i think it is just being scaled according to aspect ratio when it shouldn't be, causing it to be stretched vertically. this is even worse at 4:3, where it defintely shouldn't happen since quake was designed for that aspect. 
quake's minimum resolution is 320*200, so 16:10, not 4:3
(320*240 won't fit inside a single dos segment, and is NOT a standard VGA resolution, you need SVGA for it, on the other hand 320*200 is _the_ VGA 256-colour mode)
the conback.lmp is 320*200 as a result of this.

I don't know of ANY quake engine that preserves the conback aspect correctly - not even software rendering will. the only real way to do it is via letterboxing, and even then replacementtextures will generally expect some other aspect (like 4:3).

really, perfectionism here is a lost cause. you'll either need to pad (with more rendering/drawfills, or with letterboxing), or use funny sized pixels. just make sure you never consider ONLY the height nor ONLY the width. 
no worries, it's great to have your feedback.
I did see #2754 but I wasn't sure how much of that was caused by the first "vid_scale" implementation.

For the text messages (centerprints like the "Arcane dimensions 1.5 update" one), the thing to remember is they can get quite long, like in this discussion a while ago about dealing with a long episode end message (from "Rapture"):

I think you're right that there is an invisible frame around centerprints; since QS always uses the same scale factor regardless of the message length.

Anyway I'll need to do some testing to give a proper reply. so just to double check, I should test 1280x800 with all of the scale factors set to 4x? 
@spike (and also baker and eric)

yeah you're right, i worded that poorly. i know it was originally designed for 16:10 and also about the dos thing. you can really only play those games at 960x600 if you're bound to a 1366x768 display, everything bigger than that will have inconsistencies of some type or another.

what i meant was that 4:3 is an aspect ratio that was actually a thing in 96 in contrast to 16:9 and is supported in the original winquake options menu. it is something that should work properly since it is not an afterthought like 16:9, even if it doesn't. i don't blame quakespasm for that, but i do think it would be cool if it was the first engine to not have this shortcoming :)

the thing is that displaying the console properly shouldn't be a problem, right? my mockup proves that at least from a non-programming perspective, but is it really that hard to just not have the image aspect "corrected" and leave it at 16:10? all i did was copy the console from a 1280x800 screenshot and overlay it in 1280x720 stopping at the same height, which makes it look way better.

i don't get the part about considering width and height separately being a bad thing and this being a lost cause. why does the height matter here? i can understand stretching the image if the source file isn't tall enough, but it is. it would be a problem if the source was 16:9 and we had to make it fit on 16:10, cause then the height does fall short if you want to display the image fullscreen. the only "problem" i can think of is that a little bit of the top of the image can't be displayed since it will be over the top boundary of the screen, but that is not nearly as much of an eyesore as the distortion. you also don't have to look at the top of the console nearly as often as the bottom. the top not being visible is part of the console anyways as far as im concerned, like a theatre curtain that is falling down and lifting up to different heights.

i agree that this is pretty hardcore perfectionism, all the devs and especially eric (since he's also acting as somewhat of a community manager) have done a fucking fantastic job with quakespasm and it is in a pretty great state as it is. but it's not perfect.

feel free to tell me to stop asking if you don't care about this level of perfectionism. seriously, i can totally understand that. it's your time that is being taken up developing after all, and i really don't want to get on your nerves. i swear i'd code this all myself if i could. i am learning, but it's a slow process for me and i'm and nowhere near the level you guys are at. it would probably take me years to reach it since i just lack the deep insight into quakes and opengls inner workings as of right now. i'm sorry if i'm abusing you to code my ideas, but it's just really great to see the things i've been wishing for actually become real, even if i didn't do the dirty work myself.

for me personally it's just fun and maybe almost therapeutic to get quake into a state where nothing nags you in the back of you head. even if the text and menu scaling thing is far from catastrophic from a sane point of view, having it fixed and being unable to find any visual inconsistencies just makes playing it infinitely more enjoyable to me. and i really do love quake, it's pretty damn important to me as far as games go. i just never get sick of it, especially since i got into arcane dimensions.

regarding the testing, 1280x800 at 4x worked without any problems for me. i think they only scale up to 3.6 or something close to that on 1280x720 as of now. same goes for the menu. would be awesome if you did find a way to fix it, i promise i'll stop asking for any more stuff after this :P 
@boris- Get A 4:3 CRT - They Are $20 
Here is a $20 CRT they are selling on EBay:

Then you have 4:3 CRT like when Quake came out. 
Option #2 
In the Arcane Dimensions folder, there is conback.lmp which is the console background.

You can open this in the Quake image editor fimg.

Edit it how you like, then save it. 
i think you might have skipped a few lines if you got the impression i actually want to play on 4:3. don't blame you, its a big wall of text. i'm no good at keeping it short. read #2764 if you want know what i actually wanted.

thanks for the idea with fimg though, i guess that's the manual way to do it. 
I just took some screenshots of extreme resolutions that maybe illustrate the reason behind the current behaviour: (it looks like the conback is just scaled to fit the window width/height exactly, then it's scrolled up).

Also note that when you start a new game the console starts fully closed and then opens all the way up, so it would be weird if it used a different stretch factor when half open. 
yeah i get why it's done this way now, avoids a lot of potential problems. my idea wasn't to change the stretch factor but rather just not stretch anything at all and instead align the texture to fit the bottom of the screen and overshoot it at the top, as if it were dropped down a bit by default. stretching should only occur when it is necessary, which it is only for aspect ratios narrower than 16:10 so you don't end up with a hole dropping down from the top of the screen instead of overshooting it.

that's the way i'm gonna try to code it for myself as soon as i figure out how, but right now i think i'll stick with baker's idea. this change probably doesn't justify the effort on your part and could cause a lot of unexpected problems down the line, and i don't want you to have to deal with that because of me. you've already done a lot :) 
I'm Only Happy When It Rains 
Is that software? Amazing. 
Is that sock's unfinished AD map?
Did he finish it? 
Qmaster, yeah it's sock's map, it's not released yet though. The screenshot is in QS_Spike with the r_scale cvar. 
I Love Sock's Maps 
can't wait for sepulcher, that screenshot makes it look badass.

@eric i saw your name in the credits for tfuma, which is actually my favorite of the bunch in ad. it feels way more interactive than the others and is probably the best looking map using the base style ever created. giant robots are also a plus.

how did you and gavin split work on that map? are you responsible for the ambush at bottom of the slime pit? :P 
looking at all these screenshots i'm imagining a alternate past where this shit was all vanilla. 
Transparency Depth 
Is there a way to get multiple transparencies to overlap properly? If I have 3 transparent brushes overlapped, the engine treats them as see through. Maybe there is a bug when the alpha sum is greater than 1.0? Using water alpha of 0.4 and *glass textures. 
Winquake Style Weapon Draw 
is there a cvar for it? 
for a quick fix, "scr_ofsz -2" (haven't done proper testing to pick this but it seems close-ish)

We really should add a proper toggle.. I can't stand the SSG hiding completely behind the status bar. 
That Seems Close Actually 
Is there any way of having QS having strafe work more like Mark_V and Winquake?

Currently the strafe value feels far too jerky. It's easy to tell the difference between QS and Mark_V/Winquake by holding forward and then hitting strafe left/right.
QS seems to allow too much travel sideways when going diagonal. 
@Qmaster, I Feel Your Pain 
Proper depth peeling in quake is rare. I hope that it becomes less rare in the future :( 
Has Quakespasm got original Quake movement, or has Mark V got the 'real' movement? Or none of them? 
afaik the only thing QS changed is it made "always run" equivalent to holding the run key, whereas in winquake, "always run" is slightly different (I think?)

Fifth, did you have "always run" on when comparing QS/MarkV/Winquake? were you holding shift/run? 
A Work Around. 
I made a slight change to this in my source, allowing the player to bind capslock to commands (in this case +speed).

That way if +speed behaves differently to "always run", any differences can be mitigated by using capslock.

(of course the frustrating thing with this is the console is case sensitive for most commands) 
I use always run.

The QS implementation is basically like holding shift to run. You are correct, using always run is a different feeling to holding shift (even in Winquake).

Not sure if this is a bug. It would be nice to have an option to have this operate more like Winquake. 
It would be nice to have an option to have this operate more like Winquake.

cl_forwardspeed 400
cl_backspeed 400
... in autoexec.cfg. 
Quakespasm Realms Not Saving 
I'm playing through on NM and my realm progress isn't saving, using latest version of Quakespasm. Is this a known bug? 
Hi Quakespasmers. I stopped by here because someone mentioned a "Beef Thread." I didn't know there was a "Beef Thread!" So I decided to go look for it, but I stopped in here too.

I see FifthElephant is asking about the "Always Run" thing being different. I actually made a post about this on my FvF forum which goes into detail describing WHY it is that way, so I thought I would post a link here for those who are interested (especially for FifthElephant, because he is my BESTEST buddy! >:D Hi FifthElephant!) 
It's Completely Preference 
After playing Quake for 20 years I am used to the default behaviour. Maybe it isn't in the design goal of the engine and an option wont be included.
I find strafe jumping harder in Quakespasm as the movement is too sudden and jerky. 
I think I may have suggested in the Mark V thread that "Always Run" could be made to have 3 different settings in the menu: OFF, ON, and ALL.

ON would be the standard old setting that doesn't affect side speed, for people who have just gotten used to that.

ALL would be doubling the movement in all directions, including the side speed.

Unfortunately, Mark V changed it so that "Always Run" is ON by default, using the old method that doesn't affect side speed....

I dislike that settings, but could always just ignore it -- I prefer to be able to sidestep really FAST to dodge those rockets. But changing the default so that it's ON is just awful; now I have to make extra settings just to get back to normal. (Yeah, I've complained about this in the Mark V thread already, heh.)

But perhaps Quakespasm would be interested in my idea of 3 different settings for the menu option, for people who prefer it the old way. More user control is usually a good thing, even though I really, really like the way Qspasm has implemented "Always Run," with the full speed in all directions, and having the +speed key still be useful to toggle you to a slower pace. 
Omnipresent Bmodels 
What is it with Quakespasm that makes it draw certain brush models regardless of their actual visibility - always and on the other side of the map, even from the outside. Unnecessary triple digit epoly boost.

What's going on and how can I work around the system? Check detail1.jpg from my post in the Tyrutils_ericw thread as an example: the square things in the bottom right corner. Originally, there were some columns in the back of the map as well, but I had returned them to world geometry already. 
Sounds like it's just the "brush model in too many leafs" fix.

Note that because QS uses VBO drawing and draw call batching poly counts aren't as relevant. 
that's the "flicker fix" we implemented. QS's MAX_ENT_LEAFS is 32, so I think the way it works is if an entity bbox spans more than 32 leafs, the server will make it always visible rather than potentially flicker.

Workarounds would be simplifying world geometry where the bmodel is or shrinking the bmodel. 
Or Splitting It Up Into Multiple Bmodels 
When this problem really came forward in community consciousness ( I had just recently fixed it by dynamically recalculating visibility for each client, for each entity, each frame. That was effective (it wouldn't have pulled large bmodels into the PVS all the time) but caused hugely excessive CPU load.

It turns out that in this case just drawing it anyway is a more efficient approach, at least for hardware-accelerated engines (the point I made above about r_speeds counts not being so relevant to a properly-optimized renderer can't be overstated enough). 
Jpg Screenshots? 
Might be a good feature? It's really annoying to convert from tga... 
Though Png Might Be Good As Well... 
+1 For PNG Screenshots 
I recommend LodePNG
Yeah Agreed 
I am always installing GIMP or using imagemagick to convert to png, it's a pain.

I'll try to look into a cvar for the classic behaviour of "always run" before the next release.

@boristhesp1der (late reply!) glad you liked tfuma, Fifth built the majority of the map and I took over finishing gameplay and routes, w/ contributions from sock. I did set up that slime pit fight :) 
Ideally PNG & JPG 
But for most web stuff you need JPG-compression, and for the rest TGA is mostly not a problem. 
JPG is not really "needed" for web use, it just the most common. Many times it gets used when PNG would be the better choice.

I always wondered why Quake used TGA, which is an obscure format and pretty much obsolete now.

Even if its improved capabilities aren't used, I think PNG is the best choice, but for in-game screenshots JPG is probably fine as long as the compression is low. 
The code to write TGA is pretty simple, that might be why. Or maybe it was compatible with other software they used at id at the time. 
Simple and fast. PNG with compression will take longer. It will freeze game for a second.
Of course I'm just speculating. 
I Prefer TGA Actually 
I prefer to start with uncompressed images. It's easy enough to convert quickly with any number of apps. I use something similar to this:

@metlslime id was most likely was using Truevision video accelerators in their Windows machines back then. TGA was originally from Truevision. 
PNG Is Lossless 
Software Quake used PCX. Because that was an 8-bit renderer it was also just a simple matter of "dump the pixels".

According to Carmack's .plan file ID were using Intergraph accelerators on NT as their graphics workstation platform of choice at the time GLQuake was written.

PNG format didn't even exist when Quake was released. First release of PNG was October 1996.

TGA offers simplicity and speed, although nowadays with disk IO being the primary bottleneck for many operations a compressed format may well be the faster option, at least until SSDs go cheaper than spinning plates of rust. 
I prefer to start with uncompressed images. It's easy enough to convert quickly with any number of apps. PNG has lossless compression. It's like ZIPping TGA, but in one operation. It is easier to preview and maintain. 
Got it. Obviously PNG would be the most handy format at the moment especially for immediate sharing. I take the previewing aspect for granted as I have the aforementioned shell viewer/converter and Photoshop. 
JPG is not really "needed" for web use, it just the most common. Many times it gets used when PNG would be the better choice.

Read about how those compression algorithms work and when they're appropriate to use. 
Quake screenshots are not a good case for png, but are OK for jpg. 
Quake with texture filtering off is a bad case for JPEG, though. JPEG is also a bad choice if you want to make brightness adjustments afterwards, especially extreme changes (something I often do when I get screenshots of lighting bugs.)

Ideally JPG, PNG, TGA would be available. I think MarkV can do those and has a cvar to pick the format. 
aye, jpeg sucks. you can reduce the compression to get something close to png, but doing so just increases the filesize too. if you've got high res textures (which frankly just look like noise in the first place) etc then jpeg can't make it any worse, but otherwise imho png is a better choice than jpeg at least for a default setting.

(windows) bmp might work if you want something more equivalent to tga, its basically just a different header but much better supported (at least on windows and except by quake engines). it can also be paletted, and doesn't need extra libraries.

but png is best if you're going to shove it on a website (and why take screenshots if not to share them). 
The problem with BMP is that each row must be a multiple of 4 bytes, so for odd resolutions like 1366x768 or if you want 24-bit data you can't just fwrite the output from a glReadPixels. 
Open the source code for JoeQuake. There are 3-5 headers. 1 cvar. Link libpng and libjpeg. Call the appropriate function to write a png or jpeg. 30 minutes tops. 
Guyz, Check Out This 8mb PNG Shot Of Some Nondescript Area In My Map!! 
Well okay, TGA isn't particularly small, either... 
doesn't matter what the engine writes out, you should convert to jpeg before uploading it. 
Case In Point 
doesn't matter what the engine writes out, you should convert to jpeg before uploading it.


If I wanted to highlight something like a conchars font with different filtering and scaling options I'd leave as PNG. 
JPG was created for photographs. If an image is not a photograph then JPG is probably not the best format. In particular, JPG is a poor choice for images with large areas of the same continuous color, such as many web page graphics.

JPG is not intended for images which will require additional editing, but for an in-game snapshot is probably fine. The option for a higher quality image would be good to have, but I would not consider it a necessity for a game. 
Stack Overflow Bug 

While playtesting a map I'm working on, I got a stack overflow bug: First, I pick up the quad damage, enter the door to the left and then aim somewhere between the Enforcer and the radioactive container in front of him. I could fairly reliably get the following stack overflow:

CALL4 1705(T_RadiusDamage)T_RadiusDamage()
misc.qc : barrel_explode
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
combat.qc : T_RadiusDamage
misc.qc : barrel_explode
combat.qc : Killed
combat.qc : T_Damage
weapons.qc : ApplyMultiDamage
weapons.qc : AddMultiDamage
weapons.qc : TraceAttack
weapons.qc : FireBullets
weapons.qc : W_FireShotgun
weapons.qc : W_Attack
weapons.qc : W_WeaponFrame
client.qc : PlayerPostThink
stack overflow
Host_Error: Program error

The map can be downloaded below: 
I've reliably reproduced this too.

Increasing MAX_STACK_DEPTH in pr_exec.c to 64 is sufficient to resolve; a lower value may also do but I didn't bother testing.

It's caused by a large amount of exploding boxes in close proximity setting each other off. 
I remember running into this issue myself once many years ago. I was under the impression it's simply a common Quake bug/limitation, but I can't seem to reproduce it in Winquake/GLquake using Esrael's map. Does it occur everywhere or is it actually something introduced in and carried over from the Fitz code? 
It's a hangover from the original ID code.

You need to be very specific about this because it's the chain of effects that sets off the stack overflow. Hence you need the Quad and you need to be in the very specific situation where there are 6 or so exploding boxes in close enough proximity.

You shoot near one box, the Quadded shotgun explodes it, it triggers the next box to explode, which triggers the next box, and so on.

Each explosion is 4 function calls: barrel_explode for the explosion, T_RadiusDamage from he explosion, T_Damage to the next box, then Killed which kills the next box and in turn sets off another barrel_explode.

Removing one of the boxes should be sufficient to prevent it ever happening.

I also have engine code somewhere that effectively gives you an infinite stack (at least until you run out of memory) which would also more robustly fix this and other similar issues. 
findradius is just all kinds of evil. its possible for exploboxes to be skipped entirely too, depending on how .chain gets clobbered by the different explosions.
Frankly, calling T_RadiusDamage inside Killed/.th_die should be considered a bug, fixable by delaying it to a think function. This also fixes the above crash, too. 
Bad QC, Not Engine Fault 
While playtesting a map I'm working on, I got a stack overflow bug ...
This is a bug in QC that happens on anything with a call to a radius explosion function within a death event.

This is why tarbaby.qc (line 172) delays the explosion to the next frame. So that you cannot get a chain effect and stack overflow.

The misc.qc - barrel_explode function is broken. It should delay the radius explosion one frame and it would be fine. I fixed this in AD QC if anyone wants an example of this. 
This Guy^ 
But yet ID1 progs does it. If ID1 does it, is it still a bug? 
... yes?
findradius cannot reliably be used recursively like that. there are other symptoms than just the stack overflow.

is it time for eg quakespasm to throw a new progs.dat into its .pak?.. 
Progs.dat Is More Fragile Than Commonly Believed ... 
Some mappers use extremophile abuse of functions (see Teaching Old Progs New Tricks).

There are plenty of maps that use "BecomeExplosion" and an array other nuances in the original progs. As a result you can take a map like dm3rmx and run in, say, ezQuake which supplies its own single player progs that was written more efficiently and then it goes to console with a QuakeC error when a tricky map calls something by name that was written in a slightly different way.

It is quite possible to make a cautiously "improved" progs.dat that breaks existing maps.

Situation where the progs.dat is the worst possible progs.dat except for all the improved ones where some of the "bug fixes" and "code cleanups" are not bug fixes but bonafide behavior changes.

It used to be common for a number of QuakeC coders to have their own "cleaned up and better" progs.dat. I have seen the source to about 10 of these from the original CleanQC to ScratchQC to public ones coder [insert coder X, coder Y, coder Z] made for a QuakeExpo and such.

I have not seen one without random arbitrary behavior changes, although sometimes it is incidental, but most of the time it is apathy or indifference.

Often the guy that only knows deathmatch breaks something in single player, the guy that only knows single player breaks something in deathmatch, or someone corrects a "bug" by breaking something not important to that coder or "fixing" something that shouldn't be fixed or that they didn't understand is a behavior change.

It also doesn't take much to make save game files incompatible with an "improved" progs.dat.

(No I haven't looked at the source code for gnounc/jonas 1.01 one so I wasn't referencing that one anywhere above. Can the 1.01 version load a real Quake progs.dat save game? I don't know.)

/Possibly preventing rarely known issues. But it was boring typing that. 
It also doesn't take much to make save game files incompatible with an "improved" progs.dat.

Like what, any example? 
Agree With Baker 
imo the right place to fix this is in "clean qc"/"bugfixed id1 progs" type of mod.. and maps that need the fixes would target that mod 
he means different precache_model+precache_sound calls, which is why dp+fte+qss save the sound+model precaches into the saved game.

Next Baker will be arguing to leave all the segfaults in... 
if its so important that everyone have the exact same progs, then maybe quakespasm should include a copy of progs 1.06 for all those people with cd versions that came with 1.01

throwing in some extra things that mean we don't need more absurd+awkward function hacks can only be a good thing. 
My monster randomizer for the speedrunning community breaks the save files... and breaks it hard. 
Now I wonder what code have you added :) 
Looks like I had stirred up quite the discussion touching on the very fundamentals on what to fix/improve/modify and where.

How about I just remove that one explobox from my map to remove the stack overflow, and we all forget this ever happened, shall we? ;D

But in all seriousness, it's good to have this discussion. Seems there really is no clear-cut right answer for it. @~@ 
Start a map, pick up some guns, shoot some monsters leaving some alive, open some doors, turn on some lights and save.

Now open the save game file.

Look at the monsters and the doors, etc. in the save game file.

Now realize if you change the names of any of that stuff in your progs, it can't load that save file.

Go to the Teaching Progs New Tricks thread, realize if you rename any of that stuff or rewrite how it works, any of the maps using those tricks are now broke with your progs. 
Ahh, ok. Just opened saves and now I see what you mean. Idk why I never opened Quake saves. I probably thought they are binary...

So if I keep names intact and just add new stuff, it should work just fine. Only problem with this approach might be when there is a new field added to some entity and it's not available in save file. This field will become null or empty after loading. 
Exactly. Breaking things would simply be normal. Someone would have to set out to deliberately not break things.

Adding fields? Well, now you are making a mod, not bug fixing the original progs.

Makes as much sense as saying "Hey everyone! I created an different flavor of vanilla ice cream!"

If you see my point. 
Adding fields? Well, now you are making a mod, not bug fixing the original progs.

Yes, I was thinking more about mods compatibility, so they don't break vanilla behavior etc. That's why I was curious about saves.

But speaking of vanilla patching, I agree, it needs to be made carefully, with lots of testing and solid code review, with attention to backwards compatibility.

It might be a little tricky to refactor vanilla progs, but there are many smart guys in this community, so I'm optimistic :)

What causes this "Host Error" ?

Im using the newest version that was released with ad_sepulcher 
that is "quakespasm-spike-admod"

it works fine in "quakespasm-spike" 
Incompatibilities With AD Mod 
I got a few instances of older maps that don't load with the AD1.6 mod. In their case, I got some Host errors. Loading them with the ID's default goes well, though.

I wonder what may brake some maps with the AD mod ? 
Spike FX In Other Mods ? 
The spike FXs from QuakeSpasm-spike-admod are working great with AD1.6. But AFAIK, these new FX aren't dependent on AD, and yet I don't have them when loading any other mod.

Any other players here are able to get the FX with other mod, and not just AD ?

If so, how could I turn on the FX with other mode ? Is there a special command for that ? 
AD does NOT support quake maps designed for other mods and maps that use map hacks, it makes no sense loading a quoth map and expecting it to work.

Even maps designed for vanilla progs can break in AD, due to maphacks/unconventional mapping features.

Same applies to the Spiked FX, each entity has to be specifically setup to support it.

So, in short, no, there is no easy command to make it work for older maps. 
Sorry, not sure.. I tried running a few quoth maps in quakespasm-spike-admod and couldn't reproduce. Does it work in regular quakespasm? 
if you want QSS to load up some custom particle effects then you can name them via the r_particledesc cvar.
eg place into id1/particles/high.cfg and set r_particledesc high and it'll use those particles.

If you want to use particles made for DP, you can set r_particledesc effectinfo[_foobar] which instead will load id1/effectinfo[_foobar].txt in a manor compatible with DP. This is effectively what AD does, except AD names them via ssqc (which then causes the client to load them as needed).

Some of the other things that AD has (like flame particles) is done via the qc itself. You may be able to replicate such effects via a particle config with the r_effect command (which attaches particle effects according to model), but the result is unlikely to be identical. 
I got it working in quakespasm-admod. just quakespasm-spike-admod that im having trouble with. :shrug: 
Thks Spike 
When I start Quake with the AD mod, I can start any custom map in my ID folder and get the special FX. They are all working great. I would like to get the same effects while starting Quake with the default ID too, without having loaded AD.

So what file should I add to my ID folder ? It's not clear to me. 
Come on dude, Spike said:

place into id1/particles/high.cfg and set r_particledesc high and it'll use those particles

1) He gave you the link to the file
2) Says where it goes
3) "r_particledesc high" is what you type in the console. 
Spike FX In ID 
Well ok, I placed that high.cfg file into a new "particles" folder, and typed r_particledesc high. It did worked somehow, but the effect is really not the same as running from AD.

Also, I got this error message in the console :

Unknown particle command "cl_expsprite". 
AD has extra effects coded into the game logic, the same way it has extra monsters coded into the game logic and optional floaty particles. So it isn't going to be the same no matter what you do.

But that config Spike provided will give you something. 
Grab the effectinfo.txt file from ad and shove it in id1 or whereever. set r_particledesc effectinfo.
that'll get you as close as is easy to do. As I say, it won't affect torches or anything the mod does explicitly, like the teleporter effects or the skill pillars, or the pentagram effects etc, but you should get the blood trails and weapon effects. 
Yep, this appears to work now, but I also had to copy all the files from the AD particules folder :


I didn't tested yet which files actually does the trick, and which one could be removed from these above.

It's very sad that we can't get the same for the torches as well. It's so cool. 
Apparently, I just need these in the particle folder :


The lava balls also use the FX. 
My balls also use spike fx.

Glad to hear it does somehow work nevertheless, what a ride. 
Reflexion On Liquids 
Is it possible to get reflexion on water surfaces and blood liquids in QS ?

Is there any technical problems/issues/constraints that don't allow reflexions in Quake with our engine of choice (i.e. QS, that is) ? 
Upgrade To Source Engine ! 
#2863 Barnak 
FTE has a 'recursive' renderer, that is it can deal with rendering another scene half-way through rendering the first. This is what gives it the ability to render reflection+refraction textures as needed (or q3-style portals etc).

I believe DP builds a list of surfaces and then only draws them after or something. I'm not entirely sure tbh, I've never found DP all that easy to read.

Either way, the point is that there's no fundamental reason it can't be done, just that doing it is messy, and really not the sort of thing that would be considered QuakeSpasm's forté.
Quite frankly, if you want that sort of thing then just use FTE(with r_waterstyle 3 or so) or DP(with 3rd-party per-texture shaders) instead, those two engines already cater to such stuff anyway. 
I already tried other Quake engines on my system before, and in my opnion they sucks.

QS is the best engine ever created for Quake (especially now, with all its great features and your FX).

I would only like to see some more subtle FX in it, but certainly NOT high res textures with bump mapping ! It's horrible in Quake and extremely heavy on the video card. Solid objects and matter should stay low res in Quake.

However, I think that all fluids, smoke, fire, skies could be great in high res, while still having solid objects in low res. I love your FS styling. The liquids could have a subtle reflection/refraction styling too. Not something ultra-realistic, but something that would add a liquid feel.

Please, could you post more pictures of your testing on liquids that you already showed before ? Why it isn't in your FX QS edition ? 
Basically, what you're saying is that you don't want bumpmapping, and yet you want to simulate bumps on water...

If someone actually wants 'FX' then they should just use FTE. I'm not going to waste my time rewriting lots of code when they can just switch to something that already excels at that sort of thing.
Yes its defaults tend to be more for deathmatch players, but you can configure it to feel exactly like QS if you want. fps_preset vanilla;r_softwarebanding 0; will do most of it.

So really, what specifically is it about FTE that you think sucks about it? Or is it just you/others being too lazy to set it up like whatever engine they're already familiar with? 
Hehe, Bump Mapping Is For... 
... simulating depth on low poly surfaces, hey... kind like what Quake is!!!

I think if done in moderation, just as with colored lighting now, higher res textures, with effects, look really nice. 
I'm not asking for bumps on water (heh !?) ! I'm asking for some gentle reflections and refractions, which aren't the same as bumps (i.e. false 3D textures).

As I said, I already tried all the other Quake engines available for my OS. I didn't liked them. Too slow, too heavy, and the rendering was, well, ... ugly.

And yes I'm too lazy to lose my time in trying to tweak their configuration. I'm just too attached to QS, which is *almost* the perfection.

Spike, come on, show us again your work on water. I think it was pretty, but I don't remember how it was ! 
Just what for mankrip to finish his Retroquad engine. 
What you're missing is that adding reflection/refraction isn't as easy or quick a job as you think. It would require gutting and rewriting the entire renderer, and the end result would be slow and heavy.

Sure GLQuake has mirrors. On one surface only. That must be planar. That backs on solid. That is inset from it's surrounds. In the words of John Carmack : not very robust but cool to look at.

A more generalized reflections system is a LOT more work. 
If by refraction you mean caustics on the surrounding walls, I have seen some pictures of this effect in Quake but can't remember on which engine. It sure would be a worthy addition to any engine. My DP with Pretty Water doesn’t even do that! 
Caustics in most Quake engines are crap because they only appear on walls, they don't appear on monsters or other objects underwater. 
Is QS AD-Mod A Fork? 
I don't know if I've missed this somewhere in this thread but is the AD 1.6 compatible build of Quakespasm going to be a continuation of the original QS or is it going to remain a fork?

Sorry if my ignorance irks anyone. :) 
I Believe 
It is merely an "emergency" enhanced version with increased limits so that sepulchre can run. Should be updated eventually. Ericw said something earlier about wanting to change some limits to be memory allocation based instead of hard limit arrays so maybe he is taking time to do that. 
Spike Pictures 
Spike, your pictures are dark and don't show much.

Come on man, you surely can do more pictures of your FX on water, with a better/clearer view.

A short video, maybe ? 
Spike's Dirty Pictures 
You could try downloading them then gamma-adjusting them.

But anyway, there are two pictures, "no bumps" and "bumps".

The "no bumps" picture shows reflection without a bumpmap and it looks just like a flat mirror. Not at all liquid-like.

The "bumps" picture shows reflection with a bumpmap and it looks more correct.

So the point Spike is making is that the kind of reflection/refraction effect you're asking for requires using a bumpmap. 
Reflective Liquids 
@barnak - I've done a number of tests with reflective liquids using a few different methods in Darkplaces. The demonstration I posted in the screenshots/beta thread a couple days ago has a bit with some reflective blood using realtime reflections and subtle refraction. This is a massive gif of that area. The floor uses realtime reflections and the walls use bump + gloss. Also, here is an old caustics test. This is just an animated decal so it can be used pretty much anywhere and isn't expensive.

You can you use a combo of bump+gloss+cubemaps to get an ok look on small sections of liquid such as puddles, but cubemaps just don't work well on large areas. If you're feeling really sassy you can just copy and flip world geometry and place it behind a transparent liquid texture to get pretty ok fake reflections :P (just kidding, don't do this).

IMO, however cool looking, realtime reflections/refractions are too resource intensive for general use. The effort needed to make them look 'good', especially in a quake-like setting, makes them route even more prohibitive. 
Both of your animations looks very good.

So if I understand clearly what you said, the first rendering is too intense on the frame rate, even for liquids only ?

Would it be reasonable to add the second effect to QS ? 
realtime reflections/refractions are too resource intensive for general use
If your system isn't too antediluvian you should be able to run most Quake maps fine. My old Core2duo E6750 and GeForce GTX 650 can run DP Pretty Water @ at least 30fps in medium to large maps. I only have trouble with the hugest ones (AD, Something Wicked...). 
So if I understand clearly what you said, the first rendering is too intense on the frame rate, even for liquids only ?

Realtime reflection/refraction are expensive, yes. However, in vanilla-ish quake maps without realtime lights with decent hardware you'll get good framerate (though it will still take a large hit).

Would it be reasonable to add the second effect to QS ?

bump+gloss+cubemap or the caustics? Either way, I have no idea of the technical aspect, I'm not a programmer. Practically speaking, there isn't a demand for reflective liquids in general and other engines already do this (FTE, DP). So, "reasonable"? Ask someone that would actually be doing the work :P

at least 30fps

1/8 of the way to an acceptable framerate! 
Engo Have It But Creater Is Feminstt Cuck 
@Qmaster. Thanks for the answer. That makes sense.

It also makes sense to address the limits issue once and for all rather than constantly just 'applying bandages'... :) 
1/8 of the way to an acceptable framerate!
Why? 30fps is enough for the eye to perceive fluidity. And I forgot to mention this was with RTlights on, of course... Should be quite higher off. 
Why? 30fps is enough for the eye to perceive fluidity.

It may be enough for the eye (although remember that movies which run at 30fps use a lot of motion blur which games may not have) but it's not enough for the reflexes/reactions.

There's plenty of work been done on this, we shouldn't have to rehash it and prove it all over again. 
K Thanx 
Never noticed a sizeable gameplay diff between fluid and fluider but my precision skills may not be that accurate... ;) 
At 30fps you've got 33ms latency between input events and the response to them; that's the equivalent of a network link from New Orleans to Denver (source:

You really don't wanna be doing that. 
Yeah, Never Heard About The 33ms 
Thanks for the info. 
Framerate Importance 
depends on the game and scenario.

For instance, it doesn't matter if you play a point and click game running at less than 30fps. But it matters in a fast paced competitive shooter. 
im with MH, even using motion blur to hide screen tearing, and quake's client-side aim, 30fps is not playable. 60 maybe; i might be a mutant but I can tell the diff between 60 and 120fps
just saying. 
32bit Colors 
This may have been answered before/elsewhere? How come I can't set 32 bit colors on my machine? Highest depth is 24 bit. Only just noticed that on some laptop it ran on 32 so something must be off here. 
32 and 24 are the same colour depth (8 bit per channel) so it's probably nothing to worry about. The extra 8 bits would be unused by qs.. not sure if it's just padding or an alpha channel. 
Question Someone Posted Over On Quaddicted.... 
...that I thought I'd relay here. This person is having trouble running the old XMen TC on the latest QS build. I've tested it on QS-admod/0.92.2 and although it starts up with the XMen background image, I get the same error messages when I try to start a new game.

It works fine on QS 0.92.0, though, so this seems to result from some very recent change/s to QS.

Original Quaddicted post:
Hey. I thought I'd give this TC a try but I've encountered this error in Quakespasm (0.92.2):


Anyone else have this?

PS: I'm not posting this because I want to play the XMen TC at all costs (I tried it once a long time ago and that sufficed for me); I just thought this could be something ericw (and others working on QS?) might want/need to know about.

Thanks for constantly improving this fantastic engine, by the way! 
The quote should have ended after "Anyone else have this?". The rest are my words. I guess I forgot to type "< / q >". 
there's apparently already a fix for that, just no new releases. for that mod just use the old build until then, or other engines. 
Ok, thanks. As I said, I'm not interested in the mod; just thought it was perhaps indicative of a bug or problem. 
Just out of interest - what is the correct value for MAX_LIGHTSTYLES anyway? There are places in the engine where it's 64, other places where it's 256. 
About this bug with xmen, I caught a case where something was calling PF_lightstyle with a style between 64-67. Since there was no bounds check, this happened to overwrite the next thing in server_t, num_edicts, which blew up the engine and was a pain to trace back to PF_lightstyle.

So initially I put in an aggressive Host_Error, but that broke Xmen, so I changed it to a debug warning + ignore the lightstyle call. 
the bsp limit for MAX_LIGHTSTYLES should be 255, not 256. it doesn't make sense to go higher than that, other than to skip the validation when parsing svc_lightstyle messages, which isn't too significant.
the 256th lightstyle might be usable for rtlights, but all the various bsp formats that use a byte for lightstyles can use a max of only 255, with the 256th (index 255) being 'no more styles'.
xmen is just buggy.... 
Type "gamma fps" in the console to get higher fps. 
actually, 'gamma fps' will drop your framerate AND be unplayable in QS (gamma 0 = white screen).
In QS, you want 'gamma 1;contrast 1' to boost your fps.

To be fair, I guess that 'gamma fps' would at least stop you from caring so much about framerates... 
Wow, I hadn't realized how much that contrast nerfed my fps. In the AD level selection map I'm running 95-105 until I crank contrast up to 1.8, which drags it down to 60-75.

The colors are so much more vibrant, though... 
I'm a femministt cuckk to. 
what GPU out of curiosity?
We could improve it a bit by (avoiding an extra copy of the framebuffer) by rendering into an fbo and drawing that to the window. (currently it draws the game in the window, copies it to a texture, then draws it back to the window with gamma/contrast.) 
contrast-only could be done without the fbo or even glsl.
will do something like:
screen=screen*(white*vertexcolour) + 1*screen;

with the above, gamma 1;contrast 1.8; is about as cheap as you can get it without blackmailing microsoft into finally fixing their gamma ramps issues.

A (quake)gamma of 0.45 or so can be achieved quite cheaply with glEnable(GL_FRAMEBUFFER_SRGB); (although you're meant to use an srgb-capable pixelformat too, which is messy but not needed at least on nvidia). Side note: this approach gives MUCH less banding than you would get with glsl.
Of course, talk about srgb just drives home that quake's colours are totally screwed, and its lightmaps are non-linear too... 
Hold On 
Let's not confuse contrast with gamma now. :) 
Feature Request (Not Hopeful!) :P 
Would it be possible to add vibration support for the controller?

Playing with controller works really well in single player but sometimes when I'm playing maps that have actual 'quakes' in them it feels strangely hollow not feeling any rumble... Also, the Widowmaker in AD could really do with shaking that controller too! 
Would Be Cool, To Control A Motorized Plastic Vagina Too ! 
Vibrations in Quake !? Geez I'm interested ! 
It's getting old; Nvidia GeForce 8600 GT running driver v341.44.

Color me interested on the vibrations as well! I've actually been using the Steam controller to strong effect. It's worlds better than an Xbox controller, but still can't quite compete with a good ol' mouse'n'keyboard. 
Just Pasting It Here, Maybe One You Find It Useful. 
QSS Protocol 
My QSS (admod) is set to protocol FTE+666. I thought this would make demos playable in both 666 and FTE protocols but they don't work in standard QS' protocol 666. I tried typing sv_protocol 666 in QSS' console but it doesn’t change to regular 666. Help? 
I haven't tried it, but try: "sv_protocol 666-"

To prevent the server from detecting replacement deltas (so they don't appear in demos), use "sv_protocol 666-" (omitting the - will neither enable nor disable fte extensions).
To re-enable extensions, use "sv_protocol FTE+666"

Thanks Eric! 
Ahh Crap 
I didn't read the readme properly, apparently the proper setting is "cl_nopext 1"

QSS uses elements of FTE's improved network protocol by default. This is in an attempt to reduce demo filesizes, as well as allow for mod extensions. This does not hinder QSS's use as a server and is only an issue for demos. Set cl_nopext 1 before connecting/starting a map if you wish to disable the use of this. 
OK, Thanks 
I did try sv_protocol 666- and it worked, though.

an attempt to reduce demo filesizes
Wow! Reduce indeed! I've recorded demos of the same map in both QSS protocol FTE+666 and QS protocol 666 and the difference in size is approx tenfold... I was wondering if this was normal. 
Well when you zip or otherwise compress demos, they squish together at similar rates. 
FTE+666 is an optimized protocol.

If a health box is just sitting around in your view, Quake will send information on that healthbox every single frame.

FTE+666 sends it once, gets an acknowledgment back, and then won't send information on it again unless something changes and if so, only sends what changed and sends the change just once. 
QS Sound Question 
I am doing some sound work for Map Jam 9999. (new sounds with play_sound_triggered)

I know QS requires mono sounds but am I cool with making sounds 44.1k 16bit? I've tested them and they work (even 48k) but wanted to make sure I won't encounter any issues. 
16 bit 44.1k mono sounds should work fine. QS's mixer downsamples sound effects to 11.025k by default, so the extra quality of 44.1k won't be heard, but it won't hurt. 
Thanks. 11k introduces extra noise on my end (if I master them in that format.) I would prefer to start cleaner so this is good news. 
Imo you should export to 11k. You'll have more control over quality and sounds will "weight" less.
Just figure out why sounds get noisy and fix it :)
I don't know what software you are using but this small free editor always saved my ass when it comes to editing sounds for old games:

It can set loop markers too, if you want loop sounds in Quake :) 
I'm using Adobe Audition CC 2017. I can set cues for loops no problem.

But no, if the engine uses 44.1k that's what I am using. The downsampling and filtering seems cleaner than fucking with noise reduction to save a couple of megs in file sizes - that will affect the sound quality greatly. But thanks for the suggestions anyway. I just wanted to be sure I wasn't going to cause any unforeseen problems. I will look at wavosaur for sure. Never too many sound apps! 
Vid_desktopfullscreen "1" Issue 
I'm using build r1425. I'm not sure when this started but every time I close a game the above is added to my config.cfg. Whether I change the resolution in-game or add it to an autoexec file, it ALWAYS resorts back to:

vid_desktopfullscreen "1"

Even if I delete the line entirely from the config it just gets added again.

I've removed all config AND autoexec files that I can find, yet it still ends up back in there!

It's driving me mental! Any ideas? :) 
I want to run fullscreen at 720x480. It also used to work fine... 
Try entering "vid_desktopfullscreen 0" at the console and then exit. It should get saved in your config.cfg as 0, then start the game again and print the value (just enter "vid_desktopfullscreen" at the console), it should still be 0. If it's not 0 then it's coming from another .cfg or quake.rc file.. do a find-in-files for "vid_desktopfullscreen" with a text editor 
Thank You :) 
I found an errant cfg file with the value set to 1. All seems well again. Thanks for replying. :) 
Can The Limit On Console Lines Be Removed? 
Would be nice to get the full list from entitylist command. 
Yeah - that would be good to raise. Workaround for now: launch with "-consize 1024" (default is 64). 
Any chance of getting a command similar to r_viewmodel_fov from Mark V? Minor thing really but it'd be nice to have. I managed to get something decent-looking with scr_ofsx but prefer how it functions in Mark V with wider FOVs. 
Another Sound QS Question 
I've created a music track for my Jam 9 entry. Wondering if the music plays lower by default in engine or if some kind of filtering could lower the volume a bit? I have the slider in menu up all all the way. I have the dynamics pretty compressed on the file so on the desktop the music plays fairly loud. I dunno - I will play with it some more but thought I'd ask if music is just by default lower overall in engine. 
Yeah, Good Catch 
even with the QS volume sliders at max, the music is lowered by 6dB (and the mixed sfx are as well) in the mixer code. I did this because the engine is outputting 16bit/44kHz to the OS, which you really don't want to have clipping in, and the mixed SFX can get really really loud (and the music has loud sections too).

This could probably be tuned a bit better.. for the time being QS just needs the system volume turned up a little.

kaffikopp, agreed would be nice, i'll look into it some time. 
Thanks yeah, best to not clip. Understood. I will remix my sfx and music tonight and try and get the dynamics raised a bit. Not a deal breaker they were just low for my taste. Good to know I am not going nuts. :) 
Windows Audio 
considering windows' audio mixer will convert stuff to floating-point anyway (hurrah for sse), engines might as well just use floats too, and by doing so skip all the clamping - windows will be doing that anyway (at least vista+ anyway).
if windows clamps the audio much, then it'll just automatically reduce the volume or something until it stops clamping so much. I assume the other audio apis will do something similar. 
Possible Controller Issue 
I use the left trigger for jumping and the right trigger for shooting. Sometimes the buttons act like they're 'stuck'. When shooting, the gun keeps firing when I take my finger off the trigger only stopping when I push it again. When jumping in liquids (and only when jumping in liquids) the same thing happens.

This only happens occasionally and I can't deliberately reproduce it. It seems to be random.

I don't think it's my controller as I have no problems with any other game. Looking at the settings in windows all axis controls (triggers and sticks) centre perfectly.

Anyway, thought I should report it. :) 
Is That With Xbox 360 Controller? 
and it's the analog triggers that do that?
Thanks for the report, will take a look at how that could happen. 
bind MOUSE1 "-attack; wait; +attack"

Substituting MOUSE1 as appropriate.

This won't solve the problem, but the symptoms of the problem will go away. If it acts up, you can just shoot again like normal. 
Hm, I bet the default for joy_deadzone_trigger is too low; it is currently 0.001. That's a fraction between 0 and 1, so if you set it to 0.5, it generates key press/releases when the trigger is 50% pressed. Maybe try raising it a bit e.g. to 0.01 or 0.1. 
I'm actually using a DS4 with DS4Windows. As far as I know that software fools Windows into thinking it's a 360 controller (ie/ totally transparent).

I've changed the trigger deadzone. So far, I've only had the issue once and only when jumping in liquid. I'll keep tweaking and let you know if there's any difference.

@Baker: Thanks for the suggestion. If the issue persists, I'll give it a try. I'd just rather try to isolate the issue first. :) 
Controller Testing 
I have all sorts of controllers, if you ever need them testing in a build I have 'em. From 360 pads, to xbone pads, ps3 pads and ps4 pads. 
All's Well With The Triggers (I Think!) 
So, I bumped up the deadzone all the way to 0.5. I haven't had the issue at all so far and with no ill side effects. It does seem the deadzone was a little tight before. Thanks for the help.

Like FE above, I have lots of controllers that I could dig out for testing purposes if you ever need anything checked in the future. :) 
I raised the default to 0.2. Thanks for the testing offers :) afaik this is the only controller thing that changed since the last release. 
Vid_desktopfullscreen "1" Issue Again... 
Hey. I'm now using r1435. I was playing Quake fine at fullscreen 720x480. Have been since I 'fixed' the issue mentioned above. I loaded up Hipnotic and, "BAM!", the screen was back to 1080.

I looked in the config and sure enough it had changed to vid_desktopfullscreen "1" again.

I redownloaded r1435, made a new folder on my desktop, deleted all config files from Id1, Rogue and Hipnotic so as to generate new ones.

No joy. I ran the game, it was windowed at 720x480, I switched to fullscreen in the menu, the game ran fine. I quit. When I checked the config it was back to "1" again.

Don't know what to do. Fresh install, no config files and only the official PAK files in Id1, Hipnotic and Rogue... 
Thx For The Info 
I reproduce the bug, should be a straightforward fix. In the meantime 0.92.1 should not have this bug: (though this is last fall's release) 
Cool Beans 
Thanks. At least I'm not going mad! In the meantime, I'll use 92.1 as you suggest and keep an eye open for a new nightly.

Thanks again, it really was driving me crazy. :) 
Should Be Fixed In The Nightly Build Now 
All's Well So Far :) 
Well, it's nearly 3:00am so I think I should probably go to bed for work tomorrow!

Anyway, so far, I've played around with lots of maps and mods and all seems well now.

Thanks for jumping on that so quickly. I can sleep easy now. :) 
Sliding On Ground 
So there is something i'm not sure about. Player is sliding on slightly rotated horizontal brush faces. Is this intended? There is nothing like that in Half-Life, but i don't know how it was in original. 
Slidey Slopes 
in vanilla NQ, you will slowly slide down slopes, even if they're fairly shallow.
in QuakeWorld (and derivatives), you won't (until they're 45ish degrees).

so for quakespasm its 'working as intended', and mods like Slide (although possibly only that one) would break if it was any different.

if you need a workaround then you can just build some steps from clip brushes around your slopey stuff. That'll give the player physics some nice flat surfaces to walk along.
alternatively, turn it into a trap that has the player needing to stay relatively still in a field of crushers and lava pits and only slopes! 
Bug Encountered. 
Please note I was using my irc-modified version of quakespasm (latest version) and a modified progs.dat. I can supply both of these if necessary.

In e1m6 my game crashed with the following error:
"SV_TouchLinks: encountered NULL link!"

It wasn't a friendly crash either, it actually froze the game and wouldn't relinquish control back to the window manager (I'm running linux).

Can you guys think of any reason (aside from my modifications) why this might occur, I wasn't able to replicate the crash. 
One of remove(eg: killtarget), setorigin, setsize, setmodel, walkmove, movetogoal, droptofloor called inside a trigger's touch event can cause such crashes.
This is why the vanilla QC code used SUB_Remove all over the place (except for killtargets, unfortunately).

The exact ordering requires two triggers near each other. If the first trigger removes the second trigger in its touch function then the engine will end up walking that removed second trigger's links. QuakeSpasm has some code to try to heal this, but it can't cope with recursion. Replicating it requires quite a few things to become ordered in an exact way (which may even have framerate dependencies).
I've no idea what could cause such recursion in vanilla quake, but to be fair you're using a modified progs.dat, so maybe its something in there.

QSS/FTE/DP have code that can handle recursion etc, so they'll never give the crash you got no matter how exotic you make it.
QS should be okay for most of those functions, but can have issues if you're using movetogoal or walkmove inside touch functions.
Vanilla can and does explode if ANY of those functions are called inside a trigger's touch function. Like I say, order matters. You may feel you've gotten away with it, at least until they're things are triggered in some other order, or a dropped backpack might be enough to prevent the bug or be the difference between an infinite loop and a segfault. 
Where is that modified progs.dat?

I think the only changes I made were in combat.qc 
exactly what do I do to trigger the issue? 
Be on the start platform on e1m6
I think I had a quicksave beforehand.

I wasn't able to replicate it.

It just died with that error. 
Well, I can't reproduce it either. We'll need to reproduce it reliably in order to find a solution. 
OK, Got A Test Case

The player spawns over 4 nailguns. The nailgun touch function calls setorigin() to move all 4 nailguns to the other side of the map (into another areanode).

The map freezes immediately in fitz085, MarkV, QS, and works in QSS and DarkPlaces 
Test Case 
Indeed it freezes immediately. (Linux note: test this with -nomouse on the cmdline.) It doesn't even hit the NULL link error. 
Re: Behaviour Difference 
the only way I can see that QC would observe Spike's version being different is if a touch function teleports something into areanode that is currently being visited by SV_TouchLinks.

e.g. player touches a lightning gun. the touch function teleports (with setorigin) a nailgun (from a different areanode) onto the same position as the lightning gun.

With the vanilla code, the nailgun touch function could run during the same SV_TouchLinks call.
With the fixed code, the newly teleported nailgun wouldn't have its touch function run until later (next frame in this case, when the player entity is relinked.)

This wouldn't be observable with id1 since trigger_teleport is delayed 200ms. 
the way I see it, the differences in what the QC might observe only appear when the QC does evil things that could crash vanilla anyway.
While that's no real guarantee that it won't break stuff, it does at least mean that you can fully blame whoever potentially crashed vanilla. :) 
I committed your patch with minor tweaks (hunk allocated array, made the touch->v.solid test in SV_AreaTriggerEdicts the same as the one in SV_TouchLinks.. shouldn't make much difference?).

Did some more experimenting, and it turns out you can make a teleporter setup that behaves differently depending on the engine's SV_TouchLinks, with vanilla id1 progs:
(DarkPlaces = you pick up RL and SSG, winquake = you pick up SSG only). Kind of annoying since I was hoping this change wouldn't be visible to a map running on id1 progs, but I did set up the map specifically to show a difference..

My attempt to summarize the behaviour of vanilla's SV_TouchLinks:

Say the player touches a trigger_teleport, whose touch function setorigin()'s the player on top of a weapon pickup:
- if the weapon's areanode was visited by SV_TouchLinks before the player's starting areanode, the weapon's touch function won't run this frame
- if the weapon is in the same areanode as the player's starting areanode, the weapon's touch function will run this frame if the weapon appears later in the areanode's trigger list than the trigger_teleport
- if the weapon is in an areanode that hasn't been visited yet by SV_TouchLinks, the touch function will run this frame.

So to sum up, whether the weapon touch function runs the same frame as the teleporter touch is pretty much random. What happens in my test map is the player misses picking up the RL because the RL is earlier in the linked list than the teleporer they just arrived through.. but there's another teleporter later in the list that can still be touched on the same frame, so they go through that before they have a chance to pick up the weapon.

With the new patched SV_TouchLinks, the weapon touch function will never run until the next frame. Hopefully QC code / maps are not relying on touch functions making changes and then other touches happening as a result that same frame, since whether that is possible in vanilla is unreliable. 
At this point, darkplaces does so many other things that you can't pin such a difference on any single feature.
We're talking ordering here, so things like a different world size can change the places of the collision nodes. DP uses a 2d grid instead of a kdtree which ensures a different order. DP also puts triggers and non-triggers (even non-solids) into the same lists.
Whereas FTE has all the same stuff, but gets only the shotgun (matching your winquake claim)...
The fun thing is that if I load up the .map directly in FTE then I get neither weapon!

Its worth noting that DarPlaces has only the bounds checks inside 'SV_AreaTriggerEdicts' and they're missing from its SV_TouchLinks-equivelent.
This guarantees that the RL will be touched.
Which is probably the safest behaviour, if it were not for triggers potentially getting touched from the other side of the map after a teleport. The only types of triggers that I can think of that might actually care are q3-style jumppads (ones that actually aim properly), and I don't really see one occupying the same space as a teleporter (q1 pushers might overlap, but they at least don't care about starting points). 
I should have mentioned, QSS gets RL+SSG on the test map (with the SV_TouchLinks_New) or just SSG with pr_checkextension 0 (reverting to the old quakespasm SV_TouchLinks). Quakespasm gets RL+SSG since r1485, before that it got just SSG.

I'm surprised FTE doesn't get the RL. 

Release candidate for the next QS release, thanks to szo for building the binaries. Note the above link is temporary and will only be around until we do the official release.

Biggest change for players is that the QS changes to "always run" are disabled by default; if you want:
- Shift to act as the "walk" key, when always run is on
- always run to be affect all directions (forward/back, side, up/down)
as they did in 0.92.1 and earlier you need to select Options -> Always Run -> Quakespasm

Aside from that there is a long change log (see the readme.txt); this has all of the limit increases from the ad_sepulcher "quakespasm-admod.exe" and can run Orl's episode. 
Orl's episode
So KenChennar = Orl? 
what's again the diff between the QuakeSpasm, and QuakeSpasm-SDL2 ?

And what about the spike version ? 
(see the readme.txt)

Quakespasm utilizes either the SDL or SDL2 frameworks, so choose which one works best for you. SDL is probably less buggy, but SDL2 has nicer features and smoother mouse input - though no CD support. 
Mugwump: yeah, see Orl's post in the episode thread.

Barnak: Generally you should use the "QuakeSpasm-SDL2" one, it has more features (game controller support, specify refresh rate, desktop fullscreen, etc). "QuakeSpasm" is using SDL version 1.2 which is officially at the end of its life, but supports old OS'es (windows 95, mac 10.4). 
What About The Spike Version Published For AD1.6 ? 
No More Rain In Forgotten Sepulcher ! 
... and no Spike effects. What gives ? 
QSS and QS have not merged into one, this is an update for Quakespasm only. Although, I slowly added some fixes/improvements from QSS to QS this past year (not the new protocol and particle system though). So - I don't know what the plan is for QSS. 
Eventual merge and option to toggle extension advertisement to the mod so particles could be either pixelly or DP??? Maybe hopefully someday. 
Arcane Dimension Issue? 
Seems when I updated to "Quakespasm-0.93.0-rc1" that when I walk up to a pedestal(sorry hate the word: PLINTH) the screen no longer goes dark making the text easier to read.

Is it just my setup? 
Hi! Seeing that people complain about this issue in unrelated places, I've made the patch, which automatically switches to protocol 999 when map bounds exceed -16384..16384 range (not sure this is a correct range, but that's easily fixable :) ). 
I wasn't aware this was an engine specific issue but this does make things easier.

So If I want something coded I just need to name my post "Not a request" - cool! 
Autodetecting When Protocol 999 Is Needed 
I need to experiment with this a bit; one potential problem is a map like telefragged.bsp is right on the edge of the protocol 666 signon buffer limit, and won't load under protocol 999 in QS (signon buffers are larger with 999 since coordinates are 4 bytes instead of 2). I think that map has world geometry extending past +-4096 too.

Maybe checking if hull1 bounds exceed +-4096 would be a more robust heuristic? It would avoid false positives that work properly in 666, where the playable area is +-4096 but scenery extends beyond. 
For the most part, FTE+QSS doesn't use the signon buffer. Ambient sounds are QSS's last hold-out (excluding things the QC might explicitly write, but tbh I don't think I've ever seen a mod that actually does).
This basically obsoletes the signon buffer size limit, allowing for pretty much unlimited entities etc.
Additionally the revised entity networking doesn't need to send coords with every single packet either (and even if the mod forces it [eg: AD's sprite particles], it can do so over multiple packets, which avoids overflow issues with the datagrams too).
Port that part of my code over and it becomes a non-issue.

The real problem is when exactly 999 should actually be used...
Even small maps will benefit from increased angle precision on rotating things, so arguably the answer is 'always'.
In FTE's case I aim for network compatibility which means I try to auto-enable to as infrequently as possible (while fte supports multiple protocols simultaneously, it still can't cope with primitives changing sizes for different clients). Thankfully for QS, it doesn't really need to care about any of that.

Some maps have non-interactive geometry outside the 4k range in the form of a skyroom or whatever. Some might even have monsters (ready to be teleported in).
So perhaps the real solution here is to just create two new worldspawn fields - one to specify required origin range, and one to specify required angle precision.
The server would then be free to upgrade as desired, or not (if the default setting causes overflows/etc).
That or just upgrade everything so that it can be used by default/unconditionally (like DP does or FTE/QSS could). 
How does this sound for worldspawn keys?
"_maxcoord" "10000" if you need +-10000
"_anglebytes" "2" for requesting 16-bit angles

Yeah - this would be more robust than trying to guess based on looking at the bsp, which would also be a mess if different engines had different heuristics.

re: signon - yeah, I need to check out QSS's code for this again. 
Design By Committee 
I think I'd rather anglebits instead of bytes. Maybe I'm just weird. It doesn't really make any difference unless some crazy engine dev decides to splurge bits instead of bytes (like q3 does...).
And now I'm wondering what interpretations engines might make if they support different sized angles in different places... (client->server angles changing can be problematic, though 666 already uses 16bit angles there anyway).

Side note: in multiplayer situations, consider giving any out-of-order unreliables time to arrive before protocols are switched.

Could also be worth adding it to your qbsp too, if only to warn when large maps are not explicit about it.

Oh, I just remembered the issue with certain bsp entities with an erroneous angle of -1 breaking on engines with 16bit coords. that makes defaulting to 16bit angles messy too. Explicit limits are nice...

re signons: QSS+FTE dynamically allocate lists of the objects instead of storing raw network data, which allows them to selectively support extensions (although with baselines that data is already known anyway). This is overkill if your only aim is to remove signon limits. It would be easier to just create a list of signon buffers and allocate a new one when the previous one gets a little full. Its not as fancy but it'll get the job done. Really it just depends on whether you know what your clients will be given before they even connect... 
In The Wild 
For the most part, FTE+QSS doesn't use the signon buffer. Ambient sounds are QSS's last hold-out (excluding things the QC might explicitly write, but tbh I don't think I've ever seen a mod that actually does)

I think that ne_marb does this when you activate the dais mechanism if you're ever after a test case.... 
I vaguely remember that Marcher sends sound messages from qc 
A map pack has 12 maps. One of the maps has large coordinates.

The start map does not have large coordinates.

Are you going to switch to protocol 999 when you walk through the teleporter to the map that needs large coordinates?

Or ...

Someone types "record mydemo; map verybigmap"

The demo is already recording before the map loads. Are you going to switch the protocol from 666 to 999 during the demo?

Someone wants to see how their map works under protocol 666 and types "sv_protocol 666; map my_new_map". Are you going switch to protocol 999 against their will?

John and Harry are playing coop. John types "changelevel verybigmap". Now what happens? 
Are you going to switch to protocol 999 when you walk through the teleporter to the map that needs large coordinates?
The demo is already recording before the map loads. Are you going to switch the protocol from 666 to 999 during the demo?
Yes. Going through a changelevel trigger does a Host_Changelevel_f which calls SV_SpawnServer, which sends the protocol version in SV_SendServerinfo, so it will already change protocols in QS e.g. if you load start.bsp with sv_protocol 666, change the sv_protocol cvar to 15, then walk through the teleporter to e1m1, e1m1 will start in protocol 15. Recording a demo of this and playback seems to work fine, and I confirmed that the demo file has two "FITZQUAKE 0.85 SERVER (24778 CRC)" headers with different protocol numbers after.

Someone wants to see how their map works under protocol 666 and types "sv_protocol 666; map my_new_map". Are you going switch to protocol 999 against their will?
No.. I guess to avoid breaking this scenario, sv_protocol would need to default to some other placeholder like "auto" or "666+" or something. Then "sv_protocol 666" would mean "force use of 666".

John and Harry are playing coop. John types "changelevel verybigmap". Now what happens?
Should just work as I was describing above, since the changelevel sends new serverinfo that may include a different protocol (?)

Btw appreciate the questions as I had to go and test the demo thing. I don't mean this is set in stone, and it's not implemented, but it would be nice to have automatic support for large maps if it can be done without negative side effects. 
It appears you meticulously walked through everything in great detail.

Which is how it should be done.

I haven't looked at the protocol 999, but I would assume it properly maps

WriteCoord (MSG_BROADCAST, player.origin_x);
WriteCoord (MSG_BROADCAST, player.origin_y);
WriteCoord (MSG_BROADCAST, player.origin_z + 16);

To the appropriate WriteCoord16/24/32 function. 
sv_test_protocol for the second scenario Baker alludes to, so it's crystal clear what it's used for. 
Those are not examples of MSG_INIT / signon buffer. Maps can't use it without QC, and marcher uses MSG_ALL (and breaks for new clients as well as saved games).

Yes if a mod uses writeshort instead of writecoord then you'll have issues if the engine switches protocols randomly. On the other hand, most people can't be bothered to do the *8 or the *256/360 thing, so mods that actually break in that way are rare, plus they'd be broken in DP too (like so many other things).

there's not much difference between a demo and a regular network connection. I don't see any reason at all for that to break any differently from single-player breaking.
Besides, you can already switch protocol for the next map.

Easiest is to just default to 999 and add a separate cvar to override the primitives. eg fte's sv_bigcoords cvar. Empty=auto(default), 0=shorts, 1=floats.
This would provide .scale support, even with 16bit coords...
The risk being people's configs that override things, and outdated clients. Forcing 666 up to 999 when using bigger coords is frankly the safer choice for those outdated clients, but hey. 
Why have a sv_protocol cvar if no matter what value the user selects, it will never be honored?

I pick 15 ---> nope you get 999
I pick 666 --> nope you get 999
I pick 999 --> you are lucky because I was going to give you 999 anyway.

If you see the humor.

What would work is honoring the sv_protocol cvar, but defaulting it to an automatic setting.

Spike would make the automatic setting "0", because Spike likes a value of zero to do wildcard things.

Spikeworld: Would you like 1 lump of sugar or two?
User: zero
Spikeworld: Then 12 lumps of sugar it is!

But a better default value would be "auto", which happens to have an atof value of 0 ;-) 
How does this sound for worldspawn keys?
"_maxcoord" "10000" if you need +-10000

The bounding box of the worldmodel would be superior method.

The bsp already has that data.

Would not require older maps to be recompiled. 
re-read #2976 
Here's a minor bug.

Quakespasm.pak doesn't load when using -basedir. It has to be copied to the actual Quake root folder. Maybe change it so Quakespasm loads it from wherever quakespasm.exe is?

Trying to make Quakespasm and vkQuake work with the same installation of Quake. Their DLLs are different versions and break each other, so I have to get creative.

Also, what's the deal with the vid_ stuff being ignored in autoexec.cfg? 
Hostmax Fps 
Is the greater than 72fps a limit of the network protocol? 
Hud Gfx.wad In-QC Reference (no Not CSQC) 
Is there a way to allow QC to refer to gfx.wad textures by name for certain "slots" in the hud inventory?

Not sure if there is a way to use WriteByte to send a string of commands to the engine to signal updating a specific hud "slot" to use a specified texture by name. QSS feature? 
I think it's more a limitation of how the physics simulation is designed.

Spike was saying that the results of physics after one 72fps timeslice can be different than after two 144fps timeslices. 
Is there a way to allow QC to refer to gfx.wad textures by name for certain "slots" in the hud inventory?

The HUD is absolutely and totally hardcoded into the engine.

DarkPlaces, FTE give you additional options (csqc). I don't believe Spiked Quakespasm has any csqc support.

I think with csqc you need to self-draw the HUD. Nahuel at QuakeOne had a open source implementation of a CSQC HUD.

Providing information only so you can decide on options, altering the HUD is impossible in vanilla Quake.

If you were to make a CSQC custom HUD, it could work for DarkPlaces/FTE and other engines would simply ignore the csqc progs.dat just use the regular HUD. 
I have a small request, please bring back m_filter. 
I've done my own dragndrop csqc inventory before. I'd prefer a simpler method, but alas oh well. 
Quit Messages 
Hey all, I've never posted on a forum or anything before but I'm seeking some help.

I was just wondering if there was ANY possible way to get back the funny quit messages from vanilla or DarkPlaces in QS. I know enabling "-fitz" in the shortcut gives you the credits box, but its bothering me far more than it should that the original quit messages are seemingly gone in this port.

Any help would me appreciated, thanks 
MacOS CLI Install Method 
I've added the 'cask' for the 'homebrew' package manager on macos, now you can install the client from the command line:

1) install homebrew: /usr/bin/ruby -e "$(curl -fsSL"
2) install homebrew-cask: brew tap caskroom/cask
3) install quakespasm: brew cask install quakespasm
4) put pak0.pak and pak1.pak into /Applications/QuakeSpasm/id1
5) enjoy 
Model skins in some mods are corrupted, appearing half blue, half black. In particular, gib skins in Shrak and tarbabies in Arcanum. This is an old GLQuake bug which is fixed in Bengt Jardrup's Enhanced GLQuake, DarkPlaces, Mark V etc. 
This bug was present in earlier versions of Mark V, I found it reported here:

I suppose, Baker can help you fix it. 
I'm Pretty Sure 
That the blacknblue checker is indicative of a mod trying to use a skin that doesn't exist. This is most notable with gibs if they are coded to 'inherit' the skin of the monster being gibbed when the gib model only has one skin.

Which mod did you see this on and what model? 
The corruption doesn't happen with Mark V or Darkplaces running exactly the same installation of Quake. Here's how you can check this:

Grab the mods here:

In Shrak just start the first level and kill one of the shotgun enemies (input "impulse 255" in the console to get Quad Damage so that you can easily gib them), their head gib is affected.

In Arcanum go to map arcanum5. You'll see the tarbabies right at the start. 
Not Sure 
But maybe the other engines default to skin 0 if the skin is not present? 
for arcanum5, I think you missed an install step; you need to install arcanum on top of drake. The monsters at the start should be spiders, not tarbabies.

In shrak, I see the blue checkerboard on the gibs. It's a feature inherited from fitzquake, I guess the intention was for modders to notice invalid mdl skins.
It looks like MarkV is displaying skin 0 instead of the checkerboard for compatibility with mods like shrak that set invalid skins. 
Oh man, totally missed that part about installing Drake. Guess I got a bit careless when playtesting so many map packs. Still though, the tarbabies don't get the checkerboard pattern in the other engines.

I suppose you could change it to display skin 0 when developer is set to 0, this way it would accommodate both players and modders. Backwards compatibility with old content is pretty important, especially in this decade that's so heavy on the 90's nostalgia.

Just my two cents, is all. 
Oh, and one more thing. In vanilla GLQuake the gib skins in Shrak are completely white, while they show up just fine in WinQuake (and supposedly DOS Quake as well). It's definitely some old GLQuake quirk. 
I was the one that at added the blue checkerboard feature. I didn't realize at the time how many mods relied on the behavior of vanilla quake to show skin 0 when the mod asks for an invalid skin. So I now agree, the engine should replicate vanilla quake's permissive behavior and maybe just put up a non-spamy console warning when the bad skin is first set. 
Glad that I could help. Here's a couple more oddities that I've come across:

- r_wateralpha < 1 results in various see through glitches on non water VISed maps, like e.g. qte1m2 in Travail. Other engines seem to ignore r_wateralpha if the current map is not water VISed, I'd prefer such behavior.

- Console font sometimes has a thin underline/overline with some characters, no matter what value scr_conscale is set to.

- Water textures are not mipmapped and thus look pixelated at distance. 
Other Oddities While On The Topic Of Missing Skins 
•Missing skin: console warning and checkered texture
•Missing sound: console warning
•Missing model: CRASH to desktop! You lose.

Couldn't this also just be a console warning and remove the entity? 
well... we could play a checkerboard sound for missing sounds. Like a horn honking or something. 
play the Wilhelm scream 
Q3A Honk 
C&C "Your Mission Is A Failure" 
Har har 
Sliding Effect 
Is there a console command in QuakeSpasm similar to sv_gameplayfix_nogravityonground in Darkplaces? I'm experiencing something called the sliding effect on my setup; it's basically when the player slides forward a small distance before coming to a full stop. AFAIK it is how the Quake engine behaves on modern hardware so the issue persists with all ports faithful to vanilla Quake (FitzQuake, QS etc). My workaround is setting sv_stopspeed to 200 (def 100) but I wonder if that has any effect on player movement (jumping etc). Is there a workaround? Could it be input-related? 
Isn't that just normal Quake physics momentum at work? Not sure I understand what you're describing. 
Not really because it looks like I'm walking on ice or some other low-friction surface rather than the ground. Moreover it reduces the precision of player control when navigating ledges, lifts etc. I don't see this when watching other people's demo runs. 
That is a normal effect in FPSes. Stopping dead from a full out run is jarring and odd. Sv_stopspeed woukd be your best option for this. Try like 1000. This may affect, however, some wind tunnels by preventing them throwing you as far once you touch the ground, but this might be ok. 
Yes sv_stopspeed is the workaround I'm using. It's not perfect but it gets me there. I tested a value of 9999 to see its effect exaggerated and oddly enough it results in almost 0 forward movement. Similar to setting sv_friction to a high number, except that here it's deceleration and shouldn't affect speed or acceleration, if I have my physics right. 
The physics in NetQuake and Quakeworld clients is different.

Quakespasm, Fitzquake, Mark V are considered NetQuake. Darkplaces, FTE and others are based on QW. I find QW clients very "swimmy" almost like what are describing. But not so with Quakespasm.

I'm wondering what version of QS are you using (SDL or SDL2) OR if perhaps a setting from another source port has carried over to your current config?

From the readme:

Quakespasm utilizes either the SDL or SDL2 frameworks, so choose
which one works best for you. SDL is probably less buggy, but SDL2
has nicer features and smoother mouse input - though no CD support.

I honestly don't know which one I am using because I switch between source ports quite often. 
I don't know what's going on to be honest..

AFAIK it is how the Quake engine behaves on modern hardware so the issue persists with all ports faithful to vanilla Quake (FitzQuake, QS etc).

The only thing I have heard of that is similar to this is the "multicore timing bug" that affected some Quake clients on Windows (including Fitzquake 0.85 I think?) that had to do with a specific timer API. AFAIK it never affected Quakespasm.

I'd suggest trying MarkV for comparison. 
I'm using SDL2. But I've had this for years and also on a previous system so it makes sense that it's just Quake physics as Johnny Law and Qmaster eluded to.

Also sv_gameplayfix_nogravityonground in Darkplaces seems unrelated to the issue, so that's that. 
Been Playing DirectQ Again 
The "lastweapon" command in DirectQ is really nice for quick grenades. Wish it could be added to Quakespasm. It's the same thing as in Half-Life, you can switch between any two weapons with one button. 
Looks like it's not a bug or even QuakeSpasm-related, but rather a "feature" of the Quake engine. I'll deal with it. 
Just out of curiosity - are you running with maxfps > 72? Lots of physics problems manifest in this case, and setting it back to 72 is often the quickest and easiest fix. 
No, host_maxfps is unchanged at 72. I also have vsync enabled which caps my framerate at 60. 
Try disabling vsync. I get input lag with it too, and I think the implementation might be buggy 
Disabling vsync didn't solve the stopdrift and I saw some image tearing with the video card getting ahead of the monitor. My solution is increasing sv_stopspeed to 300 (def=100). Looks like there's no adverse effect on player movement up to a setting of ~500. Thanks lads, appreciate the help. 
Found Another Bug In Quakespasm 
The hidden closet with the Shambler at the start of id1/e4m7 is visible through the sky brush.

Doesn't happen in Mark V, DarkPlaces or DirectQ. Does happen in vkQuake, which is a Quakespasm fork. 
On further inspection, this seems to be caused by my wrapper (QeffectsGL) trying to do a "ZTrickFix", works fine if I set ZTrickFix to 0. However, the bug does occur in vkQuake regardless. So, maybe still worth looking into. 
Ah - that's good. I checked and can't reproduce on QS 0.93.0-RC1. Can reproduce on vkQuake, though. Maybe file a bug at: 
The Rapture map pack also has the blue gibs issue, it's mentioned several times in the reviews, people must've played it on FitzQuake, and QS inherits the same problem. 
I plan to implement metl's recommendation in post #3008 
Is There A Way To Load Multiple Mod Folders In Quakespasm? 
E.g. in DarkPlaces you can just use multiple -game commands, like -game ad -game coolmaps. Seems like QS only reads the first -game parameter. 
Way to break my SM134! 
break how? 
He means this:

It's an improvement to the map IMO. 
god that fucking map pack lol 
Qump_vingal Missing Torches Issue 
continuing from:

The bug is in vanilla quake (ED_ParseEpair): if an entity has "origin" "", the engine will read from uninitiazlied memory, so the results depend on the OS and compiler. The same thing will happen if there are less than 3 values in the string, e.g. "100 100" will be loaded as "100 100 ???".

Made a fix here:

and added a developer warning that will be printed if the map has any fields that would trigger this bug in unpatched engines. 
Would you consider adding the "bestweapon" command? E.g. "bestweapon 5 4" selects the best nailgun you have, etc. It's supported by all the other engines, so I was wondering why QS still doesn't have it. 
How Do I Set Up Quake Multiplayer? 
Okay so i have 2 copies of quake with quakespasm. one version on my friends computer and mine. we have a router and 2 ethernet cables. he's coming over soon and you guys are like the encyclopedia of quake knowledge and have helped me before so i came to you guys for help. So how exactly do we get a multiplayer game started? if you could post exact details it would help a lot i really want to get my friend into quake and maybe even into level editing (he's a great artist too.) and it'll be his first time playing quake so i'm very excited please help me out guys! 
I don't know multiplayer very well but this should get you started:

- first look up your computer's local IP address. this starts with 192.168. e.g.
- Use the "Multiplayer" section of the main menu in Quakespasm to start a game on your computer. Your player should be in the game.
- On your friend's computer, start Quake and go to the console. type "connect 192.168.XX.YY" replacing the number with your computer's local IP. It should connect and have both players in game. 
So Er, 0.93.0? 
rc1 came out a couple months ago and there doesn't seem to have been much mentioned about it since. Real life just got in the way or such maybe? I'm just looking forward to only having one version around again, not needing -admod for the one map. 
Thanks For Fixing The Skin 0 Issue, Eric! 
Now I can finally replay Shrak on the best engine!

@Keiya, I think a lot of people in the community just use dev builds of QS that are updated almost daily. You can get them here:

These will run ad_sepulcher and have all the other latest fixes. 
If you are going to play on a LAN (local in the same room or same place) and not online it's very easy. Follow these steps before launching the game:

1. both of you need to turn off your firewall in the Windows Security settings (this is a must) turn it back on when you stop playing.
2. Whomever hosts the map hits Windows+R on their keyboard and type CMD in the box
3. in the the command window that pops up type ipconfig and hit enter.
3.the IPv4 address is your local LAN IP address

Now launch Quake

4.Whomever is hosting the game go to the Multiplayer menu in Quake, follow the steps to host a game (map, game type, etc)
5. when the game is running on the host the other player brings down the console by hitting ~ key. that player types "connect"

the X's are the IP address you discovered earlier. Usually it's like this: or something similar.

that should do it. 

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)

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"

o Fix memory corruption in PF_lightstyle with out of bounds

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 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 :) 
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. 
Does this version support AD-Sepulcher? 
Yes (and Orl's Map Pack) 
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: 
Its not too much work. They already did it in the admod version of Quakespasm released with Sepulcher. 
Indeed, I'm aware. And that particular version causes bugs like this:


vanilla QS: 
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. 
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:

Mark V:

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. 
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.) 
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. 
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? 
Hm, that's not good. I'll see if I can reproduce it. 
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? 
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. 
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. 
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:

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? 
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 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. 
Could you add an "r_viewmodel_fov" cvar from mark_v 
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):

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

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). 
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 ? 
I believe that this was already answered up-thread? 
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. 
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
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?

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? 
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. 
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? 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:

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

Do you think reworking my compilation recipe to change my working directory away from the map's directory would be a good idea? It's a lot of work, sadly :( 
I can reproduce it now - the key is launching the engine through the "Run Tool" feature in TB.

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

Still weird that SDL1.2 works when launched via "run tool" and SDL2 fails, I will look into why that is the case. 
TB fails to close the compilers if you dont hit stop before exiting. 
seems like its not a specific QS bug, but my 'custom' folder has my Qrack config, and trying to exec my autoexec.cfg QS runs into many keys and cvars that it doesnt recognise. Now, thats when things get weird. It will read the whole config, then if i type timedemo demo2 it says it cant find progs/player.mdl even though using the path command it finds id1. then pressing q then tab it fails at Q_strncmp strings not equal. So, my only assumption is that reading a config full of unknown cvars is polluting a string buffer.
again probably not a QS specific bug. Using a clean config i get no errors. 
mind emaling me or uploading the configs from your "custom" folder?
this isnt the actual cfg (not at home atm) but its still should be close enough 
i can upload the **actual** config later tonight if you need 
thanks. No luck so far, I tried loading that config and doing a "timedemo demo2" followed by "q", tab.
Could be it needs the combination of config.cfg + autoexec.cfg to reproduce 
ok when i get home i can upload the configs
i can even make a video im using the win64 build also
if that makes a difference.
i know its not a big issue but if your like
me i hate when something breaks without knowing why ;) 
Shame about having to use the Launch Engine feature, since it's many more clicks than just Run Tool... I might just deal with the mouse snapping unless this is never going to be fixed, since I usually just jump into the game to check lighting and entity placement anyway...

Perhaps in the future a Launch Engine operation can be added for the Run Tool recipes... 
@pritchard roll back to a version that works?
@ericw config.cfg and autoexec.cfg yet i tried on my laptop winXP no crash so please dont lose sleep over this. :) 
if you know how to roll back a Windows 10 update, please let me know :P

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

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

If you dive in, it's quite powerful: 
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:

And software Quake's mipmap code is here: 
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.

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

game custom
exec config.cfg
timedemo demo2
host error: progs/player.mdl not found
game id1
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? 
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. 
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. 
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. 
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! 
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. 
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 ( 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. 
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. 
Here you have similar project for Quake2: 
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? 
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
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). 
And I thought Spikedspasm was a dead end fork.

"And I Thought Spikedspasm Was A Dead End Fork." 

QS_Spike version is my Quake version of choice. Long live Spike! 
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. 
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

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 and there is an r8+ released recently. 
I Meant R8+ , Grrr... 
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: 
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) 
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? 
• Reduce video resolution
• Play on a computer made after the year 2010. 
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... 
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. 
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! 
Interesting comparison of model light levels across WinQuake, QS and FTE: 
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. 
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. 
It was indeed the pak0.pak. Man, my CD must be old. 
Collectible! :-) 
0.93 "has stopped working" when trying to load death32c.bsp 
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:

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 - , and the death32c.bsp crash (vis data overflow). 
Does That Allow For Alpha Values Below 0.666 On {fence Brushes? 
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?

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:

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. 
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?
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:


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. :-) 
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? 
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. 
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. 
Winquake traced up to 2048 below the mdl, QS traces 8192 units. The code is in R_LightPoint:

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.

If I ever dab at mapping I'll be sure to employ your workaround... :) 
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!

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? 
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 
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. 
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. 
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" ... 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? 
Pretty Cool Idea Yeah. 
I'd use it. 
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. 
I like the cut of your gib. Sounds like an elegant way of doing it :} 
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 [] 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. 
@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? 
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. 
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? 
Ooh what other scary effects are there? 
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. 
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? 
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? 
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. 
Do you experience this on both the SDL 2 and the SDL 1.2 .exe? 
A Windows 10 update broke that. The SDL2 version should still work though. 
#3314 #3316 
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.

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

A-Armor (Fitz, Spasm & Mark V)
L-Lava Nails
M-Multi Rockets

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

and here is r_scale 5 (went with a much higher value to better demonstrate what I'm talking about):

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: 
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 [] 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 [] 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 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;
Con_Warning("failed to open controller: %sn", controllername != NULL ? controllername : "NULL");
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.)

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

Here is a mod on Steam for Half-Life:

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:

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. :) 
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 ? 
says it all. 
Suggestion: Add option to disable auto weapon switch on pickup 
That's the realm of QuakeC, and not something that can be done in engine without the hideousest of hacklets. 
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. 
That explains why some of my sounds from a few mods fail in game. 
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. 
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. 
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. 
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. 
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. 
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. 
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: 
Here Is Another One 
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. 
lol, I skimmed past that.

Yeah that's even better. 
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. 
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. 
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: 
Ah, I see.

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

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. 
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. 
2 posts not shown on this page because they were spam
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.