[hatari-devel] Issue with switching - fullscreen/windowed mode

Eero Tamminen eerot at users.berlios.de
Mon Feb 8 20:54:01 CET 2010


Hi,

On Monday 08 February 2010, Anders Eriksson wrote:
> > 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 havn't been able to build Hatari for over a year, there is always some
> breakage for the Xcode project, and I'm too lame to fix it myself.

Hatari uses now Cmake on OSX (to e.g. create the Xcode stuff).  If it
doesn't work, please report it so that it can be fixed (Thomas is/was
looking into this).

If you cannot check whether patch fixes an issue, it's hard to help.   But 
maybe you could at least check what screen modes your monitor claims to
support according to SDL?  You can use code from falcon/hostscreen.c
functions HostScreen_selectVideoMode() & HostScreen_searchVideoMode()
for this.


> >>   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.
>
> As far as I can tell it sets the screen to 800x600 but the display should
> be at least 832 width to fit all ST borders. So the display is cropped.

Your original image was 320x240, the second image you sent was 640x480.

If the original image didn't have borders, they don't just appear out of
nowhere in fullscreen.  Or did you mean that the same issue is happening
also with ST emulation?

(Falcon graphics code is completely different from the one used for ST
emulation which is the one concerned with border tricks.)


> > 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.
>
> Yeah why would it ever be a problem with Hatari and the rest of the world
> is wrong. I should have expected that answer, really :)

I don't see how it would not be a bug in the application.  Are all OSX apps
as broken when it comes to their window management, or is this misfeature
specific to Photoshop?


> >>   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.
>
> No it's not a problem with my LCD, it's how they work. That's why more or
> less all other apps when run in fullscreen uses the graphics card for
> scaling to native resolution.

On slower devices using the display HW to do the scaling instead of doing it
with SW in Hatari helps with performance.

> Then it can be done with or without 
> interpolation, whatever works best for the specific case, the switch to
> fullscreen is instant as well as it doesn't need to re-sync anything.

But it would be nice to have a SW fallback for this as you suggest.

It should be in SDL though, that can do it much more efficiently than
an application on top of SDL and it would be stupid if every SDL using
application implements something like that on its own...

You could file a bug against the OSX SDL implementation.


> But yeah CRT should be the standard norm when the entire world have
> stopped using them :-)

I do have a couple of (mobile) devices with LCD screens, but Hatari doesn't
have on them the problem you describe either.  They claim to support
only resolution(s) that they support properly.

Btw. those devices display HW has a good scaling algorithm.  It's used e.g.
for fullscreen video playback through the XVideo API.


	- Eero



More information about the hatari-devel mailing list