I agree, and also don't want to step on Baker's toes, and hopefully he may have some time in the future to continue dev, and if things align well, it can be mutually beneficial. Let's move the fork thread somewhere else. :) http://www.celephais.net/board/view_thread.php?id=61903&start=0&end=0#0 

Protocol 66 is when they killed all the Jedi

Protocol 666 is documented here: https://quakewiki.org/wiki/Fitzquake_Protocol 

The old OpenGL 1.1 calls are no longer directly supported by drivers, haven't been for almost 20 years now, so everything is emulated internally. That means that a driver might be able to do it's own optimizations in certain cases.

Quakespasm has had a number of serious performance bottlenecks inherited from the original codebase, but IIRC the last 2 major ones left should be water and sky. Since QS provides GLSL paths where available, more efficient (and higher quality) options for both do exist.

You can set up test scenes to prove any version of any API is faster than any other, so much depends on other factors - culling, CPU load, fillrate, etc. As a general observation I've found that bad OpenGL is faster than bad D3D but good D3D is faster than good OpenGL, with OpenGL being primarily hampered by buffer object updates (good in D3D, catastrophic in OpenGL) and bind-to-modify behaviours (don't exist at all in D3D) but D3D being primarily hampered by draw calls (catastrophic, even in 10/11). Designing around maximizing an APIs strengths and avoiding it's weaknesses will always give better results. 

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