Author Topic: Moebius 2.0 has broken Vsync - please fix  (Read 11021 times)

Offline MarkoH01

  • Silly Adventurer
  • **
  • Posts: 57
  • Silver Lining Forever!
Re: Moebius 2.0 has broken Vsync - please fix
« Reply #20 on: July 06, 2016, 12:23:18 PM »
I am pretty sure the reason fpr this whole is a mixture of newer Unity versions and actual Nvidia divers. I just opened a Unity account so I could talk to them and in the forum. Unfortunately the only way to file a bug report is as a developer. Fun thing this:

http://answers.unity3d.com/questions/950989/screen-tearing-on-windowed-mode-with-vsync-on.html

Sounds pretty familiar and the "solution" also does. It's also interesting that the GPU mentioned seems to be nearly the same as mine (GTX960). I am planning to post a new topic in their Unity answers section (because obviously there IS no real support section). Could you please tell me which version of Unity was used to make Moebius 2.0? This was the first version of the game with this issue and I want to tell the version in their forum. Since more and more Unity games are getting released I have to switch aero on every time I play one of them which is a bit annoying. Obviously this is NOT your fault but the fault of the engine you are using. But I wanted to keep you informed you because you tried to help me for such a long time - which btw is very much appreciated :)

Offline Oldbushie

  • Administrator
  • Phoenix Groupie
  • *****
  • Posts: 7488
  • Gender: Other
  • Mmmm... rich creamery butter...
    • Aerobush Entertainment
Re: Moebius 2.0 has broken Vsync - please fix
« Reply #21 on: July 06, 2016, 12:44:57 PM »
I'm not 100% sure which version we used back then, probably Unity 4.6.0 or Unity 4.6.1. The latest version we recently pushed was built with Unity 4.7.1. The original release of the game likely used Unity 4.3.4.
.......... <3 Oldbushie <3 ..........
Forum Emoticon God
Master of Time and Space
Aerobush of the Jarada Knights
TSL Programmer
and...
The TSL Candyman




Hero Of The Queene!

Offline MarkoH01

  • Silly Adventurer
  • **
  • Posts: 57
  • Silver Lining Forever!
Re: Moebius 2.0 has broken Vsync - please fix
« Reply #22 on: July 07, 2016, 11:06:15 AM »
I'm not 100% sure which version we used back then, probably Unity 4.6.0 or Unity 4.6.1. The latest version we recently pushed was built with Unity 4.7.1. The original release of the game likely used Unity 4.3.4.

Thank you for your quick reply and the information.

Offline MarkoH01

  • Silly Adventurer
  • **
  • Posts: 57
  • Silver Lining Forever!
Re: Moebius 2.0 has broken Vsync - please fix
« Reply #23 on: July 14, 2016, 01:33:40 PM »
Moebius is still on Unity 4, so it's not a Unity 5 specific thing. We did fix GK at least to use the native video plugin for desktop, so I'm surprised cutscenes would still be tearing on the latest update (2.01) for you.

I have now also posted my "problem" in the nvidia forum and got some interesting answers that MAY help to shed a bit light on this:

"Most Unity games don't run in a true fullscreen - only a borderless window with the same dimensions as your desktop. As a result, like any other Windowed game, if you have disabled Aero (which is pointless on any system that actually meets the requirements for a Unity game) than you've also disabled the ability to use V-sync at all."

I then answered that you told me that you did not experience the issue even without aero and it was replied:

"It's odd that they couldn't reproduce it, though. This has been the case with Aero and windowed software since Aero was introduced with XP. I can only figure that their internal build is running in a true fullscreen mode where the release code isn't, as is likely to be happening with older Unity games."

