WinUAE 2.3.3 beta series

[Toni Wilen]

Originally Posted by lordofchaos

Latest Beta (2330b3) seems to be working like a charm for me, one hour of playing Turrican and not a single tear or jitter, fantastic work Toni! Oh and still just as responsive as before :-) Ooops!

You forgot to test input latency, Turrican is not that "fast" game

Bad news is that the tear/jitter still happens in this new beta in both DD and D3D with the new v-sync (top portion of the screen effected), I`m using fullscreen 50Hz...very intermittent and not very frequent. I`ll keep testing with other settings/options and report back.

It is most likely display driver/card issue if nothing changed between b2 and b3.

[Steve]

I have been testing SWOS with the latest beta and I am quite sure some minor tearing when the screen scrolls up or down has been fixed in beta 3 and no longer occurs.

There was also a bug when the advertisement boards became animated and the ball was out of play for a corner or a throw in. While the board scrolled/animated, the static players would all change colour rapidly while the advertisement board scrolled. This bug also no longer occurs.

[lordofchaos]

Originally Posted by Toni Wilen

You forgot to test input latency, Turrican is not that "fast" game

Well I have played around with the settings to the point of nausea to try and remedy the screen tear but to no avail. Latency is definitely improved since the implementation of the new v-sync though, using pinball fantasies as a test game.

[rare_j]

OK I have tried B3 and I have new results.
DirectDraw no filter window - no tear
DirectDraw no filter fullscreen - no tear
DirectDraw filter window - no tear
DirectDraw filter fullscreen - no tear

D3D window - no tear
D3D full window - no tear
D3D fullscreen - 1 tear, always there, always in the same place!
approx 1/3 - 1/4 from the top of the picture.

Remember this may be the crappest graphics chipset on EAB!
But it claims to run at 50Hz
This must be interesting!
Logs attached

[Toni Wilen]

Originally Posted by rare_j

D3D fullscreen - 1 tear, always there, always in the same place!
approx 1/3 - 1/4 from the top of the picture.

Card/driver probably don't support D3D queries and/or D3DGETDATA_FLUSH command. Next beta will have debugging messages that shows result of above calls.

[rare_j]

Originally Posted by Toni Wilen

Card/driver probably don't support D3D queries and/or D3DGETDATA_FLUSH command. Next beta will have debugging messages that shows result of above calls.

Perhaps it loses sync because the machine isn't fast enough to draw the frames in D3D full screen mode.
It's a 1.60Ghz Celeron M (Sonoma core).

[Maren]

Hello. I'm experiencing some really nasty lag in the game "Brian The Lion" . Here's what I know so far:

. I used WinUAE's default quickstart profile + cycle exact and full collision level for recording this savestate, but it's worth noting that leaving them disabled doesn't help the lag whatsoever.

. Happens only with my custom Host config. WinUAE's default works ok.

. Disabling vsync fixes it, so it looks like it's a combination of vsync (tried all methods, none helped) + something else in my custom Host config. And I believe it must be said combination because I don't get the lag when going fullscreen + vsync with everything else intact in WinUAE's default Host config.

. Happens with both the ipf and the adf versions of the game.

. Works fine on 2.3.2.

Download a savestate and my custom .uae from here

Cheers.

[Dr.Venom]

Originally Posted by Toni Wilen

http://www.winuae.net/files/b/winuae_2330b3.zip

Beta 3:

- tearing in new vsync modes should be completely gone, without introducing any extra latency
- Display panel buffering option now does nothing in new vsync modes

Found a small issue with "locking/unlocking" a custom refresh rate in the GUI: setting a custom refresh (e.g. 49.92) for the default PAL and NTSC values get reset in the GUI to 50.0000 and 60.0000 after ticking "lock -> unlock -> lock" sequentially.

How to reproduce:
- Start WinUAE -> PAL value is at 50.00000
- tick "lock" box and fill it with a custom value, say "49.92"
- save the "locked" configuration -> config file shows custom value as "displaydata_pal=49.920000,locked,pal"
- unlock the value again by unticking the "lock" box -> custom value (49.92) resets to default 50.0000
- lock again by ticking the "lock" box -> value stays at 50.0000 (should go to 49.92)

When starting with a saved config, same problem occurs:
- quit and restart WinUAE with the custom "locked" PAL config -> "PAL" dropdown shows custom value of 49.92
- tick unlock -> tick lock again -> custom value has been reset to 50.0000 while value is "locked".

[MxMShare]

Hello, I had been using an old version of WinUAE and just upgraded to v2.3.2
Looking through what posts I could find on this BBS, I see that Native and RTG can turn on/off the row of LEDs. Is there a way to have the disk drive LEDs (i.e. HD, plus enabled 1.4FD and Red Power light - when it is not blinking!) but not the other items seems to be a number, percent, and something else. They are probably telling something interesting to more techies, but I just want to play games and see that the drives are reading. Is this possible in this version? I apologize if this isn't the right thread for this. Help would be greatly appreciated! Thanks all!

[andreas]

Originally Posted by Toni Wilen

You forgot to test input latency, Turrican is not that "fast" game

Granted, so one idea from me:
If you guys want to test something REALLY fast [1], you may want to try R-Type II.

[1]Linux UAE even showed a respectably fluent performance back in 1998. But I remember this game to always stutter like hell on my K6 w/sound on, even (!) with frame skip > 2 - one out of very few though! That's why I have to assume it is not only very hardware-demanding (speaking in OCS terms), but also requires a great precision in interrupt handling; hence, it might make a suitable guinea-pig for "stress" testing.

[Steve]

Originally Posted by andreas

Granted, so one idea from me:
If you guys want to test something REALLY fast [1], you may want to try R-Type II.

