WinUAE 2.3.3 beta series

[Toni Wilen]

Originally Posted by rare_j

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.

Yes, this means graphics driver does not support "Flush GPU pipeline" command which also means GPU isn't finished when WinUAE asks driver to show the screen.

Following happens each frame:

- Amiga screen (D3D texture) is updated.
- Pipeline flush command is executed
- Wait for vblank (During this wait GPU is rendering new frame)
- Show new frame (page flip or copy if windowed). This has to happen near-instantly (1-2ms) or there will be tearing. (No flush = GPU starts rendering at this point which can take many milliseconds)

Of course it is possible to add one more buffer but goal was to have minimal latency..

[rare_j]

Originally Posted by Toni Wilen

Of course it is possible to add one more buffer but goal was to have minimal latency..

If it is straightforward to do, and not too boring, perhaps you could offer vsync (new) with no buffering, and vsync (new) with a single buffer, for crappy d3d drivers.
Although you're right that wasn't really the goal of it.

If you offered a single buffer as an option, would this mean you could safely remove vsync (old)?

[Dr.Venom]

Originally Posted by Toni Wilen

Beta 1:

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

- new vsync option
* does not need extra buffers (very little input lag), make sure "no buffering" is selected
* works also in windowed/fullwindow mode
* attemps to autodetect exact refresh rate, ignores what Windows/driver reports

Hi Toni,

With regards to the "attemps to autodetect exact refresh rate, ignores what Windows/driver reports". Maybe this can be improved..

I've been triggered by the fact that the autodetect refresh rate comes up with a different value every time you start WinUAE. In the attached picture I have 20 autodetected refresh rates in a row (this is also reported by other users, see e.g. here ), which questions the accuracy on how close it comes to the real refresh rate. Since this inaccuracy sooner or later can cause problems (resyncing and stuff) I gave it a second thought, which hopefully is useful for further improvement..

I had to dust of some old books, but the bottom line is that one determines the sample size based on the needed level of accuracy. It's explained in more detail here: Single Mean - Determining the Sample Size . The rule for determining the appropriate sample size (n), to get within "d" from the real refresh rate is as follows:

n = (zs/d)^2

z = 1,96 when at 95% confidence
s = standard deviation of sample
(And translated to the WinUAE situation)
d = maximum distance from real screen refresh rate

Now please take a look at the attached picture, which works out the needed sample size (number of frames or number of seconds to poll) to get the estimate to within 0,1Hz up to 0,000001Hz accuracy of the real refresh rate. The findings are that to get to at least 0,0001Hz accuracy (higher than the current implementation) one needs to sample between ~5 seconds to ~22 seconds. Of course these numbers will depend on the actual standard deviation of the sample (which only you can calculate precisely). But give or take a few, my guess is that the numbers in the picture should give a rough guideline.

