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

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. 

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):
https://sourceforge.net/p/quakespasm/code/797/ 

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. 

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.