Duke4.net Forums: That goddamn fps / frametime jitter / stutter - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic

That goddamn fps / frametime jitter / stutter

User is offline   Mark 

  • Honored Donor

#31

I installed the latest in my current project and had no crashes in about 2-3 minutes of running around.
0

User is offline   TerminX 

  • el fundador

  #32

How can I reproduce the crashes?
0

User is online   Zaxx 

#33

Here's a log:

Quote

EDuke32 r7940
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

0

#34

View PostZaxx, on 09 August 2019 - 12:01 PM, said:

Anyway: anyone else experiencing crashes in 7939 and 7940 or that's just me too?

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

1

User is offline   Trooper Dan 

  • Duke Plus Developer

#35

Those log warnings are just the standard ones it always shows because of the original game scripts and unused sounds.
0

User is online   SonicB00M 

#36

Can confirm the crash when shooting at the gas cylinders in the beginning of Hollywood Holocaust.
0

User is online   Zaxx 

#37

Yep, as soon as a rocket would explode it crashes except when you turn sounds off. The explosion sound is crashing the game now? :D
0

User is offline   TerminX 

  • el fundador

  #38

View PostZaxx, on 09 August 2019 - 01:09 PM, said:

Yep, as soon as a rocket would explode it crashes except when you turn sounds off. The explosion sound is crashing the game now? :D

Rockets are supposed to blow things up, right?

Edit: confirmed the issue, will fix shortly.
4

User is online   Zaxx 

#39

As for the stuttering introduced in 7937 I think this is what you should do, TX:

- 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

0

User is offline   LeoD 

#40

Everyone talks about crashes but no one gives a debug log.
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:
Attached Image: assertion.jpg
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?
Attached Image: assertion2.jpg

Adding the cfg to the allowed attachment file extensions would be nice.

Attached File(s)


2

User is online   Zaxx 

#41

Yay, the crashing got fixed but the stuttering didn't. Honestly I don't even know what is happening here anymore, who locks the fps to 119.9 instead of 120? Revert this shit, please, spare us from the horror.

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

-1

User is offline   LeoD 

#42

View PostLeoD, on 09 August 2019 - 01:38 PM, said:

[...] At least I can come up with an assertion:
Attachment 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.
Still present in r7941. Narrowed down:
- 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"

0

User is online   Zaxx 

#43

So here's the things I did to check for a software / hardware issue other than the game.

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

0

User is online   Zaxx 

#44

