the real value for me is software rendered Mark V Winquake, without gfx glitches due to z-index in some maps, disclosing hidden doors etc.
The problem is that sometimes suffers tearing, some others work fine without tearing, sigh... 

Hello,
i7-8750h + 1070 8GB + 32GB RAM + 144Hz G-sync screen.

I've set in my config.cfg
...
host_maxfps "72"
...
vid_refreshrate "72"
vid_vsync "1"
...
but sometimes randomly when I launch Mark V Winquake, I see a lot of tearing, some others is perfectly smooth at 72fps (144/2 = half v-sync since I have a 144Hz screen).
Of course there are no issues with Mark V DX/GL and v-sync does always work fine in this case... But I can't understand why sometimes randomly Winquake version runs with tearing and some others is perfectly smooth... ??? 

Solution found to remove tearing with the "Mark V WinQuake" GDI rendered version (using Microsoft Application Compatibility Toolkit):
ForceSimpleWindow
ForceTemprorayModeChange

https://i.ibb.co/0mZd8YK/image.png 

I have a Logitech G PRO Wireless and when I keep it at my usual 1000Hz the input becomes unresponsive. Sometimes shooting gets stuck or doesn't register. Bringing it down to 250hz seems to run fine.

Is this a known issue? 

Yeah I've had the same issue. It's probably the main thing preventing me from using this engine regularly. Haven't tried changing the polling rate yet. 

Might add:

if (scr_center_lines <= 4)
..... y = vid.height * 0.35;
.. else
..... y = 48;

Is the original Quake code. And quite terrible, really.

I came across one of Carmack's old .plans: https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_year/johnc_plan_1996.txt#L3436

changed center print position for very long text messages AND end of e4 text crash both on the very same day.

Hmmm - fishy.

The end of e4 text is 17 lines; 17 * 8 + 200 * 0.35 is 206 - yes, that'll overflow a 200-high display. 17 * 8 + 48 is 184, however.

Looking further at Sbar_FinaleOverlay we see Draw_TransPic ( (vid.width-pic->width)/2, 16, pic); - and this banner pic is 24 texels high.

So I'm 99.99999% satisfied that the weird centerprint y calculation is for positioning end of episode messages. 

Now we would just need someone to implement this code. :P 

Are you sure that these are engine and not QC bugs? My recollection is that they happen in all engines, not just WinQuake. If QC bugs it would be inappropriate to modify this behaviour in the engine.

Coming up on Quake's 25th, I've since modified my views on this.

I'm now of the opinion that the ID1 maps are legacy content, and that - in the absence of a community-curated .ent file pack fixing all of this crap (hint, hint) - it's perfectly OK to hard-code fixes for certain map bugs into the engine.

Compatibility with mods that depend on buggy behaviour can be achieved by checksumming the entities lump and ensuring that the fix only applies if the original unmodified ID1 map is running. You could go further and only apply it if the original progs.dat is running, if there are no add-on PAKs beyond PAK0 and PAK1, only if it's a SP game, or whatever.

The original point remains valid that these are content bugs, and the correct place to fix them is content. But after 25 years it's not going to happen, is it? 

I agree with that. Hacks in the engine to support legacy content can make the code messier, so it's not desirable to do too much of it. But if the symptom is bad enough, and the fix is lightweight enough, it seems worth it.

I did this in Fitzquake for the ugly row of pixels on the bottom of the large box of shells -- since players see this on every level they play, the impact of the bug seemed high enough to make it worth the ~6 lines of code. (If you have never seen this bug, I guess my efforts were worth it!)

I should have done a similar fix for the z-fighting brushmodels in id maps, but never got to it. 

That platform in e1m1 is another example. It's one of the worst z-fighting examples in the entire game, but yet it's probably the first that everyone sees. Every z-fighting fix known to man or beast either fails to fix it, or fixes it but breaks something else even worse.

In 2021 it's officially OK to check if cl.worldmodel->name is "maps/e1m1.bsp", if e->model->name is "*15", and drop e->origin[2] a little before drawing it. 

How do you config your controller after you add the -joystick command? Sensitivity settings need adjusting among other things 

I think I still found a bug in Mark V WinQuake after all these years, unless it has already been noticed. If you are underwater, the game actually seems to switch resolution.

You notice it if you play e.g. in 1080p. Once you are in the water, everything suddenly becomes super-pixellated.

Now if only Baker were still around to do something about that. Unless we can change it by ourselves somehow. 

The original software renderer (DOS/Win/etc) did that. It performed the underwater warp to a scaled down buffer, but it wasn't so noticeable because it ran at lower resolutions and the warp effect kind of helped hide it. 

I remember reading somewhere that original game did that. Anyway I installed DOSBox and checked the behavior of DOS original.

And yes the original game actually does "lower the resolution" when player is underwater. In higher resolutions it's actually a neat effect, like additional hindrance to the player's vision. But it's not noticeable if you play in 320x200, which is the resolution that was intended to be played at and designed for.

Which actually reminds me that no modern sourceport draws HUD elements correctly, it all looks a bit 'squished' compared to how it should originally look:

https://www.youtube.com/watch?v=tyLC1vR9oGk

Notice that Ranger's face on the hud is not square and has the correct proportions, while ammo box icon actually is a square. It's all because 320x200 is not a 'square pixel' resolution, but modern resolutions are. Similar thing was with original Doom games, but a lot of modern Doom ports have an option for correct HUD aspect ratio. The only Quake ports I know of that display HUD correctly are Super8 and DarkPlaces (this one has settings for any HUD stretching the user wants).

Another thing that is annoying are particles. It seems their "size" is reversed. In DOS/WinQuake if you are really close you see the particles are small, but they are displayed as big squares if you are even just a bit far away. In GLQuake (and all the ports that came later) it's like the other way around. Same thing in Quake 2 as well. They look really "chunky" in software mode but really "thin" in GL. 

In all these years I never noticed it. Then again, this was the first time I have played with a WinQuake-like port since ages. I guess it's supposed to simulate some kind of mirky water effect. Come to think of it, the idea isn't that bad... 

I would suspect that the main reason for the smaller size is performance. The underwater warp requires to touch every pixel in the framebuffer twice, which would have been a big deal for a software renderer running on a pentium 60. It also needs it's own copy of the framebuffer in memory, so keeping it small helps relieve memory pressure if running under DOS with no virtual memory.

I once tried to set up an aspect-corrected status bar, but I was just so used to the wrong one that it looked too weird. 

my understanding is that the horizontal warping is basically free because you just offset the scanlines during rasterization. Not sure how vertical warping is done, i haven't looked in a long time. 

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.