-/*QUAKED trigger_magicear (0 0 1) (-8 -8 -8) (8 8 8) IGNORE_SAY IGNORE_TEAMSAY IGNORE_TELL IGNORE_INVALIDTELL REPLACE_WHOLE_MESSAGE REPLACE_OUTSIDE CONTINUE NODECOLORIZE
-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 33.44.55.66, I will be using the current IP:port"

DP Master to Quake Server: "9.8.7.6 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. 

https://github.com/tpoechtrager/osxcross

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. 

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. https://www.youtube.com/watch?v=ulOeZEYqOk0

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? 

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. 

https://www.opengl.org/registry/specs/EXT/texture_filter_anisotropic.txt

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. 

https://i.sli.mg/tV6enY.png

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? 

Rolling back the driver to version 364.72, dated march, fixes the issue.