The user also suggested a tool (of which I haven't heard of until now):
"As a potential work-around, maybe try GeDoSaTo and use it to force a true fullscreen mode. Assuming, of course, it's DX9 (it's not DX11-only since it still supports XP) - I don't know if GeDoSaTo supports OpenGL or not. "

What do you say, could this be the problem - not real fullscreen but borderless window in newer unity games?

Offline Oldbushie

  • Administrator
  • Phoenix Groupie
  • *****
  • Posts: 7488
  • Gender: Other
  • Mmmm... rich creamery butter...
    • Aerobush Entertainment
Re: Moebius 2.0 has broken Vsync - please fix
« Reply #24 on: July 14, 2016, 03:22:19 PM »
There IS a setting in Unity where you can pick between Fullscreen Window and Exclusive Mode. I suspect the latter is more likely to be "true fullscreen". The one big catch I'm reading is that exclusive mode is more likely to crash when alt-tabbing.

https://docs.unity3d.com/Manual/CommandLineArguments.html

In the Unity Standalone Player command line arguments section, try:
-window-mode exclusive
.......... <3 Oldbushie <3 ..........
Forum Emoticon God
Master of Time and Space
Aerobush of the Jarada Knights
TSL Programmer
and...
The TSL Candyman




Hero Of The Queene!

Offline MarkoH01

  • Silly Adventurer
  • **
  • Posts: 57
  • Silver Lining Forever!
Re: Moebius 2.0 has broken Vsync - please fix
« Reply #25 on: July 15, 2016, 12:02:11 PM »
There IS a setting in Unity where you can pick between Fullscreen Window and Exclusive Mode. I suspect the latter is more likely to be "true fullscreen". The one big catch I'm reading is that exclusive mode is more likely to crash when alt-tabbing.

https://docs.unity3d.com/Manual/CommandLineArguments.html

In the Unity Standalone Player command line arguments section, try:
-window-mode exclusive

If you meant starting the executable with the shown parameters like
\Moebius\Moebius.exe -window-mode exclusive
I just did this and it did not help. I may try some of the other graphic options and will tell you if I should find one that helps. I cannot tell you how much I appreciate it that you are taking so much time to help me here :)

Offline MarkoH01

  • Silly Adventurer
  • **
  • Posts: 57
  • Silver Lining Forever!
Re: Moebius 2.0 has broken Vsync - please fix
« Reply #26 on: July 22, 2016, 08:02:37 AM »
Not really helping but interesting reply in the Uity forum regarding the issue:

Normally, I would agree that forcing the user to activate a feature of the OS shouldn't be a solution, but in the case of Aero, that's actually one of the rare exceptions. The problem isn't with Unity, but with the OS Windows itself since Aero was added to it back at Windows XP. To put it bluntly, Microsoft did a BIG blunder when they developed Aero... They put some of the essential parts of Windows' display system directly within the Aero plugin itself. For example, without Aero, Windows XP or later OS's display drivers are unable to render opacity on any frames.

The best way to describe the problem is that, when Aero is turned off, Windows is unable to use the GPU anymore to render its frame-related content and relies solely on the CPU. It wouldn't be a problem if it was ending there, but here comes the next problem... What happens if you have a screen that has a part that is rendered solely with the CPU and one that is rendering with either the GPU or a mix of CPU and GPU? Ping-pong! The dominating software render both in row and not at the same time! The screen-tearing that comes around when you try the game in windowed mode without Aero is caused by the fact that Windows let the applications render their frame, then render the "outer" frame (rest of the screen) through the CPU... and through that comes the possibility that the second rendering produce a screen-tearing.

If you still don't get it, another more simplistic way of explaining it is this : 1) You turn off Aero. Now Windows is unable to use the GPU to render any frame and solely relies on the CPU. 2) You run an application in Windows mode. 3) Windows can't do its own rendering with the GPU, but the application (which has priority) can so Windows wait for the application to finish rendering its frame. 4) Then Windows take the rendered frame save it into its memory bandwidth. 5) Windows renders its own frames through the CPU (which exclude any application that runs on the GPU). 6) Windows fuse both the GPU rendered frame with the CPU rendered frame. 7) Sometimes, when Windows fuse both frames, it does a sloppy job (like any software running purely on CPU) and a screen-tearing appears with the positioning of the memorized GPU-based frame being 1 or half a pixel off.

The reason why it only appears in newer Unity version is because of a change in how the software is handled CPU-wise... which without Areo also affect how much memory bandwidth Windows can handle for rendering its content.
 

anything