Yeah, it was a clean install, straight outta the box. New directory and everything. No old cfg files, lifted it all off my quake CDrom from '96. It's probably the r_shadows cvar. 

There should be a qconsole.log file in your Quake folder after you start Mark V.

Can you paste the text of that? 

That Microsoft crash report, could you post the text of that as well. Often the crash report text can indicate where something crashed.

What version of Windows are you using?

And I assume you are using current version of Mark V? 

Dutch, if you happen to be testing in the Start map, make sure to set r_mirroralpha 1 to disable mirrors. Mirrors are enabled by default (really shouldn't be). They are bad for my FPS.

I don't think any other FPS killing settings are defaulted on. r_oldwater 0 is another one that harms my FPS, but that isn't set by default. Assuming the secret hidden cfg file isn't retaining any non-default settings when you do c clean install....

You couldn't possibly be using a slower/older computer than I am (XP Netbook!).... I get between 40-75 FPS on the Start map, depending on what the lava balls are doing, as long as I don't have too many extra features enabled.

Hm, and if you happen to be running in a window, and you have some other program on screen that is drawing stuff, that could cause a problem too. I have a program called BitMeter, and it will destroy my FPS if I have it showing while running DX Mark V in a window.... 

I'll see about the crash report later today, because I'm currently using my phone. I remember it was referencing 3 files located in Appdata/Local/Temp.

My OS is Windows 7 (32-bit) and yes, I'm using the current version of Mark V, or at least that's what I think.
I've downloaded it here: http://quakeone.com/markv/ 

Slight correction: Windows 7 SP1.

I copied the 3 files in another folder:

https://i.imgur.com/33g4ZtZ.png

WERD147.tmp.WERInternalMetadata.xml
WERECF3.tmp.appcompat.txt

Should I send the .mdmp file? I'm a noob at debugging. 

I am on Windows 7, although not 32-bit.

The quake\id1\qconsole.log would be helpful. It is the log file Mark V writes out. 

Here are its contents:

Command line: [ ]
Log file: C:/Games/Quake/id1/qconsole.log
Sat Sep 09 18:17:08 2017
Mark V Windows (Build: 1036)
Exe: mark_v.exe (1327 kb)
Exe: 22:32:27 Jan 19 2017
Caches: C:/Users/kliker/AppData/Roaming/Mark V/caches
UDP4 Initialized: INADDR_ANY, 192.168.x.xxx
IPv6 Initialized: [fe80:0:0:0:a59f:53f6:4528:9fe7%41]
Exe: 22:32:00 Jan 19 2017
256.0 megabyte heap 

1) Do the WinQuake or Direct3D versions run?
2) Is there an opengl32.dll in your Quake folder?

I know Quakespasm runs on your machine, so it shouldn't be an Open GL issue although Mark V uses some Open GL capabilities that Quakespasm doesn't.

If there is an opengl32.dll in your Quake folder, you should delete that. But since DarkPlaces seems to run for you, I can't see how you could have a (toxic) opengl32.dll in your Quake folder. 

Baker, compile a debug build for him, keep hold of the exact pdb file that msvc generates when compiling said debug build.
Send him the debug exe, get him to send you the resulting .mdmp file.
Open the mdmp in msvc.
Then you can see the stack etc, and inspect many of the variables that might be relevant etc.

That or rip the stack trace code out of FTE's win32 port. That would allow him to simply paste you a whole list of function names which is usually enough to figure out where it crashed (although not always what actually went wrong).
This of course requires no pdb files, so hurrah for that, but it won't show line numbers etc.
Still, if you expect your code is going to crash then its quite handy... 

Ywah, the strangeness/uniqueness of Admer's problem is has been making me think about improved crash data.

Can't do anything tonight, but I'll ask you questions tomorrow or Monday about what you are referring to in FTE. 

1) Yes, but they crash the same way.
However, the WinQuake and DirectX versions don't give any crash reports. That only happens with the original Mark V .exe. :P

2) I'm sure there is, I'll still check to make sure.

Mentioning OpenGL reminded me of something:

My GPU only supports up to OpenGL 2.0. This gave me lots of compatibility issues with programs that require OpenGL 2.1. 

Correction:
1) No, they crash almost the same way.
(I misread what you wrote up there, sorry) 

If WinQuake or Direct3D are crashing, your OpenGL drivers aren't involved in this. Neither use Open GL. WinQuake doesn't use anything at all ;-)

So it is something else.

I never actually suspected a drivers problem, mostly wanted to rule it out. It but seems unlikely.

I have couple of suspects.

I imagine in the next 72 hours or less, I'll make a special build with some of Spike's inventiveness, and then exactly what is going will be clear.

Thanks for the feedback ;-) 

Well, I was wrong. There was no such file as opengl32.dll in my Quake folder. :P 

