Our ReVolt Pub

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

Touriga wrote:I would say windows 10 is the problem.

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

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.

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

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.

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

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.

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.

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!

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.

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?

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?

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.

MaLDo @ 5 Jan 2017, 07:14 PM wrote:Ok then. The surprising part is when people deny it.

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

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.

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 [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).

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.

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

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

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

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

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.

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?

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.

Abc @ 7 Jan 2017, 01:40 AM wrote:hmm, i recall being told the engine runs at 125fps?

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.

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

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.

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

also you can take screenshots with rvgl directly..... iirc

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

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

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.

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.