There's plans from Baker to de-couple the physics from the refresh rate so that these weird glitches don't happen.
Not sure when he's planning on doing this but it will probably take some time before it happens.
I've personally stopped playing at 144hz since I was made aware of the bug and I am honestly used to 72fps again. I'll bump it back up when it's fixed. 

It breaks my heart I re-worked a kick-ass part of a map because I was so ill-informed about this but I didn't want to release something that would randomly kill players. I hope Baker can get this to work. 

The usual engine caps framerates above 72.
Result is you get damage from being elevated by a plat/door. (Dont ask why, thats above the topic for now)
Try FTE-Quake from spike. It does support "pixelvision" and all the other features we love. Plus a ton of functions you'll never see with QS or FitzMarkV or the like.

Never use DP ever.

Thats my best bet for a future engine.

vQuake is another option to try, idk if it supports the latest AD maps.
But its written for the new Vulkan (API), which should get more attention in the future. Or not. 

It is an annoying issue isn't it?

FTEQW and DarkPlaces are completely immune to this issue.

There is about nothing FTE can't do and it is very faithful. 

Thank gents. I was going to check out vkQuake but it's a fork of QS so may have the same issue. But as for as the future-proofing it's a great step. 

http://nquake.com 

vkQuake is going to have the same issues.

It is just a different rendering pipeline, which has nothing to do with any of this.

It's a physics/clock issue. 

related insideqc threads:
Is vid_vsync wrong?
Framerate-independent physics

One thing to note is that, if you implement it by locking the server framerate at 72fps, and then lerping between the last 2 server frames to generate the high fps client's view, this adds ~14ms of lag to the whole game. (at the moment when a new frame arrives from the server, you're going to be rendering the last frame. correct me if that is wrong)

I also want to note how old and problematic Wally and TexMex are. They work but how long will it be before they are obsolete?
This is true, the wad format is really simple though. though it is surprising there is no "take all images in the current directory and pack them into a .wad" tool already? 

with opengl, you can change the vsync interval so that it vsyncs every other frame, that would mean that they'd scale to decent monitors even without fixing the underlying physics (which also means avoiding breaking the 'wait' console command).
that said, vsync has its own lag, and in my experience its smoother to use cl_maxfps or whatever instead of vsync as implemented by nvidia's opengl driver (d3d or single-threaded vulkan don't have the smoothness issue, though fte seems to be able to acquire about 10% more backbuffers than it should when device queue stuff is offloaded to a worker thread).
@ericw, what you're forgetting is that thanks to interpolation, many things in the game are already up to 100ms behind. more video frames means it'll actually be closer to current.

Regarding wads, what I want to see is editors/qbsps that just directly use pcx/tga/png (with some vague shader-like scripts to provide stuff like phong angles and rescaling[so engines could directly use the same high-res textures]. I'm not saying that engines should need to read these scripts, just that I think it would be a nicer way to get per-surface stuff than creating entire func_details for a single face).
the problem with that is politics, of course. 

re: politics

Much the way the ISO works couldn't we get all the brightest, active minds in the Quake source port scene to "meet" and agree to standards moving forward? Perhaps a "lowest common denominator" standard engine architecture could be agreed upon and followed by all active developers and then engines could diverge off as long as they have these features available to the end user? 

couldn't we get all the brightest, active minds in the Quake source port scene to "meet" and agree to standards moving forward?

This has been tried and failed so many times that it's long since gone beyond being funny and is now orbiting a black planet fuelled by the crushed hopes and dreams of a small child.

We tried it, it didn't work, because everybody has their own ideas and sooner or later (and most likely sooner) it just collapses.

Then we tried it again and it failed again. Repeat to fade.

That's classic design-by-committee.

What does work is when one person pushes something forward in a way that's easy for others to pick up. That's how we got LIT files, it's how we got standardized fog, it's how we got BSP2. 

I don't know how it compares to Wally and TexMex, but in 2006 FrikaC made FImg, http://www.insideqc.com/frikbot/fimg/fimg_v02.zip

You can read the initial thread here,
http://forums.insideqc.com/viewtopic.php?p=2916

That thread has old links on it to inside3d which is no longer up. 

SLADE already can open Quake WADs and other game formats, sadly it can't save Quake WAD back. At the moment you can export textures to png, remap palette etc.

Supported Data Formats

It would be awesome if some smart dude could add Quake WAD save option.
SLADE has many useful tools, and opens many other formats, so it would be super easy to convert textures from other games.
Of course it has many tools we don't need, like Doom Editor, but Texture management is very good. 

That is actively developed with updates this month.

Ask the author. Offer to beta test and offer up a couple of other beta tests plus volunteer to spread the news around Quake sites including mentioning it.

If you actually want that, that is the proper way to do it. 

Ok, good point. 

Asked and this is the answer:

it's probably possible I guess
just not a priority as SLADE is primarily a doom engine editor

...I expected this answer ;)
"Yeah it's possible but I don't have time for this shit."

Welp I'm not surprised, guy is doing tool for Doom, so he doesn't care about Quake. 

I play Quake 2 at 120 fps and have no issues so far.

I am aware of the physics limitations meaning I can jump through lasers if my speed is high enough (only takes a few strafejumps in rapid succession), but this hasn't had any other gamebreaking issues for me so far. One really odd thing that happened was that I managed to get stuck in the roof of lab above the acid pit when I managed to slide off and decided to quad boost myself out of the acid again. It's the only time it's happened, though. I had to noclip my way out. I wish I had recorded it but every time I reload the map the .dm2-recording gets rewritten...

I think the best way to futerproof the Quakes is to not stop playing them. :3 

A hamburger isn't really made out of ham.

Quake 2 isn't really made out of ... 

Welp I'm not surprised, guy is doing tool for Doom, so he doesn't care about Quake.

SLADE is GPL 2 so if you can convince anybody else that (1) it's a good tool to use, and (2) it's a worthwhile change, they can freely make the change themselves, in either a forked version of it or to contribute back to the original. 

We're all aware of your love for Quake 2 and I certainly want you to feel welcome here. But unlike reddit and QuakeOne, when a specific post refers to Quake - we are only talking about the original Quake. Not the "Quakes."

No harm done but just a heads up if you feel some hostility here and there. IMO it's good form to keep the two games separated by specific posts. 

 

 

Hrmm. Weird, I've been playing Quake (using Quakespasm of course) for the longest time with 144hz and host_maxfps set to 144. I haven't noticed any issues. I believe I have seen weird glitches and shit with unlimited FPS though.

I'll have to look at the demo and see if I can recreate the issue sometime this weekend. 

It's kinda far into the demo but you can't miss it. It's on the first big indoor lift (I think.) At the top of the lift are floating bookshelves. watch out for the Ogre's on either side of the lift exit. 

A glitch at 144 fps isn't surprising or unexpected.

I wouldn't worry about what a non-engine developer says because their entire body of feedback chain is own experience and awareness.

An engine developer has gotten feedback from hundreds and tends to also keep an eye on feedback other engines receive as well.

To the best of my knowledge the most sentitive standard Quake map is E3M3 and multiple players have said you can easily miss the trigger in the beginning of the map with a higher fps cap.