Anything that uses stuffcmds cannot be saved into saved games, and will need special care for clients that record mid-game.
Saying that the fog is part of the map is just about the least hacky way to do it, and will work in all saved games or demos, so long as there's no stuffcmds.

Its for this reason that csqc was designed to avoid random writebyte etc use, depending upon entities and stats. Stats can be trivially regenerated by the server (because they're dependant upon some global or field, and mapped correctly in the worldspawn function). Ents are regenerated automatically via the same mechanism that covers pvs, which must be present anyway. The fact that 515 added tempentity hacks to dp which got popularized by xonotic is a disapointment that breaks saved games all too easily.

Yes, saved games and demos will never record the entire state, but the key thing is that they don't have to - so long as the mod abstains from stuffcmd (and similar extensions). The rest can be reproduced from the state that is preserved.
Which is how mvds and qtv work. Note that mvds allow you to switch perspective from one player to another on the fly, while qtv is capable of adding new spectators mid game, all without access to the original game state.

TLDR version: stuffcmd is evil and cannot be supported properly. Stats rock. 

stuffcmd is evil and cannot be supported properly.
What do you suggest that MOD creators use instead of stuffcmd? I know several MODs that use stuffcmd to change fog parameters for example, how else can the MOD issue console commands without the echo to the console? 

<quote>Is it possible to continue recording a demo after level change or a reload (and demo would actually play back after reload point)?</quote>

IIRC, QuakeSpasm has support for that since v0.85.7. 

at: http://quakespasm.sourceforge.net/devel/

If nothing goes wrong, I guess I'll release this as v0.85.9. 

I don't know about others, but in my view the console and status bar alpha values that QS defaults to are way too transparent. I'd prefer 0.8 and 0.9 respectively - currently it's sometimes unnecessarily harder to read on bright or busy backgrounds. I also wonder why this is forced on by the engine while other things like the slow console speed remain unchanged. 

Works fine, didn't test much just tried insta/reload demo recording. 

I also wonder why this is forced on by the engine while other things like the slow console speed remain unchanged.

Should honestly just get rid of the console sliding imo... 

(should have been in quote tags) 

Is there an option to turn ON the FSAA, on the OS X version ? This is a must have ! 

I forgot to ask about the command-H feature, on OS X. Can we put Quakespasm to background ? Another must have. 

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?