WinUAE 1.5.1 beta series - Page 12

Steve · 04 August 2008, 23:37

Quote:

Originally Posted by Toni Wilen

- D3D filter does not crash if texture creation fails (=non D3D9 compatible display card/driver)

RC3 = Perfection!

Mad-Matt · 05 August 2008, 00:02

Just tried this out and it seems to have an issue i noticed in the previous non rc beta. RC1 is fine.

Once rtg desktop is opened, the mouse is trapped in a box so i cant move where i want on the desktop. If i manage to open a window and drag around abit in the confines of this invisable box, then the boundaries also seem to move. I cant easily explain it. Opening the f12 menu can also change where the mouse restriction box is .

If i use rc1 , then no issue.

UncleSpam · 05 August 2008, 06:28

I'll second that find...

Something's definitely wrong. And this is in a "plain-vanilla" KS/WB3.1 load.

Trying to switch the ScreenMode to Multiscan:Productivity, slows down the emulation to a crawl.

I'll check on this more tomorrow... it's getting late here.

Bogdan

Quote:

Originally Posted by Mad-Matt

Just tried this out and it seems to have an issue i noticed in the previous non rc beta. RC1 is fine.

Once rtg desktop is opened, the mouse is trapped in a box so i cant move where i want on the desktop. If i manage to open a window and drag around abit in the confines of this invisable box, then the boundaries also seem to move. I cant easily explain it. Opening the f12 menu can also change where the mouse restriction box is .

If i use rc1 , then no issue.

Tony Landais · 05 August 2008, 07:31

I experienced the mouse trap too in non rtg screen (Direct 3D, Fullscreen, 50 Hz) with RC3.
From a RTG Workbench I started a PAL application then my mouse was locked in a box, after moving it around the mouse became free. Switching back to workbench screen didn't make any problem...
Windows XP SP3 ATI Radeon Mobility X1600 latest drivers and latest DirectX...

Toni Wilen · 05 August 2008, 08:29

Quote:

Originally Posted by Mad-Matt

Once rtg desktop is opened, the mouse is trapped in a box so i cant move where i want on the desktop. If i manage to open a window and drag around abit in the confines of this invisable box, then the boundaries also seem to move. I cant easily explain it. Opening the f12 menu can also change where the mouse restriction box is .

Mouse = Amiga mouse or Windows mouse? = after ALT-TAB (untrapping mouse) Windows mouse is still "trapped"?

Mad-Matt · 05 August 2008, 09:41

I think ive got it set to Windows Mouse (at work atm). alt tabbing doesnt get the pointer out of the box, but the box can move depending where I reclick in the emu.

Toni Wilen · 05 August 2008, 16:07

Attached version should fix the mouse problem.

Ed Cruse · 05 August 2008, 17:11

Quote:

Originally Posted by Toni Wilen

Attached version should fix the mouse problem.

The Amiga mouse in a box with rc2-3 has been fixed with the attachment.

Toni Wilen · 05 August 2008, 17:26

Quote:

Originally Posted by Ed Cruse

The Amiga mouse in a box with rc2-3 has been fixed with the attachment.

Great. Now I only need to wait until winuae.net works again..

Ed Cruse · 05 August 2008, 21:10

Quote:

Originally Posted by Toni Wilen

Great. Now I only need to wait until winuae.net works again..

Don't hold your breath.

Mad-Matt · 06 August 2008, 00:08

Thx for the update toni, I can confirm the mouse trap has gone

One last thing though. I dont know if its an issue with emu or my fault entirly, but regarding jit direct. I can boot to rtg desktop in Direct mode. I use "cpu_speed max 0" for whdload and "cpu_speed max 8192" for when whd quits. However when jit is restored its now in Indirect mode.

Is there an option I can set to make sure it comes back into direct mode ?

UncleSpam · 06 August 2008, 02:18

Yes, indeed, the mouse trapping issue is fixed.

