Framerate problems

Report issues with v1.2 here.

Moderators: Huki, jigebren

Framerate problems

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

27 Dec 2016, 17:26 #1

Hi, I found about those Re-Volt updates just yesterday.

Re-Volt was a endless fun game years ago in my home so I'm really happy to found this.

Anyway, I have a problem with RV 1.2 (tested RVGL and the problem is the same).

Game stutters and is not smooth. It miss frames here and there with regular periods.

I tried vsync on/off in game and other external tools to lock framerate with no luck.

Using vsync off the framerate is higher than 1000 fps but the framerate is not smooth.

I did a few test with CheatEngine SpeedHack and found that the game currently renders 62.5 frames every second no matter the options I use. So, the only way to play RV 1.2 with smooth framerate is using SpeedHack at 0.96 that slowdowns the game a bit.

This way, the game is smooth, but I can only play without music. If I try to use MP3 files with edited .inf, music has slowdowns that affect framerate because the music system tries to syncronizes with the game renderer.

I tried both RVGL and RV 1.2 in another computer and the problem is exactly the same. My computer is a 2700K@5 ghz with a GTX1080 so is not a problem with the performance. I think the problem starts with a bad frametime rounded number. 62,5 fps means 16 miliseconds frametime instead of 16,666666 needed for 60 fps.

Looking at the Kotaku 60 fps video linked herehttp://rv12.revoltzone.net/rvgl.php

The stuttering is present too, so everybody suffer this problem.


Maybe someone can check this. Thank you.
Reply
Like

Touriga
Regular
Touriga
Regular
Joined: 23 Aug 2012, 19:07

28 Dec 2016, 10:38 #2

Hi MalDo,

Definitely not everybody suffers from your problem but I've seen other users reporting similar troubles.

With RVGL you have in folder /Profiles/rvgl.ini where you can limit the fps:

LimitFPS = 240

Without using any other tool, you could give it a try.

I'm on AMD gfx and most problems I've heard where either Intel Graphics or Nvidia related.

I'm sure Huki will have a look into it but again I haven't heard of anything this bad.

Planning to upgrade soon to a configuration similar to yours so this definitely interests me.

All the best,

Touriga
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

28 Dec 2016, 20:24 #3

Touriga @ 28 Dec 2016, 11:38 AM wrote: Hi MalDo,

Definitely not everybody suffers from your problem but I've seen other users reporting similar troubles.

With RVGL you have in folder /Profiles/rvgl.ini where you can limit the fps:

LimitFPS = 240

Without using any other tool, you could give it a try.

I'm on AMD gfx and most problems I've heard where either Intel Graphics or Nvidia related.

I'm sure Huki will have a look into it but again I haven't heard of anything this bad.

Planning to upgrade soon to a configuration similar to yours so this definitely interests me.

All the best,

Touriga
Hi Touriga, yesterday I test the game in a AMD cpu/gpu combo in Windows 10 and the problem was the same. Maybe some people is not sensitive enough to framepacing problems.
Reply
Like

Touriga
Regular
Touriga
Regular
Joined: 23 Aug 2012, 19:07

28 Dec 2016, 22:28 #4

I would say windows 10 is the problem.

Could you try with Windows 7 ?

I encoded video for many years and believe me I have an eye for video :-) specially stuttering and alikes.

I ain't no guru here so I'll leave it to who knows.

But again from the 10 to 15 players I race with online never spoke about anything like you said.

Can't believe they can't spot stuttering.

All the best,

Touriga
Reply
Like

Abc
100% Proofer
Abc
100% Proofer
Joined: 07 Apr 2009, 18:43

28 Dec 2016, 23:12 #5

the 1.2 update that tweaked vsync and high fps issues people were having also created some awkward limitation in fps, i can confirm that my fps was higher before the update and limited after.
windows 7 here
Yes, I'm the ABC block and you can find me in Toy World 1 track! ;)
Reborn as Juest Zungo :P PS: I prefer chatting and i have Steam, Skype, Google and Microsoft account, just ask for it via PM or rarely find me in RVHouse. Also check out my interests.
Reply
Like

Huki
... as a Newt
Huki
... as a Newt
Joined: 30 Dec 2006, 16:01

29 Dec 2016, 03:27 #6

@MaLDo: Hi, and welcome. Well, I've neither personally experienced nor received a report about any stuttering, so I'm really confused and curious. According to you, the stuttering exists both in v1.2 and RVGL, so that rules out OpenGL driver specific issues. There is also nothing in either v1.2 or RVGL that attempts to limit the framerate (recent RVGL versions do have a framerate limiter that is disabled by default).

For now a few things are not clear from your report. What is the OS used in your first machine? (the one with the 2700K@5 ghz and GTX1080). Have you tried running the game in windowed mode? (using the -window command line).
Touriga wrote:I would say windows 10 is the problem.
I don't think so. I've run RVGL in Windows 10 32-bit on my main computer and Windows 10 64-bit on a newer AMD laptop, both have run really smoothly (both with vsync on and off).
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

29 Dec 2016, 11:54 #7