Been looking for an update of WinQuake and so happy to see you giving it some love, Baker! The original software renderer is still very charming. I love that washed out shading, you can't replicate it in Quakespasm.

Tried loading Arcane Dimensions with this and was surprised to find out that it mostly works. The engine even auto converts the full color skyboxes to 8 bit! However some textures with alpha channel are broken, the fog in ad_necrokeep looks especially bad, and ad_swampy crashes when you get to the main area. Anyway, what I'm getting to is, any chance your version of WinQuake could be fully compatible with Arcane Dimensions? AD is probably the best benchmark for the modern map packs, so it'd be a good milestone to achieve, I think. 

I am sure Baker will eventually provide builds for *all* MkV builds that fully work with latest AD additions. Maybe even Ter Shibboleth. These days, mappers are doing everything to push Quake map specifications beyond any previously known limits. I hope that eventually we'll have a solution which won't require updating ports over and over again to make maps work. 

Fog in custom Quake maps is usually too subtle, to disguise the fact that it's not volumetric.

Custom Quake maps can "fake" volumetric fog by making some areas small enough for the fog to not show up, and making other areas large enough for the fog to cover them. Combining this with strong shadows in the small areas and very subtle shadows in the large areas makes the global fog seem to have different densities in each area.

The thing is, subtle color translations are very difficult to pull off in 8-bit color palettes. Large areas of the screen ends up being rounded to similar color values, resulting in huge color banding if not dithered, or heavy graining if dithered. This gets even worse when the raw color of the fog doesn't exist in the Quake palette.

Making fog look good in 8-bit color renderers requires design restrictions that the mappers won't adhere to. Just like transparencies usually looks awful in 8-bit color, fog and colored lighting will usually look awful too.

A fun thing is that the same principles applies to regular lighting. Vanilla Quake maps features mostly strong shadows, because subtle shading has lots of banding in the software renderer. But newer Quake maps usually disregards this limitation, because they're usually only designed for hardware renderers. Most of the awfully looking maps from the 90's usually failed to understand this limitation too. 

Another reason for the subtle fog in custom Quake maps is to disguise the fact it's not spherical. Thick flat fog looks bad when turning the camera. 

I've done some more testing in Mark V WinQuake and turns out the water/teleporter transparency (r_wateralpha) actually works, via dithering. I suppose the same effect could be applied to the fake fog layer in ad_necrokeep. It just seems like the engine has no support for alpha channel in textures, e.g. various trees and vines in AD and Jam 8 are broken, with solid white where they should be transparent. 

Put these guys in the maps folder and you'll have transparent water on the stock id1 maps

External .vis files for original Quake maps

They should work in DarkPlaces as well.

The original Quake maps don't treat water as transparent.

Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).

It actually works for .mdl models, but few maps use that although it might be visible in Arcane Dimensions in some cases. 

Alpha masked/alpha transparency doesn't work in the WinQuake version for brush models at this time (tried it maybe 4 different times, something I'm not understanding about the WinQuake depth buffer or draw process prevents me from getting the job done in this case.).

The BSP renderer sorts depth by edge at the spans level, rather than at the pixel level. To avoid this, I've tried partially reinitializing the BSP renderer upon rendering each alphamasked BSP surface, but this resulted in massive slowdowns. Now I only reinitialize it once for each BSP entity containing alphamasked surfaces. Qbism did something similar in Super8, IIRC.

Quake's spans-related code needs a lot of work. It's non-intuitive and has bugs such as this.

I don't fully understand it yet either, but I'm sure the reinitialization overhead can be eliminated almost completely. I should only manage to do so after fully rewriting it, though. 

Thanks for the link. Looks like a good read.

I had determined that some sort of reset was required, but either I did it in the wrong place or performed it incorrectly. Or the third possibility of something I am not considering and wasn't on my radar.

Some day in the future I'll make another attempt. Last time I almost got "serious" (I was piece by piece reimplementing qbism super8 in WinQuake until I isolated what I didn't understand), but then something more shiny to me pulled me away (probably something Spike did in Spiked Quakespasm like single port server).

Network code to me > everything else ;-) 

One more thing, does WinQuake Mark V support any kind of HUD scaling? Integers like 2x, 3x etc would look quite good even in software rendering I'd wager. The usual scr_*scale commands don't seem to work. 

In the video menu, stretch is as close as it comes, emulating 320x240 or 640x480 as best it can depending on your current display mode.

It isn't exactly the same thing as scaling the HUD, and for most people it is probably "good enough" -- although as a purist I don't feel it is good enough.

But since it would be quite time consuming and effort to implementing true scaling (aka FitzQuake) in the software rendering with the appropriate alpha masking support, such a thought sits somewhere closer towards to the back of list rather than the front.

Keep in mind a trule scaling solution needs to handle all 2D graphics like the menu, scoreboard, etc. otherwise it would be quite silly.