Here you have similar project for Quake2: https://www.yamagi.org/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) 

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? 

I'm running latest SVN code on Linux. I notice that when several enemies teleport in, only one teleport effect is displayed, while the other enemies just pop in. Is this normal? 

QSS is a separate fork/experimental build and QS 0.93 doesn't include any of its features. Perhaps for the best. 

I'm running latest SVN code on Linux. I notice that when several enemies teleport in, only one teleport effect is displayed, while the other enemies just pop in. Is this normal?

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

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

Run with -particles ### where ### is some number higher than 2048 to support more particles. 

@SavageX certainly not an intentional change. Could you try 0.92.1?
https://sourceforge.net/projects/quakespasm/files/Source/quakespasm-0.92.1.tgz/download 

@mh: Thanks, that's it! Increasing the particle limit fixes this!

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

I wonder if bumping the default particle limit makes sense. Are particle emitters sorted by player distance regarding priority or is it "random" which emitters starve? 

Quake doesn't really have a concept of particle emitters as such. Particles are just moved from a free list to an active list as required, then returned to the free list when they expire, with no sorting.

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

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

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

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

By comparison, Quake II bumps MAX_PARTICLES to 4096 but IIRC even that isn't enough for stock ID1 Quake; there are some scenes in demo1 that can go over 5000. 

http://triptohell.info/moodles/qss/
I've updated the windows builds of qss to merge in the latest qs changes... And FINALLY fixed a couple of bugs in qss-r7, so quoth shouldn't bug out any more (is the theory). 

And I thought Spikedspasm was a dead end fork.

Cool. 

I HOPE NOT!

QS_Spike version is my Quake version of choice. Long live Spike! 

we need an MacOS version of QSS!!! :-) 

And FINALLY fixed a couple of bugs in qss-r7, so quoth shouldn't bug out any more (is the theory)

That's cool, but were we doing something especially weird or dodgy that provoked this? Like the ultra-high fps "bug" that keeps being reinvented, if it happened to your engine it might happen to others, and I'd like to programme defensively if so. 

sorry, I should have phrased that better. That bug was totally my fault, and it happened on more maps than just quoth's ones.

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

https://i.imgur.com/Ye09ueS.jpg

WTF?! :) Sometimes (often) last Vore teleports in the player at the end titles. I don't remember this bug in original game. 

You've probably just got faster at completing the level, and leave a vore alive more often. The teleporter at the end isn't flagged "player only" so if the vore's alive on the final ledge then it can walk towards the camera and hit the tele. 

Before I overwrite I'd like to know ;)

Thanks in advance. 

I think qss-r7 is older and lacks some fixes needed to run ad_sepulcher.
btw QSS homepage is http://triptohell.info/moodles/qss/ and there is an r8+ released recently. 

Thanks. 

I quicky tried it yesterday and AD Sepulcher seem to run as good as with the ADMod version of QSS. Unfortunately no chance at the moment for a deeper test session.
Only thing that is missing is the possibility to select the mod to play directly in game main menu. 

I haven't been able to play QS in a while. I play with a controller but it seems that movement is more twitchy than it used to be.

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

Just so you know, behaviour hasn't changed in any other game. :) 

The only default that has changed since June 2016 is L/R trigger deadzone, because the shoot/jump keys were getting stuck sometimes.

Maybe try deleting the joy_* cvars from you config.cfg's in case they got changed at some point.
Here's the manual section on the controller cvars if you need to tweak them:
http://quakespasm.sourceforge.net/Quakespasm.html#ss3.2 

Any idea why SDL 1.2 and SDL 2 treat mouse buttons differently? Between the two versions my mouses thumb buttons are 4 & 5 in SDL2, but 8 and 9 in SDL1.2.

Not a big issue, it just means another rebind, was just curious about the logic. (am using linux btw)