Version 0.85.9 of QuakeSpasm is released:

* fixes for several undefined behaviors in C code (gcc-4.8 support.)
* implemented Hor+ style field of view (FOV) scaling, useful for
widescreen resolutions. configured by new cvar fov_adapt: set it to 1
and your fov will be scaled automatically according to the resolution.
enabled by default.
* adjusted string buffers for PR_ValueString and friends to fix crashes
with excessively long global strings seen in some rude mods.
* toned down warning messages from PF_VarString() a bit.
* fixed fitzquake's map existence check in changelevel (used to leak
file handles which would end up in a Sys_Error() due to consuming all
free handles if many maps reside not in pak files.)
* fixes/cleanups in chat mode handling. client no longer gets stuck in
chat mode upon disconnect.
* mouse grab/key_dest fixes and key cleanups.
* the "speedkey" now acts as "slowkey" when "always run" is on.
* support for demo recording after connection to server. (thanks to
Baker for a patch)
* corner case fixes in COM_Parse() for quoted strings and support for
C-style /*..*/ comments.
* changed lightmaps to GL_RGBA instead of GL_RGB.
* better parse for opengl extensions list (from quakeforge.)
* vsync saving/loading fixes.
* fixed pointfile loading.
* multiple cleanups in gl_vidsdl.c.
* Opus music decoding support (as an optional patch only.)
* several other minor fixes/cleanups. 

So if I understand, there's still no FSAA and command-H features for the OS X version ? 

No, not yet, unfortunately. 

Then this update is useless to me...

AAARGH ! I'M GONNA KILL ONE THOUSAND OF FIENDS AND PEEL-OFF A SHAMBLER ! 

You can send QS to the background by switching to windowed mode (Alt+Enter) - it's a bit clumsy, but it works. To release the mouse, hit Esc to go to the menu.

Regarding FSAA, If you have a high resolution screen, you can just run QS at its native resolution and everything will be pretty much as smooth as if you were running with FSAA. I run QS at the native res of my 27" iMac and I don't miss FSAA at all. 

Another release, nice!
Just downloaded it, will play some later 

I did a timedemo with the Win64 bit build out of curiosity and it did about 40 fps for demo1.dem.

I wondered if this was a Win64 issue, so I did a timedemo using Win32 Quakespasm. Again 40 fps.

Thinking this might be a sound issue, I started up again with -nosound. timedemo results were the same.

I get about 180 to 200 fps doing timedemo demo1 for other FitzQuake engines. And while SDL might be a factor, I've run DarkPlaces SDL before and it runs normal speed.

Could be compiler used for Windows builds? My Mac runs Quakespasm fine +++ @ 447 fps for timedemo demo1 

That sounds like the framerate is capped somehow. 

I was rounding a bit. I had host_maxfps set to 999 and vsync off. 

I set gl_flashblend 1 and got 200 fps. 

In other engines you can make the gun visible by putting v_gunangle or r_viewmodelfov... any idea what the command is to do this for quakespasm? Right now it's hidden behind the status bar. 

i�ve no clue, running on QS either, that problem never occured... 

I recently ran make on QuakeSpasm, Yamagi Quake2 and ioq3 and they all have such painless build processes. Literally 'make'

Does anyone know how QuakeSpasms Makefile was crafted? If by tool or by hand? 

It was originally based on/inspired from tyr-quake's makefile with some additional bits from uhexen2, and then updated/improved as needed. 

I don't know what causes this but I have noticed that age-old problem of screen tearing (whilst in presence of flickering/styled lights) reappeared under the latest version, 0.85.9. When I revert back to 0.85.8, things are smooth, no more tearing.

I managed to overcome this problem while I was still using FitzQuake two years ago, through these cvars:

host_maxfps "120" (actual refresh rate is 85Hz)
vid_vsync "1"

I am still using the same cvars and the same autoexec. Triple buffering is enabled through NVIDIA control panel, while vsync is left as "application controlled". Tried different rates for host_maxfps to no avail. I am clueless. I guess the two versions handle something differently than each other. Can anyone help me out? 

tearing is most noticable around dlights on account of them changing every single frame. a 'good' engine will tweak the dlights to only update at most 20 times a second, that'll reduce the hideousness of it.
vsync should kill all occurences of actual tearing, but dlights will still be able to produce epilepsy-inducing flickering...
if changing the maxfps value between different values above 85 actually changes your ingame fps rate (don't use timedemos, go by show_fps instead) then it implies that your driver/engine is completely ignoring your vsync preference for some reason. some engines might possibly need a vid_restart for it to take effect. Or maybe its just broken.
Just force vsync on in your driver control panel. :P 

I suppose this is the place to ask, but can ipv6 support be added to QuakeSpasm?

Other than that, this is a great Quake engine. Keep up the good work! 

Download

Untested since I don't have Quake via Steam. 

I've got some problems with save games - missing runes. Is there any solution? 

FYI I tried out that installer. The system I tried it on has Steam installed at the default location, so I don't know if it finds non-default Steam installs automatically, but it works fine.

I also tried using it concurrently with the "ProQuake for Steam" and they both work (and uninstall) correctly without interfering with each other. 

One more bit of info about that:

There's a popular installer used by Steam-ers that dumps the DarkPlaces engine and libraries into the Steam folder. That has at least one DLL file that overlaps with QuakeSpasm's libraries (SDL.dll) and one with ProQuake's libraries (zlib1.dll).

I don't know if there's any mismatch in those DLLs between the different installers that would cause functional issues running any of the engines. But certainly using the QuakeSpasm or ProQuake uninstaller will remove a library that is used by DarkPlaces.

I don't know if you want to try anything cleverer to deal with that (like sticking engine+libraries in a subfolder and using -basedir to get at the data files). Maybe a warning in the README though. 

Thanks for the feedback on that and it gives me some insight on future improvement (see if the installer can be made to rollback a file overwritten). My main goal was to provide a method for the "barely computer literate" (and those people are not rare) to install Quakespasm. 

Enthusiasts like you --- yes I do know -- are the reason this game forges ahead. Credits to you and your diverse mindset. You may not think it matters -- and whether or not you think it does: it does. Sure, maybe others don't notice, but natural born winners have a spider-sense that notice others of our kind. 

Maybe Windows has something like LD_PRELOAD? Then you could just rename the DLL and load it specifically for each engine. 

I have sort of a self-deprecating arrogant sense of humor and I shouldn't be exercising that stupidity in someone's elses thread but rather limiting this bad taste humor to my own little corners.

@spirit: Windows has the "/DELAYLOAD:<blah.dll>" compile option at least with sources compiled in Visual Studio (the Quakespasm guys cross-compile on Linux so I don't know if that exists in their compiles) ... and ... unfortunately, as far as I know, the way Quakespasm and many engines are linked (the linker) the name of the .dll cannot be changed at run-time without a great deal of a code rewrite (although I think DarkPlaces goes full dynamic since it doesn't actually require any of the .dlls to run). DarkPlaces used to come with "non-standard" dlls, like the zlib1.dll wasn't the official zlib1.dll but some other one although I think that has been rectified in more recent times. Unsure about the other DLLs.