Great to see proof of life from you, pal. This port needs you. Don't allow Mark V to get owned by Quakespasm! 

Welcome back. I am staying tuned! 

I hope you still intend on working on Mark_V at some point, since support has dropped off I have migrated to QS_Spiked for some extra QOL features but your engine was my favourite for a long time. :) 

Haha... Bend over Baker :) 

So how's that going? 

When you promise something big, then the self-imposed deadline expires and nothing is happening.

Still, Mark V is awaiting urgent limit removal updates for latest Quake content. 

There is one day left... 

... "after exactly two months", so there's little hope we can expect the second coming of Christ tomorrow.

Actually I wouldn't need a revolution or anything like that, just some port updates. Baby steps. 

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.