@Julian82 Firefly is on sale, 27 dollar at the moment, buy it and test yourself.
27 dollars is a good price, but I'm not interested in Firefly, so that's actually too much for a recording :/
The frefresh of your monitor could be a contributing factor. I have increased the refresh of my screen to 66Hz and as a result get a smoother experience when I use 66fps.
Try increasing the monitor refresh as this has given a smoother experience on the Windows and runtime tests.
I'm using a i5 16gb and 1070 FTW and I can see a stuttering after the 3rd or fouth bounce.
If taking video footage do not use a screen recorder but a phone which supports high frame rate (Slow motion) records.
I made myself a little tool to view the frame/time data on a graph, just like Fraps benchmark viewer but without the middle-man. It's simple so anyone can use it, change or build upon it. It's in similar spirit to what @schrodinger did in the earlier history of this thread but with a graph slapped on, it makes it all the more easier to see when things go nuts.
Please let me know if I messed up the math or how I go about the data, it's new territory for me!
I always seem to get a little cluster where things goes especially crazy as seen above.
Extensions needed: File, Surface and Microtimer, all available for free in the manager.
1) Open profiler.mfa and Run Application
2) Press the Start button and wait 10 seconds. Each time you run will overwrite last session.
3) Review the data... Click-Drag along the graph if you want to see a specific frame time
4) Press Clipboard or Save to keep the graph output.png. Again each time you press will overwrite the last output.png file.
I hope you get something out of it! Also remember to kill the debugger! I realized I forgot to turn it off after checking some global values before packing it up. The performance as always is obviously much better when the debugger is gone.
Looking forward to see what you can make of it. My recordings gives much better results than what I get from Fraps. That in itself could be a clue...
I am really curious how the relationship between Fusion and its rendering works. For instance I know that Fusion can work just fine with a crashed/frozen rendering(I have black belt in crashing Fusion graphics!) making it possible to continue playing your games when the graphics appear to be stuck frozen.
So I am curious how the graphic updates in relation to Fusion, is it possible it can get left behind during some frames or is it tightly locked to Fusion's "loops"? Does these tests give CT any ideas/clues at all?
Awesome idea @chrilley ,
just a little thought other than the debugger off, I would also suggest to untick the "vertical scroll bar" on the list object,
that scroll bar is a real fps-stealer, not sure about its influence in the inconsistency of timing,
but with or without I get a noticeable difference on the averages (0.015 to 0.016)
(that's the reason I moved to strings in following tests at the beginning of this thread)
Thanks @schrodinger! I'll look into strings instead of lists at some point!
- Removed Vertical List Bar on frame 1
- Disabled Debugger
- Removed the green "average" line(it felt pointless) on frame 2
- put all reference lines behind the graph(they sort of obstructed the view) on frame 2
By the way, do you think the handling of the microtimer makes sense in frame 1? I see that you approached it differently in one of your .mfas
Mmm apparently going to frame 1 event list/event editor makes my Fusion crash after few instants
Think it has to do with that missing action in the microtimer, perhaps it's been updated with new actions I don't have?
Time to update to the latest release and check I guess
(guessing you made it with latest Fusion version?)
Earlier today I had launched in on another pc where I had updated Fusion, so that could be it..
Sorry for unuseful post, will be back shortly when the update is done and mfa hopefully working
**** edit ***
ahhh nice there's new actions, I think the custom timer was not available before, that's why I was getting the error,
your tester seems all good to me, custom timer events makes it more elegant too
it just skips the very first frame loop after the button press because the timer is reset in the same frame for that cycle,
but that's really not relevant for the purpose of testing
I think a number of tests now determined this little wobblyness in frame durations,
would be really curious if devs have some idea on what might be causing it and if/how to approach the issue
Ahh... that frame skip is perhaps the cause for that spike in the graph I get at the start? Or am I the only one who gets that? It is almost always roughly the value of 2 frametimes so I guess it's just my error there!