Another thing: tried Duke 3D on my laptop. Stutters (even though when I set r_maxfps to 0 the game is running above 200 fps so 120 shouldn't be a proble... same goes for 60). Could trigger the jitter bug by quick saving too.

I know it's my hardware... but can it be all of my hardware? Maybe it's my eyes? :D

This post has been edited by Zaxx: 10 August 2019 - 02:42 PM

0

User is offline   Mark 

  • Honored Donor

#45

I've tested a few of the latest versions but not in Vanilla duke. My custom projects and in Polymer. Not done any saving/loading. So its by no means an extensive test but I haven't had any stuttering that was not map related.
0

User is online   Zaxx 

#46

Cool, you were a great help in confirming the crash bug too. :D Don't get me wrong, I really appreciate that you're trying to help but it's a specific issue.

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

0

User is offline   Jim Rockford 

  • Banned on Rigel

#47

I just played around with vanilla Duke3D and the Aug 10 snapshot trying to reproduce this bug. My PC is significantly shittier than Zaxx's, yet I didn't have any problems. I basically savescummed while I was playing. The game has NEVER run this smoothly for me in either classic, polymost, or polymer. Not only that, I did dumb shit like leave Chrome open. Considering my pretty shitty rig, I expected to have some drops and didn't really experience any. So then I decided to test the latest version of Ion Fury on an even shittier hard drive, and had the same results, the game plays better than before for me. In fact, before the Queen of the Hill mode was impossible for me to complete because I'd get single digit frame rates after a while. I got some minor slowdown near the end when there's hundreds of spiders but it wasn't unplayable, in fact I finally completed that mode.

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?
0

User is offline   Trooper Dan 

  • Duke Plus Developer

#48

Ok, but in his most recent posts Zaxx is talking about a specific bug recently introduced with the framerate limiter, he's not talking about the old stuttering problem.
0

User is offline   Jim Rockford 

  • Banned on Rigel

#49

I was under the impression that the old bug was still happening. Regardless I maintained a consistent 60FPS except in situations where it has a reason to dip (tons of enemies and shit happening.) The new updates DEFINITELY improved performance. Also I forgot to mention that I've always had better experiences with EDuke32 in windowed/windowed-fullscreen mode than fullscreen mode. Not sure why that is, but it works for me.

This post has been edited by BlitZ: 10 August 2019 - 09:30 PM

0

User is online   Zaxx 

#50

It's possible that my original problem was solved by the change, it's just that frankly I have no idea now because of this new stuttering. :D I couldn't trigger the bug "in its original form" since the latest change to the frame limiter, now when it happens it seems like that the engine corrects itself in a second... and that's what's giving me a headace since visually I just can't tell the difference between the new stuttering and the old one. :D In a nutshell I think I can still make the game jitter after saving but it's rare and it goes away by itself now it seems.

This post has been edited by Zaxx: 10 August 2019 - 11:28 PM

0

User is online   Zaxx 

#51

Anyway if you lock your fps to 120 and enable "r_showfps" what does it say? Since the latest change I'm seeing 119.9 instead of 120 (and 240 is 239.8 now :D).

This post has been edited by Zaxx: 10 August 2019 - 11:33 PM

0

User is online   Phredreeke 

#52

I ask again, what about the FPS Offset in the video mode settings? I thought that was meant to fix such issues
0

User is online   Zaxx 

#53

View PostPhredreeke, on 10 August 2019 - 11:53 PM, said:

I ask again, what about the FPS Offset in the video mode settings? I thought that was meant to fix such issues

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

0

User is online   Zaxx 

#54

r7955 fixed the periodic stutter itnroduced in 7937, thank you, TX! :) I can still trigger the bug with saving or loading but it seems to happen very rarely now.

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

1

User is offline   Striker 

  • Auramancer

#55

I very well suspect the remaining issue could be interpolation acting all assy if the frame pacing in RTSS seems fine. I have had strange instances in IF where it seems some things start operating at 30fps visually, while everything else like aiming is still buttery smooth 120fps, but I find it extremely rare and difficult to reproduce. (Around three times over the last year)

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.
0

User is online   oasiz 

  • Dr. Effector

#56

I believe camera movement is tied to the 2048 angles you have for a rotation so a 90 degree rotation will have 512 positions at most.
0

User is online   Zaxx 

#57

View PostStriker, on 12 August 2019 - 05:23 AM, said:

I very well suspect the remaining issue could be interpolation acting all assy if the frame pacing in RTSS seems fine. I have had strange instances in IF where it seems some things start operating at 30fps visually, while everything else like aiming is still buttery smooth 120fps, but I find it extremely rare and difficult to reproduce. (Around three times over the last year)

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

0

User is offline   Striker 

  • Auramancer

#58

The game operates at 30 ticks per second, with everything being interpolated visually to look smooth at higher frame rates. If interpolation is off, stops working, or the variables storing the time of the last tic and the next one get reversed or somehow end up the same, the issues I described can happen.

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

0

User is online   Zaxx 

#59

View PostStriker, on 12 August 2019 - 09:43 AM, said:

the non-SDL build works for you

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 :D). 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

0

User is offline   Striker 

  • Auramancer

#60

I know it's on an ancient codebase, but I figured I'd eliminate the possibility of me introducing the bug as I keep updating the thing.

View PostZaxx, on 12 August 2019 - 11:17 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.

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

0

Share this topic:


  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Fury! ;) © 2019 Voidpoint, LLC

Enter your sign in name and password


Sign in options