There is one important difference between software and GL: http://imgur.com/a/DhAgo 

That's the first show that shows the difference pretty clearly. Winquake seems much sharper and harder due to the way the palette has to cope with gradients. 

also....models have minlight in software? 

IIRC models are minlighted to 5 in order to avoid a check for division-by-zero in an inner loop.

The MDL lighting is almost completely different in software in general; it just doesn't use the same calculations as GL did, although I don't recall specifics. 

Yeah, in software, mdl's have minlight. From this comment, it sounds like the reason for doing that was an optimization:

#define LIGHT_MIN 5 // lowest light value we'll allow, to avoid the
// need for inner-loop light clamping

I'm not sure if this is the only difference. The code for determining the light level of each mdl vertex in software quake is structured a bit differently than glquake. These are the relevant parts of sw:

https://github.com/id-Software/Quake/blob/master/WinQuake/r_main.c#L563
https://github.com/id-Software/Quake/blob/master/WinQuake/r_alias.c#L617
https://github.com/id-Software/Quake/blob/master/WinQuake/r_alias.c#L433

And glquake:
https://github.com/id-Software/Quake/blob/master/WinQuake/gl_rmain.c#L476 

QuakeForge uses shader magic to simulate the look of the software renderer...

Hmmm - we're not really about geewhizz effects.

I do love these effect sort of things ... but the code belongs in separate patches and/or forked projects. 

unless.. are you talking about the banding from lighting? why would you want that, it looks shit. 

I can see where this conversation is going.

I'll just leave it at that, and say that yes, quite a few people do actually like quake's original 8-bit aesthetic, and have done for some time. 

I like the 8bit feel. It's difficult strokes for different folks. :) 

if anyone wants to test a dev build, there's one here with some neat features:
http://quakespasm.ericwa.com/job/quakespasm-sdl2/146/artifact/quakespasm-r1164.zip

@Bloodbat: this has a new gamma implementation that should fix your gamma issues
@LeopolD: I didn't get around to adding vid_borderless, but did add something: set vid_desktopfullscreen to 1 to make fullscreen mode use sdl2's new "fullscreen deskop" mode.

Other stuff:
-it has the glsl-accelerated mdl renderer. Szo reported an issue where some models are rendering black on his AMD card, still working on finding that bug.
-"game" command tab-completion
-demo pause support 

I found the cause of my missing runes: if I die and click the mouse to respawn (and presumably load the last save)...the runes are gone, this behavior doesn't seem happen when loading from the menu or using F9 to quickload. Hope this helps fix it. 

I reproduced it this way:
"map e1m7", grab the rune, then "changelevel e1m1". save. get killed. click to respawn, you will still have the rune.
Restart the engine. Load the save, you will still have the rune. Get killed, click to respawn: this time the rune is gone.

I think this is the same bug mh was talking about, pretty sure there's a fix on inside3d, so I'll have a look at integrating that. 

Almost certainly it's the same bug.

I've personally only observed it with the "kill" command (and have a hacky workaround for it there) but that doesn't mean that it doesn't occur elsewhere or have a different source. 

svn'd up, working fine here on my OpenBSD box, and gamma works, thx! 

Have you lads had a taste of HRTF? Aka binaural audio. In case you're unaware, it's a form of surround sound which can be played through any standard ear/headphones and soundcard. It's available in zdoom/gzdoom, where it's rather amazing to hear. There is a version available in the form of openal soft. Any chance of integrating that into quakespasm? 

I will have to try that in gzdoom. yquake2 also has an openal backend: https://github.com/yquake2/yquake2

Can't promise it will happen; the Quake sound code is a pain to work with so it might be a fairly substantial project. Also, I've found it's important to mix all the sfx at 11025Hz, otherwise you lose the "classic" sound (the Quake sfx clip a lot when mixed, but it sounds ok if the clipping is at 11025Hz). But it could be an optional backend of course. 

above was me.

re: the runes bug, I looked in to it, and the background is, there are two pieces of information about each rune: 1. does the player have it, 2. has the player beaten a level while holding it. #2 determines whether you get to keep the rune after dying. The problem is the savegame format doesn't keep both of those pieces of information, I think it only saves and restores #1. IMO it's best to just live with it as an "old gameplay bug". 

While you are still thinking about, can you describe in more detail the specifics?

The documentation of this problem is essentially non-existent and I know I'd like to "once and for all" at least know what is going on.

[And opens the opportunity for someone other than yourself to maybe even solve it.] 

