where it says: "New version available"... 

please say you are forking this and working on some fixes - Mark V is very close to a perfect source port IMO. 

The minimum that should be done is to raise limits to match latest Quakespasm so that newer maps run again. Would also like to see some of the (re)introduced bugs fixed that I mentioned earlier on, but Baker needs to show up again first. 

I'm not yet knowledgeable enough to do that. But if I get there, I would love to. I also think MV is pretty golden, and just needs a few bug fixes. My most pressing issue is that the "firing" mode seems to get stuck randomly and my character just shoots a bunch until I span my keyboard to try to stop it. 

Also don't forget it doesn't support raw mouse input, physics breaks above 72fps, more restricted limits, etc.

The features it does have are pretty good though and the WinQuake software executable is probably the best part about it. If whatsisname sorts out the major drawbacks then it might be preferable over QSS/vkQuake. 

I think MV does ease of use the best, built-in mouse support, and keeps the menu and interface clean and straight forward. (also like that it's self contained into one .exe) @dumptruck_ds has a nice video highlighting these nice features: https://www.youtube.com/watch?v=dMOF3l2MtlI

QSS does not have mouse menu support and vkQuake also lacks mouse support in menus. 

Hello,

I have cloned the source code to a GitHub repository. And updated build instructions for Windows 10, using Visual Studio Community 10 (the oldest available VS IDE). https://github.com/victorbstan/mark_vi

This initial repository is aimed at providing a place for future updates and modernization of development and community contributions. I wan to make it easier for people to contribute code and updates to the engine. Ideally the original creator would move to GitHub as well, so I don't maintain redundant code. Otherwise I will try to integrate updates as they become available.

Next steps, I would like to set-up and test a modern build environment for the GitHub repo, so that developers can use the latest tools to contribute. 

If anybody increased the engine limits I mentioned in #2684 with this Github mirror and create usable x64 binaries, it would at least be a start and a welcome update after this long time without any changes.

I would be willing to test the problems I had reported earlier again if anybody was willing to look into them and fix anything that can be fixed. 

I have no engine coding experience, but I'm happy to test. 

Have you tested that you still have issues on the latest release of `1099_mark_v_windows_revision_4.zip 2018-05-23 03:00`?

I would like to know if it's still an issue, or if it's something that has been addressed in the meanwhile (since the original post). I would also like to mention that I am focusing on forward compatibility, more so than optimizations on older hardware and computers. Just FYI, as I have limited hardware to test and develop on; and am personally more invested into "contemporary" platforms. 

One very poor performance I can replicate is in Arcane Dimensions: The Necromancer's Keep, in the GL release the transparent fog makes the game perform noticeably worse, while using the DX9 version performs much better (the game is capped at 72 fps). 

My last tests were done in January 2019, after the last official Mark V release, which was used.

Check my last post regarding the topic (#2551), it's still valid. Basically it concerns Malice, Ne_Ruins and Xmas Jam 2018. I still have no clue how the Malice and Ne_Ruins issues were fixed and then got broken again. Unfortunately I wasn't able to find out exactly when it happened, but my guess is somehow Baker mixed in some outdated code again without noticing.

Besides fixes for those issues, raising limits should probably be the main focus of the Mark V development resurrection efforts since that's the main blocker with recent maps. 

One of the problems with MarkV performance was that Baker was reluctant to move beyond the old-style GL1.1 glBegin/glEnd renderer. This style of GL code performs absolutely terrible with higher polycounts, so the MarkV GL renderer as it is should be considered completely unsuitable for big map support.

If it was up to me (and it wasn't - even though I wrote the D3D8 and 9 wrappers MarkV was always Baker's engine) I'd just dump the alternative renderers and focus on a single high-quality high-performance path. This could even be GL as the old issues that made GL less attractive 10-odd years ago are really no longer relevant.

I end to agree that forward-compatiblity is to be preferred over supporting old hardware that no longer exists. An approach like picking a GL 3.0 (or even 4.0) baseline and just getting rid of the old byzantine codepaths for compatibility with single-TMU/etc cards definitely yields benefit. A single, simpler codepath makes it MUCH easier to test, implement and build on new features as well. 

I feel a bit uncomfortable discussing the future of the port here without Baker's input. It's still his baby after all. The least that should probably at least be considered is to put all "Mark VI/Mark V on Github" talks into a new thread.

Personally I don't mind whether OpenGL or DX9 is used as long as it's fast. The reasons why I prefer Mark V over Quakespasms are still:

- All-in-one executable (just one file)
- VIS file support (saves disk space)
- Vanilla Quake underwater warp
- Adjustable POV angles for HUD weapons
- Nehahra support

There are more advantages, but for me those are the most important ones. As long as those aren't touched and the goal remains to continue improving speed, efficiency and flawless functionality with as many mods and maps as possible, I shall be pleased. Just keep it working with latest maps (by getting rid of the limits) and get the fixes for my reported bugs back in if possible. 

oddly, even using quakespasm, i dont nearly get the performance kick as say FTE or even DirectQ 1.9. Yet using an engine with ogl 1.x i can still get 500fps on most AD maps.
is opengl 1.x emulated via shaders in the drivers? thus it's performance ? or is it just that my 1070ti can pump out more than quake can dish out...

@Baker, joe of joequake is wanting to add prtocol 66 support and i cant find the specs online anymore, besides just pointing him to the source do you still have that todo-howto list u made back in 2012?? 

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?