I think MicroMachines is the ultimate fast scrolling test! Latest beta scrolls perfectly on mine!

[Maren]

I had been experiencing this horrendous input lag with the latest beta when using my custom Host configuration (which's virtually the same I use for 2.3.2)

Some games such as "Brian The Lion", "B.C.Kid" and "Fire & Ice" were pretty much unplayable, whereas "The Great Giana Sisters", Turrican II" and "Rolling Ronny" worked beautifully (as usual). Only recently did I find out that some of these games were still laggy even though vsync had been completely disabled, so I guess vsync wasn't the offending setting afterall. The mouse pointer in Workbench 1.3 and the demo "Wild Copper" also lagged badly.

Anyways, after fiddling more carefully with the options, the tweak that actually solved this for good was setting "When Active run at priority" back to "Normal".

I'd religiously change it to "Above Normal" when creating my custom config as it helped some audio issues I experienced a few years ago, but I guess I don't need it anymore.

Now the question; is this normal behavior for the beta?

[Toni Wilen]

Originally Posted by Steve

I think MicroMachines is the ultimate fast scrolling test! Latest beta scrolls perfectly on mine!

It was supposed to be input lag test, not some scrolling speed test. Input lag is so easy to notice when playing pinball games.

Originally Posted by Maren

Anyways, after fiddling more carefully with the options, the tweak that actually solved this for good was setting "When Active run at priority" back to "Normal".

I'd religiously change it to "Above Normal" when creating my custom config as it helped some audio issues I experienced a few years ago, but I guess I don't need it anymore.

Now the question; is this normal behavior for the beta?

It is not beta specific (it has been reported years ago for the first time), some systems have huge input lag if priority is too high and CPU usage is 100%, reason unknown.

[Dr.Venom]

Originally Posted by MxMShare

Hello, I had been using an old version of WinUAE and just upgraded to v2.3.2
Looking through what posts I could find on this BBS, I see that Native and RTG can turn on/off the row of LEDs. Is there a way to have the disk drive LEDs (i.e. HD, plus enabled 1.4FD and Red Power light - when it is not blinking!) but not the other items seems to be a number, percent, and something else. They are probably telling something interesting to more techies, but I just want to play games and see that the drives are reading. Is this possible in this version? I apologize if this isn't the right thread for this. Help would be greatly appreciated! Thanks all!

Indeed wrong thread, next time better post non-beta related questions as a separate thread.

If you're only interested in seeing if the drives are reading, then a suggestion is to configure your keyboard leds as the floppy leds. You won't get it more real than that

You can find the setting under the "Miscellaneous" panel -> Keyboard Leds

[rare_j]

Originally Posted by Toni Wilen

Card/driver probably don't support D3D queries and/or D3DGETDATA_FLUSH command. Next beta will have debugging messages that shows result of above calls.

Hello,
Previously I reported that I only saw a tear in D3D fullscreen mode. I thought this was a bit odd. Actually I tried again tonight, except this time I scaled the emulation to fill the whole screen in D3D windowed, full-window and full screen modes.

The tear is actually there in all D3D modes on my machine, I just didn't see it before because I had used no scaling, so the emulation was a small picture in the middle of the screen.
Now when I scale the emulation to the full resolution of the display I see the tear in the same place in all modes.

Hope my previous report didn't cause too much confusion.

[Toni Wilen]

Originally Posted by rare_j

The tear is actually there in all D3D modes on my machine

Does http://www.winuae.net/files/b/winuae.zip log some extra messages about D3D query problems? (when in new vsync mode)

[Dr.Venom]

Hi Toni,

I think I've found a possible bug. When starting WinUAE from a saved config with a 'locked' refresh rate I also experience screentearing with vsync(new).

In most games it can be hard to notice because it's so stable and only shifting the line by a few pixels. At each restart of WinUAE it can be in a different spot or even not be seen (probably being outside of the visible screen area). I've attached a picture of it showing a clear example.

Notice:
- the tearing does not occur when running WinUAE normally (unlocked/automated refresh rate)
- the tearing does not occur when starting WinUAE normally and changing the value in the custom refresh rate box while a game/demo is already running.

Maybe in some unforeseen way this possible bug is related to the problem rare_j is experiencing?

[rare_j]

Originally Posted by Toni Wilen

Does http://www.winuae.net/files/b/winuae.zip log some extra messages about D3D query problems? (when in new vsync mode)

Hello,
Yes it does, this line appears while I am testing different D3D modes:

54-781 [0 000x000]: D3D9: CreateQuery(D3DQUERYTYPE_EVENT) failed: 8876086A S=1 F=0876 C=086A (2154) ()

See also attached logs.

I also have a PC with a Radeon 9250 in the loft with a CRT monitor so it should do 50 Hz. I'll test with this at the weekend if I get the chance.

[Maren]

Originally Posted by Toni Wilen

It was supposed to be input lag test, not some scrolling speed test. Input lag is so easy to notice when playing pinball games.



It is not beta specific (it has been reported years ago for the first time), some systems have huge input lag if priority is too high and CPU usage is 100%, reason unknown.

And that would explain why it's the most demanding games the ones exhibiting this problem. System requirements increase as WinUAE is perfected; my system's been left behind.

[Toni Wilen]

Originally Posted by Maren

And that would explain why it's the most demanding games the ones exhibiting this problem. System requirements increase as WinUAE is perfected; my system's been left behind.

Not necessarily. It can be driver specific, perhaps even some virus scanner specific etc.. It is not CPU power specific, some very powerful systems also have it as long as CPU usage is 100%, even if it is multicore CPU and other cores are idle! (Which is always true in fastest possible + no CPU idle setup).

Fix is easy: do not use Above normal priority.