I noticed that with developer 1 active the console gets spammed with messages about sound volume -

https://www.dropbox.com/s/33s43kepni4d7cc/mark_v_0000.png?dl=0 

I'm really happy your music works now! 

Cheers. This has replaced all my other engines now. I will still be using dark places too but only to make sure dark places is compatible.

Any reason why gl_texturemode settings don't save? It resets each load unless you set it in an autoexec.cfg 

It isn't a cvar. Fitz 0.85 it was a command.

[Quakespasm made it a cvar and has it save. I don't see that as something someone generally would touch except as curiousity and if they do, they wouldn't know the default value easily to restore it.] 

I can confirm that latest snapshot fixes screenshots with transparent statusbar for me.

Something else on my wishlist for quite a while is a sound resampler - especially useful if you set sndspeed 44100. I picture something like in ZDoom with its snd_resampler variable, letting you choose between "NoInterp", "Linear", "Cubic" and "Spline" modes.
Currently, I try to compensate the most annoying upsampling side-effects with converted sounds, but as we know, that's not a very elegant solution. 

the nice thing about MarkV using DirectX to play back the music is, the sfx and music are mixed together by the OS, not by MarkV. By using the default sndspeed 11025, you'll get very high quality upsampling provided by Windows, better than "Cubic" or "Spline" I'd guess.

In stock id quake, the lightning gun crackle is one of the only 22050Hz sounds, and I think everyone's used to hearing it downsampled to 11025. the need for a good resampler only comes into play if you want mix 11025 and 22050 sounds (in a mod, say), or mix 11025 with 44100 music in-engine (quakespasm does this). 

Good start. Now 2 of 3 known issues that I don't or can't experience are gone.

If someone with a 1080p monitor can see how the WinQuake version reacts to setting a screen resolution like 1920 x 1080.

I have another update with maxedicts gone (client always has 8192 edicts available, server will use 8192 edicts unless protocol is 15 (standard Quake) and in that case will use 600 for backwards compatibility), ericw's allocblock and double precision adjustments for lightmaps (even in the WinQuake version for the lightmap adjustments) and a few other things like fifth being annoying with developer 1 and changing mp3 volume printed.

I have dzip for .dz demos integrated in the current released build, but I don't have it doing anything yet.

I need to tweak the Nehahra handling a little and see if there is anything else I've missed. 

@ericw:
Really good advice with sndspeed 11050, thanks a lot! Didn't know that it actually sounds better with default setting. As you said, some sounds (not only in vanilla Quake, but also addons) have different sampling rates, but I guess this is a fair compromise.

I am about to finish my Travail tests. So far no issues. 

I can select the mode for 1080p, it seems to work in that respect but I can't tell if it's truly setting that as the resolution. I thought taking a screenshot would show the true res but the resolution of the .png file was 960x540 

Yep same here. I'd guess that's intended since Baker was talking about handling the problem thru scaling. It's funny that you get "fewer pixels" at 1080p than at 720p here, but if for whatever reason the renderer can't handle 1080p then pixel-doubling could be better than having to interpolate.

Is this what other SW renderers do at high resolutions? 

I loaded up Half Life and went to options->video and selected the software renderer, but my vertical resolution is 768 and it won't let me try higher.

Don't have Quake 2 installed at the moment to try that either.

[I did try to adjust by a percent initially instead of dividing by an integer, but the status bar was imperfect at some resolutions showing a line (WinQuake doesn't always draw the status bar, so it isn't quite a single surface.). So I went with the integer multiplication method because of that and the results should always be very predictable and I don't have to worry about stretching and such possibly looking bad at some resolutions, so it will look clean cut.] 

r_shared.h, change #define MAXHEIGHT 1024 to 1080.
1920x1080 works fine now, though it's pretty slow 

Touching that definition introduces a chain reaction that filters into the assembly language definitions and numerous things in the software renderer files.

That's way outside the scope of this project for me. 

didn't realize you were doing scaling.
The latest markv winquake build works well here @ 1920x1080. 

Haha, you know what ... 1080 vs. 1024, that's a mere 56 pixels. A quick look and I dug up some Engoo/QBism/Makaqu threads and it appears that isn't going to explode anything. 

Beta 12 - Windows GL | WinQuake

1) mp3 status events don't print for developer 1
2) Increased the maximum vertical resolution for WinQuake to 1080 (in theory -- can't directly test).
3) ericw's lightmap precision changes + alloc block speed up from Quakespasm implemented.
4) Max edicts is gone. As a client it always uses 8192. As a server it uses 8192 if running FitzQuake protocol 666 (the usual) and standard Quake's limit of 600 if serving a protocol 15 game.

