[hatari-devel] Issue with switching - fullscreen/windowed mode
Eero Tamminen
eerot at users.berlios.de
Sun Feb 7 23:05:48 CET 2010
Hi,
On Saturday 06 February 2010, Anders Eriksson wrote:
> I can confirm strange behaviour when jumping in/out of fullscreen mode,
> at least in Falcon hicolour mode.
>
> 1. Screenshot when first starting up Hagtari in Hicolour:
> http://ae.dhs.nu/pics/hatari_hc1.png
>
> Everything is fine then.
>
> 2. Then when entering fullscreen, Hatari looks like this:
> http://ae.dhs.nu/pics/hatari_hc2.png
>
> The blue part is the useable workspace, the rest is inactive. But as you
> can see the pixels get the wrong colour in fullscreen.
>
> 3. And last when returning to window mode, the window has changed size
> and have graphics garbage in the unused parts.
> http://ae.dhs.nu/pics/hatari_hc3.png
So the use case is just:
- Start Hatari in Falcon mode with TOS4
- Switch the video mode to "True color" from desktop
- Switch fullscreen on (F11)
- Switch fullscreen off
?
> All screenshots are taken with Hataris internal screenshot function with
> version 1.3.1 under OS X 10.6. It had the same behaviour under 10.5
> before as well.
I cannot reproduce this on Linux, so I guess it's OSX specific issue
(or LCD, see below).
Hm. Now that I look at the code, I think Thomas may have broken the code
year ago with this:
http://hg.berlios.de/repos/hatari/rev/fc9d076344be
I'm pretty sure in Aranym bug() is always defined (and exits program?)
whereas Hatari Dprintf() isn't always defined and because code doesn't use
braces properly, it may work in a bogus way when SDL cannot just switch to
fullscreen. This doesn't happen on CRTs like I have, but I guess may happen
with LCD screens because you say that the resolution changes on
fullscreening...
Can you apply the attached patch, set VIDEL_DEBUG at the beginning of
falcon/hostscreen.c from 0 to 1, re-compile and tell whether the bug is
still there and if it is, what Hatari outputs on this use-case?
> I'd also like to point out that Hatari changes resolution when going to
> fullscreen. This is very irritating in my opinion, some points why;
What Hatari does on Fullscreen switch, is just:
- Ask SDL to switch to fullscreen (at least on Linux, SDL uses separate
window for the fullscreen mode, not sure whether that's relevant)
- *IF* that fails, Hatari will ask SDL for the modes supported by the
display and selects the closest one to the Atari resolution (or doubled
one if resolution is small and user has requested such to be doubled)
All differences in the resolution come from below Hatari.
(Unless the attached patch fixes the issue)
> a) it takes the LCD screen some time to resync for the new resolution
>
> b) it sets the resolution so low that it won't fit the ST/Falcon
> resolutions properly
This one sounds like Hatari bug, but I need to debug output.
> c) some apps which are running beside Hatari can get quite fucked up by
> this resolution change,
Why? This has never been a problem on Linux.
If the apps resize when resolution changes although they aren't even
visible, I'd say that's an OS or application bug. And them not resizing
back to original sizes & positions unless user has changed them in the
meanwhile sounds like another (application specific) bug.
> Photoshop in particular, it's annoying to have to
> restart Photoshop becuase you ran Hatari fullscreen
You should complain to Adobe that their SW is buggy.
> d) the LCD performs interpolated scaling so pixels won't be as sharp as
> they would with decent doubling/tripling etc of pixels to the native
> resolution
This would be a problem in your LCD (or SDL) driver or configuration.
It shouldn't be offering bad resolutions to Hatari as Hatari has no way to
know which of them are bad. On CRT the scaling is "perfect" because CRTs
don't have a fixed resolution with bad scaling, but actually support the
resolutions they claim to.
- Eero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hostscreen.diff
Type: text/x-diff
Size: 1898 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20100208/b3b12938/attachment.diff>
More information about the hatari-devel
mailing list