|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
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
Not Transparent Water
> but not transparent water
use the following:
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
Prepare To Get Primed
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?
He Is Back!
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!
Good To See You Again, Baker
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. :)
Prepare To Get Primed
Haha... Bend over Baker :)
Just The Usual
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.
He Did Not Write...
... "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...
Here You Go Hexaae, A Better Thread To Ask It In,.
i7-8750h + 1070 8GB + 32GB RAM + 144Hz G-sync screen.
I've set in my config.cfg
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):
Issue With High Polling Rates On Mouse.
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.
#1336 In The Old Thread
if (scr_center_lines <= 4)
..... y = vid.height * 0.35;
..... 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?
You must be logged in to post in this thread.
Website copyright © 2002-2022 John Fitzgibbons. All posts are copyright their respective authors.