Oh ok, so the lighting being restricted to the palette? Fair enough. 

I would really like to see before and after shots on that. 

(because I have no idea what kinn is looking at) 

i think that would be great, I really like the look of software quake... it just seems more surreal and gritty. 

Random saw this https://gaming.stackexchange.com/questions/164991/quake-1-under-linux-using-quakespasm-0-85-9-couldnt-find-a-cdrip-for-track-an

The QuakeSpasm developer said that I'd need a full version of Quake for the music to work.

Bacause of the shareware is limited to only what is inside pak0.pak file - music resides outside it so the engine ignores it.

I am 99.9% sure that the Quake shareware came with the CD audio, can check if you want me to. You could unlock the full version with just the shareware disc so the CD audio had to be on the disc.

So there is no reason to block CD audio if someone does not have pak1.pak. 

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.