The codepath looks like this.

In R_RenderView_ the warpbuffer is declared on the stack at WARP_WIDTH*WARP_HEIGHT size (320*200).

R_SetupFrame determines if we're underwater.

D_SetupFrame checks if we're underwater and sets the framebuffer to either the warpbuffer or the main video buffer.

Back to R_RenderView_ and the scene is drawn. This is the part where every pixel in the framebuffer gets touched for the first time.

Again in R_RenderView_, if we're underwater D_WarpScreen is called which warps both rows and columns from the warpbuffer back to the main video buffer. This is the part where every pixel in the framebuffer gets touched for the second time. The warp itself is just a lookup in a sin table.

The warpbuffer is always sized at 320*200 and may be scaled up when copying to the video buffer in D_WarpScreen.

A simple fix for sizing the warp may be to just change the defines of WARP_WIDTH and WARP_HEIGHT. Alternatively, warpbuffer may be allocated dynamically when the mode changes.

Running the warp shouldn't be hugely affected by this, but the overhead of the extra copy from the warpbuffer to the video buffer may be measurable. 

be interested in seeing what a full-res vanilla-style underwater warp would look like in 1080p. 

vkQuake does a vanilla-style water warp and does not scale the resolution down.

You can see how it looks in this video (if the timestamp doesn't work, go to 0:15) - https://www.youtube.com/watch?v=vY8YbeGtfZw&t=15s 

However, since Mark V WinQuake tries to imitate original game behavior as close as possible, I wouldn't expect this to be changed there (besides the suspicion that Baker probably wouldn't get back to working on this, anyway). And again, one might consider the resolution change actually being intended or at least convenient to imitate murky water. But nice to see someone implemented it actually. 

Does anybody else experience periodic micro lags? It's like every 10 seconds or so there is a lag or less than a sec, which is super annoying. Maybe it's related to a setting? Demo recording is turned off, I think. 

Yeah now I notice that too. Every 10-20 seconds there's like just a slight hiccup. Even if you're doing nothing, just standing in stock standard map, looking at the sky. Weird!

I even removed the config files out of ID1 to see how it will behave in 'default' settings, and it was the same thing still. 

Maybe it was introduced in the later builds and works with older ones? Time to resume testing, I guess.

In general, for me the WinQuake build is quite amazing besides this stuttering and the lack of OGG support. Changing HUD size would be a nice extra, but it wasn't possible in the original, so I dunno.

I dunno if it can be changed to support larger maps, but I doubt AD will ever run with it. Then again... someone first would have to resume working on this. 

Mark V WinQuake does run AD for me, even the Forgotten Sepulcher, but of course it fails to load Tears of the False God. On most maps the surfaces disappear though, because there's too much on the screen I guess.

However even if these modern maps and mods are run in WinQuake, the 256-color software rendering, while authentic, in my opinion doesn't really "work" for them. The colored lighting is missing, skyboxes and some occasional textures often look bad, transparent textures like vines are not supported, and perhaps there are other things.

I think modern stuff like Dwell, AD, UDOB, both SMEJ packs, Alkaline, EOE were designed with Quakespasm/Spiked in mind, they have transparent liquids, transparent textures, colored lighting, skyboxes, etc. Recently released map Perish the Thoth while ran fine in WinQuake, looked way better in vkQuake because of different lighting.

For myself I installed several sourceports and I decided that it would be definitely nice to play the "classic" or "classic-like" releases (DOPA and Q25Limits for example) in some WinQuake variant (currently using MarkV_WinQuake and also need to check out Windows version of QDOS), but modern stuff definitely should be played in some QS variant (currently using vkQuake). And the "GLQuake era" releases could be played in either, depending on the map/mod, I guess. 

Classic style maps work well with vanilla style ports. In big, recent maps you'll want to take advantage of latest technical options available.

It can be fun to try anyway just for the "what would it have looked like in vanilla" effect, but WinQuake isn't exactly the way to go with everything, so it's OK for it to have these technical limitations. 

