It looks like some sort of stack corruption. It goes to draw a model, sets the pointer to a texture. And the pointer to the texture is fine.

Then at the end of the function, it isn't fine and points somewhere crazy.

I tend to use vc6 because it is fast, quick to compile and stays out of my way. I guess I'll use vs 2008 to compile the ones for distribution. 

I have tried resetting following variables to their defaults (as written below):

gl_subdivide_size "128"
gl_texture_anisotropy "1"
r_lavaalpha "1"
r_oldwater "1"
r_slimealpha "1"
r_wateralpha "1"
r_waterripple "0"
r_waterquality "8"
r_shadows "0"

Even if that frees up memory as you say, the effect would still occur, even if I start a new game (not using the savegames I posted above). 

Played it a fair bit, so here's some feedback and bug reports.

No issues so far with the text editing shortcuts, seems to work fine. Really love this and hopefully various other non-Quake id open source engines devs adopt it for their own engines.

- WinQuake at 1080p seems to be mainly ok, but I noticed one or two minor issues. First, something I noticed is that the WinQuake version starts to feel more 'choppy' and with seemingly worse input latency as you dial up the resolution, even with equal framerate. So 1920x1080 @ 72 fps feels worse than 1600x900 @ 72 which in turn feels worse than 1024x768 @ 72. This is with vid_vsync 0. Maybe this is just some quirk deep in the engine that would be hard to fix, but just thought I'd mention it.

- Also in WinQuake, is it intended behaviour for water/slime/lava to each produce identical results when their respective r_*alpha value is set to anything below 1? Ie, there is no visual difference between 0.1 and 0.9. Also, at least to me, lava tends to look a little strange with a value below 1 - http://puu.sh/htMTZ/49939b0dd4.png

- Moving on to the OpenGL version, I noticed this strange blue pixel that appears on the shotgun (circled in red) - http://puu.sh/htN8I/85a40ed076.png - which doesn't appear in other engines (apologies for png, but it shows up better with this image format).

- If gamma and contrast cvars have been adjusted and the engine crashes, it results in Windows desktop displaying as excessively bright. Tried to take a screenshot of this, but Windows always produces normal colours in the screenshot.

- Not necessarily a bug, but gamma has a much broader range of possible values than contrast. Not a problem on my monitor, but might be for some people.

- Regarding the ne_ruins crashes - are you using -zone 2048 -heapsize 192000 as instructed in the ne_ruins readme, NightFright? I was getting a crash frequently at a particular location - http://puu.sh/htOoc/47766c1234.jpg - and it always happened without setting those values. When I did set them, it happened much less frequently. Demo and save game if you want to take a look, Baker - http://www.mediafire.com/download/u1k64zqugv45d8y/ne_ruins_demo+save.zip

- You probably know, but runes weapon stripping stuff and 'pak/zip help' issues still there. 

ne_ruins crash conclusively solved. Incorrect handling of entities with alpha = 0. The End.

So that's what was up with that. 

1. WinQuake slow @ big resolutions.

WinQuake is software renderer. Big resolution = slow. Low resolution = fast. Even though 1080p "works".

However, no one makes you do 1920x1080 full screen, you could pick another full-screen resolution like 800x600 or something with less pixels and it would be faster.

2. Stipple alpha on|off doesn't recognize differences

The stipple alpha I put in WinQuake isn't fancy. It draws every other pixel if r_wateralpha < 1, so it is sort of yes or no.

3. "I noticed this strange blue pixel".

I noticed that myself months ago. If you open up id1/pak0.pak ... progs/v_shot.mdl you'll discover the background is blue!! Look a shot gun box in DarkPlaces and you'll see other fun stuff. FitzQuake engines and, say, ezQuake have a "fix the shotgun shell texture" fix in them, DarkPlaces is purist in that regard and does not correct content.

So rack that up as one of the weird things in Quake. If you do enough poking around, you'll find little weird things in Quake.

4. gamma has a much broader range of possible values than contrast.

Not sure what to say. The range is the acceptable range that Windows accepts for hardware gamma for contrast. The gamma cvar will accept all possible values for gamma that Windows will accept, but as I noted before the slider bar corresponds to the WinQuake menu.

5. If gamma and contrast cvars have been adjusted and the engine crashes, it results in Windows desktop displaying as excessively bright.

Which is why I don't like using hardware gamma.

Hardware gamma is the worst. Except for all the other ways of doing it :( Hardware gamma is free, other ways either are an FPS hit or imprecise which is why there is the vid_hardwaregamma cvar and maybe at some point I'll try to implement a sneaky tactic of shoving gamma+contrast into the textures (and hope it looks right). But that's for the future.

6. ne_ruins

As of like 20 minutes ago, the mysterious ne_ruins crash is solved once and for all --- in the next release.

I think more people have discovered ne_ruins seeing it cause Mark V grief in this thread than from any other source ;-) 

@Baker:
Sounds cool. I am curious whether this might actually even fix my issues with Shrak and Malice, as the crashes there were quite similar. Will playtest till it breaks (well, hopefully not) once you have an updated build. Great that you found something after all - admirable dedication you show there!

@THERAILMCCOY:
I experienced the same issues regarding texture seams on HUD weapons. To counter the effect, I have released OriOn's fixed weapons with edited skins over at QuakeOne.com. With these, the texture seams should disappear (my edits of the original model pack was aiming especially for that). 