For exploring possible improvement to the autodetect refresh rate on different setups, I have a simple suggestion (as I appreciate your preference to keep things simple ), which is to add (for this Beta series) the possibility for the user to set the number of seconds manually that the refresh rate detection will be sampling (currently it's two or three seconds I guess?).

That way we can report back for different systems whether or not (and if so, by how much) longer sampling time leads to higher accuracy and consistency in the estimated refresh rate, as suggested by the statistical rule.

[Toni Wilen]

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

Beta 4:

- rawinput was not enabled properly in all situations (mainly affected -rawhid parameter)
- write log message if D3D command pipeline flush fails or is not supported (tearing in new vsync mode)
- added win32.gui_page=<name of panel> configuration entry, selects default panel when GUI opens
- magic mouse in fullwindow mode only uncaptures if mouse would move to another monitor
- quickstart mode now sets sound mode to "disabled but emulated" if it was "disabled", previously it was always set to "emulated".
- CD/CD image switching on the fly was unreliable (different problem than b2 fix)
- optimization that detects if sprite changed has not been working for ages
- sprites above or below bitplane area and AGA border sprite bit set caused graphics garbage around the mouse cursor in some situations.
- possible fix for autoresolution aspect ratio problems when filter aspect ratio setting is enabled
- removed default scroll lock -> inhibit screen updates key mapping
- AROS ROM updated

Remaining new vsync updates coming later...

EDIT: bug causing RTG slowdown (on some systems) found, introduced in b1, will be fixed in next beta.

[Mequa]

Originally Posted by Toni Wilen

Remaining new vsync updates coming later...

Is it a long way before VSync works well with JIT (on fastest possible settings)?

(Of course VSync may impose a speed penalty, but it's 68060-level performance with VSync that would be useful, e.g. for Alien Breed 3D II, Gloom Deluxe, Amiga Quake, etc.)

[Toni Wilen]

Originally Posted by Mequa

Is it a long way before VSync works well with JIT (on fastest possible settings)?

(Of course VSync may impose a speed penalty, but it's 68060-level performance with VSync that would be useful, e.g. for Alien Breed 3D II, Gloom Deluxe, Amiga Quake, etc.)

It won't be in next official version. Maybe later..

[trackah123]

Mouse cursor corruption in Protracker, does not happen in WinUAE 2.3.2

Note : mouse cursor corruption only seems to happen when moving the mouse exactly in a vertical line over the Protracker-buttons.

In this case i tried Protracker 3.18b but other versions also seems to be affected by this issue.

[Toni Wilen]

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

Beta 5:

- CD image audio play buffer size increased, some system have glitchy sound if buffer is too small
- on the fly resolution change didn't reset all parameters
- resolution autoswitch now uses startup resolution and doubling values as highest supported mode (internal display buffer needs to be as big as max supported mode and it can't be re-allocated on the fly without major display glitches)
- RTG modes were rendered twice/frame, caused performance loss (b1)
- do not add >2M chip RAM to memory list if it is already added (perhaps m68k AROS does this automatically in future)
- borderblank change didn't redraw all changed scanlines
- key/button mapped to mouse directions didn't work
- Add Harddrive allowed without admin privielges, removable drives do not seem to require extra privileges. (anymore?)
- b4 sprite optimization fix was broken
- automatic scaling max scaling values adjusted, now 3.x max overscan fits completely on screen

[geecab]

Hi Toni!

Thanks so much for this beta 2330b5, I really appreciate it and all the work you do on winUAE, I was especially interested in the "key/button mapped to mouse directions" fix and it works really well!! Now can control stuff like "defender of the crown", "obliterator" and "lost patrol" on my arcade machine and it just such a novelty to be able to do that

One thing I thought I'd mention, I have noticed the mouse moves quite quickly when controlled by keys, so I was looking for some way to slow it down (or maybe a kind of non-linear speed setting thing (moves slow at first then it speeds up the longer you hold the key down)). There is a mouse speed slide bar in the winUAE GUI but that doesn't seem to have any effect? In any eventuality, please don't think I'm flagging this up as a problem for me as I doubt I'll be spending hours playing mouse driven games with a joystick. I just wanted to have the "key/button mapped to mouse directions" fix thing work for the novelty factor, which you have made possible in this beta and I'm very happy with that

Thanks again!!

[Toni Wilen]

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

Beta 6:

- added "statefile_name" configuration file entry, sets default statefile name (normally "default.uss")
- fixed jittery raw mouse movement
- resolution autoswitch should now work correctly, no more strange centering without autoscale.
- analog stick mapped as a mouse had wrong and unstable speed
- rarely used configuration entries were only supposed to be written if they had non-default value. re-saving configuration will reduce size of most config files. Older bug.
- "Integer scaling" visible in GUI (AF specific feature originally), selects biggest integer scaling ratio that still fits on screen
- "VSync (new)" renamed to "Low latency VSync"
- Input panel configuration #1-#3 can be renamed by manually editing config file (input.x.name=name)
- GUI allows FPU in cycle exact modes. Not much point but if you really want to enable it..

[lordofchaos]

Hi Toni, I`m really loving this current Beta series with all the cool additions and fixes, thanks for all the hard work and making Amiga emulation some of the best on the net!

Yes, thanks for the great work! WinUAE is getting better every time!
But now with beta 6 the HIGHGFX monitor driver is broken. I use it for VGA resolution in DPaint, and now it is not fully visible anymore. Or is there a new setting I haven't discovered yet?

[Toni Wilen]

Originally Posted by Juppi

Yes, thanks for the great work! WinUAE is getting better every time!
But now with beta 6 the HIGHGFX monitor driver is broken. I use it for VGA resolution in DPaint, and now it is not fully visible anymore. Or is there a new setting I haven't discovered yet?

More information needed. When did it last work? (see first post) What configuration? Do you use any filters? (Note that "strange" modes like highgfx are not supported in autoscale and similar modes and positioning can and will change between versions)

I start AmigaOS 3.9 BB4 with HighGFX in windowed mode 1024x770.

With WinUAE 2.3.3 beta 5 it looks fine, but in beta 6 the screen is shifted to the left:

[Supamax]

Originally Posted by Toni Wilen

Beta 6:

- resolution autoswitch should now work correctly, no more strange centering without autoscale.

Hi Toni,
is the above a fix for the "centering" "issue"? (http://eab.abime.net/showthread.php?t=60052)

[Toni Wilen]

Originally Posted by Juppi

I start AmigaOS 3.9 BB4 with HighGFX in windowed mode 1024x770.

With WinUAE 2.3.3 beta 5 it looks fine, but in beta 6 the screen is shifted to the left:

It is slightly better if you select Superhires resolution in Display panel. (EDIT: it shouldn't be that bad but I am not yet sure if it is "unsupported" or should be "fixed" )

It is now required when showing superhires modes (highgfx is one), it sort of worked previously but it was never fully supported. It "worked" only because lores/hires/shres "centering" didn't handle superhires correctly previously.

("Centering" does not mean centering options but internal image positioning so that image does not move "randomly" when switching between display panel lores/hires/superhires selections)

Originally Posted by Toni Wilen

It is slightly better if you select Superhires resolution in Display panel. (EDIT: it shouldn't be that bad but I am not yet sure if it is "unsupported" or should be "fixed" )

Thank you for the explanation, it works now (sort of):
Highgfx is shifted with 'Resolution:Hires(Normal)' and fine with 'Resolution:SuperHires', even with 'Resolution Autoswitch' ON !
So 'Resolution'(greyed out) is a kind of Default for 'Resolution Autoswitch'?

I switch between Hires and SuperHires sometimes, so a fix would be nice :-)
but I understand if you don't emulate unsupported things.

[Toni Wilen]

Originally Posted by Juppi

Thank you for the explanation, it works now (sort of):
Highgfx is shifted with 'Resolution:Hires(Normal)' and fine with 'Resolution:SuperHires', even with 'Resolution Autoswitch' ON !
So 'Resolution'(greyed out) is a kind of Default for 'Resolution Autoswitch'?

I switch between Hires and SuperHires sometimes, so a fix would be nice :-)
but I understand if you don't emulate unsupported things.

Resolution autoswitch only works in superhires mode if superhires is selected before autoresolution checkbox is ticked.

Originally Posted by Supamax

Hi Toni,
is the above a fix for the "centering" "issue"? (http://eab.abime.net/showthread.php?t=60052)

Nothing to do with it.

As I said: "fixing" this would break most existing filter position configurations. It will be mentioned in big letters when it happens.

Originally Posted by Toni Wilen

Resolution autoswitch only works in superhires mode if superhires is selected before autoresolution checkbox is ticked.

NOW I understand!
And I discovered HD720 (the HighGFX bonus driver) that behaves normal, not like HighGFX, and is 16:9.
So I switched completely to 1280x720, with SuperHires and autoswitch on, for both DPaint and Workbench.
Looks good, thank you for solving my problem!

ps. I have a limit of 512+8MB ChipRAM and 1GB-FastRAM. I can choose 1GB Chip and 2GB Fast but I do not get them.
Is this a limit of AmigaOS? (DPaint can do 'uncompressed anim frames', so every megabyte helps there.)

[rare_j]

I tried out b6 'Low latency VSync' mode on a PC with a Radeon 9250, which is quite an old card, and it worked fine, no tearing at all.