Huki @ 29 Dec 2016, 04:27 AM wrote: @MaLDo: Hi, and welcome. Well, I've neither personally experienced nor received a report about any stuttering, so I'm really confused and curious. According to you, the stuttering exists both in v1.2 and RVGL, so that rules out OpenGL driver specific issues. There is also nothing in either v1.2 or RVGL that attempts to limit the framerate (recent RVGL versions do have a framerate limiter that is disabled by default).

For now a few things are not clear from your report. What is the OS used in your first machine? (the one with the 2700K@5 ghz and GTX1080). Have you tried running the game in windowed mode? (using the -window command line).
Touriga wrote:I would say windows 10 is the problem.
I don't think so. I've run RVGL in Windows 10 32-bit on my main computer and Windows 10 64-bit on a newer AMD laptop, both have run really smoothly (both with vsync on and off).
Hi Huki, my SO is Windows 10 x64 (1607 version 14393.576 compilation)

I just tested with -window parameter. First of all, the game keeps the window border but fit the 1080p rendered image into the less than 1080p pixels window (because the borders) and adds scaling artifacts.

Apart of that, even with Vsync ON in game menu, Vsync is currently disabled in windowed mode, and framerate is between 800 and 1500 fps during races.

Last, stuttering is not fixed. The problem is mixed with the usual no-smooth framerate because vsync off, but is there.

I think a test for people that thinks the judder is not present could be to use CheatEngine and slowdown the game with a 0.96 factor (and disable music). If the game is smooth using it, the judder was there before.

I want to note again that Kotaku 60fps gameplay footage has judder.

I will test in a different pc with Windows 7 tomorrow.
Reply
Like

Huki
... as a Newt
Huki
... as a Newt
Joined: 30 Dec 2006, 16:01

31 Dec 2016, 13:22 #8

MaLDo @ 29 Dec 2016, 05:24 PM wrote:I just tested with -window parameter. First of all, the game keeps the window border but fit the 1080p rendered image into the less than 1080p pixels window (because the borders) and adds scaling artifacts.

