That goddamn fps / frametime jitter / stutter
#31 Posted 09 August 2019 - 12:45 PM
#33 Posted 09 August 2019 - 01:03 PM
Quote
Built Aug 9 2019 04:08:16, GCC 7.2.0, 64-bit
Using F:/Games/EDuke32/ for game data
Running on Windows 10 (build 10.0.18362)
Initializing SDL 2.0.10
Searching for game data...
Using "duke3d.grp" as main game data file.
Compiling: GAME.CON (151190 bytes)
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45482 bytes)
USER.CON:844: warning: sound 261 already defined (hydro43.voc)
USER.CON:873: warning: sound 323 already defined (aisle402.voc)
GAME.CON: In actor `ORGANTIC':
GAME.CON:3967: warning: found `else' with no `if'
GAME.CON: In state `pigshootenemystate':
GAME.CON:5890: warning: found `else' with no `if'
Found 4 warning(s), 0 error(s).
Compiled 134600 bytes in 52ms
Initialized 96.0M cache
Sound hlminhal.voc(#23) not found!
Sound hlmexhal.voc(#24) not found!
Sound yes.voc(#45) not found!
Sound fan.voc(#77) not found!
Sound hover.voc(#80) not found!
Sound turrrm.voc(#145) not found!
Sound turrrg.voc(#146) not found!
Sound turrat.voc(#147) not found!
Sound b3atk01.voc(#152) not found!
Sound turrpn.voc(#161) not found!
Sound turrdy.voc(#162) not found!
Sound b3atk01.voc(#176) not found!
Sound vpiss2.voc(#182) not found!
Sound jacuzzi2.voc(#322) not found!
Sound joke.voc(#397) not found!
Initializing OSD...
Switching keyboard layout from 0000040E to 00000409
0 joystick(s) found
Executing "settings.cfg"
Setting video mode 1920x1080 (32-bpp fullscreen)
Refresh rate: 60Hz
OpenGL information
NVIDIA Corporation GeForce GTX 970/PCIe/SSE2 4.6.0 NVIDIA 431.68
Opened "texturecache" as cache file
Initializing music...
Initializing sound... 64 voices, 2 channels, 16-bit 44100 Hz
Sound hlminhal.voc(#23) not found!
Sound hlmexhal.voc(#24) not found!
Sound yes.voc(#45) not found!
Sound fan.voc(#77) not
#34 Posted 09 August 2019 - 01:03 PM
Zaxx, on 09 August 2019 - 12:01 PM, said:
Edit: If I turn the sound off the crashes stop happening.
Yes, looks like is caused by explosions, shot at gas cylinders and it crash, shot rockets (RPG/Devastator), use laser tripbombs, pipe bombs, and everytime immediately before the explosion it crash.
(Didn't tried to let shot explosives from enemies eg: Overlord, but i suppose it will crash. i'm in a hurry btw)
As already pointed, turn off the sound and does not crash, letting the music ON is not a problem.
This post has been edited by The Battlelord: 09 August 2019 - 01:07 PM
#35 Posted 09 August 2019 - 01:05 PM
#36 Posted 09 August 2019 - 01:07 PM
#37 Posted 09 August 2019 - 01:09 PM
#38 Posted 09 August 2019 - 01:10 PM
Zaxx, on 09 August 2019 - 01:09 PM, said:
Rockets are supposed to blow things up, right?
Edit: confirmed the issue, will fix shortly.
#39 Posted 09 August 2019 - 01:13 PM
- turn off GSYNC
- switch the monitor to 60 hz (everything is more noticeable that way)
- lock your game to 120 fps (60 "works" too)
- play and observe
I think it's pretty obvious that there is some periodic stutter happening now, especially if you compare to something like 7930 (rock solid).
This post has been edited by Zaxx: 09 August 2019 - 01:13 PM
#40 Posted 09 August 2019 - 01:38 PM
Just a reminder...
I admit that I experience freezes, not crashes, so no debug logs for me. At least I can come up with an assertion:
Seems to be reproducible by using the left mouse button only from closing the startup window over skipping screens until E1L1 start on let's rock.
Btw., any idea why the MS VC++ runtime library chimes in on an MSYS2-built debug binary?
Adding the cfg to the allowed attachment file extensions would be nice.
Attached File(s)
-
assertion1-cfg+log.zip (4.59K)
Number of downloads: 89 -
assertion2-cfg+log.zip (4.92K)
Number of downloads: 97
#41 Posted 10 August 2019 - 06:20 AM
Goddamn Build engine, man: tried locking the game with RTSS instead of the in-game limiter and while that fixes the periodic stutter it can introduce some random jitter. I give up.
This post has been edited by Zaxx: 10 August 2019 - 06:54 AM
#42 Posted 10 August 2019 - 09:06 AM
LeoD, on 09 August 2019 - 01:38 PM, said:
assertion.jpg
[...] reproducible by using the left mouse button only from closing the startup window over skipping screens until E1L1 start on let's rock.
- Win32 = Win64
- release binaries will return to main menu instead of assertion
- introduced in r7804
- triggered by this eduke32.cfg entry:
[Controls] MouseButton0 = "Move_Forward"
#43 Posted 10 August 2019 - 02:13 PM
Played some games:
Doom 2016: perfectly smooth frames with a lock both in Vulkan and OpenGL (60 fps)
Wolf TNC: perfectly smooth frames with lock (60 fps)
Blood FS: perfectly smooth frames with lock (120 fps)
GZDoom: perfectly smooth framese with lock (120 fps)
QC: perfectly smooth framese with lock (120 fps)
BloodGDX: perfectly smooth frames with some minor stutter here and there so usual BloodGDX (120 fps)
Amid Evil: perfectly smooth frames with lock (120 fps)
DUSK: perfectly smooth frames with lock (180 fps)
Tried the ingame fps limiters where they apply. Did the same with RTSS in all of these titles, tried both the usual fps limiter and the scanline sync: smooth again, solid framepacing. Vsync wasn't used.
Tested EDuke32 again: version prior to 7937 are all significantly smoother, 7937 and up is garbage.
Looked at hardware stuff: everything's in order, also no viruses and stuff like that. I keep a clean system so no stuff running in the background.
I think it's safe to say that it's not my system just like how that was already established 1 fucking year ago. Please don't ship IF like this and just trust me in that the frame limiter's "improved behavior" is everything but that. Anyone else test this apart from you and me, TX?
This post has been edited by Zaxx: 10 August 2019 - 02:15 PM
#44 Posted 10 August 2019 - 02:42 PM
I know it's my hardware... but can it be all of my hardware? Maybe it's my eyes?
This post has been edited by Zaxx: 10 August 2019 - 02:42 PM
#45 Posted 10 August 2019 - 02:47 PM
#46 Posted 10 August 2019 - 06:24 PM
Maybe I should have been more clear on that since this stuttering is not what the thread is about, this is a new problem caused by the messed up frame limiter... but you don't need to test it because I've just found a way that proves that I'm right without any question whatsoever.
Here's the thing: EDuke32 has an adaptive vsync feature. Now we're in "indie dev land" or "source port world" so that means that this is most likely not an adaptive vsync feature specifically developed for EDuke32 but just a trigger for Nvidia's shit. In this case that's great because adaptive vsync is independent from the game engine so it works as it was intended by Nvidia: when your framerate drops below your monitor's refresh rate vsync will disengage and instead you will get screen tearing.
Now since TX implemented the frame limiter update in 7937 adaptive vsync does not work in EDuke32. Why? Because the frame rate is constantly below the monitor's refresh rate now if you try limiting your frames to your monitor's refresh rate in EDuke32's frame limiter. It's a bit hard to notice because the limit is not massively under the refresh rate (we're talking about something like a 0.1 fps difference, very tiny shit, a better engine would even handle it, for example in GZDoom this would most likely result in a moving tearline instead of stutter) so adaptive sync may even be on for a while but then it turns off and you get tearing.
In previous versions adaptive vsync works as intended.
Edit: Btw. it's a shame that the limiter got messed up because I was playing around with r7930 with vsync on with an fps lock that matches the refresh rate and it seems like that the frame time fixes have also fixed EDuke32's problems with vsync.
This post has been edited by Zaxx: 10 August 2019 - 07:46 PM
#47 Posted 10 August 2019 - 08:40 PM
PC Specs:
Windows 7 Professional Service Pack 1
Intel Core 2 Quad Q6600 CPU Overclocked to 3.22GHz (Stock 2.4GHz)
Nvidia Geforce GTX 460 1GB (Overclocked to 800MHz Core/2000 RAM, stock is 675/1800)
4GB OCZ DDR2 1066 RAM (Running at 715MHz. Maximum supported speed by motherboard is 800)
250GB Fujistu 5400RPM (Laptop HDD) [Played: Vanilla Duke3D]
80GB Maxtor 7200RPM (Regular HDD) [Played: Ion Fury]
My suggestion is maybe this has something to do with Win10? Zaxx could you try using an HDD to test with?
#48 Posted 10 August 2019 - 09:18 PM
#49 Posted 10 August 2019 - 09:23 PM
This post has been edited by BlitZ: 10 August 2019 - 09:30 PM
#50 Posted 10 August 2019 - 11:26 PM
This post has been edited by Zaxx: 10 August 2019 - 11:28 PM
#51 Posted 10 August 2019 - 11:30 PM
This post has been edited by Zaxx: 10 August 2019 - 11:33 PM
#52 Posted 10 August 2019 - 11:53 PM
#53 Posted 11 August 2019 - 12:28 AM
Phredreeke, on 10 August 2019 - 11:53 PM, said:
The difference from the correct value is so small that you can't correct it manually by using the fps offset setting (you can't offset the limit by let's say 0.05 fps). As it is now I guess it depends on your monitor if it works or not, for example if you have a 59.94 hz monitor the values may be right for you.
This post has been edited by Zaxx: 11 August 2019 - 12:30 AM
#54 Posted 11 August 2019 - 08:59 PM
If the in-game indicator and RTSS is not wrong then looking into a security camera can still mess with the frame pacing (and it has some lingering effects on the game after you go back to regular gameplay) but in the last few weeks I've tried a bunch of Duke ports and this actually happens in all of them (I've just tried LeoD's non-SDL version of EDuke32 and it happens there too so yep, I don't know of any Duke version where this isn't an issue). Maybe it's caused by the camera's movement not being interpolated or something? That and the recent improvements got me the idea that maybe the bug caused by saving-loading is not related to the frame times at all: I have no idea how framerate interpolation works in EDuke32 but can it happen that something along those lines is the cause?
Made a little video on it that hopefully shows this off better than previous attempts. Guess the only visible thing is the in-game frame time indicator going a bit crazy (ingame it results in more pronounced screen tearing) so I dropped the rendering resolution to 720p to make the font bigger:
In any case I think the frame times have improved tremendously. It's obvious you worked hard on this so I can't thank you guys enough, EDuke32 has never been this smooth.
This post has been edited by Zaxx: 11 August 2019 - 09:02 PM
#55 Posted 12 August 2019 - 05:23 AM
A similar issue can happen in EDuke32-OldMP online, where totalclock & ototalclock get screwed up, and interpolation breaks for a lot of things, and it takes a while to correct itself.
#56 Posted 12 August 2019 - 05:37 AM
#57 Posted 12 August 2019 - 07:38 AM
Striker, on 12 August 2019 - 05:23 AM, said:
A similar issue can happen in EDuke32-OldMP online, where totalclock & ototalclock get screwed up, and interpolation breaks for a lot of things, and it takes a while to correct itself.
You've just described the bug pretty well. A few things about this:
- when the bug happens visually it doesn't look like microstuttering but rather a smooth 30 fps
- RTSS can report hiccups in the framepacing but it's weird, I mean the readings don't really make sense
- the in-game frame timer stays where it should when the bug happens, even when the game looks like it's running at 30 fps the frame time is 8.3 ms
- if I compare mouse movement between locking the game to 30 fps and the game bugging out the crosshair does move a lot smoother when it's the bug. It's this weird effect that looks like motion blur when moving the mouse fast.
- When the bug happens I don't get more screen tearing. Now I'm not sure how that's supposed to work but afaik a stable 120 fps produces two stable tear lines on a 60 hz monitor. Those tearlines stay there when the bug turns up its head.
So yeah, if broken interpolation is 30 fps then I'm 99.9% sure that it's an interpolation issue. I mean apart from RTSS telling me weird stuff everything points in the direction that I have a solid 120 fps and a solid 8.3 ms even when the game's bugging out.
This post has been edited by Zaxx: 12 August 2019 - 07:47 AM
#58 Posted 12 August 2019 - 09:43 AM
Then again, the non-SDL build works for you, so it very well could just be SDL itself. Try EDuke32-OldMP Release 29, and tell me if it's smooth. It's a non-SDL build as well.
https://gitlab.com/m...ance/-/releases
This post has been edited by Striker: 12 August 2019 - 09:49 AM
#59 Posted 12 August 2019 - 11:17 AM
Striker, on 12 August 2019 - 09:43 AM, said:
No, it doesn't, before 7955 it was smoother than OG EDuke32 but I can break that one with saving or loading too.
As for old-MP I don't know if I can do anything with this because this seems very-very ancient (oh, the good old days when you could only limit your frames to whole miliseconds so if you typed in r_maxfps 120 you got 125 fps ). I'm using ED32 since I dunno, 2006 or 2008 and I'm pretty sure that this is based on a version of ED32 from the time when I didn't have this problem. If you can tell me how to trigger the interpolation bug there then I could compare it to what I'm having.
Anyway I got into some EDuke32 talk on Discord and somebody just reported the bug:
"Also, all EDuke32 port variants run ok for me but they have moments were they feel sluggish; movement works smooth but everything else looks slowed down. It goes away after a while. I don't particularly mind, but I can see how that can be a huge issue for most people."
And I didn't talk about this specifically, I just said that ED32 has some rendering issues sometimes.
This post has been edited by Zaxx: 12 August 2019 - 11:21 AM
#60 Posted 12 August 2019 - 12:04 PM
Zaxx, on 12 August 2019 - 11:17 AM, said:
Oof. I was under the impression it was fixed with LeoD's build.
This post has been edited by Striker: 12 August 2019 - 12:06 PM