However, when running WinUAE 1.5RC3+ and running the unmodified OS3.1 environment, there's a problem with the speed when using Multiscan:Productivity display (640x480x2bit, or more bitplanes).

The screen update is incredibly slow... taking 45 seconds to paint the initial WB screen.

If I click to another Window application, the WinUAE window remains on top.

I'll provide more information if required.

Bogdan

Toni Wilen · 06 August 2008, 08:07

Quote:

Originally Posted by UncleSpam

Yes, indeed, the mouse trapping issue is fixed.

However, when running WinUAE 1.5RC3+ and running the unmodified OS3.1 environment, there's a problem with the speed when using Multiscan:Productivity display (640x480x2bit, or more bitplanes).

The screen update is incredibly slow... taking 45 seconds to paint the initial WB screen.

If I click to another Window application, the WinUAE window remains on top.

I'll provide more information if required.

Bogdan

"The Usual": winuaelog.txt. (bootlog not needed this time)

Rabbit80 · 06 August 2008, 10:11

I dont know if this is the place to report it, but Worms directors cut seems to have some major graphical errors when choosing weapons on 1.5.1RC2 (I haven't tested other versions)

Toni Wilen · 06 August 2008, 10:27

Quote:

Originally Posted by Rabbit80

I dont know if this is the place to report it, but Worms directors cut seems to have some major graphical errors when choosing weapons on 1.5.1RC2 (I haven't tested other versions)

99.9% surely usual "too fast" AGA blitter/cpu issue and 99% surely not 1.5.1 beta related.'

and added: "- bug reports but make sure bug is NOT in previous offical version. (Old bug -> separate thread)"

Rabbit80 · 06 August 2008, 12:30

Forgive me - I'm still a noob around here

UncleSpam · 07 August 2008, 01:28

Toni,

As requested... winuaelog.txt

Same behavior in Windowed and Full Screen modes.

No RTG modes used... just Multiscan:Productivity with no overscan.

Bogdan

Same behaviour with "Euro 72Hz: Productivity" mode

Quote:

Originally Posted by Toni Wilen

"The Usual": winuaelog.txt. (bootlog not needed this time)

Toni Wilen · 08 August 2008, 20:51

Quote:

Originally Posted by UncleSpam

However, when running WinUAE 1.5RC3+ and running the unmodified OS3.1 environment, there's a problem with the speed when using Multiscan:Productivity display (640x480x2bit, or more bitplanes).

Fixed. This was difficult to duplicate (not every boot had this problem)
It was really ancient bug in code that calculates approximate blitter speed in current display mode.

Bug can only happen if:
- AGA enabled
- doublescan sprites enables or AGA wide sprites enabled
- immediately blitter not enabled

In worst case it can cause about 3 second blits, even if blit is tiny which explains the slowdown but mouse cursor still updating normally.

UncleSpam · 09 August 2008, 01:39

Yes, indeed... the mouse was updating properly. Nothing else was, however.

Glad you found it!

Bogdan

Quote:

Originally Posted by Toni Wilen

Fixed. This was difficult to duplicate (not every boot had this problem)
It was really ancient bug in code that calculates approximate blitter speed in current display mode.

Bug can only happen if:
- AGA enabled
- doublescan sprites enables or AGA wide sprites enabled
- immediately blitter not enabled

In worst case it can cause about 3 second blits, even if blit is tiny which explains the slowdown but mouse cursor still updating normally.

Toni Wilen · 09 August 2008, 19:21

RC4: (still waiting for fixed winuae.net..)

- quickstart A1200: increase A1200 KS 3.1 priority over Cloanto A4000 KS 3.1 (AF2008 finally includes real A1200 3.1 ROM)
- multiple identical USB game controllers fix really works now
- non-ce/non-immediate blitter timing calculation returned totally bogus values if AGA fmode=3, wide sprites or sprite doublescan was enabled (tiny blit could take few seconds to finish in worst case..) Ancient bug.
- input device re-enumeration cleanup after usb device insert/remove
- crash when inserting or removing USB devices before emulation has been started
- inserting/removing USB devices does not anymore change currently selected mouse or joystick device in ports panel

05 August 2008, 16:07	#227
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,570	Attached version should fix the mouse problem. Last edited by Toni Wilen; 16 August 2008 at 21:07.

09 August 2008, 19:21	#240
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,570	RC4: (still waiting for fixed winuae.net..) - quickstart A1200: increase A1200 KS 3.1 priority over Cloanto A4000 KS 3.1 (AF2008 finally includes real A1200 3.1 ROM) - multiple identical USB game controllers fix really works now - non-ce/non-immediate blitter timing calculation returned totally bogus values if AGA fmode=3, wide sprites or sprite doublescan was enabled (tiny blit could take few seconds to finish in worst case..) Ancient bug. - input device re-enumeration cleanup after usb device insert/remove - crash when inserting or removing USB devices before emulation has been started - inserting/removing USB devices does not anymore change currently selected mouse or joystick device in ports panel Last edited by Toni Wilen; 16 August 2008 at 21:07.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
WinUAE 2.5.1 beta series	Toni Wilen	support.WinUAE	69	22 December 2012 10:22
WinUAE 2.3.3 beta series	Toni Wilen	support.WinUAE	124	17 September 2011 15:48
WinUAE 2.3.2 beta series	Toni Wilen	support.WinUAE	79	31 May 2011 19:39
WinUAE 2.3.0 beta series (was 2.2.1)	Toni Wilen	support.WinUAE	229	22 September 2010 19:20

05 August 2008, 07:31	#224
Tony Landais Zone Friend Join Date: Mar 2003 Location: uk Posts: 426	I experienced the mouse trap too in non rtg screen (Direct 3D, Fullscreen, 50 Hz) with RC3. From a RTG Workbench I started a PAL application then my mouse was locked in a box, after moving it around the mouse became free. Switching back to workbench screen didn't make any problem... Windows XP SP3 ATI Radeon Mobility X1600 latest drivers and latest DirectX...

05 August 2008, 09:41	#226
Mad-Matt Longplayer Join Date: Jan 2005 Location: Lincoln / UK Age: 45 Posts: 1,854	I think ive got it set to Windows Mouse (at work atm). alt tabbing doesnt get the pointer out of the box, but the box can move depending where I reclick in the emu.

06 August 2008, 00:08	#231
Mad-Matt Longplayer Join Date: Jan 2005 Location: Lincoln / UK Age: 45 Posts: 1,854	Thx for the update toni, I can confirm the mouse trap has gone One last thing though. I dont know if its an issue with emu or my fault entirly, but regarding jit direct. I can boot to rtg desktop in Direct mode. I use "cpu_speed max 0" for whdload and "cpu_speed max 8192" for when whd quits. However when jit is restored its now in Indirect mode. Is there an option I can set to make sure it comes back into direct mode ?

06 August 2008, 02:18	#232
UncleSpam Registered User Join Date: Jan 2007 Location: Burbank, CA Posts: 161	Yes, indeed, the mouse trapping issue is fixed. However, when running WinUAE 1.5RC3+ and running the unmodified OS3.1 environment, there's a problem with the speed when using Multiscan:Productivity display (640x480x2bit, or more bitplanes). The screen update is incredibly slow... taking 45 seconds to paint the initial WB screen. If I click to another Window application, the WinUAE window remains on top. I'll provide more information if required. Bogdan

06 August 2008, 10:11	#234
Rabbit80 Its hard being famous! Join Date: Aug 2008 Location: Gateway to the dales, UK Age: 44 Posts: 633	I dont know if this is the place to report it, but Worms directors cut seems to have some major graphical errors when choosing weapons on 1.5.1RC2 (I haven't tested other versions)

06 August 2008, 12:30	#236
Rabbit80 Its hard being famous! Join Date: Aug 2008 Location: Gateway to the dales, UK Age: 44 Posts: 633	Forgive me - I'm still a noob around here

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)