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
FTE Cvars 
in_xinput 1 //enables xinput for 360 controllers.
joystick 1 //enables the old joy* apis that vanilla winquake used. some of the stuff will have been tweaked over the years, however... you'll probably need the binds menu to figure out which button is which. 
Does FTE splitscreen work with networked multiplayer? IIRC a few years ago it didn't. 
set 'allow_splitscreen 1' on the server if you want cl_splitscreen to work with a separate server (otherwise its only permitted for the local client by default). This setting has existed for as long as fte has had splitscreen support. 
This mean we can create an 8-player game using only two computers, right? 
Imagine a team deathmatch like this. Two teams of four in two computers. 
I Play Lots 
Of local multiplayer. So it would be awesome 
^ I Need A Job Like This 
Noclip Fun 
You know when you're noclipping and you hit a brush sloped in a certain way, and it takes control away from you and sends you floating vertically upwards until you exit noclip?

I know it's low priority as it only affects developers/cheaters, but I just wondered if it was an easy fix because when developing I seem to spend a lot of time wrestling with this quirk :( 
Never seen that... noclip always, well, doesn't clip with anything no matter what shape it is.

Is it just because I only make boxes? 
I think that's a trigger_monsterjump and the following tutorial I wrote over 3 years back on Inside3D is all you need: 
It's when i noclip into brushes that are sloped in two axes maybe??

But - it's definitely world brushes and happens to me constantly. 
That's weird ... I mean, as was said, noclip shouldn't be colliding with anything. At all. 
just checked - slope in only one axis will do it.

Hmmm..maybe it's only in unsealed maps?

Leave it with me, when I get a second I'll make a test map to demo it. 
I've seen it in id1 maps too. Or maybe there's two problems here and the one I've seen in id1 maps is trigger_monsterjump... 
A Test Map 
Would be cool by the way. It would be possible to trace through the physics code, selectively disabling sections of it, and home in on exactly what's causing it that way. 
it's obviously more complicated than I thought. I made a simple test map with a number of different slopes and noclip worked fine all the time.

I have no idea what's going on now. If I ever find a way of reproducing it in a test map i'll let you know. 
^ Moved To Drunk Thread 
theory: do you press space to strafe up, realize that doesn't work, then press x instead? I do that a lot when noclipping, and that might be setting a stale jumpflag on the player that doesn't evaluate until you're near a surface. 
I Have Had Similar Troubles 
and I think Lunaran is on the right track. I could always remedy the problem by mashing buttons until the player stopped moving again. 
i think the only time i have seen this it was from hitting a waterplane at the same times as a ~16 unit lip above the water. I think it was triggering the "jump out of water" code that lets you get up onto the shoreline. 
which implies that the quakec is responsible rather than the engine. 
Ok, get into waist high water. Go into noclip and fly around. when you hit geometry that would trigger the get-out-of-water-jump, you go on a space adventure!

Thanks metl.

I have so much waist high water in this map, that's why it seemed like it was happening all the time for me. 
i know some of these words. I had similar troubles during testing, a mystic force pushes you up when noclipping. But this also occured for me in maps with yery little water(RRP). 
Nothing more. 
Quakespasm 0.91.0 Released 
Enjoyable Changes 
Raised limits:
Default max_edicts 8192 (was 2048) and no longer saved to config.cfg.
Default heapsize 256 MB (was 64 MB).
Default zone 4 MB (was 384 KB).
Raised MAX_SFX to 1024 (was 512).
default zone is nice. it's a mostly unknown setting, and most people don't notice it like they would -heapsize, but it causes crashes if not set high enough. thanks for that! 
Someone should add a "-singleplayer" command line or something that just jacks everything to the max. I'm not networking, I don't care ... I just want to play this level without crashing. :) 
That's not actually necessary: the engine should be able to detect when a single player game is being played (if ( && !dedicated && svs.maxclients == 1) or something similar, and automatically tune itself. 
Anything that means people have to write less crud in configs and command line arguments is a positive step. 
mh - That would be awesome. 
None of those new defaults has anything directly to do with networking or single player, by the way.

max_edicts was a cvar in FitzQuake dating back to at least 0.80 because in earlier times some people would use GLQuake or another custom engine (there used to be tons of them) and GLQuake had a max_edicts limit of 640.

FitzQuake allowed you to set max_edicts from 2048 to 640 to make sure things worked in standard Quake without using a different engine so a mapper could ensure wide compatibility. 
Site Blocked 
Just as an FYI, I recently installed uBlock Origin as I finally got sick and tired of the increasing amount of ads online and mainly because the latest version of Chrome had a terrible freezing problem. One of the filter lists this plugin uses blocks Sourceforge. It can be disabled, but just thought I would let you guys know. Maybe switch hosting of the site to Github Pages? 
So you have an adblock plug-in that blocks SourceForge ...

And your idea is that to accommodate your adblock plug-in, that the Quakespasm guys should uproot all of their machinery and tools from SourceForge to GitHub because of your plug-in?

Is this a correct way to understand what you are suggesting to the Quakespasm guys? 
I use uBlock Origin too. Just click "Temporarily" olol 
I use FireFox + AdBlock Plus and Quakespasm's SourceForge page works just fine. That's all I'm saying! 
Not telling anyone to move anything. Just letting them know. Sourceforge has bigger problems anyway.

I'm a savvy user so yes I unblocked it. I was just posting an FYI. 
I Use 
Adblock. The original one written by one guy.

I don't really trust the others since I got massive slowdown from Adblock Plus one time and another from uBlock. 
Adblock ... I also installed a YouTube specific ad blocker. 
Called, surprisingly enough ...

"Adblock for Youtube"

I was just saying suggestion sounds a bit extreme. ;-)

And if other adblockers don't have issue, sounds like uBlock needs to get on the ball. 
Adblock seemed to hog resources. uBlock Origin is light as a feather, in my experience (Chrome). All the kool kids seem to use uBlock Origin also. 
I use adblock on its own to block youtube crap as well, seems to work fine.

It does have a problem with more than one ad blocker installed at once though (on chrome) because each becomes a new instance that doesn't play nice with the others. 
I use ABP... seems standard 
Just fyi �block Origin is the best ad-block around, especially in terms of performance.

Pro-neckbeards might like �Matrix. 
my keyboard doesn't have a � key 
alt gr + m 
I don't have any ad blocker specifically, just NoScript and Ghostery. However, my HOSTS file is nearly a megabyte in size and has close to 30,000 entries.

It's extremely rare for me to be blocked from a reputable site, and I almost never see an ad. 
Thanks for the new Quakespasm update. You guys are awesome. 
MD3 For The Shambler In QS Engine? :) 
So yea... this guy has an MD3 version as well... I convert him to MDL afterwards.

I would love to include a more precise version for folks to use in Quake Spasm in the future. If that lovely tech gets added then I would just for joy. 
OK here is my wishlist:

What are the chances of sticking in a simple external file read/write ability, accessed via QuakeC?

Something a bit like this? 
I posted it in the thread for the new Q1SP map, but whenever I try to start a game with this new updated client, the game exits to the desktop. Anybody know what's going on? 
Is this with the "Experimental build" in the oms3 thread (quakespasm-rf6d[...].exe)?

Argh, crash to desktop is the worst. No error message / dialog I assume?
Could be some dll conflicts.
If you don't mind trying a clean setup, this could help: create a empty directory. Extract all files in the QS zip. create an "id1" subdirectory in the same dir, and copy your pak0.pak/pak1.pak files to there. 
Haven't tried with the one in the oms3 thread, just the newest one in this thread and on the quakespasm site, 91 i believe. I'll try a clean install when I get the chance and report back. 
Alright so making a clean install didn't work either. To answer the previous question yep, no error message at all, just exits to desktop. 
Run it from a cmd window, might show something 
quakeisdead, ok, thanks.

Did a previous version of QS work for you?
There are 4 QS build to choose from for windows, 32/64-bit and SDL1/2 - which are you trying, or do all fail? the full download list is here:

One thing to check is enter "gl_info" in the console. It'll print a bunch of GL extension info, but scroll up with PageUp and check the GL_VENDOR, GL_RENDERER, GL_VERSION.

Another idea is launch with the "-condebug" command line option (create a shortcut and put it in the end of the target field.) This creates a qconsole.log file that may have some info on the crash. 
QC File Access 
If you're going to implement this, then I strongly recommend that you first implement a Sys_FileOpenAppend function in your sys_*.c rather than using the zone-memory nastiness in the original tutorial. I have no idea why the original authors didn't do this. 
Not a mapper or a programmer so I have absolutely no idea what any of that is. I guess I'll wait til the next stable release of Quakespasm to play again 
Case-sensitive Console 
I just realized you can type in small or big.

Is this a feature for case-sensitive OSs?

In Windows versions it does not seem to be a very useful feature, because if you happen to use a capital letter in a console command it says 'unkown command'. 
RE: Case-sensitive Console 
Seems like it is not case-sensitive for commands, but it _is_ so for cvars. The behavior seems to be the same in the original quake source too. 
all quake engines do this. it's not very useful. 
I don't know the difference between command and cvar.

If you type 'mAp e1m1', it will load e1m1.

If you type map E1m1, it won't.

Is that what 'it is not case-sensitive for commands,
but it_is so for cvars' means? 
"map" is a command. What the engine not being case-sensitive for commands means is that "map", "Map", "mAp", etc will all work and will all change the map.

It's actually even worse because the engine is case-sensitive in some places for commands, but not in others. Cmd_AddCommand for example is case-sensitive, so it would in theory let you add "mAp" and "map" as separate commands. Cmd_ExecuteString is case-insensitive so which of the hypothetical two it actually executes depends on the order they're added in (or something else if you e.g sort commands for faster finding).

All of this is clearly buggy behaviour, but is it the kind of buggy behaviour that legacy content may have dependencies on? 
Are you thinking like cfgs and stuffcmd/localcmd? 
Not thinking anything in particular other than I've been in a "put the bugs back" scenario before, so caution seems merited. 
All of this is clearly buggy behaviour, but is it the kind of buggy behaviour that legacy content may have dependencies on?

Is Cmd_AddCommand used for alias commands? If not, then surely only the engine is going to be calling it. That should make it safe to fix in a given engine. 
i was thinking there may be some mod that executes commands from a config to set things up and maybe they typed the command with/without caps. 
Is fence texture support on .mdl planned? 
Is there a way to change water color? Underwater everything is beige and in dark corridors I can't see anything. 
try setting "gl_cshiftpercent 50" in the console (default is 100) 
Mark V has a cvar r_watercolor for the underwater cshift color. There is also r_lavacolor, r_slimecolor.

In the engine code itself, it is referred to as called r_watercshift as a more descriptive internal name. 
Thank you, ericw. Now underwater fights aren't a pain anymore.

PS. I'm planning to speedrun a forgotten map pack. 
Suppress Launch Dialogue 
Am I correct in understanding that, on OSX, there is no way to suppress the Quakespasm launch dialogue (which allows the selection of command line parameters and resolution)?

I am writing a shell script to compile my map and then launch it in the game and it would be great if I could pass an argument that tells Quakespasm to suppress the launch dialogue and go straight into the game engine. 
You Can 
open ./ --args -nolauncher

Substitute the correct bundle name, of course. 
Suppress Launch Dialogue 
Excellent, thank you. 
how do you launch this engine windowed with a specific size?
when working on maps, i prefer to keep it windowed... i am using these args:
-vid_fullscreen 0 -width 1440 -height 900 -bpp 32
it starts windowed, yet it is not using the size i specified with width and height... 
Any chance of a command similar to "kill", but...

like kill, it reloads the map but it preserves the player's position, angles, and flags such as god, notarget, noclip etc...

When mapping I find the time it takes me to noclip over to the distant area I was working on after each map reload, really adds up, especially when making millions of tiny incremental tweaks to lighting and things... 
This works fine for me:

c:\quake\quakespasm.exe -width 400 -height 300 -window 
cool, thanks. looks like -window does the trick :) 
Use "testplayerstart"? 

not a command it seems 
could you do that by relying on an alias with multiple commands and some QC support?

impulse 50; kill; impulse 51

eg: impulse50 encodes player position and angles into temp1, kill restarts the map, impulse 51 uses data in temp1 to reset position? 
well I was hoping there would be a solution that doesn't require the use of a custom mod 
ok I can abuse the save/load system to reload the world whilst preserving the entity state of everything...

that may do for now :} 
It is an entity i place to avoid noclipping 2000 units over and over.
AD doesn't have it, i used the normal "info_player_start" there.

You'll see a warning of multiple start entities in the engine, usually the engine picks the first it finds to place the player. (or was it the last?eric?) 
Right - I have never managed to get region compile to work in netradiant, so I'd have to stick to using one info_player_start and keep moving it around with me, which would be a pain.

Meanwhile, I have stuck this in my config:

bind "F5" "echo Dev Reload...; wait; save devsave; wait; load devsave;"

Of course no entity changes can be viewed with this, but it works a charm for refreshing the world geometry and lighting, which will save me a bunch of pain already. 
Windows Defender Is Detecting Quakespasm As Malware 
Windows Defender is now detecting the latest QuakeSpasm as malware:


It detected it when I tried to run the version already on my computer, and then when I tried to download the engine again, it caught it again on the download. 
Sourceforge Is The Asshole Here 
Lets move this project to github? 
That Were My Two Cents 
Another Image 
This image shows the culprit file when it detected it on my existing installed version:

See that it flags the file quakelibopusfile-0.dll

I'm assuming it's a false positive, but it's stopping me from playing it right now :( 
delete your HDD, throw the screen out the window(just to be sure), and melt your HDDs with thermite(to be super sure). Thanks Sourceforge! 
Note that Windows Defender has only just started doing this - the version I had on my PC has been there for a couple of weeks with no problems. Dunno why Defender is sharting over it now :/ 
I Know The Answer To This 
use tails. 
Windows Defender isn't detecting anything for me. I just updated the definitions now and am running the latest windows 10.

Would you mind uploading that dll somewhere, or the whole .zip that is being flagged? I'd be curious to see if it has been tampered with or is binary identical to what it should be. 
microsoft's virus scanner spuriously detecting false positives in software that uses technology that might be a competitor to their voip product? who'd have thought it!... 
Adware Is As Bad As Cancer. 
Once they started this, they prepared their demise. In my view. 
Windows defender removes it so I don't have it to hand but the file that this link downloads has the "trojan" apparently: 
Re: Sourceforge 
Hey Guys,

Not to sound like a smug a$$hole, but I did mention problems with Sourceforge a month ago here and was treated poorly by Baker.

You should just move the hosting to GitHub Pages. 
We Don't Know It's Sourceforge 
Right now my bet is it's a false positive. Weird no one else is getting this. Windows 8.1 using up-to-date Defender. 
Re: Sourceforge 
Well whether it's a false positive or not, Sourceforge has been caught red handed last year injecting malware into software they host. I wouldn't trust those guys anymore. 
Last year the Direct X version of Mark V was continually flagged as a trojan by Microsoft while 61 other file scanning services say it is not a trojan.

As a result, I now I distribute the Direct X version in a separate zip.

It's somewhere in the Mark V thread around post #732 
What Tamarisk is referring to is this:


Developers must opt in to a new "DevShare" feature.

If you opt in, your project gets embedded in SourceForge's custom installer.

That custom installer may bring crapware along for the ride.

Important thing is that if the developer doesn't opt in, none of this happens.

Personally I think that Tamarisk is scaremongering a bit. 
Scaremongering eh? Did you even read that article mh.

While true that the DevShare is opt-in, SourceForge has been caught red handed doing other not so nice things. Repackaging "abandoned" projects for one. 
Done And Done 
Anyway, I'm done with this thread until it goes back to the real purpose, to discuss Quakespasm. You know this is just typical of the BS online nowadays. Try to post some useful information and get some nitwit shooting you down. Have a nice day folks. 
Home Of The Critics 
Func_msgboard is home of critics. It's what makes this place high quality. Participants here are expected to be able to explain/prove what they say or defend their thought process.

If you want to say Sourceforge is messing with a .dll fine, but you better be prepared to back it up with evidence.

That's just high standards at work. 
Sourceforge has new owners, clam down...

Antivirus is a fucking laugh. 
"If you want to say Sourceforge is messing with a .dll fine, but you better be prepared to back it up with evidence."

^^ This.

I mean, seriously, dude .. YOU brought it up! Don't get pissy when someone asks you to prove it. 
Kinn, when I download using the file I get has this SHA1 sum: 080f764fd7ace0764906a4d524e9463c47731f3a
If you want, check the sha1 on the zip file you download to make sure it's the same.

Here's an alternate download with the dll's:
The libopus-0.dll file is in the subdirectory: quakespasm/Windows/codecs/x64/

Note that this dll should be binary-identical to the one in the from SF (it is for me.)

My windows defender info is:
The archive comes up clean with both Windows Defender and Trendmicro HouseCall.

Sorry you had to deal with this, hopefully it's a false positive. 
Thanks - both of those links work for me without Defender shitting a brick :)

The SHA1 I get is 080F764FD7ACE0764906A4D524E9463C47731F3A

which is the same as yours (typical it comes out uppercase making it more annoying to compare hehe)

My defender version is now this:

So yeah it looks like a false positive and Defender's new virus definitions have sorted that shizzle out hopefully. 
since sourceforge changed it's owners in what 2012 I tried steer away from it. I used to like the service but not anymore. I'm always reluctant when stuff is hosted there and it leaves the impression of an abandoned project.

I don't understand why quaskespasm is hosted there. I don't even care that they changed owners again in 2016 because there's github and that service I do still trust in and also really like.

I'd leave sourceforge just for the sake of not making people download from a site they distrust. I don't care if they get their shit together or not. 
Yeah, let's put everything on Github because that is never going haywire. Self host, you lazy people... Gitlab is fun.

flp: Read my post above. 
is this ever going to happen? i cant bring myself to game from a desk when i can game from a recliner.

let me play quake again, please. 
shub: Yes, soon! I have it working pretty nicely - played some of AD with a 360 controller, just need to polish up a few things.

.. continuing from the RRP thread about Barnak's HOMs when using fsaa + "r_oldwater 0" + OSX 10.6...

Baker, I found a workaround, adding "GL_SetCanvas(CANVAS_DEFAULT);" to the end of R_UpdateWarpTextures.
R_UpdateWarpTextures leaves the glViewport configured for the warp texture (the square in the upper-left of the screen), and R_Clear is the next thing to happen after R_UpdateWarpTextures, so my guess is that fsaa activates some code path within the mac GL implementation where glClear is broken and uses glViewport as the area to clear..

Here's what it looked like for reference:
The second shot has gl_clear enabled, but you can see it's only clearing part of the screen. 
Ironically, the bugged glClear behavior would be better standard behavior. 
glClear should respect scissor test but not viewport, which is a bit more flexible IMO. 
360 input - awesome

Will we have tons of commands where we can fine-tweak deadzones, accelerations, and all that? 
Yes, the bug I described looks like your screenshot. But on Rubicon3, it is terribly much more messy, with an extremelly luminous background (skybox ?).

I'm still wondering why it only happens with this Mod, and never saw the bug on any other Mod or map before. 
It was probably RRP's quake.rc with settings put in there. I would expect r_oldwater was in there. 

I made a few personal changes to Quakespasm to solve a few minor annoyances I had. I was told I should show them off here in case any of them could be added to the main project.

What I've done:

QW hud option (cl_sbar)

Did the legwork to adjust the weapon offset on screen, I noticed some murmuring in here about what the best behavior should be as QS draws it with no offset. I decided to make it work closer to WinQuake, however I also made it adjust according to your status bar scale setting and status bar alpha, so it isn't ever too far up. There's some screenshots in the github link.

Adjusted centerprint message canvas so it's always above the crosshair. Depending on settings they used to cover the crosshair or even appear below it!

Right now I'm adding a new feature, automatic UI scaling. What it will do is when any sbar/console/whatever scale cvar is set to 0, automatically set the scale factor to make it fit the screen as cleanly as possible (integer scaling). That way new players won't have to mess with cvars to be able to read things at high resolution, or mess with the scale slider until it's even looking. Could be handy as a possible default. 
Great work man!! 
I finished and pushed the auto scaling feature. I've also been experimenting with a widescreen status bar implementation when sbar alpha is 1, though it's a bit hacky (lots of tris)

Does it look good or is everyone used to the regular border graphics? 
Looking From A Phone Screen 
It's a nice idea, but the empty boxes above bother me more than they should.

Ideally this sort of thing needs a proper layout design first. Try grabbing a pen and paper - for me random scribbles are good during the creative phase and the computer during the productive one. 
Side note: Don't want to interfere with the current conversation.

Quakespasm inherited bad centerprinting from FitzQuake. No other engine from DarkPlaces to ezQuake to WinQuake to JoeQuake has a centerprinting problem (Mark V does not have the problem either).

The FitzQuake centerprinting location can't be solved by moving text up or down a line, because "what line" it prints on was never the problem ...

It's a multi-factor problem that will resurface with a different combination of settings if "fixed with a hack" --- the problem is the "definition of a line" is not consistent across various settings.

(Please carry on with existing interesting conversion ...) 
My description is a bit simplistic, I did not simply change a y-coordinate. I reorganized centerprints to its own GL canvas that spans the height of the screen, and I have the lines start printing in reverse order from 1/3rd the height of the screen. This keeps it off the crosshair even when the sbar is fully scaled up. (if there are more lines than would fit in that area, then they do start covering the crosshair, but this would have happened in any engine)

Winquake (and I'm assuming the other quake engines you mentioned) did it by drawing lines 35 pixels from the top of the screen, scaled to whatever scaling values each engine uses. The drawback is the smaller the text scale value the closer it is to the top of the screen, which draws it away from the player's focus more and more.

Quakespasm's old behavior drew centerprints in the Main Menu GL canvas, which originates from the center of the screen. This limited the height that centerprints could start at without shifting up the main menu as well. 
To Ijed 
My intention with the widescreen sbar was to be able to construct it in-engine from the sbar graphic, that way it could be compatible with whatever mods replace that graphic. Since QuakeC can't rearrange the HUD, any such graphics would fit the same layout and probably look about as good. 
+1 Sounds like you are detail oriented and anal retentive and do your homework and then plan.

(I like this guy already!) 
Back On Centerprints 
I checked Mark V and it seems we had the same idea. Yours just takes into account status bar height as well. Mine doesn't, I based it on Winquake's offset at 320x240.

I guess I remembered WinQuake's behavior a bit wrong, it only used fix offset from the top when there was more than 4 lines.

Still, what I did was make it always originate from about 1/3rd the height of the screen. The difference is I set it so that point is where the LAST line will be drawn. If there are more lines, they originate from higher, unless it would start offscreen. 
At Baker 
True enough, it's why I did this fork to begin with...:P

@ijed: How's this? Now it skips the vertical lines 
Controller support :)
Amazing the amount of stuff Eric is doing.


The QW Hud option is great, but i'm not sure about adding the option to the main option window. Probably ok... but the Menu-Item should be something meaningful, like "QW Style Hud".

