[hatari-devel] FYI: new --desktop option

[Eero Tamminen]

Hi,

On keskiviikko 09 maaliskuu 2011, Christer Solskogen wrote:
> On Tue, Mar 8, 2011 at 7:20 PM, Eero Tamminen <oak at helsinkinet.fi> wrote:
> > What's your Falcon resolution,  1, 2, 4, 8 or 16 bit?  And does the
> > issue happen both with Falcon HiColor and bitplane modes?
> 
> The same problem occurs when I use 4 color, 16 color, 256 color and True
> Color. I don't start any application. I just boot the machine (no
> autofolder or startup disk)

According to this SDL forum post, red and blue color channels have been 
swapped in later OSX versions:
http://forums.libsdl.org/viewtopic.php?t=5030&sid=a24c2194e10c62be658d687ddd9eaa17

Looking at the Hatari code, all window updates should go through SDL color
mapping which should take care of this issue, unless the issue is in SDL.

You said that the issue happens only in 32-bpp mode, when switching
from fullscreen to windowed mode.  If it's possible that the color channel
order changes on OSX between in fullscreen & windowed mode, it's possible
that palette color mappings could break for non-HiColor modes, but you're
saying that this issue happens also in HiColor which doesn't use palette...

If you switch back to fullscreen, do the colors get correct again?


> > (I cannot reproduce the issue on Linux with either 16 or 32 Hatari bpp,
> > or any Falcon bit depth.)
> > 
> >> As far as I can see "--desktop" does absolutely nothing. I guess that
> >> is a good thing :-)
> > 
> > What's your desktop resolution and what you have configured as your max
> > Hatari zoom size?
> 
> By default max zoom size and my resolution is the same.

What is your desktop resolution?

If you use "-z 1 --desktop" and toggle fullscreen, does that change
anything?


	- Eero

Ps. While checking the Hatari code, I noticed it was redundantly doing per-
pixel Uint8 -> Uint32 -> Uint8 conversions for Videl updates, this is now
fixed.