Thanks for your replies,
MH it's always nice to read your insightful comments. :) 

Baker, thank you so much for this wonderful port.

Why I was sold on this port? The hw rendered version looks great yet authentic. And the coop features are nice.

I use the 1099_mark_v_windows_revision_4 on win7 with some HIPS software installed. Works fine.

On my winxp machine the 1099_mark_v_windows_revision_4 runs but unplayable due to mouse control problems. I tried 1036 and it works fine. However I have the same HIPS software installed on winxp and I have to disable it in order for the 1036 to have mouse work ok. The 1099 has mouse problems with HIPS on or off.

I tried 1099 on win7 + 1036 on winxp in coop. Works fine. However quicksave overwrote my single player save. It'd be nice to have separate quicksaves for single and multi player.

Also is it possible to have colored lights but not transparent water? Transparent water is kinda cheating in campaign missions, because enemies still can't see you.

Comparing this to spasm. Latest spasm works fine all around on both win7 and winxp with HIPS on. No mouse problems at all. However multiplayer doesn't work. Says trying then nothing. I like markv over spasm because it's more authentic looking, plays intro demos, its preferences menu.

Once again thank you for your work 

> but not transparent water

use the following:

r_wateralpha 1 

gila, thanks

I also did r_slimealpha 1 since some items and secrets sit there 

Music volume. I compared markv to the original winquake via dxwnd with the same mp3 music set. Both at default volume levels. Markv music barely noticeable by default. Maxing out the music volume slider didn't help. So i tried lowering the sound volume instead. It turns out that lowering sound below .3 lowers music too. So you can't have music with no sound in markv for example. In original winquake you can 

My high school son is laughing his ass off in a "groan" sort of way at the title of this post. Nevertheless, this is the title of this post. He does not approve.

In the following 2 months I am going to be putting on a show, a show that severely pisses off Microsoft and probably Google.

The short version is I am going to demonstrate how much they suck by superceding their work in a massive way.

The long version is I intend to kill C Sharp. And Java. And Python. And many other languages.

If you enjoy a great show, that is a lot of fun and exciting to watch --- stay tuned.

I wouldn't be the programmer I am today if it were not for my interactions with mh, Spike, metlslime and I would not have the user common sense if it were not for the entire Quake community providing me feedback.

There will updates.

It is going to be quite a wild show ... 

are you doing quakec on rails? 

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.