Weapon Offset changes.. not sure about that.
Personally, i'd favour bigger field-of-view over re-placed weapon models.

The other things - an auto scale option is interesting, but not gonna bastardise the scale widget like that. It'd have to be a cvar only. And not keen on the widescreen status bar. Centerprint should be left as-is if crosshair 0, but otherwise - i don't use the crosshair, so can't say if it's an improvement. 
"The drawback is the smaller the text scale value the closer it is to the top of the screen, which draws it away from the player's focus more and more. "

Where the hell did this guy come from? Engine coders that preemptively analyze for situations that aren't on the screen.

(But yeah, that's true and fixed in Mark V. Probably DarkPlaces too I would hope because if LordHavoc cared about getting the gun to be in the same place in all resolutions, no doubt he thought about the text placement too. The gun thing is of course fixed in Mark V.) 
"The difference is I set it so that point is where the LAST line will be drawn."

But you can't do it that way. Some mods print 20 lines of center print.

(Ok, so he's extremely intelligent and introspective but isn't a grand master --- I'm kidding around a little with you) 
Sounds like some nice changes, thanks for contributing!

I'm not sure about , I think we'll want to keep the original tiling background. I imagine most people use a bit of status bar alpha so they don't see the tiled part anyway.
One change that could be good though is scaling the dark tiled part so the pixels are the same size as the main part of the status bar; currently QS doesn't scale that part. e.g., here's winquake at 640x480, sceenshot scaled 2x: 
Wow, thanks for the feedback guys.

@Baker "But you can't do it that way. Some mods print 20 lines of center print."

Simple "if (y < 0) y = 0" check takes care of that :)

A cvar to disable the weapon offsetting back to regular QS behavior is simple enough.

As for the wide-screen HUD, maybe it's not worth it after all. At least the regular tiling border is a close enough color to begin with (unlike Doom)

As for center print positioning I guess that's a personal preference sort of thing. I guess I just don't like text obscuring where I'm shooting.

Can cvars have multiple callbacks? If autoscaling was made a cvar it would be handy if any changes to the regular scaling cvars would disable it. 
Re: Tiling Sbar 
no way. those empty boxes would drive me nuts.

why even show the border at all? just remove the brown areas on the side of the sbar and float the sbar in front of the screen. 
why even show the border at all? just remove the brown areas on the side of the sbar and float the sbar in front of the screen.

Yeah, that would be my first thought too :P 
It's a "What do I need to find!?" OCD thing. 
Here Is A Fun One ... 
Omicron Bots mod has a feature Quakespasm can't use.

"registered 2 - the patch does not load the models supplied with the bots"

You can't set registered 2 in Quakespasm.


Omicron Bot Mod Download 
Controller Support 
Finally committed this! Windows builds available here ( r1293):

I'll need to add some documentation later, here is a first stab though:

* joy_deadzone - fraction of the stick travel to be deadzone, between 0 and 1. default 0.2.
* joy_sensitivity_yaw/pitch - max angular speed in degrees/second. Defaults are currently 300 for yaw (turning left/right) and 150 for pitch.
* joy_exponent - for the look stick, the stick displacement (between 0 and 1) is raised to this power. Default is 3. So a value of 1 would give a linear relationship between stick displacement and fraction of the maximum angular speed.
* joy_invert, joy_swapmovelook - enable to swap the move/look sticks or invert the look stick. Default is move on the left stick, look on the right stick.

Some of the controller buttons are hardcoded: back=TAB, start=ESC, dpad=arrow keys. The others are normal bind-able keys: L/RTRIGGER L/RSHOULDER, L/RTHUMB (pressing in the sticks), A/B/X/YBUTTON.

quakespasm.pak's default.cfg has been updated to give some default bindings, so make sure to install the quakespasm.pak. L/R shoulder buttons are bound to weapon switching, L/R trigger are jump and attack. A and B are hardcoded to operate the menu, but they're not bound to anything in game by default. If you choose "reset config" in the menu, these default bindings will be loaded, and I think "exec default.cfg" will also do it.

Other stuff:
The key bindings screen in the menu now supports 3 keys per action. This could be annoying for non-controller users, so maybe controller bindings/settings should get their own menu page. I just try to avoid adding things to the menu if possible.

Anyway feedback is welcome! Especially, are the default sensitivity/acceleration settings good? 
Amazing, this feels really responsive on the default settings. I blasted through episode 1 and I don't feel like I was hindered too much by the pad.

I bound jump to LT and shoot to RT and it was great. I wanted to have weapon up and down on X/Y but for some reason weapon down doesn't work??

I'm really hoping that at some point we can get split-screen working 2-4 player so I can run "lan" deathmatches and co-op from a single pc set up. I'm not sure how you would implement multiple pads but this would be a dream come true IMO.

Yes, I still play games in the old-school console way with my buddies even though I'm an old codger. ;) 
Here's a demo of me playing through Episode 1 with a pad -

As you can see I didn't really have much trouble, admittedly I can go through a bit quicker with the keyboard and mouse but it's still fun. In-fact it's almost more fun because of the slight handicap, some of the challenge was reintroduced. 
Awesome, glad to hear! Not sure why weapon down didn't work.
Yeah, local multiplayer would certainly be cool to have for lan parties.

I've had a lot of fun testing this too, played a few maps from AD with it while working on it. 
Possible feature?

Instead of weapon cycle it could be interesting to use the D-Pad to cycle through weapons.

Left = SG/SSG switch
Up = NG/SNG switch
Right = GL/RL switch
Down = Axe/LG

It will be a little bit like a weapon wheel but less crappy. 
Years ago there was a way of getting splitscreen to work on Quake 2 I think it was. The implementation was a bit funky, you opened separate executables and there was a window that allowed you to input the in-active window as well as the active window. You connected to your own pc through your LAN.

I tried searching for it but all I could find was this Quake 3 Arena source port that has native split-screen - 
Multiple Monitors, Multiple Engines? :) 
Open up 2 Quakespasm clients.

Use the new borderless feature.
Carefully position the windows and then toggle the borderless. Do this twice.

For the Window you touched last, the player uses the mouse and keyboard because only the active window can actually receive keyboard and mouse input in Windows.

For the Window you didn't touch last, the player uses the 360 controller. This will work because I suspect the 360 controller code won't check to see if it is the active window (but I didn't look) because the original Quake joystick code never did.

Now the guy using the mouse is going to own the 360 controller dude, so play coop.

You might want to set sv_aim 0.93 (the default Quake sv aim) so the 360 controller dude gets a little bit of aim help. 
D-Pad weapon cycling could be hacked in like this:

alias ng1 "impulse 4; alias ng ng2"
alias ng2 "impulse 5; alias ng ng1"
alias ng ng1
bind leftarrow ng

That would make leftarrow cycle between NG and SNG. The problem is you might have to tap it twice if you have the SNG but not the NG, the first press would try to select the NG.
Not sure if that can be improved on without doing it in QuakeC.

I can add a cvar to select which controller number is used, I assume SDL2 properly handles multiple controllers plugged in. Running multiple QS executables as Baker mentioned might work OK, I'm not sure if the background window gets joystick events, need to check. Also, currently sound is muted when a QS window loses focus. 
If the mouse/keyboard computer ran Quakespasm older Quakespasm without controller support and the 360 controller window ran newer Quakespasm with 360 support ... 
typo: not "computer", "window". 
you could do it like

bind leftarrow "impulse 4; wait; impulse 5"

This will pick SNG if available or NG otherwise, or do nothing if you have neither weapon. 
failed at my own board markup!!! 
I think native support would be more desirable than workarounds. The quake 3 source port shows its feasible. 
Looks like FTE has splitscreen support... would be interesting to see if controllers work with it! 
Sorry to do this again, but I went to try this out and Windows Defender is shitting itself again. it claims to find:

Trojan: Win32/Pocyx.gen!C!plock

in SDL2.dll

This is from downloading this build:

I'm sure it's nothing, but is anyone else having issues? 
Well I just tried sending that link to an online virus scanner and everything seems to check out, so

wtf is wrong with my windows defender? 
You've Already Got A Virus That Injects Itself Into Everything You Dow 
Czg - Is That A Thing? 
Ok...any idea why it would only pick on quakespasm downloads? 
Do you mean controllers working w/ splitscreen particularly, or FTE in general?

FTE seems to have controller support:

...but I haven't tried it myself. 
I can't get pads to work with FTE at all!

I have enabled the joystick CVAR but it only lets the d-pad work for some reason. 
in_xinput 1; in_restart
someone tells me that controller axis works, but buttons don't or something. not sure what's up with that, it might also be specific to csqc-only mods. all I can say is that faking xinput inputs (I've no physical hardware myself) appears to propagate events through my code in both csqc-only and ssqc-only mods, so I'm not sure what's up with that. 
Custom Mdl Doesn't Load From Id1/progs 
But if you put it in some folder ("quakedir/s/progs" for example) and enter "game s" then the model will be loaded and used.

quakespams 0.91 windows-x32-sld2

You can test it with a new shambler: 
That's normal Quake behavior. WinQuake and GLQuake will do the same thing. Files in a pak > files sitting around in the folder. 
Just recently discovered the "maps" and "mods" commands and tab completion by accident. Don't know if these are Quakespasm-specific features, but they're great!

A question, though: if I understand things correctly, the "maps" command lists all of the maps in whatever directory you're in (i.e. whatever "-game" option you've selected), as well as the maps in id1/maps. Is there a way of showing only the maps in the current mod directory? E.g. let's say I started up Quake with "-game retrojam1" is there a command for listing only the maps in the retrojam1/maps directory?

For that matter, is there a list of QS commands somewhere? 
Oh Wow... 
Didn't realize it was possible to use Quake with external controllers.

Will have to investigate this. 
List commands -> cmdlist
List settings -> cvarlist 
Thanks, Baker! 
I'm guessing the answer to my first question (whether it's possible to list just the maps from the current mod directory) is "no"... 
Segmentation Fault When Trying To Load A Particular Map? 
Not sure if this is a QS-related, mapping-related or perhaps even TrenchBroom-related issue, but: I've just made my own version of this test map by Rick, and when I try to load it in Quakespasm, QS just immediately quits and says "Segmentation fault". Other maps etc. still run fine.

(On another (possibly related?) note, I always have to add "-zone 4096" whenever I start up QS, otherwise I get

QUAKE ERROR: Z_Malloc: failed on allocation of 4100 bytes

I once read the "-zone 4096" tip somewhere and since it works, I've been using it ever since ... but I don't actually know what it does and was wondering whether it is normal that I can't even run the stock id maps without it. Does it mean there's something wrong with my QS installation?) 
it's been a few years, but iirc, zone is a special space in memory different from heap where textures and such go. in qs, zone is used for strings, so if you have a mod with a lot of text, it runs out of space to store it there. other engines use other parts of memory, so you don't always need more zone space. 
The fact that this even matters is another artefact of Quake's MS-DOS origins. No virtual memory, no multitasking. In Quake 2 "zone memory" is just a wrapper around malloc and the issue of potentially running out of space never even comes up. 
I'm guessing the answer to my first question (whether it's possible to list just the maps from the current mod directory) is "no"...
afaik that's correct, there's no way to list just the mod's maps.

The most common reason I get engine segfaults when loading maps is:
- if you have no brushes in worldspawn (all brushes in func_group) + compile with tyrutils (my version at least), the bsp will segfault when loaded in engine. That's a bug in tyrutils I haven't got around to tracking down.

If that's not the cause of your issue, post your map source and bsp, and QS version. :-)

Re: -zone 4096, it sets the size of a memory pool in the engine to 4096k (4MB). The latest QS release 0.91.0 does this by default. It seems wrong that you get a crash on launch without -zone 4096, though.
IIRC, QS keeps the mod/map filenames for tab completion in zone.
Are you compiling QS yourself btw? 
Yeah - I have a patch similar to your i3d tutorial on replacing zone with malloc. Should probably do that, as well as the cache one.. 
Thanks, Necros, Mh And Ericw 
ericw: Thanks, that was exactly it! I had only func_groups in that map, and when I ungrouped one of them, it worked. :)

I'm running QS 0.90.0, so I guess I need to update ... once I manage to remember how one does that. It's possible I compiled it from source (it's been a while), but if so then not without help. A lot of what I'm using I got up and running by following instructions on this board and elsewhere without really understanding the commands I'm typing.

Is it possible I did something wrong and that that's why it won't work without -zone 4096? 
Oh wait, can't I just download the first Linux precompiled, uhm, package (or whatever the correct term is) from and stick somewhere in my home directory? I think that's what I did to get 0.90.0. 
About Controller Support 
The xinput support is great!

The only thing I would suggest is acceleration functionality, where you don't instantly reach the top turning speed but rather ramp up to it over time, even when the stick is all the way in a direction. That way you can have fast turning but retain precision aiming. It really helps it feel more natural.

Pretty much every console shooter makes use of this. 
Zone Memory 
Heee, the zone memory system comes nearly straight from Doom. Fun times... 
Color For Dynamics Lights? 
Is it possible to add as an option? All I really want is orange lava balls, but it might be nice to have color light available for everything. 
All I really want is orange lava balls

What a marvelous sentence. 
No trojan warnings for me with the latest windows defender definitions (March 8). Weird. See if updating Defender fixes it (that worked last time, right?) 
Xinput/controller Support 
ericw... you have made america great again.

im off to do my happy dance. 
Needs splitscreen in order to receive his free handy j 
It would be great if this engine had an option, or default, so it handles stairs like Q3 does.
Or more so, really small edges, so when you jump up some stairs, you can't get stuck in them.

I know this isn't a thing in Q1, but it really improves the movement 
Yes Please 
That would improve gameplay on those maps with unclipped overcomplicated floor design. 
Is gooning with the player physics not a crossing a bit of a red line? 
Yes, I was thinking that too. But the reason why I choose to mention this is cause I don't think that would be crossing the line, this small specific "fix".

I can see if even more things were added, like double jump, ledge leaps, etc etc.
I think Id added this small thing so you wouldn't get stuck as easy when jumping too close to something.

Actually, I'm not sure what the difference really is, I mean, it's not like you are jumping close to a ledge in Q3 and magically just appear on top of it, but in Q3 you can jump around in stairs and not get stuck. 
it's not like you are jumping close to a ledge in Q3 and magically just appear on top of it

Not sure if it is related but q3dm13 mh? 
Maybe you are right, can't try it now.
In any case, it's not an issue in Q3 afaik =) 
Case Sensitive Autocomplete 
makes it harder to run some maps 
Quake Physics 
is a little twitchy. I personally hate that a floor connected to a slope will often stop you dead as you transition onto the slope. It's like there is a forcefield stopping you. 
In quake2 and darkplaces you can do this, i think in darkplaces it's called "air step." It's a nice feature because you won't get snagged on things like running across the floor grates in dm4.

I added it to Fitzquake early on, but deleted it before releasing because I realized it changes gameplay too much. The player can jump onto much higher crates with the feature -- ~40 without the fix, ~56 with the fix. Of course it's tunable, but the lower you tune it the less beneficial it is. 
Fifth, I noticed that in ad_zendar, when you climb the bricks at the start and go up the slope, there is an invisible wall blocking you at the top of the slope. It doesn't happen in DarkPlaces though - maybe LH fixed a bug in the collision code.

QS probably errs on the side of leaving everything vanilla; touching physics can have unintended side effects like metl mentioned. 
modern quakeworld servers have airstep enabled via the pm_airstep cvar.
even small airsteps of 1 or so should help work around the invisible barriers issue that results from bsp hull precision (tbh I don't actually remember quakeworld ever having that problem).

you could also only allow it when near to the ground which would fix steps (but also mean people could bunnyhop far too easily) without making ledges too easy.
that bunnyhop thing is why its not enabled by default in fte. I believe it is enabled by default in dp. 
I try my best to avoid using ramps in my maps specifically for this reason. I fudged the ramps in q-deck by having a "lip" to prevent getting caught when moving down the ramp. 
...this small specific "fix"...this small thing...

First rule of engine coding is that what may seem to be a small thing from a player's perspective quite often isn't.

Second rule is that this applies doubly so when it comes to the physics code.

Anything involving Quake physics code is almost definitely not a "small fix". It may seem small to you because you're just describing one single problem that only seems (to you) to happen in certain very specific circumstances. But the physics code has ways of blowing up spectacularly and innocuous-seeming changes in one place can have huge repercussions elsewhere. 
Go to E1M1 quad secret area. Stand under the screen with the world on it. Lower gravity a little. Jump. In a normal engine, you'll hit your head on nothing. In DarkPlaces you will jump unimpeded.

It is odd. 
That's a trigger_multiple with "health" "1". I guess it's solid? 
What is weird is load up ezQuake and -- like DarkPlaces --- you won't hit your head on the invisible trigger.

Go figure ...

So normal Quake = it is there.
Quakeworld/DarkPlaces = it is not there. 
Frogbots Support? 
Hey, I've been learning to play with bots in Q1 and it's come to my attention that compatibility with some bots is borked in QS.

Frogbots seem to be the best bots around but sadly they're one of the bots that don't work. Frogbots work fine in Fitz et cetera

Is it possible to add support back in to QS?

PS: The Xinput support is a godsend for my tired old wrist! Thank you. :) 
Auditory Funniness 
"Couldn't find a cdrip for track 0" the console tells me.

happens in aop, and in some custom maps like teacups. playback works fine *most* the time(?) so i am at a loss.

hoping this is just a case of operator error.

using win7 and the xinput build of qspasm. 
I Think You Can Ignore That 
I just checked and AOP's qc code sends a "svc_cdtrack" command to the engine requesting track 0, which is what causes that warning to print. Possibly QS should suppress that warning message, not sure.

btw, valid music tracks are 2-11 for the original soundtrack. You can enter a console command like "music track03" to start music manually, if a map doens't have it set up. 
Thanks Eric 
hmm. well ive got my naming convention correct, and my oggs in the proper dir. so perhaps i will just go with the manual playback for now. thank god for the console.

i wonder if the tracks playback sequentially in the game, or what. i need to find out. i guess that is the real problem now? not knowing what track an author has intended for their map. 
It doesn't sound like an issue with the engine or with your setup. It sounds like the mapper forgot to specify an appropriate music track. 
i wonder if the tracks playback sequentially in the game, or what. i need to find out. i guess that is the real problem now? not knowing what track an author has intended for their map.
They don't play sequentially; mappers can set a key on the worldspawn entity of their maps to specify a cdtrack.. I forget the key off hand. All of the original game maps do this.
e.g. the base maps e*m1 all use the more industrial sounding music track. 
I think mappers used to set the music track to track00 so that no music would play during their map even if a CD was in the drive...

I vaguely remember someone creating a track00 song so that one could listen to that instead if one liked (I think that was around the time Travail was released). 
it would be cool if there was a way for the user to specify a custom playback via autoexec.cfg ie

music_eXmX "trackXX"

manually playing tracks via the console is an acceptable workaround, i know 100% aop compatibility is not a huge community priority :D 
You could always bind keys to whatever tracks you like. Then it would only be a single keystroke instead of going into the console every map. :) 
// entity 0
"classname" "worldspawn"
"message" "Centerprints this text on map start"
"worldtype" "0" // specifies silver and gold key models
"sounds" "10" // specifies CD track to loop
"wad" "path to wad; path to wad" // paths to texture wads used
"fog" "0.025 0.50 0.50 0.50" // fog density and color
"sky" "skyboxname_" // specifies skybox to use 
I Just Found A Problem 
My main laptop has a partially broken keyboard; the C and D keys doesn't work. Due to this, to play Arcane Dimensions I've went to the Controls menu and configured QuakeSpasm 0.91.1 like this:
bind 2 +forward
bind w +back
bind q +moveleft
bind e +moveright

Now I'm using an external keyboard, so I've decided to reconfigure the movement controls back to the WASD keys. I've done this through the Controls menu again, but to rebind the "impulse 2" to the number 2 key I'd have to use the console.

And this is where the problem happens. Take a look at the ABNT2 keyboard layout. This is the keyboard layout for Brazilian keyboards. Also, remember that vanilla Quake engines does not require quotation marks around the command string for the bind command. But QuakeSpasm does, and instead of using a fixed American keyboard layout like vanilla Quake does, QuakeSpasm uses the actual keyboard layout from the OS.

Now put these factors together, and you'll understand the problem. QuakeSpasm made it impossible for me to rebind impulse commands through the console. If I don't put quotation marks, QuakeSpasm doesn't accept the binding, and when I try to type the quotation marks, QuakeSpasm toggles off the console - even if I type "disconnect" to get a full screen console (it switches to the main menu).

From an usability perspective, this is an awful situation. The only way to restore that binding without resetting everything else is to manually edit the config file.

Such problems must be predicted when designing input interfaces. Even the American keyboard layout can have problems in some cases, since the tilde character is used in some filepaths. The solution I've implemented in the latest versions of Makaqu is to not toggle off the console when pressing that key; the Esc key should be used instead.

Also, an additional user-friendliness feature can be to only toggle off the console by pressing that key if there's nothing typed in the commandline. That would prevent the user from starting a line with tildes, quotation marks or other stuff, but the user can work around that by inserting a space first. 
Not knowing history means being doomed to repeat it:

DarkPlaces 2007-03-15

"Changed default value of con_closeontoggleconsole cvar to 1, to put an end to the nearly 2 years of complaints about the tilde key not closing the console." 
That's an awesome bug report for the Quakespasm guys.

