New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Low FPS in Quantum room (AKA Timestep Woes) #101

Closed
Gyoo opened this Issue Apr 16, 2016 · 14 comments

Comments

Projects
None yet
3 participants
@Gyoo

Gyoo commented Apr 16, 2016

As I was doing a derust run, I went through the Quantum room for fun, and I noticed something that never happened before : FPS was getting lower in this room.

I all previous versions I never had any problem, but right now I do.
Here are my settings, if it helps : http://i.imgur.com/v71r4OK.jpg

@flibitijibibo

This comment has been minimized.

Show comment
Hide comment
@flibitijibibo

flibitijibibo Apr 16, 2016

Collaborator

Do you happen to know the last time you went into this room? What graphics hardware is this?

Renaud: Looking at an apitrace it seems okay (or at least, the VertexAttribPointer calls aren't any worse than other rooms), though there are a lot of client side arrays just for a couple triangles at a time, and the profiler's pointing to those as the longest calls (on a GTX 770 it's anywhere from 200us to 7ms per call, averages ~400us). Depending on what those primitives are it might help to push these to a buffer (either with USE_BUFFERS or something more clever), as it looks like the texture isn't changing for any of them anyway.

Gyoo: If you want to play around with profiling (or just check out how the game renders, for fun) you can run the game through apitrace:

http://apitrace.github.io/

./x86/bin/apitrace.exe trace --api=gl FEZ.exe should generate a trace, and ./x86/bin/qapitrace.exe FEZ.trace should let you read, profile, etc.

Collaborator

flibitijibibo commented Apr 16, 2016

Do you happen to know the last time you went into this room? What graphics hardware is this?

Renaud: Looking at an apitrace it seems okay (or at least, the VertexAttribPointer calls aren't any worse than other rooms), though there are a lot of client side arrays just for a couple triangles at a time, and the profiler's pointing to those as the longest calls (on a GTX 770 it's anywhere from 200us to 7ms per call, averages ~400us). Depending on what those primitives are it might help to push these to a buffer (either with USE_BUFFERS or something more clever), as it looks like the texture isn't changing for any of them anyway.

Gyoo: If you want to play around with profiling (or just check out how the game renders, for fun) you can run the game through apitrace:

http://apitrace.github.io/

./x86/bin/apitrace.exe trace --api=gl FEZ.exe should generate a trace, and ./x86/bin/qapitrace.exe FEZ.trace should let you read, profile, etc.

@Gyoo

This comment has been minimized.

Show comment
Hide comment
@Gyoo

Gyoo Apr 16, 2016

I remember going there during my last full playthrough of the game, which happened when I got access to v1.12, must have been during Christmas break.
My GPU is an ATI Radeon HD7970, so it's much more than enough to run the game correctly :P

I'll try to see what I can do with APITrace but I don't promise anything

Gyoo commented Apr 16, 2016

I remember going there during my last full playthrough of the game, which happened when I got access to v1.12, must have been during Christmas break.
My GPU is an ATI Radeon HD7970, so it's much more than enough to run the game correctly :P

I'll try to see what I can do with APITrace but I don't promise anything

@renaudbedard

This comment has been minimized.

Show comment
Hide comment
@renaudbedard

renaudbedard Apr 16, 2016

Owner

You're running the debug build, most likely the CPU cost of this room is much greater in debug. Try running the fna-unstable branch instead of debug and see if it resolves the problem?

Owner

renaudbedard commented Apr 16, 2016

You're running the debug build, most likely the CPU cost of this room is much greater in debug. Try running the fna-unstable branch instead of debug and see if it resolves the problem?

@Gyoo

This comment has been minimized.

Show comment
Hide comment
@Gyoo

Gyoo Apr 17, 2016

Somehow I don't have the fna-unstable branch anymore in my beta versions list D:

Gyoo commented Apr 17, 2016

Somehow I don't have the fna-unstable branch anymore in my beta versions list D:

@renaudbedard

This comment has been minimized.

Show comment
Hide comment
@renaudbedard

renaudbedard Apr 21, 2016

Owner

(sent him the beta password via twitter DM)

Let me know if that was it!
Edit : For reference, on my computer in this room I go from ~1000fps to ~450fps from Release to Debug.

Owner

renaudbedard commented Apr 21, 2016

(sent him the beta password via twitter DM)

Let me know if that was it!
Edit : For reference, on my computer in this room I go from ~1000fps to ~450fps from Release to Debug.

@Gyoo

This comment has been minimized.

Show comment
Hide comment
@Gyoo

Gyoo Apr 21, 2016

Did some further testing now that I got some time to do it.

Actually, I've checked with several FPS profiling tools (FRAPS, Steam FPS feature), the game runs at a solid 60 FPS everytime in the Quantum room. However, it feels like it doesn't run at 60. I don't know the exact cause, but it's almost like, sometimes, Gomez' position isn't updated for 2 consecutive frames, causing this weird feeling I have.

And yes I'm using FNA-unstable this time ^^

Gyoo commented Apr 21, 2016

Did some further testing now that I got some time to do it.

Actually, I've checked with several FPS profiling tools (FRAPS, Steam FPS feature), the game runs at a solid 60 FPS everytime in the Quantum room. However, it feels like it doesn't run at 60. I don't know the exact cause, but it's almost like, sometimes, Gomez' position isn't updated for 2 consecutive frames, causing this weird feeling I have.

And yes I'm using FNA-unstable this time ^^

@renaudbedard

This comment has been minimized.

Show comment
Hide comment
@renaudbedard

renaudbedard Apr 21, 2016

Owner

I'll do some testing of my own, it's entirely possible that the timing code
has that problem. Weird that it happens in this room especially, but worth
a look.

If you can take a 60fps video with fraps that you think highlights the
issue, we can analyse it frame by frame and see if the 1-update-2-frames
scenario is actually happening.

On Thu, Apr 21, 2016 at 4:27 PM Gyoo notifications@github.com wrote:

Did some further testing now that I got some time to do it.

Actually, I've checked with several FPS profiling tools (FRAPS, Steam FPS
feature), the game runs at a solid 60 FPS everytime in the Quantum room.
However, it feels like it doesn't run at 60. I don't know the exact
cause, but it's almost like, sometimes, Gomez' position isn't updated for 2
consecutive frames, causing this weird feeling I have.


You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#101 (comment)

Owner

renaudbedard commented Apr 21, 2016

I'll do some testing of my own, it's entirely possible that the timing code
has that problem. Weird that it happens in this room especially, but worth
a look.

If you can take a 60fps video with fraps that you think highlights the
issue, we can analyse it frame by frame and see if the 1-update-2-frames
scenario is actually happening.

On Thu, Apr 21, 2016 at 4:27 PM Gyoo notifications@github.com wrote:

Did some further testing now that I got some time to do it.

Actually, I've checked with several FPS profiling tools (FRAPS, Steam FPS
feature), the game runs at a solid 60 FPS everytime in the Quantum room.
However, it feels like it doesn't run at 60. I don't know the exact
cause, but it's almost like, sometimes, Gomez' position isn't updated for 2
consecutive frames, causing this weird feeling I have.


You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#101 (comment)

@Gyoo

This comment has been minimized.

Show comment
Hide comment
@Gyoo

Gyoo Apr 22, 2016

Noted. I'll do that during the weekend.

Gyoo commented Apr 22, 2016

Noted. I'll do that during the weekend.

@Gyoo

This comment has been minimized.

Show comment
Hide comment
@Gyoo

Gyoo Apr 23, 2016

I will post the video tomorrow. Spoiler alert : I was right :P

Gyoo commented Apr 23, 2016

I will post the video tomorrow. Spoiler alert : I was right :P

@renaudbedard

This comment has been minimized.

Show comment
Hide comment
@renaudbedard

renaudbedard Apr 23, 2016

Owner

Actually I'm seeing that locally too, after taking a FRAPS capture... I'm trying to understand why that happens.

Owner

renaudbedard commented Apr 23, 2016

Actually I'm seeing that locally too, after taking a FRAPS capture... I'm trying to understand why that happens.

@renaudbedard

This comment has been minimized.

Show comment
Hide comment
@renaudbedard

renaudbedard Apr 25, 2016

Owner

Okay so to be clear... this happens throughout the game, not just in this one room.

The reason why is explained in more detail here : https://plus.google.com/+flibitijibibo/posts/PysMth9Y5kN

But the tl;dr is that FEZ uses a physics timestep of 17ms instead of 16.666 because of historical reasons.
This means that updates need to be sometimes staggered, and sometimes need to catch up to account for that, and there are duplicate frames if we want to get a nice 60hz v-sync.

I took two steps in my WIP code to fix this :

  • The camera interpolation is now framerate independant. This means it really does run at 60fps at a 60hz v-sync, and on my 120hz monitor the camera movement is now silky smooth!
  • Gomez's movement code now has framerate independent extrapolation. By using his velocity, I can sort of infer where he's going to be after the next update, and interpolate to that position in the draw code. This mostly works, but has some issues that I hope to fix (floor penetration, some warping) before I push.

The rest of the entities like DOT, critters, anything else that moves is still using the 17ms timestep so it looks less than smooth, but it's a good step forward. Maybe I can generalize the extrapolation code I use for Gomez and make it work for more stuff, I'm not sure.
Also : needs moar testing, so pushing that soon!

Owner

renaudbedard commented Apr 25, 2016

Okay so to be clear... this happens throughout the game, not just in this one room.

The reason why is explained in more detail here : https://plus.google.com/+flibitijibibo/posts/PysMth9Y5kN

But the tl;dr is that FEZ uses a physics timestep of 17ms instead of 16.666 because of historical reasons.
This means that updates need to be sometimes staggered, and sometimes need to catch up to account for that, and there are duplicate frames if we want to get a nice 60hz v-sync.

I took two steps in my WIP code to fix this :

  • The camera interpolation is now framerate independant. This means it really does run at 60fps at a 60hz v-sync, and on my 120hz monitor the camera movement is now silky smooth!
  • Gomez's movement code now has framerate independent extrapolation. By using his velocity, I can sort of infer where he's going to be after the next update, and interpolate to that position in the draw code. This mostly works, but has some issues that I hope to fix (floor penetration, some warping) before I push.

The rest of the entities like DOT, critters, anything else that moves is still using the 17ms timestep so it looks less than smooth, but it's a good step forward. Maybe I can generalize the extrapolation code I use for Gomez and make it work for more stuff, I'm not sure.
Also : needs moar testing, so pushing that soon!

@Gyoo

This comment has been minimized.

Show comment
Hide comment
@Gyoo

Gyoo Apr 25, 2016

The odd thing is that, if you say it's historically there, I've never noticed it before this particular version !

Anyway, thanks for the update, and I'll make sure to test it again when it's pushed :)

Gyoo commented Apr 25, 2016

The odd thing is that, if you say it's historically there, I've never noticed it before this particular version !

Anyway, thanks for the update, and I'll make sure to test it again when it's pushed :)

@flibitijibibo flibitijibibo changed the title from Low FPS in Quantum room to Low FPS in Quantum room (AKA Timestep Woes) May 23, 2016

@flibitijibibo flibitijibibo modified the milestone: 1.12 May 23, 2016

@renaudbedard

This comment has been minimized.

Show comment
Hide comment
@renaudbedard

renaudbedard May 26, 2016

Owner

@Gyoo : Let me know how the current build feels, when you have a chance! It contains that fix.

Owner

renaudbedard commented May 26, 2016

@Gyoo : Let me know how the current build feels, when you have a chance! It contains that fix.

@renaudbedard

This comment has been minimized.

Show comment
Hide comment
@renaudbedard

renaudbedard May 27, 2016

Owner

Closing this, if there are new issues related to these changes refer to the issue I referenced above.

Owner

renaudbedard commented May 27, 2016

Closing this, if there are new issues related to these changes refer to the issue I referenced above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment