V-Sync and Animation Smoothness Test

[another_commander]

There have been some discussions time and again regarding cases of micro-stutters occurring in Oolite. Micro-stutters do seem to occur quite a bit, although there have also been cases (I can personally confirm at least two of them) where animation is completely fluid and butter-smooth overall. The last such discussion was this one started by Zieman. The discussion hinted at the possibility of two reasons for stuttering. One was the possibility of the game having to wait for textures to be loaded to graphics memory when requested or similar operations that work on threads other than the main one, but could result in the entire game having to wait until they are completed. There could be ways around it, but this type of delay is not the one I would like to discuss here.

The second stutter type seemed to be a graphics card / driver combination type of issue. These micro-stutters are more frequent and could result in what appears to be a not perfectly smooth motion, even though the FPS are high to very high and theoretically motion should be totally seamless and fluid.

I would like to kindly ask anyone using Windows and testing nightlies to try the 64-bit executable located here: https://drive.google.com/file/d/0BwG6R5 ... sp=sharing

Just drop it in oolite.app and run it. Then let us know if this exe seems to make things run more smoothly and gives you an overall feeling that the game runs better. Some stutter will still occur as per above commentary, but I would be interested to know your overall impression.

The test executable is based on the current trunk and corresponds to revision 42ab20b, posted on github today. You need to have a trunk install to run it; don't drop this inside a 1.80 installation as there are no guarantees that it will work as expected.

What it does: Upon running it, this executable will query Windows for the current display refresh rate. Then it will adjust the game's animation timer interval internally so that the maximum FPS produced will coincide with that refresh rate. Effectively, it bypasses SDL's v-sync settings and creates a v-sync state of its own. First results on my Intel HD and on one NVidia family card have been encouraging, so I would like to hear what you think too. If this is indeed an improvement, we may be seeing it soon in the trunk. So, please test and get back to us with your feedback.

Thanks for your help.

[Cody]

Ahh... interesting. I'll be running that tomorrow, after I've fitted new case fans.

[Thargoid]

Unless this is going to be a longer-term test, I may need to sit this one out. Just had to nuke from orbit my Windows installation on my netbook to resolve the wifi connection issue (and also try unsuccessfully to upgrade the wifi card to an Intel 802.11ac one, which is now instead on a fast-transfer back to it's Amazon supplier).

So I'm now ploughing through the first wave of Windows updates (154 of the damn things in this first batch, no doubt with many more to come to update those) and it'll be a while before I can even think of rebuilding enough to get my build environment back.

If I do make progress tonight and tomorrow I'll chip in and grab it, but chances are not good, especially as I'm travelling basically for the next month continuously.

[Zireael]

I won't have access to Oolite for a week, so unless you can wait longer, I'll sit this one out too.

[another_commander]

No worries guys, it's not an urgent thing. You can do it if and when you get the time.

[Cody]

The test executable is based on the current trunk and corresponds to revision 42ab20b, posted on github today.

Just checking - will this morning's nightly serve, or must it be revision 42ab20b or later? I presume the former?

[another_commander]

Next upcoming nightly should be fine. Even the binaries currently on terrastorage should be OK, as I think the resources are for the most part unchanged.

[Cody]

Even the binaries currently on terrastorage should be OK, as I think the resources are for the most part unchanged.

<nods> That being the case, I've just spent an hour or so out there (from which my overheated machine is now slowly cooling), and my first impression is this. I emphasise, that is only a first impression - I'll hammer it tomorrow night once the new case fans are in, but it's looking good so far. There is still a very occasional minor stutter, but that almost rhythmic stutter of before seems to have gone. <grins> More tomorrow, Admiral!

[Getafix]

@another_commander
Considering that I have prepared the Linux equivalent,
could you, please, move this thread under "Testing and Bug reports"?

I would like to give away a Linux oolite binary for anyone willing to test, and
my chances to find someone are getting even lower in this forum.

[another_commander]

Aye aye sir! Topic moved to Testing and Bug Reports.

[Getafix]

@a_c: Thank you commander.

I would really appreciate if anyone using a Linux 64bit distro and testing Linux nightlies would like to try the 64-bit executable located here:
I would really appreciate if anyone using/testing Linux nightly builds, would like to try any of the executables shared below:
Linux x86-64: https://drive.google.com/file/d/0B__DrF ... sp=sharing
Linux x86: https://drive.google.com/file/d/0B__DrF ... sp=sharing
(I will prepare a 32-bit executable if it is needed; just ask it here and I will provide a link)

I quote a_c, updating where necessary for Linux...

Just uncompress and untar the "oolite" executable and then drop it in oolite.app and then execute oolite-trunk as usual. run it. Then let us know if this exe seems to make things run more smoothly and gives you an overall feeling that the game runs better. Some stutter will still occur as per above commentary, but I would be interested to know your overall impression.

The test executable is based on the master trunk revision b1ac90d.and corresponds to revision 42ab20b, posted on github today. You need to have a trunk install to run it; don't drop this inside a 1.80 installation as there are no guarantees that it will work as expected.

What it does: Upon running it, this executable will query Windows Linux for the current display refresh rate. Then it will adjust the game's animation timer interval internally so that the maximum FPS produced will coincide with that refresh rate. Effectively, it bypasses SDL's v-sync settings and creates a v-sync state of its own. First results on my Intel HD and on one NVidia family card have been encouraging, so I would like to hear what you think too. If this is indeed an improvement, we may be seeing it soon in the trunk. So, please test and get back to us with your feedback.

Thanks for your help.


EDIT 2014.08.17:
Shared Linux x86 (i.e. 32bit) executable for V-Sync test.

[Cody]

Still only able to do shortish runs, but this is definitely an improvement - even the BGS hyperspace effect is smoother.

Only problem being, I cannot go back to 1.80 Deployment now - I'm stuck with that damn watermarked trunk again!

[Getafix]

@Cody:
Just let me know which 1.80 Oolite executable you need (Linux/Windows 32/64-bit) and I'll PM you a link for the executable only.

Can you tell me what did you do to test this v-sync?
It will help me understand how is the 1.80 Deployment corrupted and help you fix it.

In the meantime, if you are on Linux, you could try executing oolite-update. This will restore whatever is broken from an 1.80 Deployment installation (unless oolite-update is lost or somehow corrupted too).

[Cody]

Just let me know which 1.80 Oolite executable you need (Linux/Windows 32/64-bit) and I'll PM you a link for the executable only.

Apologies, amigo - perhaps I was misleading. I can run Oolite 1.80 Deployment okay, but how can I use it now that the V-Sync test version has rid the game of most of its stutter? I was kinda looking forward to a few weeks simply playing 1.80, and not testing trunk - but it seems that the Admiralty has tricked me back into service!

[Getafix]

Let me be even more thick.
So, when you said that you are stuck with that damned watermarked trunk again, it was because you liked it and not because you had actually broken your 1.80 Deployment installation, right?