I had a soundcard that did that way back. Gave me a huge advantage in multiplayer games because I could easily tell when sounds were behind me vs in front.

As far as I know, it was a hardware thing, don't know what software has to do to support it. 

The two variables are:
pr_global_struct->serverflags stores whether you are currently holding the runes.
svs.serverflags stores the "permanent" state of each rune: whether you completed a level holding the rune, so you would get to keep it after dying.

So when you grab the rune in e1m7, pr_global_struct->serverflags has a bit set to 1, while in svs.serverflags it's 0, so if you die in that level, you lose the rune and have to grab it again.

When you beat the level, Host_Changelevel_f calls SV_SaveSpawnparms, which copies the rune status into svs.serverflags making it permanent. If you die in another level, you spawn with the rune again. (In SV_SpawnServer, there is
pr_global_struct->serverflags = svs.serverflags which means you currently have the rune if you previously had it permanently.)

The issue is, saving only saves pr_global_struct->serverflags (via ED_WriteGlobals), and loading only restores pr_global_struct->serverflags. If you don't quit the engine, svs.serverflags will stay however it was, but if you quit it gets reset to 0. So the info on whether you had a rune "permanently" is not kept in the savegames.

mankrip on i3d also investigated it and I agree with his take on it:
http://forums.inside3d.com/viewtopic.php?f=3&t=4875&p=44571&hilit=runes#p44558

He points out that if you try to work around this using methods like "copy pr_global_struct->serverflags into svs.serverflags when loading a savegame", it creates this bug: grab the rune in e1m7, save/load, die in the lava -> you should lose the rune, but you don't. 

Runes are stored in the QC in the "serverflags" global, which corresponds to pr_global_struct->serverflags in the C code. That's the "does the player have it" part.

They're also stored in svs.serverflags which is the "has the player beaten a level while holding it" part.

svs.serverflags is 0 when the engine starts and is only ever set to any other value during a "changelevel" (see below).

When issuing a "map" command svs.serverflags is set to 0, then SV_SpawnServer runs.

When issuing a "changelevel" command SV_SaveSpawnparms runs which first copies pr_global_struct->serverflags to svs.serverflags, then SV_SpawnServer runs.

During SV_SpawnServer the progs are loaded which sets all QC globals to their defaults, then copies svs.serverflags to pr_global_struct->serverflags so that it's updated from whichever value was stored - either 0 ("map") or it's previous value ("changelevel").

The savegame format only stores pr_global_struct->serverflags, not svs.serverflags.

So the value of svs.serverflags needs to be valid in order for runes to be properly restored.

Steps to reproduce.

Grab a couple of runes (cheat if you like).
Save the game.
Exit Quake.
Restart Quake.
Load the game.
Die.

Runes are gone; it doesn't matter if you die by the "kill" command, by jumping in lava or by getting too close to a Shambler.

Cause

svs.serverflags has lost it's stored value during the exit Quake/restart Quake cycle, so when SV_SpawnServer runs after you die, it restores them to 0.

Fix

In Host_Loadgame_f, after restoring all of the values of "svs.clients->spawn_parms" and before calling CL_EstablishConnection, add a "svs.serverflags = pr_global_struct->serverflags;" line.

I think that should do it. 

Now that I've read ericw's post, yup, that's a problem... 

nice two-person reply, mh wins for better formatting.

The only good thing about the original bug is, if you save, quit, load, and manage to beat the level without dying, svs.serverflags will get updated and everything will be fine after that. 

Just done some more testing, and I think that the bug where you still have the rune is the lesser of the two.

It only affects maps which have runes so it doesn't falsely give you runes you shouldn't.

The rune can still be picked up.

And losing them when you die gets fixed.

So it's a toss-up between having a rune which you're going to get later in the map anyway (and which doesn't otherwise affect gameplay) versus losing all runes to date.

The only thing I can think of against it is maps which use runes as keys as well as for cross-level info, which doesn't affect ID1. 

I guess the 'ideal' solution is to reload the saved game instead of restarting.
might need to cache the save in case someone overwrites it though.
possibly more useful in other situations too.

as mh suggested, I'd just go with giving the player a freebe rune, it won't break anything or confer any advantage, it'll just look a little buggy on the hud. you need to grab the rune to open barriers infront of the exit on each map anyway.
if you want to hack some kind of (hud) fix, you could just scan for an item_sigil entity and clear out any serverflags that match the spawnflags. thanks to the qc clearing out the rune's classname, this should work even if you save after grabbing the rune.

or you can change the saved game format (possibly just add some //comment at the end of the file, ala dp).