I'm just pointing out your suggestion was the most universally reviled feature that DarkPlaces ever had and people complained about it without end. 
That's why I also suggested to only close the console if the commandline is empty. 
Thanks for the detailed report Mankrip.. that does sound annoying. :(

I was hoping all keyboard layouts would have some unimportant character at the tilde key location, but double quotes break that assumption. That microsoft site looks really useful.

I'm not sure what fix we should take.
- Maybe 'Alt+console key' suppresses toggling the console, and types the character instead?
- a '-uslayout' command line option makes the keyboard act like a US layout, like vanilla Quake? 
I'm not sure what fix we should take.

Making the "toggleconsole" key not toggle the console if the console prompt isn't empty should be a good solution for everyone. When the prompt is empty, let it toggle as usual.

I've just created a tutorial for it, and implemented it in Retroquad. Worked perfectly:
User-friendly tilde typing in the console 
Making the "toggleconsole" key not toggle the console if the console prompt isn't empty
Sorry that is a really annoying feature in DP, that in order to close the console you have to clear the console line of anything typed! Having a single key toggle the console regardless is certainly a good feature. 
Why not just make it so the user can specify which key toggles the console?

Am I missing something? 
of course you can already do this. just edit the config.

bind "~" "toggleconsole"

replace ~ with your key of choice

So what's the bloomin' problem here? 
Kinn: Looks like ~ is hardcoded, even if you bind another key to toggleconsole. It was like that in winquake too. Not sure it's a bug, there could be some value in having it hardcoded in case a mod rebinds it by accident. Anyway, a cvar to move it completely to another key might be good.

I agree with sock, blocking the toggle when there is text typed annoys me in DP because the QS beahviour is muscle memory for me, I don't even think about it. 
Shift-escape is nice 
I Second Shift-Escape 
I agree with sock, blocking the toggle when there is text typed annoys me

How often does that really happen? In my case, it's almost never.

Is is okay to effectively punish some users in order to keep a behavior that is not a concrete need?

- Making a command work is a concrete need.
- Avoiding seldom small nuisances is a emotional need.

I give up. I don't debate things when emotion is put above reason. Nevermind the users who must enter commands that the default behavior doesn't allow them to. 
just hit escape if there's already text there.
shift+escape to get to the console, escape to close it. then keymaps make no difference.
ideally you shouldn't be going to the console very frequently anyway.

small note regarding tilde... it should actually be bind ` rather than bind ~, as the actual key is backtick rather than tilde.
note that this clearly leaves the console inaccessible with that keymap because backtick requires shift to get at it, and thus shift+escape to get at the console starts to sound so very much better.

the issue is also present on german keymaps, in a different form.

and wasd key layouts on french azerty keymaps just do not work. :P

and laptops... *shudder* 
How often does that really happen? In my case, it's almost never.

I imagine that lots of players are in the habit of toggling the console to cancel a command. Even if you offer a alternative, there's a cost to breaking a habit.

That's not to say that we should leave players with non-US keyboard layouts stranded, but having a fix behind a cvar which defaults to vanilla behaviour is probably the best of a bad bunch of options. 
QS handles WASD on AZERTY (and other non-qwerty layouts) by making in-game keys always use a US layout. The logic is that ingame you're not doing text entry, but using the keyboard like a joystick. Source engine does the same thing, so hopefully it's a sane approach.

IMHO changing the behaviour of the US layout is not acceptable because we are trying to keep the original feel, people got used to the nuances of how the ~ key behaves over the years.

There are various hacks possible, like we could probably disable the key-under-Esc as the toggleconsole key under some conditions (only use it if they key is "`"/"~" on your keyboard layout?) That seems ugly though. Still, having the Alt key suppress the console toggle in case you want to type that character seems most elegant atm.

I'm assuming people on non-US layouts actually like the fact that QS uses your native layout for text entry in the console? 
I'm used to toggling the console with "tilde" and certainly wouldn't want to get used to another system. And this is despite the fact that in QS it's already broken on a German keyboard layout where closing the console with the "tilde" key causes it to print a ^ character the next time you open it which then has to be deleted in order to type the command. To avoid it from happening the console has to be closed with ESC which I already consider a hassle.

Just had me thinking whether some sort of alias script could fix it as a workaround. But meh. 
Do Whatever You Want 
just as long as you provide a way to bring it back to stock. *you* may think your new way is awesome, but not everyone else does.
and yes, i fucking hate the dp console. i also hate any console that doesn't auto complete q+tab to quit. i don't care is there is a command higher up in the alphabetical order. 
Alias q quit 
Already have that for toggle entities. ;) 
I am so with you on the q<completion> hate. FTEQW does the same iirc. 
Different Styles 
How often does that really happen? In my case, it's almost never.
There are countless examples of console text being incomplete. Try creating RTLIGHT files for DP and see how often you need to work with the console. Checking for commands, trying to find out options and modifying fog parameters. It can take a while to tweak fog for a map and then there is trigger volume fog for AD!

I think you have to appreciate as a coder you are using the engine different to a level designer. It may not seem obvious, but the console is used a lot during development and testing of a map. 
I agree with him, i use it like crazy too, for getting fog right, doing good info_intermissions, checking coords in general with showpos, the various developer messages that get displayed during testing and you don't godmode and need to read them later...
Also, Negke, i feel you...^ 
there is trigger volume fog for AD!


also, setting up rtlights via console sucks, would be nice to have some sort of editor ui... 
Killpixel, did you even play it? Just kidding, ad_crucial shows it well, the fog triggers are ace, right?

Perfect for changing the mood when entering a lavacave or an area high up, it really does compliment the lighting and all..

Swampy uses them too, more subtle though. 
fog triggers in quake is not something I ever thought I would see so it never really registered... another reason to play through again! 
^ Bug 
finally tracked down what is going on.. I think it's a bug in SDL2.

We switch SDL2's "text input mode" on when the console is open and off when it closes. What's happening is, accent keys pressed when text input mode is OFF are still having an effect when we go into text input mode.
will look into this further and see if there's any fix possible.. 
I'm trying to play co-op with a friend from over the Atlantic, and we can't find any command to enable client side movement and firing prediction. This makes it very difficult for him to play. Darkplaces has it, (cl_movement), and of course ezquake does. Problem is that those clients aren't compatible with a lot of maps.

Is there one? If not, I'm requesting it for future version.

Ooh, very nice client, I'm running into issues with it too though. Teleports that should take me to another map are just restarting the map for me. It's working well for my friend on linux though. I guess I'll take this elsewhere though as it's not related to Quakespasm. Thanks. 
Samelevel 0 
(cvar is used only by the gamecode - even vanilla, so applies to quakespasm too. you probably have that issue due to some dodgy third-party qw deathmatch-only config.) 
Thank you very much. :) 
Latest windows dev build has the fix for ^ getting inserted in the console on German keyboard layouts: 
could you please fix also the OSX version? 
I haven't seen this bug on OS X.

IIRC, I tested the latest stable build, 0.91.0, SDL2 version. OSX 10.11. German keyboard layout.

What configuration is it happening with for you? 
EricW ... You Are Right! 
I�ve just added --> bind "^" "toggle console" in the config.cfg and it works .. sorry for that! 
I'm adding some functionality to Quakespasm for qexpo, I have some questions regarding the engine. Is your email in the your profile here correct? Can I hit you up with some questions there? 
Yep, Sure 
Mousewheel Weapon Switching Bug? 
For some reason I can only switch forward, but not back -- i.e. rolling the mousewheel forward will e.g. switch from shotgun to super shotgun, but rolling it backwards does nothing.

Oddly, this does not happen when playing Arcane Dimensions. In AD, I can switch in both directions. In id1, though, I can only switch in one direction.

I'm on Linux, running QS 0.91.0. 
This is a mod issue, some mods do not support the impulse that cycles backwards through the weapons. It's not actually an engine feature! 
This shouldn't happen with clean and up to date id1 though. 
Err, how do I know if my id1 is up to date? 
Thanks for the responses, by the way.

metlslime, I'm not sure if I understand your reply correctly, but I didn't mean that it was an issue I was encountering when playing with mods (unless one counts id1 as a mod). I just added the bit about AD because I thought it might be relevant that it does work under AD.

I was under the impression that cycling through weapons in both directions should be possible when playing in standard id1 (as dwere's response seems to imply as well).

But now I'm a little confused... 
total_newbie, I think either you don't have quake patched to 1.06, or the mousewheel down isn't bound in your id1/config.cfg.

Under id1, try "impulse 12" in the console, then close the console. If it doesn't switch to the previous weapon, then you must be missing the 1.06 patch.

The patch is here but it's DOS-only unfortunately: 
Thanks for the response, ericw.

Turns out I am using an out-of-date set of pak files, but I can't get the linked patch to work.

Would it not suffice to download an up-to-date pak0.pak (i.e. the shareware pak) and replace mine with it? The readme from the patch you linked to suggests that it's just the pak0.pak that gets updated anyway:

Step 2: Run the file 'patch.exe' from your Quake directory, which will alter
your quakeid1pak0.pak file.

Or does it do something to the pak1.pak too? 
That Last Sentence Wasn't Supposed To Be A Quote. 
try updating pak0.pak. Is there a zip on quaddicted? I guess this should be covered on: which currently doesn't say anything about patching.

(hmm, weird my pak0.pak - from Steam, I think - doesn't match the md5 sum listed there. the pak1.pak does though.) 
Found it here via a google search:

Haven't checked to see if Quaddicted has it too.

Anyway, that seems to have worked. :) Here's hoping I haven't inadvertently broken something. 
Just checked and both my pak files have md5sums matching the ones on Quaddicted. So I seem to be up to date -- finally. :)

Thanks for all your help. 
Optimization On Raspberry Pi 
The quakespasm engine does not seem to work nicely on the raspberry pi. It has slow framerates and broken geometry. Oddly, the more demanding darkplaces engine works smoothly. Any clue why this is happening? 
QS needs desktop OpenGL, whereas DP is able to use OpenGL ES.

It sounds like desktop OpenGL has been software emulated only until recently, see:

Do you have a Pi2? Try enabling the experimental hw-accelereated OpenGL option. 
Already Did That 
The experimental drivers do help with qs, but effects like dynamic lights slow it down, and some other factors I haven't pinpointed yet. Would it be hard to allow OpenGL ES with qs? 
Ok, Interesting 
adding full GLES support is possible, but relatively a lot of work.

there may be some simple tweaks to the lightmap format that would fix slowdowns with dynamic lights.. but we need some developer with a RPi to do it. 
Would it be hard to allow OpenGL ES with qs?

It would need a rewrite of much of the renderer because it still uses a lot of glBegin/glEnd calls which don't even exist in ES. BSPs and MDLs IIRC use vertex arrays/VBOs but they're the easy ones to port. 
It would probably be worth it on the long run but sacrifice compatibility for some ancient hardware maybe? 
The network drivers for vanilla have this class-like structure with function pointers that are filled with the proper functions for a specific net driver. I don't currently see a reason why we couldn't use such a mechanism to incorporate multiple rendering engines. (id Tech 2, the engine for Quake II, actually uses that).

Also, if you're interested, I had to implement ES on the iOS VR target of my port... might guve you some useful pointers :) 
GLES1 pretty much just requires using vertex arrays instead of glBegin. The rest is basically just omissions. It should be easy enough to update quakespasm to use this, but you'll probably want to handle batching properly to compensate for the batch-merging work desktop drivers do with small glbegin batches.

GLES2 requires glsl too, which is a little bit more messy, but also offers significant speedups.

GLES3 is a strict superset of GLES2, thankfully.

FTE's gl renderer dates back to when glsl was still new (and slower). as a result it still copes just fine with glsl on some times and not others (also, yay q3 shaders).
tbh the only significant difference is whether glsl is available or not. There's a few extra limitations from using GLES, but tbh those things should probably be avoided even on desktop GL, so its not a huge problem really.
Of course, this is assuming you're willing to have gl1.1 as a minimum requirement - this may mean you need to use a quake3 minidriver instead of an older one, so I don't personally see this as a serious issue, even for those old cards. 
Just Buy A Pi 
If you need to develop on one, they are like 35$ dude. I have no idea on your linux ability, but it shouldn't take long to learn how to code on one. Seriously, the OS comes with gcc and g++, it's super easy to compile anything. 
Just Buy A Pi 
If you need to develop on one, they are like 35$ dude. I have no idea on your linux ability, but it shouldn't take long to learn how to code on one. Seriously, the OS comes with gcc and g++, it's super easy to compile anything. 
Got A Duped Post, Please Remove Post 2048 
All developers have their own interests and own things they are interested in contributing to a free project.

ericw may or may not be interested in this task.

It sounded like he was inviting someone else to step up the plate and pursue this item of interest.

Everyone likes to armchair manage what someone else "needs to do", but really free projects depend on new volunteers.

/One opinion, my opinions are often wrong. 
I Have A Pi 
and I really have no idea how to bloody use it. I'm sure if I struggle hard enough I could offer up some testing... 
Seriously, the OS comes with gcc and g++, it's super easy to compile anything.

Yeah, type "make" and you can compile anything.


Let's get serious. Compiling stuff is the single most basic part of the build process. It's expected to be easy and it's expected to work. So the part of the toolchain that's supposed to be easy is easy? Big swinging mickey. Gimme decent debug tools and we can start talking. 
I wish compiling on OS X was easy. My other poject is a pita on El Capitan which i'll have to solve some time soon. They symlink gcc to freaking clang! and have separated the command line tools from Xcode in some mess i have to resolve. Mebee it's not too hard. 
Xcode is good. Xcode is your friend. Accept the Xcode. Let it flow through you.</spooky> 
You'll get the command-line tools if you install Xcode.

You can also get the command-line tools by running "xcode-select --install". In fact you should do that even if you've installed Xcode, since that command will also set up some default Unix/Linux-y paths for the linker and preprocessor (like paying attention to /usr/local/lib and /usr/local/include by default). 
Mouse Stuttering? 
Since an arm injury a few years ago I've only been able to play with a controller.

Today, feeling good, I thought I'd try a mouse in QS again in anticipation for the new Arcane Dimensions.

Sadly, I found that mouse movement 'jerked' or 'stuttered' every few frames or so. This doesn't happen when I use a controller.

Looking around I found some threads pertaining to other games having the same issue. It seems to be an SDL thing.

Is there a way to set raw mouse input in QS?
Does anyone else have this issue?

I have a Logitech g700s mouse on a Win 7 x64 PC with GTX 780 and i7 4770k.

And, no, it's not lag because my mouse is wireless! The mouse is as smooth as butter in other games. :) 
Are you using quakespasm.exe or quakespasm-sdl2.exe? (or the dev builds from ?)

Try the -sdl2.exe one, it should use raw mouse input.

Another thing to try is setting "host_maxfps 60".

(I have this problem on OS X, where mouse events only arrive at 60Hz, and there is no raw mouse input in SDL1/2 on OS X.) 
Thanks :) 
I always use the most up to date dev builds (in this case 1308 and 1310).

Setting "host_maxfps 60" seems to have done the trick though. I had host maxfps set to 72. I presumed, having a 144Hz monitor that half the refresh rate would result in a more solid performance than 60Hz. You live and learn, I suppose.

By the way, while looking around for this issue I found that you're using an older version of the SDL2.dll. Is there any reason for that? Just curious. :) 
I usually set my host_maxfps to 150. 
Problem with variable host_maxfps in single-player Quake is that so much of the engine is FPS-dependent, and often in ways that are gameplay-breaking. 
Ok, glad to hear host_maxfps 60 helped. That suggests QS is only getting data from your mouse at 60Hz which is weird :-(. Try host_maxfps 150 as Fifth mentioned too, although I'm not sure how much physics starts to mess up at 150?

I found that you're using an older version of the SDL2.dll
It's a custom build by szo, made from the latest release (2.0.4) + some patches, details here.

MH - yeah, trying your Inside3d tutorial on decoupling the server / client FPS is on my wishlist. 
Not noticed physics messing up at 150. I find Quake literally unplayable below my monitor refresh rate of 144. I get headaches and nausea. 
I need to get a 144Hz monitor! 
Anything Greater Than 60 
I have a monitor that goes to 100Hz, and even that is a night/day difference. Highly recommended! 
MH - yeah, trying your Inside3d tutorial on decoupling the server / client FPS is on my wishlist.

I've better code since, unreleased but if you're ever looking at this I can give you a code dump. 
In DirectQ, which had client/server decoupling if you turned left or right using the keyboard while moving forward you had jerky movement, like a mild stutter.

DarkPlaces and the QW clients don't, was something I wanted to get to the bottom of.

In 2014, I spent some time trying to implement client/server independence before ultimately moving it to the back of the list because that would have just been a piece of a more ambitious goal like implementing DPP7 or some sort of predictive protocol for better coop.

(Which itself is quite a laundry list -- delta compression, server timestamps, baseline, acks, etc. etc. and of course implementing IPv6 and connectionless connections.)

Merely implementing client/server independence DirectQ style is no small task :( Timing nuances are everywhere, even in a few places they have no reasonable place existing.

Spike takes timing to even more of an extreme by creating a separate thread for the server.

/Pandora's box 
But yeah, when I made a run at it, I had all of mh's notes from insideqc I could find on-screen for reference. 
I'd say multiple controller support and splitscreen in a decent engine is more important ;) 
its DP that can run the server on a different thread. the real issue with running the server on a different thread is that of cvars and commands. cvar_set would require a full-blown sync to ensure the other thread isn't reading cvars that are about to go away, while commands also need some sort of sync - which is not what you want with +forward etc.
on the other hand, running the server in an entirely different process skips over ALL of that, with more understandable behaviour for the user. much fewer mutexes, much less likely to break other stuff, but more annoying to configure.

either way your client needs to be able to properly cope with dropped/delayed packets. 
In DirectQ, which had client/server decoupling if you turned left or right using the keyboard while moving forward you had jerky movement, like a mild stutter.

Part of the problem there was that I'd made a huge mess of the timer code well before then. In earlier versions you can timescale down and see how atrociously jerky it really is, and it took me a long time and many revisions to get things back to something that even approached correct. I don't think I was ever 100% successful either, and I didn't really understand the subtleties of the timer code at the time. 
Latest Version Bug? 
prev weapon bind does not seem to work for some reason. Anyone else getting this? 
Prev weapon is controlled by QuakeC and QuakeC only. Some mods don't support the prev weapon impulse, one example is Duke of Ontranto and I think another example is Castle of Koohoo.

(Mark V uses the Requiem engine cheat to make prev weapon available in about any mod, but it isn't 100% fullproof and at least one mod --- Neruins --- it doesn't work "right" at all) 
N64 Style Rumble Support? 
I really, really appreciate the Xinput controller support added to recent builds of QS but I was wondering if it would at all be possible to add rumble support?

My first foray into Quake was on the good old N64. Two things I really miss from that version is centred message text (though I don't think you're interested in adding that option) and the other is the Rumble Pak.

It adds some real heft to the weapon fire. 
Splitscreen Support 
please... please please please......

(obvs you'd need to have support for more than 1 pad) 
This has come up quite a few times, and I think Spike has given some good discussions on what's involved, but one thing to realise is that this:

(obvs you'd need to have support for more than 1 pad)

Isn't true.

You need a hell of a lot more.

You need to recode the engine to be able to support 2 or more clients, running concurrently, in the same process. 
And considering how there are more global variables in the Quake engine than atoms in our solar system, that is going to be a huuuge, collosal task.

I wonder, if that's the case, if we should consider instead recoding the engine completely, from scratch. And while we're at it, doing away with the hardcoded engine limits. 
@Izhido Re:Limits 
Raised limits have long been standardized -- and mostly don't present a problem in modern times.

What Quakespasm uses as limits is essentially the standard. Those limits are ...

1) BSP2 for map limits
2) For non-map limits, the limits are nearly unchanged from FitzQuake 0.85 (with 2 small modifications, if I recall, max packet size and visedicts)

Protocol 666 --- written by metlslime in FitzQuake 0.85 in 2009. Supercedes protocol 15. If there were awards in Quake, metlslime would have won something like "Best Modification of The Decade" or something. --- comparing the FitzQuake 0.85 vs. FitzQuake 0.80 source codes. (summary of protocol 666 changes)

BSP2 --- written by MH in 2011 or 2012. Similarly outstanding like protocol 666.

Spike made a BSP2 patch of Mark V, which was used to easily port BSP2 to Quakespasm ... <--- changes for BSP2

... and later probably the basis of BSP2 support in other engines like Super8 and Qrack, if I recall correctly. DarkPlaces and FTE support BSP2 as well. BSP2 was written by mh for the RemakeQuake engine. 
Requiem Impulse 12 Hack 
I was able to get prev weap to work with ne_ruins a while ago based on reQuiem. It may require omission of quaketest compatibility or similar to obtain this result. 
The Requiem impulse 12 hack will crash neruins. Give yourself all weapons and ammo, then use impulse 12 a whole bunch. *boom* 
neruins doesn't need a impulse 12 hack. It has impulse 12 support for prev weapon in the progs. Nevertheless, the Requiem impulse 12 hack explodes on neruins. 
ne_ruins is a strange release. It's the only mod that screws with my movement speed settings, maybe except total conversions like Malice.

No, wait, I think I caught OpenQuartz doing something similar. 
Impulse 12... 
try "give all" instead.. maybe this works.. though.. 
What's wrong with cycle reverse in ne_ruins? I always use 1.6 progs which has the reverse cycle function. 
Nothing is wrong with ne_ruins. The Requiem impulse 12 hack has a certain method of trying to determine whether or not a mod supports impulse 12 previous weapon and some it depends on QuakeC function names.

In the case of ne_ruins, it (falsely) concludes that ne_ruins doesn't have impulse 12 support and then does forced progs hacky kung-fu that explodes.

The only thing remarkable about ne_ruins is that it is first known mainstream mod that the impulse 12 hack doesn't play nice with.

Mark V has a cvar named "sv_fix_no_impulse12_exceptions" and the value is "ne_ruins" (supports comma delimited list i.e. "ne_ruins,kinns_new_sp" would work) --- so as you can imagine ne_ruins doesn't crash Mark V any more. 
interesting. maybe because i refactored a lot of the impulse handling and renamed the W_WeaponFrame method to player_processInput?
what do you check for to determine that there isn't support? 
a) It looks for an ImpulseCommands function. If it cannot find one, assumes there is impulse 12 support.

b) Found an ImpulseCommands function. Check for a statement that checks to see if self.impulse == 12. If found one, assumes there is impulse 12 support, otherwise assumes there is not impulse 12 support.

ne_ruins apparently has an ImpulseCommands function but doesn't check for impulse 12 there. 
"sv_fix_no_impulse12_exceptions" drips off the tounge like "r_nolerp_list", but could the approach be a whitelist instead of a blacklist? That is, a list of the old classic maps that need it.

The reQuiem impulse 12 hack is missing a 'default' fall-through during switch. The prev weap crash seems to be solved by coding the default to axe. But now next weap will fail... because it's not really an axe, it's a book or something... 
Well, there have to be a finite number of single player mods without impulse 12 support.

And in theory, if someone had the entire Quaddicted archive, could code an engine to switch gamedir to each gamedir and if impulse 12 support was not detected, write it to a log along with maybe ...

a) the CRC16 (what Quake uses), the filesize in bytes and maybe throw in a MD5 (because GitHub uses MD5 for file comparison and Linus Torvalds seems to how versioning down to a science)
b) and the file date and time from the archive.

1) Koohoo
2) Stuff using CustEnts like about all of Fat Controller's stuff
3) Probably a few random ones where the author could write QuakeC but used a bad progs base

Then you have to determine what dumb progs exist like Quake Progs 1.01 --- or is it 1.02? --- but catch the ones that aren't 1.06.