Looks like I am unable to get music working with MkV-WinQ in SoA (MP1). I checked everything, music is in place (track02-09.mp3) in the "hipnotic" folder, external_music "1" is set in config, mp3 files are not corrupt. Music works in regular Quake and DoA (MP2). Is this known? 

It occurs when volume is maxed out ("1") during startup. If it's any value lower than that, even just "0.95", music will play normally. Also, as soon as you reduce volume from 1 to 0.95 or lower through the menu, music will suddenly play. After that, you are able to place the slider back to 1 without problems (but if you leave it like that, music will again not play with next launch).

This only seems to happen in Scourge of Armagon. Very strange. 

I've reproduced this as well after seeing the complaint about exactly this issue on Steam forums. I don't know if it's a known issue though.

Another weird thing about SOA startup in modern sourceports is error message something like "CD Track 98 not found" when HIPDEMO1.DEM is started - the demo plays fine but the music does not, obviously because there's no CD Track 98 (or track98.mp3/ogg file). The workaround for this is to copy track02 as track98.

But looks like modern ports read that part of .DEM file in a certain way. Looking at the file in hex editor, HIPDEMO1.DEM has a bogus one byte ("space") in front of CD track number (20 32 0A) which is perhaps wrong, but was still processed by original game without problem and not resulting in track 98. The orignal game's DEMO1.DEM file has no "space" byte (32 0A) and is processed normally by sourceports.

Yet ANOTHER thing I find to be weird is how in Mark V, the music volume is also affected by the sound effects volume. In other ports these two are completely independant of each other.

Also, what's up with Pause not muting the sound? Even in DOS original the ambient sounds are still playing while the game is paused. 

The music code is probably attempting to detect and react to changes in the bgmvolume cvar. If it hasn't changed from it's default of 1 then it won't set things up properly.

A weird quirk of the .dem file format is that everything in it is binary, with the exception of the CD track number which is plain text. Carmack must have been eating funny burritos that day. 

You may have failed to embarass Microsoft and Google by not delivering whatever it was you wanted to do (never cared tbh), but there are a few bugs right here, waiting to be squished by you... 

I play MarkV Winquake (so the software version without z-buffering issues of the OpenGL branches) at 1920x1080 and runs perfectly smooth and fine with music etc.... The only issue I have is with TINY UI and fonts.
Would be great an update with UI zoom factor. 

Have you tried different settings for Autoscale in the preferences menu? 

You may have failed to embarass Microsoft and Google by not delivering whatever it was you wanted to do (never cared tbh), but there are a few bugs right here, waiting to be squished by you...

No, I totally have not failed to deliver this thing you don't care about.

I, Baker, am now the creator of a programming language and development environment that runs on everything and by my accounts better than everything. I had to level up about 200 times to do it, and if it is super hard -- I like it!

I have some interesting choices I need to make, and I think this beer is going to help me figure it out.

I will say that I am a bit touched that despite a couple of years of "developer inactivity" that this thread is still getting love and attention touches me. It makes me think I am right to care a lot about Quake --- which I do. 

But a lot has happened with Quake ports in the last few years. Any plans of bringing Mark V up to speed? TBH I am only using QSS these days because Mark V cannot run all maps any more. 

@Joel B
>Have you tried different settings for Autoscale in the preferences menu?

That option is for the OpenGL (MarkV, not MarkV Winquake version) only :(
That's the only "issue" with the amazing winquake software rendering version, which runs so smooth and without Z-Buffering issues etc. 

Do you have a Discord account, a Twitter, an e-mail address or something where we could stay in touch? 

if that's already all we read from Baker for the next 1-2 years again. Sadly. 

Is the WinQuake version of Mark V a true software rendered version or is it some shader type of thing? 

It's purely software rendered, no GPU required.

Its support for big maps is quite impressive, and I was hoping to ask him a few questions about that, but nevermind. 

thanks - this is helpful 

is mark V still being updated? Because I can't seem to find a build from later than 2017/2018