The game was very choppy at the default host_framerate 72. Smoother at 120, however buttery smooth at 240. Now my display is only 60hz, but I think that with host_framerate 240 and triplebuffering a freshly drawn frame is always ready when its time to show it on the display.
Another thing with host_framerate 240. High performance mice can operate up to 1000hz, so you can get the game to act on more mouse changes per second as well for smooth mouse motions.
Last edit: Gman 2017-08-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Should be way to make physics framerate independent, well maybe not entirely, but maybe more than it is currently.
vsync with triplebuffering shouldn't make the CPU wait. Computer could be busy drawing frames as fast as it can (and doing physics) to one of the 3 buffers, but the display only shows however many of them as it can, always swapping to the most fresh complete buffer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Physics and control input should be at least 240hz. A 60hz display will only show 1/4 of the physics frames. However, the positioning of each of those frames is along a smoother curve, and I think people notice this and get a sense of smooth movement.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Big jump from host_maxfps 249 to 250 (observed fps goes from 180 to 227 I think because 250fps = 4 millisecond frametime. Actually anything from 200-249 results in the same fps. Maybe it should be host_minframetime instead since the actual stepping is 1ms frametime.
frametime to framerate
4ms=250fps
5ms=200fps
10ms=100fps
~13.9m=72fps
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(Wish I could rename the thread title to 250 instead of 240)
BTW Quakespasm mouse turning seems to have much more precision than Darkplaces (and uhexen.) Even when both are set to 250 fps. I think the reason is that Quakespasm performs more physics/input sampling per time.
EDIT: just noticed that on e3m2 if host_maxfps is 160 the blue key will fall all the way, at 170 it doesn't fall fast enough.
EDIT2: Only on the SDL version is the mouse motion seem more smooth/precise.
Last edit: Gman 2017-10-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think it has anything to do with that. However 1000 is evenly diviible by both of those numbers.
I'd sure like to see the physics ran at 1000hz and mouse input polled at 1000hz so motion is very smooth. Even if only seen at 60hz the locations that are seen are located along very smooth curves.
Last edit: Gman 2018-02-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
New Quakespasm presents a warning," host_maxfps above 72 breaks physics". Can't stand the stuttering movement at host_maxfps 72, maybe I'll try 160 so the blue key in e3m2 will fall fast enough.
There's gotta be a way to make physics framerate independent, at least the gravity physics which is causing problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The game was very choppy at the default host_framerate 72. Smoother at 120, however buttery smooth at 240. Now my display is only 60hz, but I think that with host_framerate 240 and triplebuffering a freshly drawn frame is always ready when its time to show it on the display.
Another thing with host_framerate 240. High performance mice can operate up to 1000hz, so you can get the game to act on more mouse changes per second as well for smooth mouse motions.
Last edit: Gman 2017-08-22
I agree it would be good to have, but it's not a simple change because we can't run physics at over 72fps or physics breaks. See: http://forums.insideqc.com/viewtopic.php?f=3&t=4786&p=43538
Should be way to make physics framerate independent, well maybe not entirely, but maybe more than it is currently.
vsync with triplebuffering shouldn't make the CPU wait. Computer could be busy drawing frames as fast as it can (and doing physics) to one of the 3 buffers, but the display only shows however many of them as it can, always swapping to the most fresh complete buffer.
Physics and control input should be at least 240hz. A 60hz display will only show 1/4 of the physics frames. However, the positioning of each of those frames is along a smoother curve, and I think people notice this and get a sense of smooth movement.
Big jump from host_maxfps 249 to 250 (observed fps goes from 180 to 227 I think because 250fps = 4 millisecond frametime. Actually anything from 200-249 results in the same fps. Maybe it should be host_minframetime instead since the actual stepping is 1ms frametime.
frametime to framerate
4ms=250fps
5ms=200fps
10ms=100fps
~13.9m=72fps
(Wish I could rename the thread title to 250 instead of 240)
BTW Quakespasm mouse turning seems to have much more precision than Darkplaces (and uhexen.) Even when both are set to 250 fps. I think the reason is that Quakespasm performs more physics/input sampling per time.
EDIT: just noticed that on e3m2 if host_maxfps is 160 the blue key will fall all the way, at 170 it doesn't fall fast enough.
EDIT2: Only on the SDL version is the mouse motion seem more smooth/precise.
Last edit: Gman 2017-10-17
Just noticed a lift bug using host_maxfps 250. It's as if you hit something going up, you take damage, and the lift goes down before reaching the top.
Funny, 240 and the lift works fine, 250 and it breaks. So 5ms frametimes OK, 4ms frametimes not OK.
Last edit: Gman 2017-11-15
Isnt it somthing to do with the physics needing to be divisible of 1000?
5 is but 4 isnt sooo
I don't think it has anything to do with that. However 1000 is evenly diviible by both of those numbers.
I'd sure like to see the physics ran at 1000hz and mouse input polled at 1000hz so motion is very smooth. Even if only seen at 60hz the locations that are seen are located along very smooth curves.
Last edit: Gman 2018-02-22
New Quakespasm presents a warning," host_maxfps above 72 breaks physics". Can't stand the stuttering movement at host_maxfps 72, maybe I'll try 160 so the blue key in e3m2 will fall fast enough.
There's gotta be a way to make physics framerate independent, at least the gravity physics which is causing problems.