Same issue from #2671 also with w1m7 of "Realm of the Lost" ("Host_Error: AllocBlock: Full" when loading the map). Also, music tracks from that mod won't work (with odd numbers like track15.ogg, track29.ogg, track117.ogg). Everything works fine with Quakespasm 0.93.2.

Any chances of seeing an update with latest Quakespasm limit changes (dynamic lightmaps allocation, BLOCK_WIDTH/HEIGHT 256, MAXALIASTRIS 4096, MAX_STATIC_ENTITIES 4096, MAX_STACK_DEPTH 64, cmd buffer size 256K, MAX_EFRAGS/MAX_MAP_LEAFS limits removed)? It's about time since more and more recent maps stop working with this otherwise still fantastic port. 

Hello just downloaded this port today and I love it. I play a lot of NetQuake and am very excited to play this online but sometimes I don't fire when pressing mouse 1 and sometimes it sticks and doesn't stop firing. I have another friend who experiences the same issue. I have updated all my drivers and that did not fix it. I will try to go back to 1036 it seems some have to do that. 

I raised my FPS cap from the default 72 to 150 slightly above my monitors refresh rate and this seemed to fix the sticky mouse issue. Had two of my friends test this also and it seemed to fix it for them as well. Even though they had 60 hz monitors raising the FPS cap above 144 seemed to help their mouse not stick. 

Anyone had this problem? Switched over to Win10 x64. Tried Mark V, the sound is fine but laggy - not choppy but with big delay rather - even in main menu, press up or down to move the "Q", and sound comes in like 2 seconds later.

No such issue in Quakespasm. 

Mark V: How Do I Disable Autoaim [EDIT]
Posted by bluemoss on 2020/03/29 00:39:09
I've been really getting into Mark V on my potato of a pc with little to no hope of open gl rendering, and Mark V seems to be the best
But it took me a while to notice some autoaim
Anyone know how to toggle this on/off?


#1 posted by onetruepurple on 2020/03/29 01:21:22 spam
sv_aim 1 

Navigate to your id1 subdir and open config.cfg with a text editor. Search for the sv_aim entry. Default setting is 0.93. Change that value to 1 (so it reads sv_aim "1"), save and there you go. 

Hello, the source code does not seem to be distributed with the installer, or zip. And Googling around, I haven't had any luck. Is there a link to the release source code? Thanks! 

on the website there is a part where it says "Current source code (download | all builds ..)" 

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.