Problem with changing Screenmode after LoadView/WaitTOF

StingRay · 21 September 2012, 16:42

I have a somewhat strange problem with WinUAE 2.4.1. It only happens on my notebook and only in windowed mode. After flushing the view in my startup (using the normal LoadView(0)/2xWaitTOF() approach) the screen changes to the native one as it is supposed to. However, a split second later it switches back to the AsmPro screen (which runs on a 640x480 Picasso screen) so I can't see any of my effects. Do you have any idea what could be the reason for this? I have found a workaround by opening a fake system screen (640x12, 1 bpl) but I really wonder why this happens. Any ideas? As said, it only happens in windowed mode, if I switch to fullscreen everything works as expected.

Toni Wilen · 21 September 2012, 17:00

I think it is probably emulation pausing when mode switches which hides the problem in windowed mode.

Some background utility doing weird things? Does it still happen if you Forbid() before LoadView() stuff?

StingRay · 21 September 2012, 17:09

Forbid() doesn't change anything. But I just tried booting without startup-sequence and problem disappeared then. So your guess is right, seems something running in the background is responsible for this. Thanks!

StingRay · 21 September 2012, 21:05

I have found what's causing the problem, it's MCP's "mouse blanker". Strange... Seems to be some timing relating bug I guess as it only happens when running WinUAE, i.e. much faster machine than any real Amiga.

Toni Wilen · 24 September 2012, 09:07

Does it happen if you move mouse to top/left corner first? Perhaps mouse "moves" internally when switching if native/RTG resolution difference is large enough?

ADDED: RTG hardware sprite emulation may also make a difference. (Direct3D needed for RTG sprite emulation, latest beta also allows to force hardware sprite off)

21 September 2012, 16:42	#1
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Problem with changing Screenmode after LoadView/WaitTOF I have a somewhat strange problem with WinUAE 2.4.1. It only happens on my notebook and only in windowed mode. After flushing the view in my startup (using the normal LoadView(0)/2xWaitTOF() approach) the screen changes to the native one as it is supposed to. However, a split second later it switches back to the AsmPro screen (which runs on a 640x480 Picasso screen) so I can't see any of my effects. Do you have any idea what could be the reason for this? I have found a workaround by opening a fake system screen (640x12, 1 bpl) but I really wonder why this happens. Any ideas? As said, it only happens in windowed mode, if I switch to fullscreen everything works as expected.

24 September 2012, 09:07	#5
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,542	Does it happen if you move mouse to top/left corner first? Perhaps mouse "moves" internally when switching if native/RTG resolution difference is large enough? ADDED: RTG hardware sprite emulation may also make a difference. (Direct3D needed for RTG sprite emulation, latest beta also allows to force hardware sprite off) Last edited by Toni Wilen; 24 September 2012 at 13:16.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Low screenmode problem in OS 3.9	Bamiga2002	support.Apps	16	21 August 2012 00:02
FS-UAE 1.1.1 screenmode problem when P96 active	PHabermehl	support.FS-UAE	19	06 April 2012 14:53
Screenmode	sram	Amiga scene	0	12 April 2009 03:01
Chaos Engine AGA screenmode problem, can it be fixed?	TjLaZer	support.Games	0	05 September 2006 07:42
winuae screenmode and refreshrate problem	PseudoDOS	support.WinUAE	0	28 May 2003 21:04

21 September 2012, 17:00	#2
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,542	I think it is probably emulation pausing when mode switches which hides the problem in windowed mode. Some background utility doing weird things? Does it still happen if you Forbid() before LoadView() stuff?

21 September 2012, 17:09	#3
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Forbid() doesn't change anything. But I just tried booting without startup-sequence and problem disappeared then. So your guess is right, seems something running in the background is responsible for this. Thanks!

21 September 2012, 21:05	#4
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	I have found what's causing the problem, it's MCP's "mouse blanker". Strange... Seems to be some timing relating bug I guess as it only happens when running WinUAE, i.e. much faster machine than any real Amiga.

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