|Posted by Baker on 2016/11/19 04:53:11|
* Nehahra support -- better and deeper link
* Mirror support, "mirror_" textures. video
* Quaddicted install via console (i.e. "install travail")
* Full external texture support DP naming convention
* Enhanced dev tools texturepointer video inspector video
* IPv6 support, enhanced server capabilities
* Enhance co-operative play (excels at this!)
* Software renderer version (WinQuake)
* "Find" information command (ex. type "find sky")
Thanks to the beta testers! NightFright, fifth, spy, gunter, pulsar, johnny law, dwere, qmaster, mfx, icaro, kinn, adib, onetruepurple, railmccoy
And thanks to the other developers who actively provided advice or assistance: Spike (!), mh, ericw, metlslime and the sw guys: mankrip and qbism.
/Mac version is not current yet ...; Linux will happen sometime in 2017
I will return.
At that point I will likely be a billionaire, just to keep it real that is how it goes down.
So if there aren't Mark V updates right now, I shall leave it you to fill in the blanks, I have other things going on.
People like Shambler who I respect wonder how "it goes down". I never wondered. Perhaps from the perspective of some I only exist to provide chaos.
Don't worry. I will provide that chaos, because I crave it. And if you are a generic peapod, you'll be uncomfortable -- mostly because you have a small "wang" and according to YouTube not everyone can "Wang Chung Tonight".
Ignore my drunk post.
/Cuz like the funny ... against my better discretion I click "Submit'.
We Love When Baker Is Drunk
Because he is posting, and when he is sober, he can resume working on his awesome port.
I have been trying QSS lately to see if I can live without Mark V, but then I was missing the different transparency settings for liquids, finetuning for HUD weapon positioning, authentic underwater warp, Nehahra support and so on. Mark V remains number 1 for me and deserves to be perfected to be enjoyed by mankind.
New Issue Found
At least the DX9 build has issues with Quoffee/CoffeeQuake.
When trying to load e3m15_kamp "Unholy Underground", you get a crash to console with following message: "Host_Error: AllocBlock: Full". Happens when you try to load the map directly or after leaving e3m14_pinchy1.
there are a way to get an updated mac build?
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.
Mouse Issues On Mark V 1099
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.
Fix For The Mouse Issues On V 1099
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.
Mark V Sound Issue
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
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 ..)"
I Would Like A Part Here
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.
Perchance To Dream
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.
It's Behind QS/QSS/vkQuake
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.
Easy To Use, And Simple
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.
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.
Let's Revive This
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 Am Up For This As Well
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.
Poor Performance With Arcane Dimension The Necromancer's Keep
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.
The Future Of Mark V(I)
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??
RE: The Future Of Mark V(I)
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. :)
|10 posts not shown on this page because they were spam|
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.