Later on, I'll upload the Mac version and updated source.

Thanks for all the help in testing all of this! 

Interesting , because protocol 15 can handle up to 8192 edicts correctly 

that's a subjective statement. while the protocol might be able to cope with up to 32k ents, the implementations of that protocol may only support 600.

seeing as vanilla nq will safely handle its limitation, I would personally say that the server should just use 8192 even with protocol 15, because its better to soft-crash outdated clients than the server.
fte filters entities over the assumed client's limit because invisible entities is probably better than soft-crashing anything. if the client supports the proquake 16bit angles thing, you can generally assume the limit is higher. heuristics can always be wrong, of course.
of course, fte is crazy, and filtering reliably is a whole load of work that I can understand not bothering with (svc_setview! oh noes!), in which case imho your server not crashing is more important than your clients not crashing. 

For protocol 15:

FitzQuake 0.80, if I recall bumped the max edicts from 600 to 1024. JoeQuake uses 2048 if I remember correctly. WinQuake and GLQuake use 600.

My thoughts were if someone was going to run in protocol 15 mode as a server, they would probably want to ensure anything original Quake could connect and play. 

No crash in "Nehahra's Den" any more with max_edicts limitation gone. So much for the good news.

Unfortunately, the game now crashes to desktop a bit later when entering the next/last map (nehend). This also happens when you directly try to go that level via menu or with +map nehend, so it's not related to the previous boss fight.

Nehahra savegames and autodemo (932 KB) to demonstrate the problem

At the end of that level (nehahra), mp3 music from id1 dir is played during the level statistics and the following episode ending screen. This interferes with the actual background music, maybe it can be fixed still even though it is a minimal issue? 

To be more precise, the following Nehahra levels now crash directly to desktop when loading them:

neh1m9 "To the Death"
neh2m6 "Your Last Cup of Sorrow"
nehend "Quintessence"

Also, ID1 music generally plays in all the levels, except for when the game searches for tracks 00 and 01, but cannot find them in the music folder within the id1 directory. 

Could you check a timerefresh command. I think it's broken. 

timerefresh is broken in pretty much any modern engine, isn't it? If not, it is completely useless on any modern hardware anyways. Use timedemo. 

@ NightFright ...

1) music + crashes

Nehahra isn't supposed to use the mp3 music or cdtracks, just the .xm tracks with fmod. I need to check the behavior there, but I bet if you temporarily remove your music tracks it won't crash. Clearly, I need to fix that so it doesn't try to play both.

2) Nehahra finale text --- interesting. Apparently Nehahra draws too many lines to display for the finale text (i.e. isn't backwards compatible to Quake minimum resolution of 320 x 200, which the menu is based on). I'll figure out how to address.

@spy ... I'll fix timerefresh. Thanks for finding that. There really is no reason why that shouldn't work. 

Really odd thing: I checked Nehahra again at home on my other PC, and neither do I have crashes there nor does it play MP3s and XM tracks at the same time. Hard to figure out the differences of the PC setups. Ofc the hardware isn't exactly the same. Hmmm... I am running the game in windowed mode in the other place. Will look into that. Still, it cannot hurt to make sure Nehahra will never use MP3 music from the ID1 folder.

So far, I have tested Mk V with:
- Quake + both mission packs (MP2 50% done) --> OK
- Travail --> OK
- Nehahra --> Intermission text length, missing fog
- ne_ruins --> Succubus resurrection crash

I also remember that the commercial TCs Shrak and Malice had some issues with Mk V at least one year ago (Shrak: crashed for me when using rocket launcher sometimes, Malice: crashes in pre-final level when killing Vasquez). Will look into those again as well, even though I am not sure you'd be willing to check this if I find anything. Those addons are not very common, and at least Shrak isn't the most popular, either.