I wasn't able to compile this on Linux 64-bit. Has it been ported over? 

Ah yeh, looks like the ne_ruins glitch was identified just before I posted.

With WinQuake, it's not like it's slow in terms of fps, as i said 1080p holds steady at 72 fps just fine, it just feels choppy. But yeh, not like I really expect wonders from a near 20 year old software renderer, it's frankly just nice to have a modern working one at all. =P

Regarding gamma/contrast, I was really just drawing attention to the somewhat narrow range of contrast values available, rather than anything gamma related. For example, DirectQuake allows you to go from a value of 0 (exceptionally low contrast) to a value of (I think) 7 (exceptionally high contrast), whereas Mark V seems to go from 1 (low-medium contrast) to 2 (medium-high contrast).

NightFright - thanks for the link. Installed it and had a look, and I do quite like some of the fixes in it, though some weapons seem to show up even more blue pixels than the id originals. =) 

DirectQ applied gamma by running a pixel shader over the entire screen as a post-process effect, so it wasn't bound by the range of standard hardware gamma, but of course it wasn't a free effect either. 

Tonight, I will take a closer look at some more recent addons and see how Mk V is doing there.

@THERAILMCCOY:
I have updated the OriOn model pack once more. Now all weapon skins have their blue background colors replaced by black. Maybe that will fix the issue for you once and for all. 

@saindd - there isn't a Linux port of Mark V. Quakeforge and ezQuake may have software renderers available for Linux. 

Beta 14 - Windows OpenGL | WinQuake

ne_ruins fix (entities with alpha = 0). Other minor things (fixed a demo pause oddity, clear undo buffer when exiting console, zzzzz ...) and changed compiler options slightly to improve speed slightly. 

runes weapon stripping stuff

Ironically, giving yourself a rune doesn't do anything except cause the item to show in inventory.

In QuakeC, this isn't how runes work. So whether or not it shows in the status bar is all psychological. If you use that give yourself runes and changelevel to the start map, nothing special happens because the game logic keeps track of things differently.

So I'll give removing the "give yourself a rune" command.

It does nothing of substance :( 

Actually if you impulse 11 4 times then changelevel start the entrance to Shub Niggurath's pit will be open, and the episode gates closed. A single rune does nothing. 

a single rune should block the entrance to the specific episode where that rune lives. 

That is somewhat inconvenient in this sense.

You can't actually type "impulse 11" in the console 4 times in single player.

You have to type "impulse 11", close the console so that game isn't paused and the server will take a command.

Then open the console and repeat 3 more times.

Even typing "wait" between won't help because frames still happen when the console is open so waiting for the next frame doesn't mean anything.

Who wants to open and shut the console 4 times.

Then after all of that, do a changelevel.

However, the circumstances are rare enough I'll just add a little extra text in typing the give command without parameters. Or something. 

Is that bug where runes disappear fixed in fmv? Otherwise people do need that workaround. 

Personally I find it more useful to changelevel to the last map in the episode for which a rune is missing, then do a quick god/notarget/noclip ride to the rune area, then changelevel back to start.

It seems like more effort but it works if you're playing the episodes out of order. 

I confirm that the succubus resurrection crash in ne_ruins is gone for good. I went to the problematic scene in the level again and had the succubus resurrect mobs for more than one minute without any issues. Before that, Mk V would crash after 1-3 resurrects at the very latest. Excellent job, Baker! (I'll still play the whole addon from beginning to the end to make sure it's 100% completable.)

I have already tested "Honey" last night and it's flawless. Never had any issues with it though, so didn't expect it to be any different now.

Next on my list are packs like RRP, The Horde of Zendar and some high-end maps for Quoth (e.g. Conference of the Shamblers) or Drake. Definitely on my list is a test for Shrak/Malice compatibility still. Shrak especially since its hub system caused trouble with some ports for me in the past, plus some random crashes when using rocket launcher (or facing a certain emeny, not sure what was the real problem). Latest update possibly fixed this, so we'll see. ^^ 

For runes, after some poking around I can just directly add them because the progs.dat serverflags is available in the engine

// sigil is 1, 2, 4 8 (1 = Rune 1, 2 = Rune 2, ..)
SV_ClientPrintf ("may require 'changelevel start' or equivalent for intended effect.n");
pr_global_struct->serverflags = (int)pr_global_struct->serverflags ^ sigil;

So the give rune1, give rune2, .. instead of being removed will actually give the rune (as opposed to simply make it show in the inventory). 

I haven't tested this myself yet, nor even given it much thought, but I'm going to have a go at making a PR_ExecuteProgram call to handle this and see how I get on. 

Found a new interesting reproducable bug in ne_ruins:

If you have the new double-barrelled shotgun equipped (not the regular one) and you use "previous weapon" (impulse 12), game freezes and eventually crashes to desktop. I have impulse 12 bound to MWHEELDOWN. "Next weapon" (impulse 10) doesn't do that (bound to MWHEELUP for me). 

Do: sv_fix_no_impulse12 0

That's the feature from Requiem that tries to add "impulse 12" to mods that are missing it.

Apparently, it detects ne_ruins doesn't have "impulse 12" and tries to improvise and causes a crash. 

While we are at it: There are addons which use impulse 12 already for other stuff. I am currently testing Malice, and there it is used for weapon reload. That means you cannot use previous weapon function in such mods.