So yeah, whitelisting would work very well --- eventually. And would be the best solution long term. 
Ok, I see, instead of checking is self.impulse == 12, i assigned self.impulse to a local float _impulse and then check that instead. :(

void() ImpulseCommands =
local float _impulse;

_impulse = self.impulse;

if (_impulse >= 1 && _impulse <= 8 || _impulse == 250)
W_ChangeWeapon ();

else if (_impulse == 9)
CheatCommand ();
else if (_impulse == 10)
CycleWeaponCommand ();
else if (_impulse == 11)
ServerflagsCommand ();
else if (_impulse == 12)
CycleWeaponReverseCommand ();
Stumbled on a strange glitch while testing a new palette.

Re-entering the map didn't change anything, but after restarting the game everything was back to normal. Only the torches, flames and hanging zombies seemed to be affected.

The way the zombies looked like random lumps of gore, twitching and extending their "tendrils" in semi-random directions, actually was pretty cool.

I think it's an interesting idea for a new decoration, or an environmental hazard. Only if properly executed, of course.

Version 0.91.0, non-SDL2. Nothing suspicious in stdout. 
Weird, I haven't seen that since the new mdl renderer was still being ironed out.

If you find a way to reproduce it that would be great, but I assume it's an unlikely combination of conditions to trigger the bug. 
Hipnotic Decals... 
Is there a way to turn them off? I think that those 1 hole decals are super ugly and don't look right in any way shape of form, so if there is a way to turn them off, that would be nice to know. (And if not, it would maybe be nice to include a way, though it might be a bit of a niche request) 
I agree that the SoA decals look rougher than a badger's behind, but they are purely QC-based so the only way to turn them off would be for someone to create a modified progs.dat 
or you could stamp over the sprite by making an invisible sprite with the same name, and putting in (for example) pak1.pak in the hipnotic folder 
That might actually be worth a shot. Good idea. 
Just did a quick replacement and it works like a charm. Here is a zip with the PAK for anyone who wants it. 
Nice One 
Quakespasm 0.92.0 Released 
Very Nice Release 
And thank you very much for your support in providing compatibility with oms3. I know its old news by now, but I appreciate all the steps you took to make it work. :) 
Couple of quick questions.

I'm trying to decide if I should add my IRC code to this version to release for QExpo rather than version 0.91.0.

Does it offer anything in the way of stability or bugfixes beyond what is stated in the notes?

Are you planning on releasing this for QExpo, and if so, do you want me to delay the official release of my code? 
The changelog is pretty much it: no other notable differences between 0.91.0 and 0.92.0. As for the qexpo thing, I have no interest in that. 
Controller Support Woes 
Hello, the latest quakespasm appears to be totally unresponsive to my controller.

Controller is a bog standard official "XBox 360 Controller for Windows", with up-to-date drivers. It also works fine on other games I use it for.

I have also done what it says in the readme and downloaded the gamecontrollerdb.txt file to the quake folder, but it does not help.

Any idea how I could troubleshoot this problem? 
@Kinn make sure to run quakespasm-sdl2.exe, only that .exe has controller support.

I have the same controller (wired version), tested it on Windows 10 and OS X so far.

Also, check for any "joystick missing controller mappings" or "failed to open controller" messages in the console. 
Cheers - that's it - mea culpa :}

Btw it's AWESOME - default sensitivities etc. are pretty much spot on - now I can sit back in a comfy chair and play quake and its the bestest thing in the world ever :D 
Great :) 
Kinn U Make Me Crie. 
ur just jelli u don't have the gamepad skillz. 
Doom was released not long after I got my first computer and it was one of the first PC games I played. Before it came out all I had on the PC was flight simulators and space combat game, so for the first year I played Doom I used a Thrustmaster joystick as the controller. 
Lol U Guys 
Honestly, after 20+ years of playing console games I don't find controllers awkward to use in any way. I prefer them to mouse & keyboard because the level of comfort is incomparable. The only time I'd want to use a mouse & kb is for games that have complex controls like mmo games or rts or whatever. 
Controller Support 
in QS and other engines has been lacking for quite a while. As superior as KB+M is there is still a problem with that setup for playing games on a couch in front of the telly box.

Also, wheres my splitscreen (yes, I am a pestering bastard but I fully intend on using this with my friends) 
Rip Kinn_sp3 
Rip Kinn_sp3

you know when there's a band you like, and then they do nothing for over a decade, but then suddenly you hear they've got a new single coming out, and ur all like "omg holy shit that band i like is back" and everyones excited and then the single comes out and you buy it and you listen to it and first you're not sure what to think of it and you look at your friend and he also has the same "i'm not sure what to make of this" look on his face and you listen to it again, and you sort of pretend to like it this time but deep down you're kinda thinking "what the fuck is this".

Just sayin. 
Fuck Off Dude 
I don't really have anything to add to that comment so instead here's a gif of a pig taking a cat for a walk: 
I mean, I kinda enjoyed Kinn during my teenage rebellion phase. But nowadays it's just lost its appeal... 
Minor Buglet 
I seem to 100% of the time get a black screen when I start up the sdl2 version. To fix it, I alt-tab to desktop, then alt-tab into the game again.

Doesn't happen with the non-sdl2 version.

Anyone else getting this?

Windows 10
NVIDIA GeForce GTX 765M 
Anyone else getting this?

I'm guessing that you have an Optimus laptop from the "M" in your GPU model number.

I was able to 100% reproduce this on a similar system, but only when running under the Intel graphics card. When running under the NVIDIA (either by right-clicking and selecting "Run with graphics processor" or by creating a profile in the NV control panel) it behaved properly. 
Whoa That's It 
Holy shit - I had no idea I was running it all this time on my crappy intel card thing. Whoa. Cheers! 
On Windows the NvOptimusEnablement (there's an AMD equivalent too) export can be set to fix this:

Only thing is, for some rendering workloads the Intel is actually the faster GPU in this kind of configuration - especially if it's a HD4000 or better. Quake falls into this category; what happens is that Optimus with the NV must transfer the framebuffer to the Intel for presenting, but Quake rendering is so lightweight that doing the transfer takes longer than just doing everything on the Intel. 
Feature Request 
Not sure if this has already been requested, but it'd be a real time saver I think.

Predictive text for commands. Just like on swyftkey or similar, you type a letter and behind it the engine fills in, in grey, any possible command pertaining to that letter.

If you hit enter then it completes the command in text, if not then you carry on typing as normal.

Adding custom keybinds is all very well... but if prediction was a base feature then it'd remove a lot of this piddling about for most if not all users.

Just a thought. 
it exists, start typing something then press tab 
Not exactly what I meant though - I know what the commands are already. 
keep hitting tab and you won't have to type the rest 
ijed is learning about tab completion in 2016?

fte does exactly what ijed is talking about with the show the command before you type it thing.

In theory it sounds great.
In practice it is a horror.

It doesn't know what you are going to type and instead annoys the F out of you autocompleting something random you aren't looking for --- and in doing so --- ruining your train of thought. 
(Hehe, I should have softened that up a bit and wordsmithed it a little before clicking submit.

The effort to write that feature is great, but the way an advanced engine will have 1000 cvars and commands and most of them are things an average user is never looking for --- this causes the end result to be undesirable.

In my opinion ;-) ... 
Feature Request : Random Map Command 
I'm still requesting this feature for Quakespasm : the ability to quick load a random map from the whole list by typing a simple command in the console.

Please, I need this, built-in ! 
Open host_cmd.c in the Quakespasm source and find Host_Map_f --- there is a list called "extralevels" and you could make it pick a random one from that list if you type "map random" in the console.

So edit it to do that and then recompile Quakespasm and you are all set. 
Fair Dos 
The Swyftkey thing I mentioned is a downloadable keyboard for mobile which manages not to be annoying.

But yeah, not exactly top of my christmas list :) 
I'd Forgotten About Barnak 
Why this meprisable attitude ?

As a player of Quake, I'm simply asking for a usefull feature, so what's wrong with my request ? 
R_shadows 1 
I recently discovered that it actually looks pretty nice. But maybe the shadows should be one-sided? Since they're supposed to fall on the floor, I see no reason for them to be visible from below. It only contributes to the amount of situations when they look weird. 
Just saw this...

Axel Gneiting, a programmer at id Software, has ported Quakespasm to Vulkan:

QuakeSpasm Shows Me Just A Screen Full Of Grey On Any Map 
Whole screen grey, except for the status bar. any map, even e.g. dm4. Does not happen in fitzquake. Any idea? 
Argh.. :(

Would you mind launching with the "-condebug" flag and uploading the generated "qconsole.log" file?

You can disable some rendering code changes with "-noglsl" (alias models, gamma correction) or "-novbo" (new world renderer), one of those may help. 
emailed you the log. neither option appears to change the situation. 
So what generation of graphics cards does one have to be using to get the benefits of Vulkan - or does it not work like that? 
its not meant to work like that.
its meant to be that if vulkan works on your gpu, then your cpu can skip a whole lot of work. your gpu might take a bit longer, but it's probably going to be idle anyway, and with vulkan its supposed to be much harder to inadvertantly cause the cpu+gpu to sync up.

in practise, there's a number of overheads due to the system compositor, and nvidia (at least) is doing a terrible job at overcoming those.
this results in double the framerate at low resolutions (yay!), and half the framerate at high resolutions (oh noes!).
however, I'm also using quake as a benchmark (few other games expect to achieve 3000fps) so take what I'm saying with a pinch of salt, at least when applied to other games.
Games with a lot more 'things' moving around are the ones that will benefit most, so it really depends how dynamic your various scenes are.

personally, the nicest thing about vulkan is not having to worry about falling back to gl1.1 :) 
Thanks, nothing obvious in the log.
The only other thing that comes to mind is try both quakespasm.exe (SDL 1.2) and quakespasm-sdl2.exe. Also might be worth backing up and deleting id1/config.cfg. 
Vulkan has little to offer Quake because a typical Quake workload just isn't heavy enough to benefit from what Vulkan does offer. It looks more like it's just a fun project for the guy at id: a way for him to learn Vulkan and give something cool to the community.

While it is true that most Quake engines (those based on/similar to the original renderer) are CPU-bound, that's because of the way the API is being used, not the API being used. Lots of small draw calls with glBegin/glEnd, sync points all over the place, animating on the CPU then pushing data to the GPU every frame; it's all a combination of the worst possible things you can do on 2004+ hardware. Try to do the same under Vulkan and you'll probably end up even worse. On the other hand, fix the way the API is used and Quake is no longer CPU-bound so Vulkan is unnecessary. 
Colored Dead Bodies In QS 
Dead Bodies 
That's a long standing GLQuake bug.

In summary: entity slot 0 is reserved for the world. Entity slots 1 to 16 are for players. Entity slots 17 onwards are for everything else.

When a player is killed, they move from one of the player slots to one of the "everything else" slots. Their old player slot then becomes free for them to respawn into (or for another player to join into, I guess). That way the player slots don't get filled up very quickly with dead bodies.

How GLQuake colours a player model is that it checks what entity slot number it's in. If it's in one of the player slots (1 to 16) it will apply colormapping to a copy of the player model texture, re-upload that to the GPU, then use it instead of the regular player texture.

And that's how it happens: the entity moves outside of the player slots, so GLQuake no longer colours it.

IIRC this is fixable but if an engine still uses the old colormapping code there may be some more extensive rewriting needed to make it run well. 
Quakespasm could be modified to do so borrowing Mark V code which has had the dead bodies colored for nearly 4 years.

The changes to do this are located in this source code and marked "#ifdef SUPPORTS_COLORMAPPING_EVERYTHING" the source. Mostly touches cl_parse.c, cl_main.c and gl_model.c are where the main changes are.

Would be a pretty straightforward code grab and the code has essentially remained unchanged for a very long time (one change since was a simple 1-liner if I recall for mods that set an invalid skin #, which I think ericw pointed out).

The remedy to fix the GLQuake "bug" is to watch for any model or colormap change in cl_parse.c for all entities.

If one happens, color up a skin for the model + color combo and store it off. On new level or gamedir change, clear the skins queue. 
sometimes I think the cure isn't any better, with spies in TF changing their appearance mid-game, having one of their dead bodies in your base makes it trivial to figure out what they now look like. 
sometimes I think the cure isn't any better, with spies in TF changing their appearance mid-game, having one of their dead bodies in your base makes it trivial to figure out what they now look like.

I can't remember if the same would happen in software Quake or not.

Either way, this is one of those issues where gameplay in a mod depends on what is clearly an engine bug. Should a fix to an engine bug be allowed to break (or otherwise have a lesser impact on) a mod? Or should it be fixed in the mod code instead? And given that the engine code change is client-side, is it even appropriate for the mod to have been depending on the bug in the first place?

Questions, questions. 
disconnect, change team, etc, all those corpses change colours too, which is weeeeird.
That said, its also weeeeird for corpses to change simply because the player respawned then.

if .colormap carried the top+bottom colours explicitly then that would solve the issue for nq.
You can work around that using DP_SV_CLIENTCOLORS and DP_ENT_CUSTOMCOLORMAP, eg:
That said, this won't help with qw skins or richer colours (unless you wanted to send a whole lot of extra data).
Of course, because mods use .colormap, and its part of every single quake protocol, there'll always be somewhere that is still b0rked - even if you did network the skin names for every single entity. 
Aren't legacy data formats exciting? 
First of all, I did not do vkQuake because I wanted to "learn Vulkan". I already did the Doom port before, which of course was much more involved.

Also you are wrong about the CPU overhead. This is exactly the kind of stuff that is much faster with Vulkan - not that it matters for Quake.

vkQuake serves as an example of how to properly write Vulkan applications. Even with something as simple as Quake there are basics which are not trivial. 
vkQuake serves as an example of how to properly write Vulkan applications
you're not using texture arrays at all nor descriptor arrays, you've no tripplebuffering, you're using an entire descriptor set for each texture of each material, you still have each texture in its own allocation.
its that last one especially that makes it look like an engine that someone's learning from (or they're just lazy, like me).
either way, I'd suggest fixing those before claiming that its 'properly written'.
Sorry, but that irked me enough that I felt I had to say something.
additionally, if you really want to make something that is useful for other people to learn from, then use a friggin license that they *CAN* use. The GPL sucks. Keeping your code separate from quakespasm's code and under a different license should do it.

Also you are wrong about the CPU overhead. This is exactly the kind of stuff that is much faster with Vulkan - not that it matters for Quake.
when running fullscreen at 1920*1080, quakespasm is about 10% faster than vkquake for me.
FTEQW's vk renderer gets about 1200 fps vs gl's 1800 vs d3d9's 3000 fps, when running at that same resolution and a single preset that doesn't have stuff that one of those renderers doesn't support (I'm not going to give numbers for vkquake here because I don't really want to start a pissing contest over engines, yet...).
(small note, this is fullscreen rather than at 640*480, so its subject to whatever excessive buffer copying nvidia are doing behind the scenes. hopefully this will be less of an issue when nvidia actually get their act together)
So yes, switching API will indeed increase your framerate!... but not by switching to vulkan for most users right now. At the same time, rewriting how the API is used will increase the framerate significantly.
I knocked up some crappy opengl renderer a while back when I was trying to familiarise myself with more recent opengl extensions without having to care about older gpus: (jam6_daya)
obviously that specific example has no entities nor server logic etc, a pure renderer. trying to match settings I can push fte's gl2 renderer to 2200fps, fte's vulkan renderer can reach 2600fps (this doesn't conflict with the gl vs vk comparison thanks to 640*480 not suffering so much from nvidia's deficiencies). comparitively vkquake does indeed get a noticably higher framerate than quakespasm but its still severely CPU limited because neither are actually making the most of their rendering API.
Imho, mh's comment about the CPU overhead is perfectly valid. Just switching APIs *can* help, but actually properly using the API you already have will still be a bigger and more reliable boost (unless you do both, but then you have the above issues with nvidia's tripple-copy inefficiencies).
Who cares when you're already pulling more than 200fps, right?

put simply, if you want high framerates, go with d3d. even on nvidia. you can call that the microsoft tax if you want, but for me linux wasn't actually any different - even just enabling bloom in linux+vulkan dropped the framerate into the hundreds (which is barely felt on windows).
vulkan might be the future, but its certainly not the present - yet.
here's hoping the drivers stop being shit some time soon.

(I'd have started on a d3d12 renderer already if it had not meant opening myself up to all the win10 malware, iiuc the drivers are more mature so shouldn't have the defects I've been talking about). 
Obviously this is not done yet. 
Also you are not allowed to change the license. The original Quake was released under GPL, so QuakeSpasm *HAS* to be GPL and also vkQuake *HAS* to be GPL.

If I used BSD I would be in direct violation with that.

I'm not going to argue with you about the other stuff. 
Unless... You somehow managed to do a full engine rewrite with not one single line copied from the original one.

And I'm not convinced it wouldn't be possible... Except for the most trivial examples, there are many many many ways to write similar software... 
It's obviously not the scope of vkQuake to rewrite Quake. 
I have to admit that when I first looked over the code what I saw led me to think that it was being used for learning. Since that's evidently not the case that was clearly my own misunderstanding.

That aside, and squabbles about API aside (which are interesting to discuss nonetheless), I still think this is cool. It's fantastic to have something where you can go in, look at a bunch of GL code and see the Vulkan code needed for the very same thing side-by-side.

I'm not sure if that's the intention, but intended or not it's cool that it exists.

Learning from code is obviously different to copy/pasting it. I've no objections to GPL on that count, but would note that since id own the original Quake code a new release of the original code under a different license should have been possible. Of course such a release would have missed out on the years of bugfixing and features added...

It's also fair to say that the state of Quake's renderer is such that any attempt to properly use an API is effectively going to be a rewrite. At which stage being able to do a direct comparison between GL and Vulkan code becomes rather more difficult. 
Quakespasm Thread: Dick-Waving Edition 
For a limited time only - enjoy 100% more condescending sneering, with extra egotistical squabbling thrown in for free!

Find out who's code is the best code! Fight! Fight! Fight!... 
Ooh Ooh 
my code is the worst.... miiiine.

wait, we were fighting over whose was the best... fuck. 
I think the fight was supposed to be over who's code. Or something. 
I think the discussion is interesting.

Much of the discussion in this thread does relate to engine coding. Always has.

If seeing engine coders argue/explain/hyperbole technical details --- you haven't read any of the rest of this thread.

It's uncommon to see the kind of technical discussion of a recent technology (Vulkcan) by people who actually can code in it. 
Well, here's one non technical question about the engine code...

Given the current state of things, who's the actual owner of the Quake copyrights? id? Zenimax? Bethesda? How should one write a copyright notice for it? 
you want to make a commercial game using the engine? 
You don't need a permission to make a commercial game. What you need a permission for is a closed-source game. 
It Was Meant As A Literal Question... 
Who owns Quake today? 
Quakespasm thread. Not "ask anything you like thread". 
Stop being condescending. This is a perfectly fine design for something as simple as Quake.

The command buffers and swap chains are double buffered to get minimal latency, which is probably the most important thing for Quake instead of getting 6000+ FPS in a meaningless benchmark. Btw. this is also recommended by AMD.

I use multiple descriptor sets because otherwise I would have to dynamically create them on the lightmap/texture permutations. In a real engine the descriptor sets would be bigger, but you probably would still want to bind multiple ones to avoid thousands of permutations.

If you want to tell me I should index into a big descriptor set: I have been specifically told not to do this, because it's slower on their hardware. On DX12 they even *always* pay this cost. Yes you read that right. Texture arrays have problems with different texture sizes and formats.

You are wrong about DirectX 12 in general. E.g. on AMD this goes through almost the same driver, there is some thin abstraction layer on top of it for DX12/Vulkan. Additionally there is no render passes which can actually also speed up desktop chips. The swap chain is fucked up on NVIDIA right now. This will be fixed very soon.

On top of that this was code for a 0.20 release. I already fixed the memory pooling for textures.

I'm really annoyed by behavior like this. You get something to free and all you can talk about how much better you are than everybody else. Meanwhile I actually try to do something for a community.

Have a nice day, maybe you learn to have some manners some day. 
"Stop Being Condescending" At MH 
Yup this will happen. 
What's weird is that I'm not the one who actually said those things. I guess that Axel just made an honest mistake there.

But I reckon OTP is just so full of hate and spite that that wouldn't matter much anyway, eh? 
Go Play Some Quoth Fam. 
mh: It's fantastic to have something where you can go in, look at a bunch of GL code and see the Vulkan code needed.

I agree with that. I think Axel made a very awesome contribution. And I've seen similar appreciative comments about the Vulkan API port on several different web sites. 
You are right, I was partly confusing Spike's post with yours. I'm sorry about that.

Doesn't change my point though, no matter who said things. 
Also about the GPL situation: Zenimax does own the rights to the original Quake source code. I do not. I can't just go ahead and randomly change licenses because I would want to. I'm also pretty sure even asking would be pointless. 
Help Mac Quakespasm! 
Never heard of this before as I'm not a MacOs Quakespasm user.
This really big map of mine which uses the "-heapsize 160000" makes my map run under WindowsXp but not on a MacOs.

Just a reaction of a player that don't know where mac periphericals go with QuakeSpasm_0.92.0

What can I say? 
You know Quakespasm defaults 256 MB by default, right?

(which is more than your crusty command line example which is asking for 160 MB or so) 
wait, I'm not the one who's asking.
It is someone on this MacOs Quakespasm that asks me advice.
I tried to reconstruckt the failure and the maps runs fine for me with the "-heapsize 160000" option.
It is his quaestion from him to me how to load a map that size on MacOS.

I know nothing of macs and apples. 
I think that's normal.. QuakeSpasm on OS X is probably running as 64-bit, and more heap space is needed to load the same content when the engine is 64-bit. Anyway, just dropping the -heapsize argument should be fine since it defaults to 256MB now. 
I understand, I'm just nudging you to not use --- nor suggest --- the -heapsize commandline argument.

It's archaic at this point except in exceptionally odd circumstances. 
I am the person trying to run LXSU4 on MacOS with QuakeSpasm.

It is telling me couldn't spawn map. I'm using the supplied command line:
-heapsize 160000 -game lxsu4 +map lxsu4

I also tried every other combination and method I know.

LXSU4 is created by MadFox and featured on the Quake Expo 2016 site: 
The zip file is LSXU4, not LXSU4, so try -game lsxu4 +map lxsu4. 
You can type "game lsxu4; map lsxu4" in the console.

Both gamedirs and map names autocomplete in the console if you press tab.

No more typos 
LXSU4: Zip File Wrong Name 
Ok, it works. Thanks! The zip file / game folder was supposed to be named LXSU4, but it isn't. 
Watch Out 
for elexis ufour! 
This Bothers Me 
The original game displayed the view weapons slightly differently depending on the view pitch. I don't know if it was a feature or an oddity (it also strangely depended on the screen size), but I know enough games that do similar things deliberately (so it wouldn't look like the weapon is glued to the player's chin).

Looks like this effect was lost somewhere along the way. What I'd like to ask is why. 
Oh, and apparently I misremembered Fitzquake exhibiting the old behavior - I just checked and it doesn't. So it's not a Quakespasm change. 
There's a car to display weapons like winquake at least in markv 
My Fault Aftershock.., 
Just saw it now, I packed it with the wrong name. 
There's a car to display weapons like winquake

Yeah, it looks really cool! Rocket launcher example
Quick Question. Uh, Make That Two. 
Hey guys, I think I've read about it somewhere but I can't seem to remember or find the page again, so please clear something up for me: there's no RTlights support in QS, is there? And while we're at it, I'm looking for something similar to DP Pretty Water for QS. Do I have any chance of getting lucky? 
As I understand it, QS is more about improving the engine within an acceptably Quakey aesthetic - stuff like RT lights and hi-res fresnel FX on water don't really mesh with the grungy pixel art look that was established in the original game. 
Eric is away this weekend, but he's working on a map with me ATM. 
Uhh... With all due respect, I don't condone this kind of backward thinking. Nostalgia is fine (I still play Quake, don't I?) but please don't be an ayatollah about it. Quake was no pixel art, it was downgraded art to circumvent hardware limitations of the time - like the sounds being limited to distorted 22kHz. I'm perfectly fine with pixel art and I've played great games that make use of it, but Quake being a highly immersive experience, it undoubtedly benefits from looking better. Take a look at the player model for example, it is very sketchy with parts of the texture shifting and trembling like jello in a decidedly unnatural way. That's not pixel art in any way whatsoever and I for once am very glad that HD content exists nowadays.