Apart of that, even with Vsync ON in game menu, Vsync is currently disabled in windowed mode, and framerate is between 800 and 1500 fps during races.
This is known to happen in v1.2 and previous versions as they didn't support variable sized windows or vsync in windowed mode. Have you tried running RVGL in windowed mode?
MaLDo wrote:I want to note again that Kotaku 60fps gameplay footage has judder.
I can see some stuttering in the Kotaku video in 720p60 mode, but problem seems to be with the video (or YouTube's 60fps mode) because the stuttering doesn't exist when I'm running the actual game.

Going back to a post by Abc:
Abc wrote:the 1.2 update that tweaked vsync and high fps issues people were having also created some awkward limitation in fps, i can confirm that my fps was higher before the update and limited after.
Let's see, we added the fixes for stability at high fps in v1.2 Alpha 15.0325:

Code: Select all

---------------
 Alpha 15.0325
---------------

Mod [General]

    - Use a fixed timestep for the game management rather than depending 
      on the actual frame rate to improve the game stability (of the 
      lights, animations, etc.) in high fps (i.e., with vsync off).

Can you try v1.2 Alpha 15.0131? That was the last release before those stability fixes. You can download old builds from: http://rv12.revoltzone.net/oldbuilds.php
Direct link to 15.0131: rv1.2a15.0131_setup.exe

Keep in mind that these old v1.2 builds are not fully compatible with Windows 8 and 10 (they don't run properly in fullscreen). You might have to test it in windowed mode, or using Windows 7.
Reply
Like

sebr
Methanolic
sebr
Methanolic
Joined: 29 Jul 2010, 17:26

31 Dec 2016, 15:59 #9

don't forget -emulatefullscreen, work as -window but stay fullscreen
and was added for win8 compatibility
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

31 Dec 2016, 17:25 #10

Huki @ 31 Dec 2016, 02:22 PM wrote:
MaLDo @ 29 Dec 2016, 05:24 PM wrote:I just tested with -window parameter. First of all, the game keeps the window border but fit the 1080p rendered image into the less than 1080p pixels window (because the borders) and adds scaling artifacts.

Apart of that, even with Vsync ON in game menu, Vsync is currently disabled in windowed mode, and framerate is between 800 and 1500 fps during races.
This is known to happen in v1.2 and previous versions as they didn't support variable sized windows or vsync in windowed mode. Have you tried running RVGL in windowed mode?
MaLDo wrote:I want to note again that Kotaku 60fps gameplay footage has judder.
I can see some stuttering in the Kotaku video in 720p60 mode, but problem seems to be with the video (or YouTube's 60fps mode) because the stuttering doesn't exist when I'm running the actual game.

Going back to a post by Abc:
Abc wrote:the 1.2 update that tweaked vsync and high fps issues people were having also created some awkward limitation in fps, i can confirm that my fps was higher before the update and limited after.
Let's see, we added the fixes for stability at high fps in v1.2 Alpha 15.0325:

Code: Select all

---------------
 Alpha 15.0325
---------------

Mod [General]

    - Use a fixed timestep for the game management rather than depending 
      on the actual frame rate to improve the game stability (of the 
      lights, animations, etc.) in high fps (i.e., with vsync off).

Can you try v1.2 Alpha 15.0131? That was the last release before those stability fixes. You can download old builds from: http://rv12.revoltzone.net/oldbuilds.php
Direct link to 15.0131: rv1.2a15.0131_setup.exe

Keep in mind that these old v1.2 builds are not fully compatible with Windows 8 and 10 (they don't run properly in fullscreen). You might have to test it in windowed mode, or using Windows 7.
Just tested 15.0131. If updating over the last version is enough (executable changed to one from feb, 2015), this version doesn't fix the problem.

EDIT: Installed from scratch and applied 15.0131. Same problem.
Reply
Like

Huki
... as a Newt
Huki
... as a Newt
Joined: 30 Dec 2006, 16:01

31 Dec 2016, 21:33 #11

Try the last v1.2 Beta that was released in 2011:
rv1.2b11.0208.zip

If it still stutters, try the original v1.1 patch: Patch 1207
Note: If the 1207 patch crashes, use WolfR4 tool to launch it.

Both require windowed mode to run on Windows 8/10.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

01 Jan 2017, 01:38 #12

Huki @ 31 Dec 2016, 10:33 PM wrote: Try the last v1.2 Beta that was released in 2011:
rv1.2b11.0208.zip

If it still stutters, try the original v1.1 patch: Patch 1207
Note: If the 1207 patch crashes, use WolfR4 tool to launch it.

Both require windowed mode to run on Windows 8/10.
Original 1.1 stutters at 60 hz. I guess the game only works perfectly with rounded frametimes.

Tested every version with a 50 hz refreshrate and is fully smooth with 20 ms locked frametimes.

At least as smooth as 50 fps in 50 hz can be.

I think people that says don't have the judder iis only they are not sensitive enough.
Reply
Like

Abc
100% Proofer
Abc
100% Proofer
Joined: 07 Apr 2009, 18:43

02 Jan 2017, 07:40 #13

about flickering in youtube: their player is NOT reliable, if you really want to verify whatever the video has flickering or not, download the highest quality version (which is likely to be the original) and try again with a media player on your computer.
maybe you have a PAL display? (those are 50hz, 50fps)
Interesting!

Note: post 700th lol
Yes, I'm the ABC block and you can find me in Toy World 1 track! ;)
Reborn as Juest Zungo :P PS: I prefer chatting and i have Steam, Skype, Google and Microsoft account, just ask for it via PM or rarely find me in RVHouse. Also check out my interests.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

02 Jan 2017, 19:12 #14

Abc @ 2 Jan 2017, 08:40 AM wrote: about flickering in youtube: their player is NOT reliable, if you really want to verify whatever the video has flickering or not, download the highest quality version (which is likely to be the original) and try again with a media player on your computer.
maybe you have a PAL display? (those are 50hz, 50fps)
Interesting!
¿Flickering?

The judder is clearly visible in the kotaku footage and is the same judder I can see playing in my pc.

I can use 50 hz or 60 hz resolutions and that's how I can test it. Nvidia gpu custom resolution. Regular games don't judder at 60 hz / 60 fps.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

04 Jan 2017, 17:07 #15

Ok, I did a search in youtube for Re-Volt 60fps videos.

Examples
https://www.youtube.com/watch?v=rWsd997gLS4
https://www.youtube.com/watch?v=rSiVhZBQ168
https://www.youtube.com/watch?v=FTkUNrb4dZE

and every other footage you can found has the same framerate problems. Framerate is juddery and not smooth at all.

Random comparisson (I'm talking about the smoothness, not speed)

Smooth 60 fps
https://www.youtube.com/watch?v=OTvgIIP777o&t=29s

Juddery framerate
https://www.youtube.com/watch?v=rSiVhZBQ168&t=58s
Reply
Like

Abc
100% Proofer
Abc
100% Proofer
Joined: 07 Apr 2009, 18:43

04 Jan 2017, 17:38 #16

Again, why don't you verify them by downloading the highest quality and playing it on your media player in your computer instead?
Yes, I'm the ABC block and you can find me in Toy World 1 track! ;)
Reborn as Juest Zungo :P PS: I prefer chatting and i have Steam, Skype, Google and Microsoft account, just ask for it via PM or rarely find me in RVHouse. Also check out my interests.
Reply
Like

Huki
... as a Newt
Huki
... as a Newt
Joined: 30 Dec 2006, 16:01

05 Jan 2017, 07:36 #17

MaLDo @ 27 Dec 2016, 10:56 PM wrote:I did a few test with CheatEngine SpeedHack and found that the game currently renders 62.5 frames every second no matter the options I use. So, the only way to play RV 1.2 with smooth framerate is using SpeedHack at 0.96 that slowdowns the game a bit.
How can I check the framerate through CheatEngine? I mean, where did you get that 62.5 number?

During my initial days of playing Re-Volt, I noticed some stuttering when the camera rotated around the car after the race had finished. That's the only place I could sense stuttering, so today I decided to give this a try.

To get into the rotating camera mode, launch v1.2 / RVGL with the -dev command line (to access the Dev mode), then Start Race -> Edit Mode (None) -> start any level (preferably Toys in the Hood 1). Then, press Right Ctrl + F11 repeatedly until the camera starts rotating around the car. You should now be able to notice the stuttering (notice the white pillars before the house in front, the crane, the red barrier pole, etc. as they pass by). Setting the game speed to 0.96 through CE appears to fix the stuttering.

Can you confirm this?
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

05 Jan 2017, 09:24 #18

Abc @ 4 Jan 2017, 06:38 PM wrote: Again, why don't you verify them by downloading the highest quality and playing it on your media player in your computer instead?
I'm not talking about general video/compression problems but an specific and regular judder problem that is clearly visible in EVERY video of this game and which coincides with extreme accuracy to the problems I have when playing. Why do you insist in your argument?
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

05 Jan 2017, 09:32 #19

Huki @ 5 Jan 2017, 08:36 AM wrote:
MaLDo @ 27 Dec 2016, 10:56 PM wrote:I did a few test with CheatEngine SpeedHack and found that the game currently renders 62.5 frames every second no matter the options I use. So, the only way to play RV 1.2 with smooth framerate is using SpeedHack at 0.96 that slowdowns the game a bit.
How can I check the framerate through CheatEngine? I mean, where did you get that 62.5 number?

During my initial days of playing Re-Volt, I noticed some stuttering when the camera rotated around the car after the race had finished. That's the only place I could sense stuttering, so today I decided to give this a try.

To get into the rotating camera mode, launch v1.2 / RVGL with the -dev command line (to access the Dev mode), then Start Race -> Edit Mode (None) -> start any level (preferably Toys in the Hood 1). Then, press Right Ctrl + F11 repeatedly until the camera starts rotating around the car. You should now be able to notice the stuttering (notice the white pillars before the house in front, the crane, the red barrier pole, etc. as they pass by). Setting the game speed to 0.96 through CE appears to fix the stuttering.

Can you confirm this?
Great, I will try the rotating camera today.

Anyway, there are two reasons that explain why it could occur:

A large majority of people are more sensitive to judder in lateral (horizontal or vertical) camera movements than "inward" displacement. The area where the view focuses on a rotating camera is more like a horizontal travelling.

Also, a large majority of people are more sensitive to judder in non-interactive moments than gameplay moments. That's because while playing, people tend to pay attention to gameplay elements like opponents, turns a so on, and do not focus on framerate hiccups.

Combining those two reasons, I can understand how you only see the stuttering in a non-interactive rotating camera.

EDIT:

Doh! I miss this part "Setting the game speed to 0.96 through CE appears to fix the stuttering.
"

So you have tried with SpeedHack and it fixes de judder? This confirms that is a widespread problem that affects everyone. I hope can be fixable.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

05 Jan 2017, 12:39 #20

"To get into the rotating camera mode, launch v1.2 / RVGL with the -dev command line (to access the Dev mode), then Start Race -> Edit Mode (None) -> start any level (preferably Toys in the Hood 1). Then, press Right Ctrl + F11 repeatedly until the camera starts rotating around the car. You should now be able to notice the stuttering (notice the white pillars before the house in front, the crane, the red barrier pole, etc. as they pass by). Setting the game speed to 0.96 through CE appears to fix the stuttering.

Can you confirm this?"



Just tried and can confirm the stutter is pretty evident in rotating camera mode exactly the same as during races. So, there is judder in every situation.
Reply
Like

VaiDuX461
Methanolic
VaiDuX461
Methanolic
Joined: 02 Jul 2011, 16:02

05 Jan 2017, 13:18 #21

Stuttering does happen, and with CE Speedhack set to 0.96 does fix it.

I never really minded, so it was never reported. But I'm surprised, I've been here for over 5 years and it was never mentioned.
aka VaidX47, Vaid
--------------------
>[MediaFire Stuff]< | >[Steam Profile]<
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

05 Jan 2017, 13:44 #22

VaiDuX461 @ 5 Jan 2017, 02:18 PM wrote: Stuttering does happen, and with CE Speedhack set to 0.96 does fix it.

I never really minded, so it was never reported. But I'm surprised, I've been here for over 5 years and it was never mentioned.
Ok then. The surprising part is when people deny it.

I noted it the first second I start my first race. My current workaround is to use an autohotkey script that starts the game activating cheat engine and a playlist with windows media player so the slowdown does not affect the music. Obviously the tracks don't start at races start but play one after one.

I don't know if revolt gl devs have access to what causes this stuttering.
Reply
Like

Huki
... as a Newt
Huki
... as a Newt
Joined: 30 Dec 2006, 16:01

05 Jan 2017, 16:04 #23

MaLDo @ 5 Jan 2017, 07:14 PM wrote:Ok then. The surprising part is when people deny it.
I'm not surprised, because it's extremely hard to notice the stuttering during gameplay. But by keeping the camera static (press F6 twice in dev mode) and moving the car horizontally to and fro, I'm now able to notice it.

Re-Volt uses a fixed time step for the physics simulation, which is an integral multiple of 8 (milliseconds). i.e., if the framerate is 60 (16.667ms), the physics moves forward each frame at 16ms. The left over bit is accumulated over time, so it alternates between 16ms and 24ms for some frames. This causes the slight stuttering that we notice.
In v1.2 build 15.0325, we started using a fixed timestep even for non-physics animation code. You'll find this mentioned in the changelog that I had already quoted in a previous post.

Code: Select all

---------------
 Alpha 15.0325
---------------

Mod &#91;General&#93;

    - Use a fixed timestep for the game management rather than depending 
      on the actual frame rate to improve the game stability &#40;of the 
      lights, animations, etc.&#41; in high fps &#40;i.e., with vsync off&#41;.

There's an excellent article on fixed timesteps that describes precisely the same issue. The technique used by Re-Volt is described in the section Free the physics, the one before the last.
Notice that unlike the semi-fixed timestep we only ever integrate with steps sized dt so it follows that in the common case we have some unsimulated time left over at the end of each frame. This is important! This left over time is passed on to the next frame via the accumulator variable and is not thrown away.
But what do to with this remaining time? It seems incorrect somehow doesn’t it?

To understand what is going on consider a situation where the display framerate is 60fps and the physics is running at 50fps. There is no nice multiple so the accumulator causes the simulation to alternate between mostly taking one and occasionally two physics steps per-frame when the remainders “accumulate” above dt.

Now consider that in general all render frames will have some small remainder of frame time left in the accumulator that cannot be simulated because it is less than dt. What this means is that we’re displaying the state of the physics simulation at a time value slightly different from the render time. This causes a subtle but visually unpleasant stuttering of the physics simulation on the screen known as temporal aliasing.
Note that the original re-volt versions only used a fixed timestep for the physics, however the latest v1.2 (since 15.0325) and RVGL use fixed timestep even for non-physics animation, such as camera movements, so the stuttering is even more pronounced.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

05 Jan 2017, 16:10 #24

Huki @ 5 Jan 2017, 05:04 PM wrote:
MaLDo @ 5 Jan 2017, 07:14 PM wrote:Ok then. The surprising part is when people deny it.
I'm not surprised, because it's extremely hard to notice the stuttering during gameplay. But by keeping the camera static (press F6 twice in dev mode) and moving the car horizontally to and fro, I'm now able to notice it.

Re-Volt uses a fixed time step for the physics simulation, which is an integral multiple of 8 (milliseconds). i.e., if the framerate is 60 (16.667ms), the physics moves forward each frame at 16ms. The left over bit is accumulated over time, so it alternates between 16ms and 24ms for some frames. This causes the slight stuttering that we notice.
In v1.2 build 15.0325, we started using a fixed timestep even for non-physics animation code. You'll find this mentioned in the changelog that I had already quoted in a previous post.

Code: Select all

---------------
 Alpha 15.0325
---------------

Mod &#91;General&#93;

    - Use a fixed timestep for the game management rather than depending 
      on the actual frame rate to improve the game stability &#40;of the 
      lights, animations, etc.&#41; in high fps &#40;i.e., with vsync off&#41;.

There's an excellent article on fixed timesteps that describes precisely the same issue. The technique used by Re-Volt is described in the section Free the physics, the one before the last.
Notice that unlike the semi-fixed timestep we only ever integrate with steps sized dt so it follows that in the common case we have some unsimulated time left over at the end of each frame. This is important! This left over time is passed on to the next frame via the accumulator variable and is not thrown away.
But what do to with this remaining time? It seems incorrect somehow doesn’t it?

To understand what is going on consider a situation where the display framerate is 60fps and the physics is running at 50fps. There is no nice multiple so the accumulator causes the simulation to alternate between mostly taking one and occasionally two physics steps per-frame when the remainders “accumulate” above dt.

Now consider that in general all render frames will have some small remainder of frame time left in the accumulator that cannot be simulated because it is less than dt. What this means is that we’re displaying the state of the physics simulation at a time value slightly different from the render time. This causes a subtle but visually unpleasant stuttering of the physics simulation on the screen known as temporal aliasing.
Note that the original re-volt versions only used a fixed timestep for the physics, however the latest v1.2 (since 15.0325) and RVGL use fixed timestep even for non-physics animation, such as camera movements, so the stuttering is even more pronounced.
So I was right about a 16 ms frametime. Using fixed timestep is a big error in game development. Only a few japanase developers keep doing that nowadays.

And moving that limitation to the renderer and camera movement over the existent physics limitation is a big error too in my opinion.

Are there plans to fix this problem or is a situation where "better you don't see the judder because is intented"?

And sorry for being surprised by you are saying this:
Huki wrote:"I'm not surprised, because it's extremely hard to notice the stuttering during gameplay. [...] This causes the slight stuttering that we notice."
But your first message in the thread was this:

Huki wrote: Well, I've neither personally experienced nor received a report about any stuttering, so I'm really confused and curious.

[...]

I've run RVGL in Windows 10 32-bit on my main computer and Windows 10 64-bit on a newer AMD laptop, both have run really smoothly (both with vsync on and off).
Reply
Like

Huki
... as a Newt
Huki
... as a Newt
Joined: 30 Dec 2006, 16:01

05 Jan 2017, 18:36 #25

MaLDo @ 5 Jan 2017, 09:40 PM wrote: And sorry for being surprised by you are saying this:
Huki wrote:"I'm not surprised, because it's extremely hard to notice the stuttering during gameplay. [...] This causes the slight stuttering that we notice."
But your first message in the thread was this:

Huki wrote: Well, I've neither personally experienced nor received a report about any stuttering, so I'm really confused and curious.

[...]

I've run RVGL in Windows 10 32-bit on my main computer and Windows 10 64-bit on a newer AMD laptop, both have run really smoothly (both with vsync on and off).
I can only notice jitter when I specifically started looking for it, and by paying close attention to horizontal movements. That was today. Before your report, none of the dev team was aware of this jitter or the problems that could arise out of fixed timestep.

For us, fixed timestep was always the only proper choice (to keep the game stable at any framerate) and that's why we extended it to cover non-physics areas too. In hindsight it wasn't such a good idea, but I'm afraid it's either this or a hard limit on the frame rate and I don't like that. There are still a few options: a) change the fixed timestep to 60Hz, or b) use a dynamic fixed timestep based on display Hz (but this could change handling based on framerate, so not sure).

I've uploaded a modified RVGL test build that does not use fixed timestep. Run it with vsync on (at 60Hz) and it should fix the jitter. Then try it with vsync off and you should notice how high frame rate breaks the physics. Thus we can't use this fix, but it's interesting nevertheless to see smooth animation.
rvgl_jitter_test_win32.7z
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

05 Jan 2017, 20:30 #26

Huki @ 5 Jan 2017, 07:36 PM wrote:
MaLDo @ 5 Jan 2017, 09:40 PM wrote: And sorry for being surprised by you are saying this:
Huki wrote:"I'm not surprised, because it's extremely hard to notice the stuttering during gameplay. [...] This causes the slight stuttering that we notice."
But your first message in the thread was this:

Huki wrote: Well, I've neither personally experienced nor received a report about any stuttering, so I'm really confused and curious.

[...]

I've run RVGL in Windows 10 32-bit on my main computer and Windows 10 64-bit on a newer AMD laptop, both have run really smoothly (both with vsync on and off).
I can only notice jitter when I specifically started looking for it, and by paying close attention to horizontal movements. That was today. Before your report, none of the dev team was aware of this jitter or the problems that could arise out of fixed timestep.

For us, fixed timestep was always the only proper choice (to keep the game stable at any framerate) and that's why we extended it to cover non-physics areas too. In hindsight it wasn't such a good idea, but I'm afraid it's either this or a hard limit on the frame rate and I don't like that. There are still a few options: a) change the fixed timestep to 60Hz, or B) use a dynamic fixed timestep based on display Hz (but this could change handling based on framerate, so not sure).

I've uploaded a modified RVGL test build that does not use fixed timestep. Run it with vsync on (at 60Hz) and it should fix the jitter. Then try it with vsync off and you should notice how high frame rate breaks the physics. Thus we can't use this fix, but it's interesting nevertheless to see smooth animation.
rvgl_jitter_test_win32.7z
Man, you're a god send. Smooth as butter and way more enjoyable experience. Maybe you can link this new timestep to a forced frame limit to avoid physics problems because this is night and day compared with the regular version.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

06 Jan 2017, 18:45 #27

MaLDo @ 5 Jan 2017, 09:30 PM wrote: Man, you're a god send. Smooth as butter and way more enjoyable experience. Maybe you can link this new timestep to a forced frame limit to avoid physics problems because this is night and day compared with the regular version.
Sorry, false alarm. The track Supermarket 2 crashes to a gray screen after the automatic door. A long number appears in the lower right corner, I don't know if it's something.
Reply
Like

Abc
100% Proofer
Abc
100% Proofer
Joined: 07 Apr 2009, 18:43

06 Jan 2017, 20:10 #28

that's exactly why fixed timestamps are used....
as he said, physics breaks, so does the engine
hmm, i recall being told the engine runs at 125fps?
maybe limiting fps to that might help? is there a way maybe we could limit the game without adding judder/stuttering while not bending the game engine?
Yes, I'm the ABC block and you can find me in Toy World 1 track! ;)
Reborn as Juest Zungo :P PS: I prefer chatting and i have Steam, Skype, Google and Microsoft account, just ask for it via PM or rarely find me in RVHouse. Also check out my interests.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

06 Jan 2017, 20:52 #29

Abc @ 6 Jan 2017, 09:10 PM wrote: that's exactly why fixed timestamps are used....
as he said, physics breaks, so does the engine
hmm, i recall being told the engine runs at 125fps?
maybe limiting fps to that might help? is there a way maybe we could limit the game without adding judder/stuttering while not bending the game engine?

The new exe with 60 fps timesteps doesn't break the physics at 60 fps, I'm talking about the screen going to grey/blue color with a number in the corner. The number is -214748364. The moment the screen goes blue, the framerate tanks to 1 fps. Using ESC key to go to menu and framerate changes to 20 fps. Quiting the race and going to main menu fixes the problem.

Messing with options trying to find a workaround, the problem is linked to texture filtering. I know, really strange. Using "Point" texture filtering, the Supermarket 2 race doesn't "crash". Using "Bilinear" filtering, it crashes.
Reply
Like

Huki
... as a Newt
Huki
... as a Newt
Joined: 30 Dec 2006, 16:01

06 Jan 2017, 21:25 #30

MaLDo @ 7 Jan 2017, 02:22 AM wrote: The new exe with 60 fps timesteps doesn't break the physics at 60 fps, I'm talking about the screen going to grey/blue color with a number in the corner. The number is -214748364. The moment the screen goes blue, the framerate tanks to 1 fps.
This means there is an NaN value that originated somewhere (because of a divide-by-zero) and it's leaking through to other parts of the code. It's probably just a coincidence that changing unrelated options like texture filtering appears to "hide" it.
I'm going to take a look at it...

EDIT: The bug is reproduced by letting the car scrape along the moving door. It occurs even when texture filter is set to "Point". You probably didn't touch the automatic door when it didn't crash.

Oh, and the new exe has variable timestep - it's not fixed at 60fps. Basically, it still computes the physics in chunks of 8ms, but any left-over part of the timestep is computed immediately in an additional loop instead of getting accumulated for the next frame.
Abc @ 7 Jan 2017, 01:40 AM wrote:hmm, i recall being told the engine runs at 125fps?
That's correct, the engine runs at 125fps while rendering is done at 60fps, this results in the temporal aliasing we're talking about.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

06 Jan 2017, 22:24 #31

Huki @ 6 Jan 2017, 10:25 PM wrote:
MaLDo @ 7 Jan 2017, 02:22 AM wrote: The new exe with 60 fps timesteps doesn't break the physics at 60 fps, I'm talking about the screen going to grey/blue color with a number in the corner. The number is -214748364. The moment the screen goes blue, the framerate tanks to 1 fps.
This means there is an NaN value that originated somewhere (because of a divide-by-zero) and it's leaking through to other parts of the code. It's probably just a coincidence that changing unrelated options like texture filtering appears to "hide" it.
I'm going to take a look at it...

EDIT: The bug is reproduced by letting the car scrape along the moving door. It occurs even when texture filter is set to "Point". You probably didn't touch the automatic door when it didn't crash.

Oh, and the new exe has variable timestep - it's not fixed at 60fps. Basically, it still computes the physics in chunks of 8ms, but any left-over part of the timestep is computed immediately in an additional loop instead of getting accumulated for the next frame.
Abc @ 7 Jan 2017, 01:40 AM wrote:hmm, i recall being told the engine runs at 125fps?
That's correct, the engine runs at 125fps while rendering is done at 60fps, this results in the temporal aliasing we're talking about.
Wow, you're right, is the door. But I'm not touching the door so maybe are the cars behind me that triggered the bug instead. I reproduced the bug using Bilinear filtering and avoid the bug in Point filtering SEVEN times. I thought was a high enough number to generate a relationship but it seems I was wrong! O_o
Reply
Like

Abc
100% Proofer
Abc
100% Proofer
Joined: 07 Apr 2009, 18:43

07 Jan 2017, 19:16 #32

the number in the corner is a negative 32 bits value, it means something is overflowing.
gray/blue? sounds like the level fog/sky.
Could you try without AI just to see if its really the door?

Huki: would F9 readings help in anything? Should i attach a debugger?

PS: apologies for late reply
Yes, I'm the ABC block and you can find me in Toy World 1 track! ;)
Reborn as Juest Zungo :P PS: I prefer chatting and i have Steam, Skype, Google and Microsoft account, just ask for it via PM or rarely find me in RVHouse. Also check out my interests.
Reply
Like

Huki
... as a Newt
Huki
... as a Newt
Joined: 30 Dec 2006, 16:01

07 Jan 2017, 22:00 #33

MaLDo @ 7 Jan 2017, 03:54 AM wrote:Wow, you're right, is the door. But I'm not touching the door so maybe are the cars behind me that triggered the bug instead. I reproduced the bug using Bilinear filtering and avoid the bug in Point filtering SEVEN times. I thought was a high enough number to generate a relationship but it seems I was wrong! O_o
Ok, I fixed it. As I suspected, it was a divide by zero in the sliding door code, which happened when the left over (variable) part of the timestep became zero. I fixed the slider code, and also updated the physics so the extra loop won't be run with a zero timestep.
Download the updated build: rvgl_jitter_test2_win32.7z

Btw, I made another change to ensure the physics is not broken at really high fps. Now, we accumulate the timestep until there is at least one complete physics loop (8ms + some left over) to run. This basically restricts the physics framerate without having to restrict the display framerate.

However, there is definitely a change in handling with semi-fixed timestep. I tested in Calc Car Stats mode and cars have a slightly increased top speed and increased acceleration time.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

08 Jan 2017, 00:58 #34

Huki @ 7 Jan 2017, 11:00 PM wrote:
MaLDo @ 7 Jan 2017, 03:54 AM wrote:Wow, you're right, is the door. But I'm not touching the door so maybe are the cars behind me that triggered the bug instead. I reproduced the bug using Bilinear filtering and avoid the bug in Point filtering SEVEN times. I thought was a high enough number to generate a relationship but it seems I was wrong! O_o
Ok, I fixed it. As I suspected, it was a divide by zero in the sliding door code, which happened when the left over (variable) part of the timestep became zero. I fixed the slider code, and also updated the physics so the extra loop won't be run with a zero timestep.
Download the updated build: rvgl_jitter_test2_win32.7z

Btw, I made another change to ensure the physics is not broken at really high fps. Now, we accumulate the timestep until there is at least one complete physics loop (8ms + some left over) to run. This basically restricts the physics framerate without having to restrict the display framerate.

However, there is definitely a change in handling with semi-fixed timestep. I tested in Calc Car Stats mode and cars have a slightly increased top speed and increased acceleration time.
Fixed, you're on fire. Maybe the handling is a little bit more crazy (it's not really noticeable for me) but overall is fine imo.

Testing both versions against RV 1.2 in Supermarket 2 track, I noted something. The blue detergent bottles and some boxes are not visible in RVGL. Is it a known bug?

Those bottles and boxes in the shelves for example


RVGL (sorry the bad mobile quality, fraps doesn't work with this version)
Reply
Like

Abc
100% Proofer
Abc
100% Proofer
Joined: 07 Apr 2009, 18:43

08 Jan 2017, 04:57 #35

Are you sure you have Instances enabled?

also you can take screenshots with rvgl directly..... iirc
Yes, I'm the ABC block and you can find me in Toy World 1 track! ;)
Reborn as Juest Zungo :P PS: I prefer chatting and i have Steam, Skype, Google and Microsoft account, just ask for it via PM or rarely find me in RVHouse. Also check out my interests.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

08 Jan 2017, 10:21 #36

Abc @ 8 Jan 2017, 05:57 AM wrote: Are you sure you have Instances enabled?

also you can take screenshots with rvgl directly..... iirc
Thank you Abc, that was the problem. In the spanish translation that options is like "example models" and I had it disabled. Sorry for the confusion.

Instance in spanish has two translations, "Instancia" and "ejemplo". "Ejemplo" is used in the sentence "by instance" translated as "por ejemplo". But "Instance models" have to be "Modelos instanciados".
Reply
Like

Abc
100% Proofer
Abc
100% Proofer
Joined: 07 Apr 2009, 18:43

08 Jan 2017, 19:35 #37

ah si, por esto te conviene usar el idioma ingles... es un poco confuso el de español :)
Yes, I'm the ABC block and you can find me in Toy World 1 track! ;)
Reborn as Juest Zungo :P PS: I prefer chatting and i have Steam, Skype, Google and Microsoft account, just ask for it via PM or rarely find me in RVHouse. Also check out my interests.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

09 Jan 2017, 11:57 #38

Abc @ 8 Jan 2017, 08:35 PM wrote: ah si, por esto te conviene usar el idioma ingles... es un poco confuso el de español :)
;)

[Vaid]: Avoid posting incredibly short messages next time. This is not a chatroom.
Thanks.
Reply
Like

Huki
... as a Newt
Huki
... as a Newt
Joined: 30 Dec 2006, 16:01

16 Jan 2017, 16:46 #39

MaLDo @ 8 Jan 2017, 03:51 PM wrote: Instance in spanish has two translations, "Instancia" and "ejemplo". "Ejemplo" is used in the sentence "by instance" translated as "por ejemplo". But "Instance models" have to be "Modelos instanciados".
Just to inform that I have updated the Spanish translation with your suggestion in the latest release.

As for the stuttering issue, cameras and animation now use variable timestep, but physics is still locked at 8ms. I think it's a good compromise for now. If it bothers you too much though, feel free to use the test build I had posted.
Reply
Like

MaLDo
Regular
MaLDo
Regular
Joined: 27 Dec 2016, 17:25

20 Jan 2017, 08:39 #40

Huki @ 16 Jan 2017, 05:46 PM wrote:
MaLDo @ 8 Jan 2017, 03:51 PM wrote: Instance in spanish has two translations, "Instancia" and "ejemplo". "Ejemplo" is used in the sentence "by instance" translated as "por ejemplo". But "Instance models" have to be "Modelos instanciados".
Just to inform that I have updated the Spanish translation with your suggestion in the latest release.

As for the stuttering issue, cameras and animation now use variable timestep, but physics is still locked at 8ms. I think it's a good compromise for now. If it bothers you too much though, feel free to use the test build I had posted.
Your support is way beyond what we can found for paid games.

Thank you very much.
Reply
Like

Eliasvan
Sober
Joined: 20 May 2017, 20:34

21 May 2017, 06:46 #41

Huki @ 16 Jan 2017, 05:46 PM wrote:As for the stuttering issue, cameras and animation now use variable timestep, but physics is still locked at 8ms. I think it's a good compromise for now. If it bothers you too much though, feel free to use the test build I had posted.
Both the new version and your jitter test build have problems:

- The new version suffers from aliasing, each 25 physics steps, a delta of three physics steps is drawn, instead of two, causing stuttering:

See also a video visualization of the problem @ 1000fps in this post:
[RVGL] No interpolation between physics states

- The test build you had posted uses a variable (= fixed 8ms + variable) timestep, which is not advised (that's why you're getting other results in Calc Car Stats mode).

The solution to both problems is mentioned in the last section of your previously posted link:
"The final touch"
You should simply (linearly) interpolate between physics states!
Reply
Like

RaydenX
Regular
RaydenX
Regular
Joined: 11 Jun 2010, 06:45

21 May 2017, 08:53 #42

All of this is extremely fascinating :o
Keep up the good work guys! :thumbs-up:
Reply
Like