WinUAE 2.4.1 beta series

[Retro-Nerd]

Your PC is strange. There is no changes that could cause this.

Really weird. I even did a reboot a checked it twice again.

[Toni Wilen]

Try just updated winuae.zip . I forgot to uncomment one line of code that is related to non-fastest possible vsync, but not sure if it have any effect..

[Retro-Nerd]

Yep, works again.

[Toni Wilen]

And to 100% confirm it isn't caused by optimization settings: does winuae.zip still work? (winuae.exe = 7 955 968 bytes)

[Retro-Nerd]

winuae.exe = 7 955 968 bytes

Huh? This was Beta 14, the smaller WinUAE.zip is 7.741.995 bytes.

[Toni Wilen]

Originally Posted by Retro-Nerd

Huh? This was Beta 14, the smaller WinUAE.zip is 7.741.995 bytes.

winuae.zip isn't beta 14, but size is still the same.

[Retro-Nerd]

You confuse me. Have you uploaded the old winuae.zip again?

Beta 14 = 7.995.968 bytes
your latest winuae.zip = 7.741.952 bytes

Edit: Aah, now you uploaded the correct file.

Anyway, now the tearing is also back in both (the new and the old winuae.zip) updates from today, with activated Native on-screen display. I give it up for now. This is really too weird for me.

[Toni Wilen]

Originally Posted by Retro-Nerd

Anyway, now the tearing is also back in both (the new and the old winuae.zip) updates from today, with activated Native on-screen display. I give it up for now. This is really too weird for me.

Did you wait at least 1 minute to see if there are any changes?

[Retro-Nerd]

2-3 minutes Superfrog (very fast scrolling) should be enough. The tearing shows up instantly and doesn't go away. Without Native one-screen display everything's still fine, tested this today for more than 10 minutes.

[Toni Wilen]

winuae.zip updated once more. non fastest possible CPU + low latency vsync dynamic adjustment didn't really work, wrong variable used

Not sure if this helps but I think it at least makes the tearing permanent or removes it completely

[Retro-Nerd]

It seems completely unstable. Sometime i get tearing in cycle exact+Native on-screen display and sometimes in fastest possible mode. I can't really tell what it makes working sometimes, besides NOT to use the Native on-screen display atm. At least the FPS counter shows constantly 50 FPS in fastest possible mode.

[Mequa]

Originally Posted by Toni Wilen

winuae.zip updated once more. non fastest possible CPU + low latency vsync dynamic adjustment didn't really work, wrong variable used

Not sure if this helps but I think it at least makes the tearing permanent or removes it completely

Latest winuae.zip now adds tearing on my machine (fastest possible JIT + no buffer Vsync fullscreen) not found in beta 14...

[Toni Wilen]

winuae.zip updated yet again, I think 1-2 days to go.

Originally Posted by Mequa

Latest winuae.zip now adds tearing on my machine (fastest possible JIT + no buffer Vsync fullscreen) not found in beta 14...

"It is normal", working or not is accidental, not a feature or a bug

It seems some display drivers return immediately when page flipping is asked, even if it actually happens in background after few milliseconds delay (ignoring also D3DGETDATA_FLUSH). It makes automatic adjustment impossible.

Above winuae.zip uses another method, perhaps it works better.. or worse.

[Retro-Nerd]

Above winuae.zip uses another method, perhaps it works better.. or worse.

First it seems to work, for maybe 40-60 seconds (FPS is stable). Then the stuttering and tearing is back (jumpy FPS counter).

[Toni Wilen]

Originally Posted by Retro-Nerd

First it seems to work, for maybe 40-60 seconds (FPS is stable). Then the stuttering and tearing is back (jumpy FPS counter).

Ok, only force flush gpu in fastest possible modes, forcing it in non-fastest would cause missed frames too easily, fastest possible modes won't miss that easily because it uses background thread.

Missed frame is much much worse than tearing.

[Retro-Nerd]

You are right. Just tested it with fastest possible and it stays stable for longer than 5 minutes, even with JIT and the Native on-screen display.

[Mequa]

Originally Posted by Toni Wilen

"It is normal", working or not is accidental, not a feature or a bug

It seems some display drivers return immediately when page flipping is asked, even if it actually happens in background after few milliseconds delay (ignoring also D3DGETDATA_FLUSH). It makes automatic adjustment impossible.

Above winuae.zip uses another method, perhaps it works better.. or worse.

Still the same tearing on my machine. Beta 14 worked flawlessly and still does.

On latest winuae.zip (fastest possible no buffer vsync) I get tearing at the top of the screen with vertical scrollers, and tearing in horizontal bands at various positions of the display with fullscreen animated games (such as Super Stardust tunnel demo).

Not sure what could have broke it since beta 14.

[Toni Wilen]

Official 2.4.1 will be released next (tomorrow, maybe), no-buffer not fully working is still considered "normal"..

But vsync debugging will continue in next beta series, with bigger updates, I didn't want to do anything else than minor tweaks to prevent stupid last minute bugs.

[Mequa]

Toni, I just tried beta 14 and the very latest winuae.zip on my Core2Duo 2GHz laptop (with nVidia GeForce Go 7600). Exactly the same results as on my desktop - no tearing in beta 14, tearing in winuae.zip.

But here's the issue:

Beta 14: (RC3) I think vsync updates are finally done now.

Since vsync changes since beta 14 seem to introduce "stupid last minute bugs", will you be using beta 14 no-buffer vsync code for official 2.4.1? I'm not saying that you need to do more "twiddling" before release, more that beta 14 seems to have largely 'nailed it' (at least on both systems I tested it on) - it's the changes since beta 14 (whatever they were) which seem to cause problems ("last minute bugs") - on more than one system I've tested them on.


Edit: Can anyone else reproduce this difference between beta 14 and latest winuae.zip? (Particularly with nVidia GPU.)


Edit: Logs included from both versions running on my desktop. (Last winuae.zip used was dated modified 8/5/12 16:13:22, size 7,741,952 bytes.)

[Toni Wilen]

Originally Posted by Mequa

more that beta 14 seems to have largely 'nailed'

It didn't. I had tearing until this latest update. Both laptop and desktop.

Actually b14 had a stupid bug that can cause jitters in other modes but it can also appear to improve tearing situation if cpu and display driver speeds are just right. Tearing is much better than missed frames!

Current solution is broken (Most likely it is impossible to have 100% tear-free no-buffer fastest possible CPU solution). Currently it is only accidental if it works on some systems.

Anyway, most users are not going to use it and those that use usually also use latest beta anyway..

Probably should not have left vsync fixes for 2.4.2 or something, 2.4.1 was supposed to be stupid bug fix release only