Oh well, at least I can still use hi-res textures and .lits... I just wanted to make QS as pretty as DP for the mods that I have trouble running in DP.

@Veyron, the link returns an error 502. 
Use DarkPlaces Then 
QuakeSpasm is for those who want the original look and feel as much as possible. 
Problem With Dp 
Is that it's no longer supported like the poster says. I'm sure other engines have added features like rt lights? 
please don't be an ayatollah about it.

Lol, with "all due respect" I just gave a simple answer to your question. Not sure why you think I'm being all preachy about this. Then again we all love a bit of salty beef on these forums - keeps it interesting doesn't it?

I don't personally have anything to do with QS's development, but it is my preferred engine, and indeed the FitzQuake/QS/MarkV line of engines are overwhelmingly the engines of choice for the mappers and players on these forums. Not bad for such a "backward thinking" approach I guess. 
Part 2 
HD content will always look terrible in Quake unless all the art assets - including the detail of the level geometry - are upgraded to a consistent fidelity.

2048 pixel texture on a 300-poly monster? Looks like shite. Hi-res bump-mapped textures on ultra-low poly quake level brushwork? Looks like shite. etc. etc.

There has been no attempt to remake Quake in entirely HD content, but what you do get are quarter-arsed efforts that are essentially the quake equivalent of this: 
Quake being a highly immersive experience, it undoubtedly benefits from looking better.

Anything would benefit from looking better. But whether HD content and new effects make classic games look better is arguable.

In short, it's about the balance of elements. When you improve textures, they make the geometry look simpler. When you improve skins, you should also improve models (which is something I'm yet to see). And when the character models will be up to modern standarts, if will suddenly be discovered that the whole animation system needs to be reworked just to make them look natural.

Some people don't notice all of this, but some people do. I would really like seeing a modern-yet-faithful Quake reimagining, but I think it should be a standalone project on a new engine, or a very deep reworking of the whole game, which will most likely mean dropping mod support.

Special effects like real-time lighting are less harmful though. In this case I'm only concerned with the fact that the quality of static lighting improved considerably in the last few years, and I'm not sure that real-time rendering can do it justice. 
And let's not forget about the actual quality of the HD art assets that the fans produce. I think it got better with time, but it's still not exactly at the professional level. 
Well, talking about Quake (or any 20-year-old game for that matter) as, ahem, "pixel art" and saying stuff like "an acceptably Quakey aesthetic" sounds pretty preachy and rigid-minded to me. You know, "this must be that way and any divergence is intolerable". Words you can hear in the mouths of zealots and dictators. Just sayin'.

As for the discrepancy between the simplicity of the geometry and the level of detail of hi-res textures, that's a matter of taste. A nice texture will always look better to me on a simple surface than a mess of blocky pixels. I thought they looked like crap 20 years ago and I still do now, luckily now I can get rid of those. And normal maps help a lot in fooling the eye into thinking that what it sees is more than a flat wall. Sure, normals can look a little weird sometimes depending on the viewing angle, but most of the time they do their job very well. As for low-poly models, you're aware that they can be replaced with hi-poly versions, right? If you haven't seen Fredrikh's awesome shambler or those shader animated ammo boxes (the nailgun boxes for example have each individual nail modeled) you're in for a real treat! 
Yeah, a modern reinterpretation of the game would rock all kinds of awesome! Sadly, each and every TC nowadays seems to stall after a while. If we're lucky we can get one entire episode, like Classic Doom, but these projects never see completion anymore. Have you tried Shambler's Castle for Doom 3? It's quite short but it's most definitely a must-play. 
Shambler's Castle 
I have, and yes, while it has its problems, it's the direction I was talking about.

A nice texture will always look better to me on a simple surface than a mess of blocky pixels.
Again with the "good vs. low-res" attitude. Low-res can be good too, even if you don't understand it. 
Dis Gunn Be Good. 
Jesus Fucking Christ 
I do understand low-res when it's real pixel art and not due to hardware limitations like Quake. Wadjet Eye productions, games like Minecraft or Eldritch are prime examples. Eldritch even emulates by geometry the broken lines of the textures in early 3D games! Quake's pixels and muddy palette were only the best approximations id could offer at the time and it makes sense to update them when technology has caught up.

Anyway, as I said it's a matter of taste and neither option is wrong, contrary to Kinn's absurd claim. We're not gonna dwell on it forever, this is not the place for this discussion. I originally asked a simple question and never intended it to escalate into a full-blown argument. But what do you know, vanilla vs. enhanced seems to be a touchy subject for a certain kind of people...

I'm gonna finish with something I wasn't able to add earlier because of connection troubles: you may not be aware of it but the monsters from Shambler's Castle (vore, scrag, fiend) have indeed been ported to Quake. Check also Fredrikh's shambler as mentioned above, it's really a sight to behold - first time I saw it I went "holy shit!" You can find both types of knights, grunts, dogs, Ranger, there's a great model for Tabun's enforcer and more. There's even a hi-poly tarbaby! Plenty of detailed models to complement the fancy textures and lighting effects. Not to mention a fix for the shambler's lightning that makes it finally come out of his hands as it should instead of his belly. 
Pixel art exists due to hardware limitations of the past as well. So?

Then again, I'm one of those misguided individuals who still produce art that's neither pixel art nor "good" art. My motives in this conversation are pretty obvious. 
Just A Comment 
I did not grow up playing Quake DOS and the first time I did play Quake was the N64 version. I started messing with Quake PC last November and used the Epsilon mod. I originally enjoyed the flashy visuals and weather effects but eventually I transitioned to Quakespasm and never looked back. I am just putting this here as someone who isn't specifically biased to old school quake...ness.

Anyway, I would love to see weather effects in quakespasm/maps. I'd make every flipping one of my maps rain because I love rain in games. 
Sitting next to his partner Kevin Cloud, [Adrian Carmack] clicks his lightpen all day long, making minuscule adjustments, one pixel at a time, to countless texture tiles: lichened stone, pitted wood, corroded metal, viny corpuscular stuff. - Wired


Quake was no pixel art, it was downgraded art to circumvent hardware limitations of the time - some fucking rando

Who do I trust?? 
Technically, Quake has little to no pixel art. Pixel art (in the modern sense at least) requires you to work with the palette colors directly, and 256 colors is a bit too much to handle efficiently.

