Succubus crash still happens, though not right after the first resurrection any more. Can take 2-3 now before you are going back to desktop.

I also still see quite some error messages, e.g.
302 models exceeds standard limit of 256
291 sounds exceeds standard limit of 256
111 lightmaps exceeds standard limit of 64
605 edicts exceeds standard limit of 600

Not sure if these still have any meaning, though. I play with -heapsize 524288 parameter. 

Demo and autosave please. Please, please. 

Here we go again:
ne_ruins autodemo/savegames (335 KB)

You can ignore the manual save(s). The quicksave will bring you straight to the situation with the succubus and the knights as seen in the short autodemo. God mode is activated.

Regarding the text length issue:
Actually, MP2 is also affected (e.g. at the end of episode 1). Maybe either use a second screen if texts are too long or simply make the game show all the text in any situation. I doubt that anybody still players in 320x200 these days, anyway. 

I've tried 15 ways to get it to crash, had tons of monsters resurrected, played your save game, watched your demo.

Also played ne_ruins for who knows how long (45 minutes?) couldn't get it to crash.

Does it just crash to desktop or does it say Host_Error or something? 

It's a straight crash to desktop without any error (besides the standard Windows thing "Program doesn't work any more"). Maybe it's again a hardware-specific issue (e.g. I have nvidia cards in both PCs I use).

In my autoexec.cfg, I have
gl_texturemode "gl_nearest_mipmap_linear"
r_shadows "1"
r_waterquality "32"

Here's the config.cfg from my ne_ruins folder.

I tried to more things which didn't change anything:
- Switch to fullscreen mode
- Move "ne_ruins" folder from "addons" subdir to Quake root dir (i.e. Quake/ne_ruins instead of Quake/addons/ne_ruins) and run it from there 

The good news: your config completely crashes me. 

The "exceeds standard limit" messages are warnings, not errors. I always get confused about that too. It means the engine warns you that engines without raised limits won't be able to load it or show errors. It's the "developers 1 for content creators output". 

It may be one of the settings applied through the config, then. But even with a default config file (wiping my customized one from ID1 folder and creating a new one from scratch when running ne_ruins afterwards), it doesn't fix the problem. 

@frightnight

I don't have an exact answer for why it is crashing for you. (It isn't for me, although I run out of memory without using a massive -heapsize 512000 because of your use of gl_subdivide_size which does look incredible with r_waterripple).

I think the use of several aggressive settings like gl_subdivide_size 16, a huge memory allocation, possibly mp3 music (and maybe model/sound replacements?) on the bunker-busting ne_ruins in aggregate is causing an unusual stress point somehow.

I notice you are using gl_texture_anisotropy 16.

gl_subdivide_size 16 is using ridiculous amounts of memory on ne_ruins.

Maybe you created the perfect storm and doing it with ne_ruins is piece of straw that breaks the camel's back. 

In my ID1 folder, I have the following additional PAKs:

- pak2.pak (.lit/.vis files for ID1 maps)
- pak3.pak (OriOn's fixed MDLs)
- pak4.pak (improved models by capnbubs/Lunaran)
- pak5.pak (E2M6.bsp with Romero's enhanced entrace included, .vis and .lit file)

Download the PAKs above here (11.3 MB) and put them into ID1 if you wish to try. However, since you said the config file is already enough for you to get the crashes as well, I hardly believe those files are to blame for it. 

But if you upload your id1 folder + your ne_ruins folder somewhere I'll try to see the nature of the problem. 

Ah, you just posted. I'll try your packs. 

Or nightfright could start from a clean installation himself and work step by step to find the culprit. Don't burn out, baker! 

I'm able to recreate the crash and really quickly. 

@spirit ... I'm not gonna burn out ;-)

I'm in this deep with this problem, I can get it to crash now. 

 

 

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. =)