Still, this kind of art (when it's done well) shares some traits with pixel art, such as a high level of precision when small details are concerned. It's kind of a necessity when you only have so many pixels to convey an idea. 
Mugwump, if you want rtlighting in quake, you need one of FTE, DP, or Tenebrae. They each have different featuresets and their own compatibility quirks too, hurrah.

I personally tend to use vanilla content more often than not. Its at least more consistent with itself, and imho replacement models tend to have goofy animations that I can't stand. Maybe I just don't like change. 
No one has to like amateur HD content. More often than not it's just weak.

Today I looked inside QRP_map_textures_v.1.00.pk3 that I happen to have. One of the first textures I clicked on was this little gem:

This is a texture of the "bodies" series. Guess what's missing: (this is the original)

I know drawing is hard, but come on. It's supposed to be an improvement. Although, FWIW, if they'd actually draw the contents of the texture properly, it would still look awkward on a flat 2D surface. You can barely get away with such "macro" detailing on a pixelated texture, let alone a high-res one. 
I like the low res art style. It's kind of funny, back in the old days I used to have a 3dfx card coupled with a Matrox 2d card and often I would prefer to play in software mode. The only time I jumped to the 3dfx card was if I was play Q2 and beyond. 
There's Something Magical About Low Res / Pixel Art 
Because of the lack of space for information, pixel artists have a somewhat impressionistic approach. The result, to me, kinda causes you to "fill in the gaps" with your imagination, giving the world a real sense of depth and interest. This works well with quake's otherworldly setting.

I love high fidelity art as well. But that's a different beast all together and puts a whole different set of demands on the artist.

In my experience, HD content for quake may be "good" in isolation, but in the context of other assets and game geometry it often comes off as inconsistent, out of place and amateurish.

A true HD quake would have to be a total remake with a focused and coherent vision from the ground up. 
Sieg Heil 
Words you can hear in the mouths of zealots and dictators

Cool, so I'm essentially Quake Hitler for simply pointing out why QuakeSpasm does not support the features you describe. Again, I'll repeat that I personally have no say over what features QS does or does not have. I'm just an end user. I happen to agree with the QS design philosophy though, as do I think most people on this forum.

We're not gonna dwell on it forever, this is not the place for this discussion

Hey, you dropped this turd on the carpet, don't think you're getting away without having a good sniff of it.

Quake was no pixel art, it was downgraded art to circumvent hardware limitations of the time

It's pixel art. There was no "downgrading" of existing higher colour or higher resolution artwork. The artists literally sat in front of Deluxe Paint with the Quake palette loaded and painted stuff precisely at the pixel level. Maybe you're using a different definition of "pixel art", in which case this is just a retarded argument over semantics and I haven't really got the time for that.

I'm not quite sure how someone could fire up id.wad in TexMex and look at arch textures like "church7" or things like "window030", "adoor01_2", "enter01", any of the stained glass windows, hell, pick almost any texture in the wad that's not just a plain stone surface...and then claim the artist wasn't precisely and purposely laying down palette colours at the pixel level... 
Literally Quake Hitler 
Making all those references to the not shooting Hitler bit from The Office has finally taken its toll. 
Actually, it's precisely the stone surface textures that make me really doubt that each pixel was done in a controlled way. You just don't do that. It's slow. Have you seen the amount of colors used?

While there wasn't any conversion from true color to indexed, it's pretty clear that some "dirty" tricks were still involved. But it really is a pointless argument, because being/not being pixel art doesn't make the assets good or bad automatically. 
I'll Write Something Relevant To The Thread For A Change 
Since the engine supports colored static lighting, are there any plans to add some colored dynamic lighting functionality? Right now all dynamic lights are white. 
Have you seen the amount of colors used

It's a very manageable amount actually because the contrast of the textures is very low compared to the range of the colour ramps used - so the number of colours used from each ramp is low, and taken from the darker end of the ramp.

The light colours in the palette only get seen in the game once the lighting engine does its thing.

Trust me, I am currently creating my own quake texture wad by working directly with the palette colours and ramps, using a bespoke pixelling program I wrote for a company I worked at (which was inspired by pixel apps like DPaint and Pro Motion).

Here is a just one example of one of my textures. I don't pretend to be an amazing artist but the aim is to at least be consistent with the style and quality of quake's original textures. The number of colours used is really really low, simply a handful of colours from the lower end of about 3 of the ramps was used in this one, and this texture look literally minutes to bash out: 
Do you know how DarkPlaces does colored dynamic lights?

(Hint: it's not pretty) 
that looks great 
And what I mean, let's say you want a fireball to be orange lighting?

How do you tell DarkPlaces to make a fireball's dyanmic light orange?

(It's an uglier hack than a tour inside a hotdog factory) 
Well, the stock textures are typically more smooth, and also occasionaly more "chaotic" in the sense that you can spot pixels that don't really belong color-wise. Some of these cases are clear mistakes that would've been hard to commit when picking colors manually.

In some cases you can clearly see that they blended two or more materials together. Quake even has some textures that are derived from Doom textures that were made of toy photos. And it's an efficient way of doing things. Although if you really made that texture in only a few minutes, I can only applaud your skill. 
I take it a cleaner solution doesn't exist?

Adding colors to old content retroactively isn't really necessary. I was thinking more along the lines of giving modders a way to assign colors in new mods. Like reading a certain entity field (if it is defined in QC), for example. 
From My Experience 
Dynamic colored lighting does not go well with static baked-in lighting at all. :( 
From My Experience 
Dynamic colored lighting does not go well with static baked-in lighting at all. :( 
I think color for the built-in dynamic lights would be a good addition. There are not that entities that move and give off light. Would it really be difficult to add?

(Lava balls
Magic bullets
Vore balls

What else?

Now, if somebody wanted moving light sourced from specific textures on doors, func_trains, and such, then I can see that being more of a problem. 
Well -- First 
But a cleaner solution than what?

I asked if you knew how DarkPlaces does it. And clearly, you don't.

One would naturally conclude:

- You have so little interest in the feature that you never have used it for yourself in DarkPlaces. 
My only interest in colored dynamic light is from a mapping point of view. It just looks very weird to see the fireballs, rising from deep orange-red lit lava, giving off pure white light.

The others I mentioned would be nice, rockets etc., but beyond that I don't see it as all that necessary for Quake. 
But a cleaner solution than what?
Than a solution used in Darkplaces, which you clearly see as ugly. I trust your opinion.

You have so little interest in the feature that you never have used it for yourself in DarkPlaces.
I have little interest in Darkplaces.

But it's pretty clear from your reaction that this is an unwanted conversation for you. 
Coloured Dlights 
Like the rather icky r_noshadow_list stuff, could we just not whack a great big string into the config file that maps modelnames to colours?

It's ugly but we already have a precedent for doing things that way...


That particular texture was really quick because it's just quick splotchy strokes with a bit of shade and highlight. Doing precise metalwork shapes and stone carving decor and whatnot is a bit slower obviously. 
Maybe if you educated yourself to understand what it is you think you want, you might see why it is unlikely to happen.

But instead, all your bring to the table is
- a lack of knowledge
- can't even be bothered to try it in DarkPlaces
- ignorance of not knowing what you are asking for

I think it is a bit rude to ask the Quakespasm guys for something you don't even know what it is, nor how it should work. 
To Anybody Who Cares To Read This Rant. 
On adding too much to the engine...

"Like reading a certain entity field (if it is defined in QC), for example. "

I'm pretty sure that is the kind of hackiness that baker was talking about. Modding in the engine is counter to what the philosophy of mods is to begin with.

Mods are programmed within the framework of what they're allowed to access / execute. Not only does it add bloat, but it also has the potential to break that mod for other engines. As soon as you bypass the vanilla framework you might as well just hard code the progs into the executable.

These features can be added, but where do you draw the line? I think the QS (and beyound that fitzquake) developers have done a great job at keeping engine bloat to a minimum.

I honestly think that quakespasm is not suited to visual enhancing features like darkplaces and co.

But you know what I did when I wanted IRC support in quakespasm? I learned some C and forked it myself. I wholeheartedly recommend that if you really want a feature added, then this is the way to go, not only do you learn a new skill, but you also get the feature that you want.

/rant over. 
Directq And RMQ 
I think had this and different colour coronas too, I'm sure they looked good because I stuck with those engines for a while 
Let me get this straight. Before I request a feature in an engine I'm interested in I need to:

- Be a programmer myself;
- Try the feature in an engine I'm not interested in;
- Understand that the feature is hopeless crap using my programmer knowledge;
- Never ask for it, because it's crap.

Did I miss anything? 
Posting in this thread is like playing Dark Souls; at first you'll find it cruel and unforgiving, but after many days, weeks and months of practice you'll intricately understand the attack patterns of the various mobs that lurk here, and be able to parry and counter their posts effectively. 
before you request a feature you need to:

- Prepare yourself for the possibility that the developers don't want to implement it.
- Not get salty when you don't get the answer you want. 
By not getting the answer I want you mean stumbling on an edgelord that I'm not even sure is one of the developers? 
That's One Approach 
Baker is weird. But he knows what he's talking about when it comes to Quake engines. 
Is certainly more articulate than Madfox, and provides far more polished content (ProQuake, Fitz V, etc) but god damn if their thought processes aren't equal. 
I kinda get that he knows things. That's why I said that I trust his opinion. 
I mean rather than arguing with them after they say no.

Perhaps instead saying to yourself:

"Maybe that's fair. That probably is a lot of effort for the developers who do this without any pay"


"well I really want this feature, maybe I should teach myself some programming and see if I can implement it myself" 
Developers saying no is not a problem. 
No, no, your opinion is wrong. Or in your ass, at least. 
"Hey, you dropped this turd on the carpet, don't think you're getting away without having a good sniff of it." No, I ONLY ASKED A SIMPLE DAMN QUESTION! You guys jumped on my back like a pack of hungry wolves on a pile of bloody meat. I'm not responsible for your behavior and I won't take any of that shit. Learn some manners.

"Mugwump, if you want rtlighting in quake, you need one of FTE, DP, or Tenebrae." You think I don't know that? Like I said earlier, I asked specifically because of those mods among my favorites that have trouble running in DP and whose readme recommends QS or Fitz.

"The artists literally sat in front of Deluxe Paint with the Quake palette loaded and painted stuff precisely at the pixel level." So they chose to add blue to... wooden planks? I remember reading a discussion about it among visibly knowledgeable people saying that the non-standard palette id chose caused weird artifacts like that.

"Anyway, I would love to see weather effects in quakespasm/maps." THIS. Weather effects, like dynamic lights, benefit greatly to immersion.

Dwere, you didn't think that the missing body from the texture was because the body was supposed to be rendered in 3D? Tsk-tsk... 
At least my ass isn't located where my mouth should be. Opinions are subjective, therefore can be neither right nor wrong. 
Nope Your Opinion Is Wrong. 
I laughed, thanks. 
Sure, whatever floats your boat, pal... 
Keep Sniffing, Mugchump. 
Bet that hi-res bump-mapped dung smells gooood, man. 
Oh, Grow Up 
Why do you feel the need to act like a jerk? 
Sleepy Was Right 
this is good stuff here. 
Learn some manners.

Says the guy who posted #2194 in response to #2191. lolbiscuits.

So they chose to add blue to... wooden planks?

Hehehe, just because you can find a few dodgy counter examples..hell, like another guy said, I'm sure you can find little elements that were photosourced if you dig hard doesn't change the fact that 95% of this shit was basically pixel pushed. I'm really not sure why this is such a tough thing to believe. 
This Thread Delivers 
Func_ Is The School Of Hard Knocks 
when it comes to dealing with trolls... 
Like Seriously, Mugwump 
Come the fuck on, dude.

and don't even get me started on the Rogue textures... 
Unlike some of your and others' comments, #2194 wasn't intended to be mean, aggressive or insulting, it was a depiction of your attitude towards graphical enhancements. You gotta admit you DO sound like a bit of a zealot about it. I'm sorry if you felt offended, I know I can be blunt sometimes but it wasn't an attack. Can we please get past this once and for all?

I'm not saying they didn't do a hard job or didn't spend countless hours lovingly crafting their game, but putting it all on intent and disregarding technicalities is delusional. IMHO. With due respect. Do you think they would have gone with blocky pixels if they had a choice about it? 
If is a word god uses when he wants to have a laugh. 
God remains to be proven real. 
Hey Im Here And Posting 
should be enough of a proof. 
Hello, God 
Ha ha, nice one! You sure do create awesome worlds. Do you do that in seven days too? 
It Took 6 
you infidel. even i need some rest. 
A supposedly omnipotent being needing some rest? Doesn't sound legit. 
Yes, It Is Legit. Worlds Are Hard. 
troll elsewhere, leave this thread for engine-related topics please. 
Since when off-topic=troll, exactly? But agreed, this whole discussion should've been taken elsewhere. I did say so myself a few posts ago. I was just making tongue-in-cheek responses to your humoristic comments. Mugwump out. 
Just Leave This Place 
else is idc 
Dwere, you didn't think that the missing body from the texture was because the body was supposed to be rendered in 3D? Tsk-tsk...
Before you leave this thread, I'd like to see a screenshot of this body rendered in 3D, or a link to a mod that enables that.

I'm assuming other textures with similar detailing preserved, but merely stretched/filtered, were always made specifically for such a mod, so you're not supposed to see the lazy parts.

I'm really not sure why this is such a tough thing to believe.
There's a saying about thirteen strikes of the clock. I've clearly seen the assets that weren't made using pixel art techniques, so I find it logical to believe that such methods were used on a regular basis. Why not, if it can make your life easier?

I admit that I don't know the exact capabilities of the tool that id used at the time (Deluxe Paint?), but I've heard it had some advanced features like blurring, even though it wasn't a true color image manipulation program.

Do you think they would have gone with blocky pixels if they had a choice about it?
Again, you could say the same about early pixel art examples. This is irrelevant to the question of how aesthetically pleasing is the art itself, or if the technique used should be abandoned.

Low-res paletted art generally takes less time to create than high-res true color art despite the former's limitations, so it still has its applications in non-commercial works where your resources are very limited.

Even a "retro" project is hard to pull off with an acceptable level of quality, so it's no wonder that "modern" amateur projects are so rare (and typically look worse than their technical level allows). 
Mugspunk Is Right About One Thing Tho. 
MFX needs to go map...

OTOH. Yes, if you redid everything in Quake, including all hi-poly models, increased the brushwork tenfold, etc etc, then sure hi-res textures and bump-mapping and shit would look good in.

At the moment, it is simply a matter of objective scientific fact that pushing some graphical aspects very far forward whilst other graphical aspects lag behind makes the game look like ass.

(Conversely, some graphical aspects - coloured lighting, fog, transparency, particles etc - can be pushed a bit and still be perfectly harmonious with the basic graphics when used well. Why is this? Who knows, just another immutable law of the universe).

This doesn't mean the potential isn't there, but the whole lot has to be over-hauled in harmony, not disharmony. 
I remember reading about this. If memory serves, QRP was originally a much more ambitious project designed to replace all textures AND all models in the game. After a while, they dropped the models part to focus on the retexturing. So the body was never actually made and the texture was "forgotten" and left as is. However, there is a fix for it: a hi-res body was added to the texture by someone else. You won't find it in QRP and I don't remember exactly who did it and where you can find it. Maybe in SMC but I'm really not sure. 
"Scientific Fact." Oboy... 
I Am Not Sure If I Prefer A New Kinn Map 
or new kinn posts. He has been on fire lately. 
A New Map. 
But using his own custom textures all of which are made from the text of his recent posts, and of course are fully hi-res, hi-definition, bump-mapped, specular-mapped and generally fucked up beyond all comprehension. 
With A Secret Room 
with walls textured in his Quake Hitler pose. 
Quakespasm 0.92.1 Released 
Version 0.92.1 of QuakeSpasm is released: This is a minor bug-fix release.
Changes since the previous version:

* Fixed large menu scale factors (was broken in 0.92.0).
* Fixed PAUSE key (was broken in 0.92.0).
* Updated some of the third-party libraries. 
In Defense Of Vagueness 
I remember reading about this. If memory serves, QRP was originally a much more ambitious project designed to replace all textures AND all models in the game.

What about remaking all the maps to have the high levels of detail that would justify the replacement textures and models? 3200 poly monsters in 400 polygon worlds look just as out of place.

But it's all academic anyway, Quake's vagueness is part and parcel of the deal now, and you can't upgrade your way out of it without disappointing a certain proportion of the player base. For example, this ogre replacement has been objected to on the grounds that he's holding the chainsaw in a hand, rather than it being grafted onto his arm. To some that was a limitation required in 1996, to others the body-horror was part of the appeal (this may explain why Edie is part-ogre rather than part-human).

Similar debates have raged on this board over whether Shamblers have fur or ragged pale skin, whether Fiends have eyes, and whether the Vore has a feminine physique or not (note to func_ regulars: please resist the natural temptation to reignite all of these below). The more you define the detail, the fewer people will agree with your interpretation. Best to let people's imaginations fill in the gaps, like a good book spared an imperfect film adaption. 
Oh And To #2276 
Thanks OZ! 
really preaches it. 
Feature Request 
Support for colored text in centerprint messages. I'm wanting to use them as headers on different bools that you read in this one map mine. They look fine in Darkplaces but have ^7 characters showing in QSPSM. 
@Veyron - my build server is back up now

re: rtlights and water shaders, I also don't think these fit in QS (both code wise, and engine focus). I think it's good for the Quake ecosystem to have multiple engines with different specialties, QS shouldn't have every possible feature.

IMO, if you run in to a map that FTE and/or DP have compatibility issues with, you should make a detailed bug report explaining the problem. 
Weird Ramps, Hidden Steps 
Getting stuck on what feels like tiny brushes. Ramps in general are pretty sticky to traverse in this engine. Maybe I'm missing something, same problem occurs no matter what the fps. Here's a screenshot
That can happen when three or more different planes intersect along the same line. In this case the floor, the ramp, and the near wall of the room. Is that a map you made or just one you're playing? 
That's good to know thanks. Nope, it's e1m1. [= 
Leave host_maxfps at 72, otherwise it'll mess with the physics. 
It happens even with host_maxfps 72 though. 
Quake has 2 colors for text --- gray and "bronze". With some QuakeC compilers like FrikQCC you can add do "/bThis is bronze text/b"

Of course, FTEQCC is the go to compiler these days and I can't remember if FTEQCC supports that (at one time it didn't), but it is still possible by pasting in text from a Quake text maker like:

This method does not need any compiler support, you should be able to put that text even in map titles and such. 
I did notice the funky physics when playing on 250. Knocking it down to 144 keeps it fluid and fixes the bobbing around on descending lifts. Will probably end up playing on 72 if I run into anything worse. 
My light.exe also processes "\bThis is bronze text\b" anywhere in the map file so you can easily use it in trigger messages, etc.

re: e1m1, I can get stuck walking towards the ramp from the e1m1 exit slipgate with winquake.exe (and in QS as well).
So at least it's not a new bug. :-/ 
@Qmaster. A 2nd option ...

Make your own conchars and distribute it with your map.

Then the "bronzed text" can be whatever color you edit the conchars to be. 
@ericw -- pretty cool (although I won't ask why the light.exe is what would do that instead of the bsp compiler, haha) 
"you can't upgrade your way out of it without disappointing a certain proportion of the player base"

Why the fuck should that certain proportion of the player base care about how I upgrade MY Quake? They're not playing on my setup, are they? I came to this thread with a simple engine-related question and got bullied for even daring to ask it. There's conservatism and then there's fanaticism. One I can understand, the other not so much. 
Why are you asking Preach for permission to upgrade your Quake?

Idea: Upgrade your Quake without Preach's permission? 
I came to this thread with a simple engine-related question and got bullied for even daring to ask it.

Please stop trying to rewrite the history. The only reason you got bullied is because you started accusing people of fanatism and backwards thinking out of the blue. People don't like such arrogance no matter how "delicately" you express it. 
Hobby Engines 
Writing engines is a hobby, so it's about the author's vision for what the engine should do. If you want them to add a feature for you, then you're talking about something larger than yourself. 
Baker, I don't ask him permission, I'm replying to his last message to me.

Preach, I don't recall asking anyone to add that feature, I just asked if it existed.

Dwere, who's rewriting history here? Comments like "acceptably Quakey aesthetic", "your opinion is wrong" and other bullshit like that ARE fanaticism and THESE are the arrogant attitude, certainly not calling people out on it. People may not like having their shit shoved in their faces but the shit is theirs, not mine. 
is this discussion seriously ongoing? 
Your Opinion 
Continues to be is wrong. 
The "Second Wind" 
...a bit like post-mortem flatulence. 
Never Disappoint Kinn. 
"Acceptably Quakey" is a valid term when talking about an engine that's supposed to improve on the original aesthetic without replacing it with something else. If you got set off by such a vague (and most likely unintentional) hint at superiority, then perhaps you shouldn't be surprised that your own sermon about what's "better" led to unpleasantness. 
The Trolls Have Awoken 
How surprising...

@Shamblernaut When people talk to me, I reply to them. That's how communication usually works. Preach talked to me (see post #2277), so I replied. A bit late, I admit, but I've been busy mapping and playing Quake.

@Kinn I bet you know all about flatulences with that potty mouth of yours... 
AFAIK, I've never stated my opinion of what's better as an undisputable fact. On the contrary, I've underlined that it was my personal preference. 
Too Little, Too Late 
Actually No. 
You argued that Quake's art is not pixel art, despite the fact that it obviously is. The result of 2+2 is not a matter of taste, it's always 4. 
It's not as obvious as you think. 
Pixel Art 
Ah, glad to see you decided to ease up on the trolling, OTP. Pixel art is a modern style designed to emulate the look of early textured 3D games. Though id carefully crafted their art direction, it was not what is called pixel art. Yes, it was art and yes, they used pixels, but the comparison stops there. 
Pixel art is a modern style designed to emulate the look of early textured 3D games

It's like he's not even trying anymore. 
Who's Not Trying What? 
One True Pairing 
Mugwump and OTP are my OTP. 
"early textured 3D games" Please read "oldschool pixellated games" instead. Though I mentioned Wadjet Eye earlier, here I overlooked the fact that the term is also used for these 2D games that emulate the look of the 8/16 bit generations. 
Well yes, 2D productions a la Wadjet Eye and 3D productions a la Minecraft are both called pixel art. 
Let's put it like this: it's the 3D games I'd use "also" for.


I can clearly see the use of soft brushes on the background. Looks like you tolerate "mixed style" games after all. 
I would also like to add that even though the term "pixel art" seems to be a relatively recent invention (correct me if I'm wrong), it still applies to older games retroactively. 
Did I ever say otherwise? After all, I do use hi-res textures on simple 20-year-old geometry. Question: how do you infer the use of 3D brushes from a fixed image? 
I wasn't aware of that. I've never heard the term used for these old games. If that's true, I stand corrected. 
I always wondered why the building blocks used for mapping in Quake-like engines are called this way. It kinda makes sense (because laying them is sorta like laying brush strokes), but not really. 
Whats Going On In He... 

*backs away* 
Yeah, 3D editing vocabulary is often puzzling me too. I've looked at your example picture again and I think you may be wrong. You're talking about the reflections on the facade of the building, right? Look again: the perspective of the reflected building right to center is wrong, it should be reversed with the side visible on the left, not right. 
No, I'm talking about soft brushes.

Brush is a thing you paint with. It's also an appropriately named tool in image manipulation programs (because you paint with it). 
Ah, this kind of brushes... I was wondering what you meant by soft. What's the mixed style you were referring to, then? I thought you were talking about the use of 3D brushes in a 2D game. 
Pixel art combined with not pixel art. 
Oh, right, in the sense that pixel art is made pixel by pixel whereas brush work is not. I have no idea how you can spot which technique was used in the final image. 
It can be argued that 256 colors are okay to pixel things. 16777216, on the other hand, is a bit excessive. 
I was certain I read somewhere that a lot of the textures in Quake were painted and then down-ressed. I suspect that many of them were touched-up afterwards in some pixel pushing software (as well as some made entirely pixel-by-pixel) 
I didn't know this game used 24-bit coloring. Is this their latest production? The last Wadjet Eye game I played was The Shivah, which still looked 8-bit to me. It seems the definition of pixel art has broadened. 
They Look Waaay Too Good For Scaled Art 
So yeah. There was a lot of precise work involved, this much I can say. 
Blah Bla Blah...use "bronzed"....Blah Blah Blah 
Ok thanks I'll stick with bronze text for both, didnt realize it was dependant on compiler...thought the engine had to be able to recognize the \b characters.

Carry on with your mindless stylistic vs realistic debate. 
Doesn't Look 8-bit To Me 
Dropping This Bomb In Here On My Way Out: GL Blur Isn't An Improvement 
That was me in the comment above BTW, I hadn't noticed I was logged out.

@Fifth Yeah, I remember reading that too. That's the source of my "downgraded art to circumvent hardware limitations" comment from the other day. 
Kosher Edition 
Unless it was redrawn or something. Its page mentions something like that.

The earliest game on the site seems to feature pixel backgrounds. 
It would seem that the debate had moved on. Not sure if it's a good idea to reignite it with arbitrary statements like "GL Blur Isn't An Improvement", which is a matter of opinion. Of course, it works better with hi-res textures, but some people do prefer blurry vs. blocky, even on low-res textures. 
Granted, this particular image looks a bit lush for 256 colors. Other screens in the game look less "refined". 
They all feature true color backgrounds with pixel art characters (excluding portraits). 
Thinking about it, I have to admit that The Shivah effectively looks more 16-bit than 8-bit. I don't know how many colors they actually used but it looks like a Megadrive/SNES game. 
You should be more careful when mixing processor bits with color depth bits in the same conversation, but whatever. 
Well as you probably have guessed I'm no expert on the subject, but you gotta admit that it's a bit confusing when they use the same term to describe different things. Like "brush". 
Scaled Art 
Like I said I'm sure it was traditionally painted, like oil painted, and scaled down. Then it was tweaked using pixel pushing techniques afterwards 
The Doom monsters started as scanned in photos of actual models. 
Which is probably why they looked so coherent from all sides. 
Is MugWump now allowed to just trash this thread into smithreens?

He's not house trained, where is a moderator?

This is the Quakespasm engine thread, not his personal litter box. 
The Fucking Bullshit Pixel Art Drama Thread 
Hey, I came back here to reply to Preach. Like I said, when someone talks to me I respond, that's the basic principle of communication. People then commented on that reply, etc etc... and I wasn't expecting the discussion with dwere to be this long. Next time I'll move it to general abuse, but between you and me you should work on your people skills. You know I'm new to this site and right now, you're making me feel very unwelcome. Not cool. Mugwump out. 
You trashed up this thread.

I don't care how you feel, you are the wrong-doer

An apology would be nice. 
Make Up Your Mind 
You want me to shut up or you want me to apologize? Maybe you should ask all the people who kept me talking - including you, how ironic! - to apologize too, they're just as responsible for making the off-topic linger on. But you won't do that, will you? Mugwump out. Again. 
The Beauty Of Hindsight 
Maybe you should ask all the people who kept me talking...

Yeah I agree that it was a mistake engaging in conversation with you in the first place. I imagine not many of us on this forum will bother doing that again. 
Yeah let's all pick on the new guy. Provides coherent arguments and all you do is whine about how this is the wrong thread. Boo hoo. Reminds me why nothing decent ever comes from this community, just circle jerking over a 20 yo game. 
Spitting obvious nonsense and/or insults is the lowest form of trolling. 
But This Is The Wrong Thread. 
not for the initial discussion, but certainly for what it evolved into. 
Yes Dwere 
I'm sure there's an argument in that statement somewhere, whether or not it is real. Right? 
Switching Mood Settings During Gameplay? 
Is it possible to switch different fog color or overall settings which support different moods? Yes I was thinking of Quoth when it comes to logic gates yet sending console commands during gameplay, but personally I wanted get back into AD modding too. I guess this hasn't to do much with the engine in this case, but it should support these features I know or might not know yet. 
AD lets you change fog colors. 
SolidClass base(TrigOFF,Targetname,Target) flags(Angle)
= trigger_fog : "Trigger Fog" [
speed(integer) : "Time to fade (-1=Instant)"
wait(choices) : "Wait before reset" = [
-1 : "Trigger Once"
0 : "Always reset"
2 : "Default"
fog_density(integer) : "Fog Density (def=0.1)"
fog_colour(string) : "Fog Colour (0.1 0.1 0.1)"
Fog In Quoth 
Quoth doesn't have a dedicated fog entity (yet), but you can use a trigger_command or trigger_command_contact to send a new fog command to the console and change the color that way. 
Feature Request 
Is there a way for an entity to be marked by QC so that QuakeSpasm does not included it in demo's or MP/Coop traffic?

A new key, an existing flag, something that can be set via QC so that an entity is never sent, transmitted or recorded and remains client side only. I really want this for the QC sprite particle system so players can enjoy the visuals and not create monster demo files or drown network connections for coop. Thanks. 
Thanks, that answered to my question* 
Fog, Just To Wanting To Make Sure 
So I can use these trigger_fog brushes, and inside of it will be specific fog I set up. If I put next to each other almost the same duplicates of the original, but I only change color a little bit.. or maybe changing it to totally different color like from blue to orange/yellow.

It that is possible, has any maps done this in the past? 
Is there a way for an entity to be marked by QC so that QuakeSpasm does not included it in demo's or MP/Coop traffic?
Its called the remove builtin... just check that deathmatch or coop are set first...

regarding demos there's not much you can practically do. The recording is clientside rather than serverside, so csqc's access to that sort of thing is going to be limited whatever happens. I guess an engine could add a some cvar that gets set when its recording/not (which would only work for local servers), or it could send a clientcmd (which qs mods would then be unable to parse anyway).
the client just dumps the entire data that it receives, so a serverside flag would do nothing to prevent demo bulk (unless the client was rewritten to be muuuuch more selective about what it writes).

one alternative would be to write a tool that just strips entities out of the demo based upon their modelindex, after the demo has already been recorded.
alternatively at least one server includes gib filters, which can be used to disable sending of entities based upon their model/frame. for instance a serverside gibfiltr.cfg file in fte with 'model firstframe lastframe' lines, which can be enabled on a per-(qw-)client basis with 'setinfo nogib 1'. obviously different engines, different rules, and I have no idea about eg qrack. looks like baker added some flags into proquake that a mod can set too (which naturally conflicts with dp extensions). the catch is that absolutely none of this is automatic, so whatever happens you'll have to get the user to manually switch stuff off to avoid huge demos.

one way to reduce bandwidth would be to pre-spawn your various particles/entities with the right frame/modelindex/colormap/skin/angles/scale/alpha already set.
then use only those entities for your particles.
this will reduce wasted bandwidth from resending the modelindex etc with every single packet.
qw/fte/dp are not so wasteful, so you won't gain much from that with those protocols.

anyway, pick your poison, give it a little momentum and someone will probably implement something eventually.
or just live with the user being explicit about it. 
NewHouse - Re: Fog 
When different trigger_fog brushes touch each other, the fog will actually flow from one brush to the other, through the joining faces, until the fog is equalised - so for example if one fog brush is full of red fog, and it touches a blue fog brush, the fog will mix until both brushes contain a purple fog. czg's Honey uses this extensively to get the smooth transitions between fog colors - different colored fog brushes are dropped onto invisible func_trains - the trains then move them around to collide with each other - when they collide, the fog mixes and you see a colour change. 
Ayy Lmao 
Thanks, that sounds so neat. I only can assume it can be used many other ways too. Maybe finally I can create that resembles doom's sector lighting even - but in form of fog. 
what* resembles doom's sector lighting.. 
Yes, it makes for a very flexible system with loads of different applications. 
ayy lmao kinda explained that poorly.
trigger_fog is NOT the same thing as eg q3's fog volumes.
the client can only use one set of fog at any time, which is applied to the entire map...
the trigger_fog brushes just change that client-wide setting once the player bumps into them, and its is applied smoothly over a short duration.
for practical purposes you're pretty much limited to one sort of fog per room, and transitions from one room to the next have to be handled really carefully to avoid the psychadelic world-changing-colour effect, typically by having small half-way rooms/corridors to keep the player distracted.
the smooth transitions mess up teleporters too.
they can be used for decent enough effects though, just remember that they're global and affect both near and far walls. 
Wishful Thinking 
anyway, pick your poison, give it a little momentum and someone will probably implement something eventually

Thanks spike for your reply. I was hoping that some kind of entity filtering happened when client demo's are recorded and another exception could be added to a list somewhere. I use the particle system built into DP/FTE so they produce better demo sizes.

There are so many new features I would love to be added to QuakeSpasm, but I do understand why they are not. Its just frustrating from a QC/MOD point of view as so many modern features (ie. global fog) are just hacks in QC to get them working. 
Would rock 
I will keep that in mind, I need to experiment a bit of it, after all my map will consist a lot of hallways, but I assume even elevator would work as a mood changer. 
Weather There Will End Up Being Weather 
I took a very quick shot at generating rain/snow and deconstructing the method used for Qrack's gl_rain.

Qrack gl_rain

Qrack uses for gl_rain video ... look at 13 seconds in to see gl_rain.

1. Take the sky surfaces.
2. In GLQuake, the sky is subdivided. (FitzQuake/Quakespasm it isn't and it would need a fake subdivision added in to have these rain or snow points.)
3. Average out the vertex positions in each sky polygon.
4. Emit rain from around those areas.
5. .. With a bit of randomness in origin
6. .. Some randomness in direction

End result is very easy rain.

But the fine tuning may be important ...
7. Appears to generate particles even out of view, which would be important if entering a new area.
8. But this means a ton of sky in a map is going to use a lot of particles.
9. But the particles at least "as-is" don't check for collision with the map or map entities (retractable bridge) and it would really need to. I can find indoor areas where rain comes through because outside a sky brush is over that structure.
10. Qrack does not appear to have rain in water, but I don't know if this is just because the particles don't last long (possible) or if I didn't find the code that killed off a particle that touches water.

Snow is would be easy to generate but possibly hard to fine tune.

Seven's DarkPlaces rain/snow

Video | Code + info

Another alternative would be the approach Seven used for DarkPlaces .

But Seven's DarkPlaces approach requires snow or rain emitting brushes in a map (func_snow or something?) -- which makes sense because QuakeC very likely has no way to know where sky brushes are.

Qrack's automatically identifying sky points method is vastly superior and easier on someone wanting to use it.

But there'd be a ton of fine tuning required.

I know because I took a quick shot at it screenshot.
1. Edit glpoly_t structure to add a vec3_t midpoint field and offset field.
2. Add a "rain think" in CL_RunParticles
3. Use -particles 8000 in cmdline // Default 2048
4. Pretty much take QMB_LetItRain from Qrack but adapting it to be just normal particles.
5. Some messing with Mod_PolyForUnlitSurface to pick vertex coordinates for snow/rain points. Would need some sort of fake polygon subdivision added back in to get it right.

(*) Seven's actual code appears to not use CSQC (client-side QuakeC), which would be better and required to avoid all of the problems with QuakeC rain (each rain drop particle is an entity, each entity saves in demos and has to go from server to client ... majorly big problems there). 
Note: The above is detailed notes for the benefit of whomever.

I took some time to chart it out, thought it would be good to record the info and make some notes.

But I don't really have time for engine coding--- especially something that would involve a lot of time intensive fine-tuning --- and don't want to create some sort of false expectation here.

On the plus side ... Spike seems intrigued by the idea of adding FTE's particle system to Quakespasm in the General Abuse thread.

If he would actually be willing to do something like that, that would be right avenue ;-) 
I have to say, I'm not sure I agree with this statement:

"Qrack's automatically identifying sky points method is vastly superior and easier on someone wanting to use it."

Unless there was some other way to limit which sky sections snow/rain could fall from, it would be a rather unfriendly situation to work with. Obviously the majority of cases it would be perfectly fine to have the particles fall from any sky surface, and it would certainly save on a few brushes, I can't think of a situation where it was better not to have as much fine-grained control as possible in content creation.

Just my 2 cents, of course. 
We'd still want the option of just spawning from all sky though - to suit the 90% of users who'd want to do it like that.

We'd certainly also want the ability to trigger sky rain on/off and change the density of it etc. midgame (like we do with fog triggers in AD and whatnot). 
Holy Shit Baker! 
That is some awesome info collation / analysis.

Best option (IMO) would be to use a particle based system from a func_weather/rain/snow brush. This way it could be triggered on or off, disabled in multiplayer, chosen where to implement and could allow flexibility in properties.

Style: snow, rain, acid-rain, etc
Density: distance apart.
Speed: speed.
Angle: straight down or xy

Am I going to implement this myself? Fuck no, I have enough shit on my plate already =P 
If You Did Do Sky Brush Emmission 
It could be blocked with skip brushes or skip the engine supported it which it should since particles should be blocked by geometry. 
*or Skip Should Read Or Skip Func_togglewall 
baker, if you're using points rather than triangles/polys, you're doing it the lame way.
you can find the correct(afaict) maths for an even distribution in eg fte's R_Clutter_Insert function. no need to subdivide that way, and you don't get particles spawning within walls either (excluding fpu precision, anyway).

the idea of quakespasm with effects like (please excuse the bugged gloss, that's an ooold video) and yet no texture replacements kinda makes me laugh.
at the same time, the idea of a load of cubes or quads or circles or whatever doesn't fill me with confidence either.

regarding csqc, the idea of that without any other qc extensions nor replacement textures is also a bit of a joke, at least for everyone but the guy trying to use it, who would get too frustrated to produce anything worthwhile.

really though, if you want an engine with a decent particle system and decent csqc etc, then just use an engine that already has that stuff.
in all seriousness, a low-res weather system is imho just going to look as goofy as eg the gloss in that youtube clip. sure, its interesting to do for the sake of doing, but I'm skeptical about the results and repercussions. 
in all seriousness, a low-res weather system is imho just going to look as goofy as eg the gloss in that youtube clip

What I had in mind visually, was something that follows the same kind of aesthetic as sock's particle stuff. It's totes quakey. Just simple pixelley spritey things. 
@Spike -- interesting points ... of course my attempt to was to chart out existing bodies of work --- I was curious as to R00k's method of picking rain origin points.

Snow? I was thinking a bit subtle along the lines of Nehahra snow.

... but adapted to look a little more like Seven's DarkPlaces snow.

I'm in the school of thought that map effects in this game should add very gently to the content they appear in. Versus the idea of the effects being the center of the attention.

/Which may be largely academic, lack of time and all that ... 
Baker, that video almost perfectly describes what I was thinking in terms of weather effect quality. 
"I'm in the school of thought that map effects in this game should add very gently to the content they appear in. Versus the idea of the effects being the center of the attention. "

Wins the thread.

Also that video is nice and subtle, yeah. Works well. 
Yes That's The Stuff 
Nice and inoffensively quakesque. 
Pixellated Snow/rain 
is perfectly fine for those engines aiming for a "classic" feel. Anything else would be jarring. 
Looking at the neh snow video, it's striking how something so simple adds so much life to an otherwise static scene. A Good Addition To Quake. 
The same way as Sock and other top modern mappers use fog and coloured lighting. 
Custom Resolutions 
So, is it possible to use a custom screen resolution in full screen mode? Setting vid_height, vid_width in the config appears to do nothing unless it fits one of the standard resolutions available in the in-game menu. 
The menu should list all the video modes that your driver says it can support, so probably not, unless the list is incomplete. 
Bah Humbug 
Well, I'm trying to set it to 960x540 on my 1920x1080 laptop lcd (so, exactly half-resolution).

960x540 doesn't appear in the menu :{

Reason I'm trying this is because I think quake looks best at around 480 vertical resolution. I figured if I could set it to exactly half-resolution of my LCD it might minimise the shitty blurring that happens when LCDs try to display lower than native res. 
Play It Windowed At 1280x960 
that is 2x scaling

nice and simple. 
Well, I'm trying to set it to 960x540 on my 1920x1080 laptop lcd (so, exactly half-resolution).

I tried exactly that a few days ago with no luck :( I thought I was just doing something wrong, guess not... 
I'm trying to get a low-resolution display of the game blown up on the screen so I can see da pixels nice and chunky.

Anything in windowed mode isn't going to be blown up - unless I'm missing a trick here?

Also, I still kinda want it fullscreen and using the same aspect ratio as my monitor.... 
I always felt you had impeccable taste. 
Me Too 
Uh, Run In Dosbox With Dosquake? 
might have more luck

-width 960 -height 540 -fullscreen quakespasm in linux just defaults to 720p with a black border 
also, i assume you've run vid_describemodes in the console? 
Uh, Run In Dosbox With Dosquake?

Nah, that sounds like a rubbish way to play QuakeSpasm. 
Ah Gotcha 
so install windows in dosbox then install and play quakespasm 
also, i assume you've run vid_describemodes in the console?

Yes, hence:

960x540 doesn't appear in the menu

Anyway, if my laptop just can't display 960x540, then I guess I'm out of luck. Stupid laptop. 
What kind of GPU is in the laptop? On this computer (Geforce 210) the Nvidia control panel seems to think it can set a custom resolution not supported by the monitor (LCD 27" 1920x1020"), but by default only lists the standard resolutions down to 800x600. I've never tried it though. 
GeForce GTX 765M 
Creating Work For Other People 
This is my attempt at getting some of the things that annoy me about quakespasm resolved, as well as some stuff that I think people like Sock would want to use if they could.
1 patch
1 readme
1 qsextensions.qc file
1 win32 binary (without deps)
some source files (without libraries)
1 copy of the gpl license...

Check the readme for the actual changes.
I'll probably update it a bit when people find all my bugs, or if someone I respect critisies me for not bothering adding something I was too lazy to bother with or didn't think of. Or other weasel phrases that get me out of any obligations both expressed or implied... 
Spike makes it sound boring. Has some very, very serious Kung Fu in the patch.

/Laughs are strlcat/strlcpy inclusion, I can't stand to see code that doesn't use those BSD originated functions. 
goddamn, just seeing QC file access stuff is almost enough to get me modding again. I haven't even read the rest of the readme! 
what is "bsp introspection"? 
Bsp Introspection 
@Kinn, posh words for DP_QC_GETSURFACE (which is handy for figuring out textures, or weird particle effects or whatever, I've used it to align csqc UIs to walls in the past, but meh). AD uses it to fix solid-sky issues with vanilla maps. smc uses it for figuring out footsteps, etc.

@Baker, strlcat+strlcpy were already in there. I just included ALL the .c+.h files from the 'Quake' subdir, because I'm lazy. I only two new .c files, but they're both bigger than any of quakespasm's existing c files...
check the patch for the actual changes, and good luck trying to isolate the parts that you're interested in. 
Pretty Cool ... Best Stuff Is Easily Seen In Readme 

Spike adds the (float) type cast.
But in C, variadic parameters of float are converted to double.

/Just a jokey comment.

Misc Noticed #1 ...

#define TEDP_PARTICLERAIN 55 // [vector] min [vector] max [vector] dir [short] count [byte] color
#define TEDP_PARTICLESNOW 56 // [vector] min [vector] max [vector] dir [short] count [byte] color

Misc Noticed #2


eliminate pink edges on sprites, etc.
operates in place on 32bit data

spike -- small note that would be better to use premultiplied alpha to completely eliminate these skirts without the possibility of misbehaving.

Misc Noticed #3

Spike does something with SZ_Clear and SZ_GetSpace, probably fixing a bug. Looks like buf->overflowed was set to true, then nuked. However, the buf->overflowed=false was removed in SZ_Clear and SZ_Clear is called all over the place. (Mistake?? Too engine rusty but looks like a possible mistake. And what bug was it fixing? I believe there is a bug it was trying to fix)

Misc #4

Looks like Spike made MAX_MTU work on packets (it never worked in Fitz 0.85) and then implemented something to allow multiple ones. (Wondering, is backwards compatible? I would guess no. And backwards compatibility probably shouldn't be important in this case.)

Misc #5


#define NUMQUAKECOMMANDS (sizeof(quakebindnames)/sizeof(quakebindnames[0]))

I hate it when people don't do that, haha.

Misc #6


"spike -- this is actually a pointless waste of memory.
//its not like this data will actually be used beyond this function in any gl renderer.
//this makes copying it pointless"

memcpy ( tx+1, mt+1, pixels);

@Spike: In Mark V, I use that data to allow real-time toggling on/off of external textures. And if I recall right, I use that data to quickly reupload textures if a video resolution change occurs that doesn't let GL context be reused without re-reading it from disk.

Misc Note #7

Some great comments in net_dgrm.c


Anyways, it's all some very nice and incredible stuff in there! 
Spike - cheers - sounds very cool :)

oh wow the particle system sounds great :o 
Any Chance Of A Translation? 
Not everyone on func_ is a programmer/wizard/jesus... what's all the excitement about? 
There's a readme in the download. Kinn has rummaged through it.

I didn't reveal hardly any of huge surprises. 
@FifthElephant, sorry, I suck at explaining, so I left it kinda raw.

basically, there's:
1) a load of boring uninteresting stuff that mods might use. eg, you can imperfectly run smc (check the readme for the issues I know of). smc itself isn't the aim, but the lack of any extensions in fitzquake-derivatives is why we can't have nice things like string concatenation or traceboxes in the mods that really should be using them instead of crappy hacks.
2) some networking fixes/tweaks that if nothing else should make coop significantly easier to get going, just open a udp port, set your server as public, and people should be able to find you.
3) particle system that can be used by mappers to emit custom particles from surfaces based upon their texture names, like rain, snow, sparks, etc. I should give a proper example of this.
You can also use particle configs made for either fte or dp, just so long as they didn't use jpg or png textures, but that wasn't the real aim here, mostly for rain/snow/sparks/emittance/smoke vents/etc.
4) some other stuff. ramble ramble. modders blah blah. *continues to make uninteresting noises*
there's not really meant to be anything fundamentally new here (if there was then I'd have added it to FTE first, thereby making it not new). Really its just a version of quakespasm that tries to NOT be crippleware for modders, as well as fixing some networking/connectivity issues.
it still has no csqc nor replacement texture support. :P

The thought of people doing non-quakey things with the particle system is a worry, but hopefully the community and that continued lack of replacement textures will keep those people grounded somewhat.

#2) alpha testing with a reference value of 0.666 will probably kill skirts well enough, but with linear sampling you get weird curved shapes to it. when blending, premultiplied alpha is much better, especially with mipmapping. I was trying to tread lightly and I'm lazy so I just left it as a comment rather than making any actual changes there.

#3) few things use allowoverflow, and thus few things can actually have the overflowed flag set. really its just unreliables, and those only check the overflowed flag when there is actual data inside them. that change just makes things a bit cleaner in that case.

#4) really I just reduced the mtu size of reliables back down to 1450, from 32000. nq always fragmented reliables, but it used the same value for reliables and unreliables. unreliables are still unfragmented and I didn't change any limits there, so there's nothing 'new' here. reliables now fragment much more frequently, this will have increased latency and made (non-local) load times worse, but should keep packet sizes below ethernet thresholds, preventing 100% packet loss and the inability to connect properly.
the protocol itself is identical, the receiver is in no way harmed by this change, but its still above 1024 and thus will still be an issue for vanilla clients.

#5) I have a countof macro in fte.

#6) I stopped copying the extra mips (because only fte would dare trying to use those in a gl renderer), but it still copies+preserves mip0 because of paranoia (I couldn't be arsed to read through the entirety of gl_texmgr.c to make sure it was safe).
And yes, I can be quite harsh with my wording even when I don't follow it myself, sometimes its just easier to not bother fixing it - I'd say it was nice to know what you could be fixing, but frankly its more a reminder of how many things you cba to fix... Lets just say that the comment was for a rainy day.

#7) well... I'm glad someone got something out of it at least. 
Awesome Stuff Spike 
some stuff that I think people like Sock would want to use if they could
Wow this is just awesome, QS + DP/FTE particle effects! Spike you are coding genius! Really nice to see all my DP particles flying around! :D

So I manually load the effectinfo.txt file (with the QC you specify in the readme file) and AD starts to use the new effects. For some reason I am getting 'backup Past 0' constantly spammed to the console when I load a map. I tried out ad_test10 and I get the following visual issues. Not sure how to fix this, any clues? 
backup past 0 is a traceline/tracebox thing (I think I included a note about how the vanilla code was stupid, but didn't dare fixing it due to probable precission differences and resulting minor incompatibilities).
the particle system does quite a lot of traces against the world and brush entities, so I guess I ought to try to rewrite that, even it it ends up behind a cvar.
or maybe I should just make a specific version for the particle system, where precision doesn't matter so much.

the diagonal Os look like a REALLY big copy of the particle font... I have no idea what's going on there.
the lines in the middle are something else, and the bit on the left is utterly bizzare, I've no idea what they're from either.
Hurrah for making sure I retested everything!... or not!...
only things I can think of is a NAN (possibly from uninitialised memory, a degenerate triangle, or even qc (read: division by 0). note that this could also explain the 'backup past 0' spam).

also I suspect I broke weather effects by trying to get decals working, it might be related. shows how much I test things...
I'll be sure to test ad_test10 to see if I can reproduce it.

try setting r_particle_tracelimit to 0, that should stop it from spamming traces (which will also disable blood decals).

Sock, just so you know, I also snuck in a 'cl_recordingdemo' cvar which will contain the filename, use cvar_string to read it or something. :) 
the glitches appear to be from decals.
it doesn't seem to happen in debug builds, so its probably something that I left uninitialised somehow.
I don't get the 'backup past 0' spam. 
cheers, this looks crazy!

Speaking of coop, I tried to run ad_swampy.bsp in coop last week, with QS svn.

The unreliable message limit of DATAGRAM_MTU = 1400 for nonlocal clients (here) was making it unplayable, was getting lots of "Packet overflow!" and most entities were not visible. Everything seemed OK once I uncapped that to MAX_DATAGRAM (32000).

Does it sound reasonable to remove that 1400 cap for nonlocal unreliables, maybe only use it if a cvar/cmdline flag is set?
I understand that large UDP packets are frowned upon and more likely to be delayed or dropped.. but not handling large maps/mods at all is worse. (I assume there is no way to break up the SV_SendClientDatagram message into multiple udp packets without changing the protocol?) 
re: "backup past 0" spam, it only happens with "developer 1" 
reliables larger than the mtu = server keeps trying to resend, blocking delivery of all later reliables. this especially includes the serverinfo, making it fatal even on tiny maps.
datagrams larger than the mtu = game packet gets dropped. when whatever activity goes away (ie: gibs fade out, the other players stop spamming shotgun effects, etc) then the game recovers.

nack networking (namely, fte's replacement-deltas protocol extension) was one of the things that I was considering adding, and would fix the huge unreliables issue, by splitting up huge updates into multiple frames.
the client parts border somewhat on trivial (at least if you're familiar with 666 etc), but the server side can get messy with logs and flags and resends and figuring out what consitutes a nack.
in contrast ack protocols like qw just spam everything every packet until acked, and are actually quite expensive on ram on the server.

remember that there are two protocols here.
if you're unwilling to change the nq protocol, you might be more willing to change the 'netchan' (ie: net_dgrm.c) to split+reassemble.
there's a limit to fragmentation though. bursting more than 4 fragments will generally result in the extra ones getting fragmented, so if you were to fragment that way, I'd suggest to have each unreliable fragment be complete in itself, so that they can still be reassembled even if there are gaps.
large unreliables will break the vanilla client anyway. so yeah, its important to know what you're trying to talk to.

I guess I ought to try to do the nack deltas thing, huh.

and yeah, I forgot about developer 1. :/ 
Just give it FTE's QW protocol support with map/model download so people can actually coop, throw in minimum CSQC so Sock's particles live on the client.

Why add another bandage to NQ's primitive protocol -- when you have insane skill levels which are fairly incomprehensible to even most of the rest of the engine coders?

(I mean, you spent how much time on this? A week? And there is other stuff in there too like IPv6 support no one has said anything about ... )

Then get a book deal.

"John Carmack Started Quake; Spike Finished It!"

/This update has a rather eye-popping feature set already. When I opened your download and looked I was like "WHAT?!?!?" 
Feature Request: Flood Fill Exception 
I've got a small request relating to model rendering. Quakespasm has the same code from Fitzquake which flood-fills the "background" of a skin with black. This is to remove the bright blue background of some vanilla model skins, which can show on seams.

The flood filling locates the background by assuming it starts at coordinate (0,0). Imagine one of the simplest models possible, 2 triangles forming a rectangle, with a rectangular skinmap that fills the entire skin, and the entire skin flood-filled with white. This model's skin gets turned entirely black by the feature, because the skin is no-background, all-foreground.

There are workarounds, like making sure that the pixel at (0,0) is differently coloured to her neighbours. However, this still compromises the model somewhat, because that pixel is still visible on the model, and must be black in colour in these engines.

My proposed fix is modest: if a model has a UV coordinate of (0,0) for any vertex, then don't apply the flood fill code. None of the original models the code is trying to fix have this coordinate, so it still does its job there. Any model which has a UV there clearly doesn't want flood filling to occur, because the point you want to start filling from is part of the skin, not the background. It even allows for an "opt-out" hack where an isolated vertex is added to models at that coordinate to disable the flood-fill even if the model doesn't use that pixel. 
Take 2.

decals seem fixed (sorry for not spotting it earlier). I've also replaced the particle traceline code with my optimised version to mute spam.
I added an example 'weather' particle config too, for people to experiment with.

@preach, doesn't sound too unreasonable, frankly that flood-fill stuff is just annoying. personally I'd probably just fill it only if it was that specific colour...

@baker, ipv6 is easy really, mostly just a copy+paste with the address families switched over, some different structs+field names, and a slightly different 'broadcast' mechanism where its the receiver that decides if its willing to receive broadcasts rather than the sender. simple stuff really. Besides, I'm not all that great a coder, I just know quake well.
regarding protocols, if you want FTE's full protocols, just use FTE. FTE's 'PEXT2_REPLACEMENTDELTAS' extension (catchy name that) should prevent the need for huge unreliables as well as providing a whole load of extra entity state that probably noone cares about. The client parts shouldn't be too bad, but the server parts would spawn lots of bugs, so if did port that stuff over, it would be as a separate patch.
That combined with voip.
I wouldn't know where to stop with 'minimal' csqc...

if you want qw protocols in an nq engine done the lame way, read 
This is all super badass. A possible future feature that I've thought would be mega useful would be QuakeC functions to draw textures to the HUD.

Once you can control the drawing of the HUD from QC, this really opens up a ton of stuff for modders (custom inventory displays, map name it) 
Take 2 
All the Backup spam is gone, decals works fine for me, but they seem really bright (colour wise). DP always made decals really dark, not sure why but all the decals look like they are glowing full bright.

I get spam on the console about not caching particles, but I have loaded the "effectinfo.txt" file so all of the particles should be setup. I am sure DP was doing the particle cache when the effects file was loaded, unless the message means something else.

I have updaded my world.qc with the new engine detection conditions (FTE_SV_POINTPARTICLES and FTE_PART_NAMESPACE_EFFECTINFO) and everything seems to switch over perfectly.

For some reason "traileffectnum" is missing so I don't have custom particle trails on plasma projectiles. Is it possible to check for this being missing? So I can fall back to the QS particle trails system instead. I know there is "trailparticles" but that is useless for traveling projectiles because you have to keep drawing the trail start and end positions all the time in QC. 

I wish this feature was available 20 years ago. Setting half the bindings via configs in complex mods was so clumsy. 
QS-Spike Particles 
@Spike, I am getting some strange particle emitters under the world geo and I am not sure why.

The size of the decals seems wrong, DP vs QS-Spike blood decals feels like a paintball game.

The size of particles in general seems to be larger with DP vs QS-Spike being very different. I tweaked all the DP effects to be a certain size and now everything feels too large. 
My Gawd 
particle system that can be used by mappers to emit custom particles from surfaces based upon their texture names, like rain, snow, sparks, etc. I should give a proper example of this.

Spike this is incredible stuff man, thank you for your efforts! I would love to see an example :O 
QS-Spike Particle Scale 
@Spike, the engine scaling of particles seems to be affecting everything. Here is an example of the floor circle effect to show the difference of the scaling between DP and QS-Spike engines. 
@kinn, you mean csqc? :P
rmqe has some simple csqc support that could possibly be used for huds or menus, but I don't think anyone really tried it.
if you want ssqc, then fte has 'tei_showlmp2' which allows adding/removing various persistent stuff relative to various parts of the screen. even dp has an svc_showlmp feature that nehahra used, but its only relative to the top-left of the screen. either form is really annoying to use.

@dwere, fte has had that for a long time. :P
kinda needs various cvar settings too though.

@Bloughsburgh, there's a weather example in the r2 zip. put the cfg in the right dir, use some console command or add a worldspawn key, restart the map, check the results.

@sock, precaches:
dp implicitly uses the effectinfo file to define the effect numbers, with both the client and server parsing the files themselves. this means that the excrement hits the extraction device if they differ. It also sucks big-time if you have multiple different particlesets loaded at once, or in other words DP has no user choice.
I could have QS parse that file server-side and auto-generate precaches that way, but that would mean two things: 1) the protocol is unconditionally changed even if the mod doesn't use pointparticles (the built-in effect names would need to be pre-assigned). 2) there's a whole load of redundant precaches if the mod uses the "effectinfo." prefix thing.

particle scales: clearly I don't use DP enough, I'll need to look in to that.
dlight scales: I assume rockets give off different dlight sizes in both engines too, without any extra particle system. at least I assume that's what the floor circle effect screenshot was meant to be showing.
looks like 4-fold scaling with decals, maybe 2-fold with particles.

emitters: o.O near the origin, too, but also far too regular.

traileffectnum: this is mentioned in my readme as not supported, because its actually part of the entity state rather than a simple addition via a new svc. if I add the replacement-deltas protocol extension then I'd be sure to include this then, but I want to ensure everything else works before I screw everything else over (assuming I ever do).
until then, you can make a particles/trails.cfg (loaded the same way you're loading effectinfo) that contains "r_trail progs/foobar.mdl effectinfo.tr_foobar" lines.
ideally you'd use r_effect (and using count instead of countextra and its framerate-dependancies) for static entity emitters like torches or items, but I can understand you wanting closer dp compat. 
kinn, you mean csqc?

God knows. I haven't done any quake modding since 2005 so this may as well all be new to me :) 
Snow Video Using QS-Spiked-R2 
Yeah... the snow is well done. tehspiderman1 ! :)

Thanks for Spike's stuff :) 
Xmas Jam 
Better happen 
Is sv_protocol 999 supported now too? 
QS 0.92.0 added support for 999, not me. 
My bad, I thought 0.91 was latest. Manifestation page doesn't specify.

Now I can test the rest of my test map. 
Branches Page Should Be Updated 
Fog Distance Versus Density 
Is there any option for a fog starting distance?

Also is there any option for a max fog density? Currently density is only based on a distance from the player view origin and anything at vast 999 protocol distances is put at max density. I would like to be able to set the max density to something like 0.2, have a density of 0 for like 1024 units or so, then gradually transition fog in from 1024 out to 8192.

Yeesh Qmaster whats next!?! a defined multiple fitted density curve??? 
Mark V has a "fogex command" with start and end.

fogex <fade>
fogex <start> <end>
fogex <red> <green> <blue>
fogex <fade> <red> <green> <blue>
fogex <start> <end> <red> <green> <blue>
fogex <start> <end> <red> <green> <blue>

Sock want to play with such a thing, so that's why the feature is there.

Sock toyed with it once a few years back, and I think even Sock couldn't find a compelling use for it.

So you do have an outlet to at least satisfy your curiosity. 
You can't mix distance with density in fixed pipeline fog; it's either one or the other but not both.

If GL_FOG_MODE is GL_LINEAR the start and end parameters (only) are used. Otherwise the density parameter (only) is used.

If you just implement everything in shaders you can supply your own fog equation which does this, but then of course you're raising the minimum hardware requirements.

This is similar to some of the discussions that went on during RMQ work: maximizing hardware coverage and desired features are often contradictory requirements, and you often can't have both. 
Can't Run Spiked R2 
"Application Error"

"The application was unable to start correctly (0xc000007b). Click OK to close the application."

regular Quakespasm works. What am I missing? 
People do not use Voodoo graphic cards anymore 
Found The Issue 
I have to use a 32-bit install of Quakespasm, not the 64-bit. 
Pretty irrelevant, but if you try to start 2 sessions of Quakespasm-spike.exe, you get a "Unable to bind to (already in use)

Too tired right now to satisfy my curiosity and see how/when the sockets are bounds for single player for a non-listen server.

/Total non-issue anyway, but unspiked Quakespasm doesn't do it. 
Super Important Feature 
Is there an way of enabling no filtering (i.e. crunchy pixels) on the particle textures? If not, can this be added? (Oh god please say yes) 
surely it obeys gl_texturemode, right? 
Amen To That Kinn, Pixelly Goodness! 
surely it obeys gl_texturemode, right?

it's probably a 1 line of code change to add that, so no biggie.

I have to use a 32-bit install of Quakespasm, not the 64-bit.
The only issues I've had with the 64-bit QS were conflicting dll's, IIRC you can't have 32 and 64 bit QS installed in the same directory. 
its all part of spike's evil plan to stop people from using nearest-filtering!...
that or I was just trying to get DP's effects to match, as well as fte's existing particle configs too. high-res stuff (unlike vailla quake) imho looks better with linear.
mix-n-match stuff stops it from being a 1-line change.
probably I'll add some 'nearesttexture' command for it in the particle configs.
side note: the classic particles don't respect gl_texturemode either.

and yeah, the build that I provided is a win32 build, so you'll need the 32bit dependancies.
I could provide both binaries, but for me its easier to focus on a single arch (yes, I'm that lazy).

I have fixes for sock's issues, but I got distracted by the huge deltas... and I now have to fix a load of code, and finish writing a load more. :s 
true, but you can make classic particles square using another cvar, which i think is good enough.

Good point on the high-res content, but then, I'm not sure which is the best way to mix low-res quake textures with high-res effect images, there is an inherent clash of styles there. But if someone wants to make a quakey-looking low-res raindrop, they should be able to make that nearest-filtered. 
Which cvar is that for making the standard particles square? 
r_particles 2 
Cannot Compile On Linux 
In file included from progs.h:27:0,
from quakedef.h:226,
from gl_refrag.c:24:
progdefs.h:25:23: fatal error: progdefs.q1: No such file or directory 
Cannot Compile On Linux 
The code from, that is. 
Grab the progsdef.q1 from:

To solve your immediate problem. 
Miscellaneous Behavior Difference 
type map i_dont_have_this_map

Quakespasm 0.92: Console: couldn't spawn server maps/i_dont_have_this_map.bsp
Quakespasm Spiked: Fatal error dialog: "Quake Error: SV_ModelIndex model progs/player.mdl not precached

Maybe some sort of missing model support similar to DarkPlaces and presumably FTE.

But not having the map will kick you out of Quakespasm as it is a "Quake error" that terminates Quake. 
Uh Oh 
Host_Error: Mod_LoadLeafs: 121741 leafs exceeds limit of 70000.

So..why is there this concept of a limit anyway. Why can't we just keep allocating more memory as needed and just use more RAM until we run out.

On a related note, why not just precache the entirety of the progs and sound folder at start and forget about precache warnings. Just use more RAM. 
Is the map sealed?
If it's leaking, seal it and the number of leafs should go down by half or more.

No hard limit on leafs is a thing on my wishlist.

Just precaching everything: I guess it would make loading slower, cause issues on old/slow computers, and content depending on that feature would not work in other engines. 
Precache All Could Be A Cvar 
cl_precache_progs 1
cl_precache_sound 1
cl_precache_all 1

Or maybe something like heapsize would be better:
-precache 3 (1 = folder only, 2 = sound, 3 = all)

That way there would still be compatibility with old hardware such as only 1GB ram. 
Quoth has a method to automatically precache custom sounds and models in entities in a map. AD very likely has this too.

Might tell the people in the mapping help what you are trying to do. The solution via QuakeC probably already exists. 
small note: fteqcc's new #merge feature allows 'merging' new code into an existing progs. Combined with the __wrap keyword, you can change existing functions and stuff rather than just adding.
it would be worthwhile even if it was only ever used to add something like misc_model into every mod.
The feature is still a little raw and a little wasteful, and maybe a little too permissive as well, but should otherwise work without needing to decompile anything (and without all the resulting breakages of decompiling). 

That way there would still be compatibility with old hardware such as only 1GB ram

A full Quake install is about 80 mb... 
The idea of precaching all available models is flawed anyway. Health and ammo boxes are .bsp models.

Are you going to precache all the maps in the map folder? No. And there isn't a non-hacky way to distinguish between .bsp that is an ammo box vs. one that is a an actual map.

/Although Mark V actually cracks open the .bsp models and looks for an info_player_start and if it doesn't find one, assumes it is a health box or ammo box or non-playable .bsp

All of this is skipping that to record a demo in anything resembling standard Quake, you have to have the model precaches known in advance. So then you would have to add protocol modifications too.

You would also need to add DarkPlaces missing model support for the feature to work right, because since you aren't using precaches a client has no idea of what it actually needs to play the game.

/Quoth and probably AD already have misc_model support and some sort of equivalent for sound. The right tool for the job already exists. 
I only mean progs folder and sound folder, not the maps folder.

I'm merely curious from a technical perspective why the precaches are even needed. If, let's say, a mod were to precache each and every model and sound in world.qc then no further precaches would be needed any and all info_notnull hacks would work fine as an example benefit (also modders wouldn't need to care about adding those ugly precache lines that are so easy to forget about).

So why not just precache each file in those two folders in a for loop whenever worldspawn is first called. Seems like a pretty neat feature to me.

I don't follow what you mean by demos requiring precache or even what the protocol has to do with it. If its all precached its precached. Mind you I'm only coming at it from a qc perspective. 
Because it isn't compatible with standard Quake.

And that's always been the goal with conservative engines like FitzQuake and Quakespasm.

DarkPlaces is the engine you are looking for. Doesn't DarkPlaces give you a haughty warning like "You didn't precache this, precaching anyway".

That's LordHavoc saying "You are not doing it right". 
In fact, I think it used to say "Model is not precached. Fix you mod. Precaching anyway". 
More Explanation 
Precache everything ...

DarkPlaces has client/server download of maps, models, sounds, etc.

Someone does a coop game, the client asks for a list of maps and models from the server.

The precache everything idea would cause a client to download a whole ton of stuff off a server, whether or not it was needed. 
Benefits Of The Precache System ... 
In the case of DarkPlaces, map + model + sound +etc download ...

The server load the progs. If there are no Shamblers in the map, there is no precache of the shambler model, the shambler head, the shambler sounds.

Same if there are no Vores. Etc, etc.

This allows the server to offer the bare minimum of required assets to client.

See this:

void() monster_shambler =
if (deathmatch)
precache_model ("progs/shambler.mdl");
precache_model ("progs/s_light.mdl");
precache_model ("progs/h_shams.mdl");
precache_model ("progs/bolt.mdl");

precache_sound ("shambler/sattck1.wav");
precache_sound ("shambler/sboom.wav");
precache_sound ("shambler/sdeath.wav");
precache_sound ("shambler/shurt2.wav");
precache_sound ("shambler/sidle.wav");
precache_sound ("shambler/ssight.wav");
precache_sound ("shambler/melee1.wav");
precache_sound ("shambler/melee2.wav");
precache_sound ("shambler/smack.wav");

self.solid = SOLID_SLIDEBOX;
self.movetype = MOVETYPE_STEP;
setmodel (self, "progs/shambler.mdl");

setsize (self, VEC_HULL2_MIN, VEC_HULL2_MAX); = 600;

self.th_stand = sham_stand1;
self.th_walk = sham_walk1;
self.th_run = sham_run1;
self.th_die = sham_die;
self.th_melee = sham_melee;
self.th_missile = sham_magic1;
self.th_pain = sham_pain;


If there are no Shamblers in a map --- i.e. no monster_shambler --- it doesn't get precached, the server never has to offer any of that stuff to the client --- in the case of a client offering download like DarkPlaces.

In the case of even a standard Quake client in single player, these do not need loaded into memory. 
no precaches = no name->index->name network compression = omghowmuchdatadoesthisgameneedtosend.

precaching everything = oh look you have more than 256 models that were auto-downloaded from that server you forgot about 10 years ago, so I'm just going to crash now.

that first thing is the real benefit here. if you don't bother precaching then there are issues and lag between when the signal to precache and the model change happens. the second, combined with horrendous loading times, is what prevents the server from scanning+precaching (although if you really wanted that you could always use the search_* builtins from ssqc).

Late-caching (as I'm going to refer to it here), like in DP,FTE,QS'S', is fine for the most part, but there are still some significant gotchas...
Essentually, precache updates are generally sent over the reliable channel, and reliables are 'slow' - they can only be delivered if the prior reliable was already acked. So, if you do a precache_sound("foo");sound("foo"); pair (or the precache is implicit), it is very likely that the sound event will arrive before the precache. The client will then not know what the heck the server is talking about, and the client will be forced to ignore that first call.
This is why engines still have a hissy fit about implicit late-caches. The correct way to use it is to still do it ahead of time. When a client first connects in the case of their player model+sounds for instance, before other players are likely to see their model, or need their sounds.
late-caching an mdl is generally safe, the client should start to display the model once the precache does finally arrive. however, csqc may have issues with it if it can't figure out the model names.
late-caching a bsp is probably problematic because its likely that the client won't rebuild all the lightmaps.
late-caching a sound is likely to result in sound events within a short period just getting lost. The same applies to particles if the engine isn't automatically making up some random precaches on your behalf.

The clients in question are fully within their rights to only actually load the model/sounds once they're needed (vanilla quake's flush command will actually purge mdls and wavs from memory and reload as needed, thanks to its cache mechanism to run on only 8mb ram).

So yeah, precache things properly but not wastefully. If your precaches are dynamic then be sure to leave a delay between the initial precache and when the resource is used. And if you're lazy, at least admit that by putting the 'precache' right next to your setmodel call in a way that should feel as icky to the quakec coder as the resulting behaviour is to the engine).

Otherwise yeah, what Baker said. 
Scratches Head... 
Aren't precaches done locally? If it's server-side does the server send the client a list of models used? Does it matter how long the list is?

So if Mr.Modder, thinking he will save himself the trouble of all those pesky precache warnings (Insert a "Stop all the warnings!" meme here teehee)creates a mod where all 300 custom models and all 654 sounds are precached from the progs and sound folders inside his mod's pak0 file and all these "wasteful" precaches are done in the worldspawn function at game start...what would happen? Crash? Or would it only cause problems for multiplayers joining his game and demo creation? 
The server does send the client a list of models/sounds needed to connect, there is a limit but it is fairly large. DarkPlaces shows this as a bar at the bottom of screen even in single player, Quakeworld clients do it as well.

Other stuff: try it. Start up DarkPlaces twice and have one connect to the other. See what the loading/downloading time is, keeping in mind the internet is way, way slower than LAN or same computer. 
I Don't Use Darkplaces Anymore, I Only Use This Awesome Quakespasm 
Quakespasm Review By Gunter 
I talked Gunter into doing a review of Quakespasm.

He's a very detail oriented guy who plays a coop mod online:

Quakespasm Review by Gunter 

Uses fte's replacement-deltas protocol extension by default. helm18 is actually playable for me now (the 10k knights map). The limit is now the renderer+server logic now.
Disable with eg: sv_protocol -666, but leaving it enabled won't hurt existing 666 clients.

Don't expect more big changes any time soon, although I'm still open to bugfixes for the things I broke in the hope that this gets stuff finds its way into the official quakespasm.

Why do I constantly feel like there's something I've forgotten to do?.. Feel free to remind me so I can get annoyed about it anew.
Ooo, maybe its multiple things! 
Minor questions for you whenever you have the time ...

I've tried seed at least fundamental information and examples including looking through engine code some ...

1. Is there a way to specify a particle effect should generate even if the particle would not be in view?

I know in the hands of someone who doesn't understand the mechanics this would be undesirable, but unlike deathmatch (Quakeworld uses of a particle system) where particle effects are primarily used for weapons blasts the uses in single player would be more for persistent weather.

If every time you look at the window, it has to restart the rain from nothing that is undesirable.

2. Is there is a method to see what the current particle count is?

So a mapper can measure the effect burden and make sure the author isn't creating situations where the particle count continually increases because the rate of creation exceeds the rate of destruction (die time, etc.)

3. What "attribute" would kill a particle if it hits a liquid?

4. It looks like models emitting effects is disabled in the particle system (like ability for a pent to emit stardust or what not --- I've seen this effect in DarkPlaces)? I could see that be used to make broken panels that emit sparks in a base map, for instance.

Was there a certain reason that you felt that was undesirable in an engine like Quakespasm or would it have introduced a code burden?

5. What method controls the particles count cap? How do you set that limit?


Very awesome feature set Spike! 
1. surface emittence is based on the distance from the view rather than frustum. so keep emitters away from teleporters and use short-lived particles you should be fine. snow will always be problematic in that regard.

2. r_partinfo

3. you can only do it on initial spawn. overwater or notoverwater will filter that effect. use the +foo stuff if you want the particle system to spawn one sort above water and one underwater.

4. using countextra/countabsolute for static effects on trails or emitters is evil and framerate dependant. that makes it undesirable. use r_effect if you want something to emit particles constantly. use r_trail if you want it to emit particles as it moves.
the previous build lacked any protocol extensions for entity fields. the replacement deltas stuff fixes that in r3, so you can resume using flawed stuff for compat with dp.

5. r_part_maxparticles or r_part_maxdecals. Changes to these cvars should take effect on map changes. 
Random stuff:

1. The delta compression should be a big help for coop.
2. Looks like you added makestatic so someone could, for example, make deadbodies from monsters into static entities.

(Is there a way in QuakeC to know if a monster's dead body is in on a lift (i.e. died on a brush entity, not worldmodel)? Specifically to not makestatic those particular dead bodies?)

3. In a previous reply to ericw, you had talked about implementing a mechanism to send multiple packets in the event they exceed 1542 +/- bytes for coop --- is that implemented? I can't tell from the readme if that was implemented.

4. DP_QC_GETSURFACE, so broken vanilla skies stop being broken -- raises this question --- what is a broken vanilla sky?

5. SOLID_CORPSE. Memory block, even reading the DarkPlaces description of SOLID_CORPSE, I can't recall the main use of the feature -- even though I remember it is useful.

6. Sprite groups. spritegroups will now animate properly - this was a vanilla glquake bug Are you aware of an existing mod that used sprite groups? Hipnotic? Rogue? 
(No one will care except Spike but I meant to type 1442, not 1542) 
View Dependant Particles 
Could particles be cached in their current state (i.e. paused/frozen), when out of view and then resumed when in view? 
2. makestatic was a vanilla thing. I've not touched it. I probably should do for extra fields, but that would mean that I'd have to actually add support for that.
either way, if the corpse isn't moving then the protocol changes mean that it'll only be retransmitted when it first appears/disappears, there's actually little need for makestatic now.

use tracebox to see if its sitting on a lift or something. or failing that a traceline. or just check thecorpse.groundentity

3. that's in this build, it probably ought to stick to a single packet due to burst, but I didn't include any prioritisation for players and skipping the player every other packet would make it a bit too jerky without better lerping, so it just spams.

4. those solid skys that give particle effects when shot, that affects some percentage of the vanilla maps.

5. so one tracelines and projectiles will hit corpses and yet monsters and players will just walk through them.

6. dpmod is one such mod. go on, get it to run in markv or something. 
"Why do I constantly feel like there's something I've forgotten to do?"

Everyone forgets to add support for 4 players and splitscreen... (FTE doesn't count cause I cant get it to work properly) 
I asked Gunter if he'd be willing to give your Spikespasm a test drive as a replacement for ProQuake server on his coop mod server

I explained the benefits like the automatic server browser.

Something that immediately occurred to me, though ...

1) Quakespasm can't actually serve a protocol 15 game (i.e. standard Quake). The sign-on packet wrongly busts the standard Quake limit, causing the client to immediately disconnect.

2) Gunter asked if it would have ProQuake rcon. I said I'd bring that up.

/I could probably easily obtain more server operator volunteers, but Gunter has run a server for a while and he's already getting familiar with Quakespasm. ;-) 
I didn't make it clear: He said he'd be willing

I explained the single port server advantage, the ipv6 support, and automatic server heartbeat advantages.

(Although Polarite is the one actually in control of the server. I haven't talked to Polarite yet.) 
RCON: What It Is ... 

* To anyone that doesn't know what RCON is, if someone has a server, the owner can connect to the server and do "rcon changelevel e1m3" from the client.

It is a way to give yourself the ability to issue console commands to the server like change the map. 
.Alpha {fence Textures Bug 
I had the idea to make low lying fog using a skip-textured 32 unit high brush whose top surface was textured with a circular fuzzy edged {fogtexture (using pink transparency index), setting this brush to be func_illusionary, and topping it off with a .alpha value of like 0.2 or 0.3 for subtlety.

This looks somewhat passable at 0.7 even, however there is a bug. I can't set .alpha lower than 0.67 or else it doesn't draw the face at all.

@FifthElephant, as much as I enjoy encouraging people to use fte, this probably isn't the right topic. poke me on irc or give a proper bug report in the afterquake topic or something.

@Baker, it'd be good to get it to use vanilla-compatible packet sizes, at least where practical. The signon buffer size can trivially be reduced to 8000 now thanks to baselines being splurged over multiple packets too, but iirc there's issues when recording demos mid-map due to clientside assumptions someone made, and I'm too lazy to re-splurge the data back out there too (so I just left it using large signons despite it being trivial to split it, to try to sidestep the issue), either way I suspect its not just quakespasm that would have an issue with that.
iirc, vanilla needs 1024-byte unreliables too, which is more of an issue without proper deltas, though I suppose if you're trying to use vanilla protocols then you get what you deserve. Obviously none of these limitations need apply to qs[s] clients connecting to the same server... Can we not just get everyone to upgrade?.. :P
The master thing is kinda irrelevant as not many clients will bother to check it at this time anyway, so he'll still need to manually get it added to whatever server listings proquake etc currently use.

@Qmaster, the engine sets up the alphatest value once and then forgets about it:
glAlphaFunc(GL_GREATER, 0.666);
that line needs to scale by the entity's alpha value in each place where its actually needed, which is probably quite a few places. 
>Can we not just get everyone to upgrade?.. :P

Protocol 15 is what DarkPlaces, Qrack, Super 8 and everything else can speak. And your single port server means that no client --- not even GLQuake will have NAT issues.

It was my thought to get the server real live tested, since few people (or even anywhere) here seem to coop even on a LAN.

And then after that works, push for a "Spikespasm coop server" that exclusively uses the new client.

/That was my line of thinking. 
(Anyway, I wasn't trying to get you to do anything of substance. I made Mark V support protocol 15 with just a couple of tweaks, I wasn't aware that getting "Spikespasm" to support protocol 15 would be difficult.) 
Wish There Was Edit But There Isn't 
( When I made Mark V support protocol 15 -- which FitzQuake 0.85 never quite did --- I just kept track of the protocol upon map start and set a global. I adjusted the signon buffer and then the packet size.
Particle Issue 
haze.cfg --- assigned the te_quad_sparkfan effect to progs/quaddama.mdl

Loaded dm3

When I pull up the console. The effect spams continually. Obvious the "die" time cannot happen when the console is up. But new particles shouldn't spawn.

Oddly this does not seem to happen with rain/snow. So far only te_quad_sparkfan seems to have this problem. 
Baker, protocol 15 might be the only commonality between all engines, but if you ignore vanilla, all the other engines have boosted what their engines are willing to receive to at least ethernet's limits.
requiring everyone to upgrade basically includes to every single notable engine with the exceptions of vanilla and proquake. One of which you(baker) can fix with a new revision.
The alternative is to cripple dp,qrack,fitzquake,markv,etc clients that give no way to identify what they support.
These clients would also need to be limited to 600 entities too, etc.
Its not that its a big change, its more that its really limiting. 
I think what've you done here is incredible as is.

Spike: you(baker) can fix with a new revision.

Heheheheh. Should the day ever come when I have time, hehe ;) Probably won't be within the next 12 months.

No one expected to get particles because you seemed down on it. The stuff on top of the particles was unexpected and a bonus.

The particle stuff by itself is quite the enhancement and I hope it gets put to good use by Sock and possibly others. 
if I'm not critical of something, I can't easily spot the flaws in it.
At the end of the day, if someone does something stupid with the particle system then that's their own damn fault, and not something that should hold back eg Sock.

Regarding protocol 15, if clients can tell the server that its not crippleware, then its only the crippleware engines that will suffer from being crippleware.
I made some tweaks, and r4 will (bug-willing) do protocol 15 properly. I even made it reduce the number of usable sounds/models if the serverinfo packet is too big, which seemed to get AD going with a proquake client, although it did feel a little empty with half the entities missing (like I said, limiting)...
I guess I also ought to do something about makestatic too now though. Stupid cans of worms... :(
Also got the server part of proquake-compatible-rcon working, although I wouldn't personally recommend using it because the password is still sent as plain text, which sucks.
Also found a nice reliable way to crash proquake servers. Hurrah.

yay polish?.. 

I don't understand your objection to the FitzQuake "game travail" or "game warp -quoth"

Is it because it doesn't use gamedir like Quakeworld and DarkPlaces and JoeQuake? I used to dislike the slightly different naming, but I've gone from disliking it to prefering it because I type it in the console a lot for single player.

Is your dislike just because the name? Or is there something else I'm not seeing?

/Slightly surprised you decided to do the protocol 15 thing, I did look through all the mega-tons of changes you did and I can see your POV. rcon on the other hand is barely a cut and paste, relatively speaking ... even easy stuff is slight PITA. 
until some rcon command crashes the server and fails to even tell the (rcon) user what happened. Blind copy+paste is never a good idea.
no feedback on errors = bad
plain text passwords = bad
client only supporting one rcon command at a time even when its just a single packet = bad
modifying the system-specific code for something common to all = bad
willingness to exceed proquake's own mtu resulting in 'bad read' errors instead of results = bad
not giving any feedback at all when the server is a listen server = bad
copy+paste = bad. :)

I dislike 'game' because it differs from the command name that id themselves used with quakeworld. that said, quake2 used 'game' so I can't really justify that much further (although q2 used a cvar, which has its own set of issues, which an engine that also supports q2 needs to be able to deal with).
What I really *really* hate about it is the '-quoth' part, which limits it to only a few base-mods that are hardcoded into the engine. This also affects the choice of hud, and even the network protocol. Each of those 3 things are unacceptable to me.
So yeah, I feel justified in disliking it, even if I ignore that qw+fte even existed.
The deltas stuff deals with the protocol change. The hud lumps can be auto-detected. The hardcoded list of 'permitted' mission-packs is just plain stupid. Oh, and quakespasm doesn't support more than those 2(+id1) either.
But yes, I should do something about the server announcing the correct gamedir to use, but probably I'll just leave that until someone else wants to actually fix up the 'game' mess and add auto-downloads and deal with the versioning fallout resulting from that. 
Mulitiple Gamedir Support Is 5 Alarm Nightmare Anyway 

Someone is using DarkPlaces as a listen server.
They decide to coop.
They use multi-game dir for replacement content.

(1) So does the client need to download all of that person's replacement content when connecting?
(2) Make sure content are the right models with CRC check etc? How do you do that when the loaded model is a replacement model?
(3) Download doesn't download the replacement textures that the replacement content needs to look right.

Multiple gamedir support is mostly a mechanism for using replacement content.

Within that context --- the support for a small set of mods (rogue, hipnotic, quoth, possibly -ad in the future) is not much of a problem.

And is probably a major benefit. I don't know how many single player users require the Quake Injector to play a custom map, but its probably no small number.

When I first wanted to try custom single player, I was not used to the installation instructions or using -game in the command line. Figuring out where things go and the startup procedure is a big challenge to most people.

Shorter version: I think a finite list of double gamedir like "game -quoth" is fine, Preach knows what's he's doing, Sock knows what he's doing ... other than Preach and Sock and some of the power mappers that really know their stuff (czg, necros, tronyn, etc.) --- there aren't a lot of people that are going to be making an expansion pack level add-on for immersive content.

When DarkPlaces added double-gamedir support, the thought wasn't of "hey, make sure feature is properly architected and well designed" but rather for modder convenience. 
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 o