Re: [hatari-devel] Open Hatari in big window

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 4/14/20 7:15 AM, Thomas Huth wrote:
> Am Wed, 1 Apr 2020 00:43:11 +0300
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > main.c::Main_EventHandler() needs to call that on window resizes, and
> > it doesn't know anything about format.
>
> Ok, I missed that.
>
> > Would separate function providing both masks & format for given
> > bitdepth be any better?
> >
> > (See attached patch.)
>
> No, I in this case, you better keep your original solution.

Ok, dropped that commit.


> I now also gave your patches a try (yes, I'm finally back at home!),
> and I think it's ok to commit them. It's indeed a little bit confusing
> that low resolutions are now scaled with "-z 1" by default, too, but I
> also don't have a better idea with regards to the problem that you get
> very different window sizes otherwise when the zoom factor is read from
> the config file and you either start in mono or in color resolution
> mode...
>
> Maybe we should simply not save the zoom factor to the config file
> instead?

It's by default 1.0, and that + max width/height
values get changed only if user gives another
value on command line [1], *and* saves Hatari configuration afterwards.

If user has done that, I would assume him/her to
actually want Hatari window to be scaled up every
time, e.g. because s/he has a 4K monitor...


[1] Currently there's no SDL GUI support for
    setting zoom factor, only max width/height.


> Or maybe we should offer the possibility to configure two
> different zoom factors, one for low resolutions, and one for
> "normal" resolutions?

Are you talking about the max width/height SDL
framebuffer size setting (controlling ST-low
resolution doubling & border sizes), or the new
zoom factor setting used to scale the framebuffer
to host screen?


If latter, what are the use-cases for wanting
radically different, or marginally different
Hatari windows scaling factors based on which
Atari resolution emulation happens to have?


If former, remember that current "-z 1" mode
framebuffer size limits work *very* badly with
some Falcon demos...

Even Falcon bootup is funky without low-rez screen
doubling, as you get *4* different window sizes
during TOS v4 bootup (before the patches):

$ hatari --machine falcon --dsp none --tos tos404.img -z 1

1. large screen
2. narrow screen
3. large screen (memory check)
4. small screen (desktop)


> Anyway, if we decide to go with the current approach, I think you
> should improve this documention section from your 4th patch:
>
> +With Hatari SDL2 build, ST-low resolution is always doubled, so that
> +all resolutions have approximately same starting size. Any zoom factor
> +can be used to scale that up (or down), regardless of the selected
> +Atari machine or monitor type.

I've changed above to more specific:
------------
With the Hatari SDL2 build, this option overrides max width/height 
options so that e.g. ST-low  resolution gets always doubled, and all 
resolutions (except TT-high) have approximately  the same size, like on 
a real CRT monitor.
------------


> Please mention that it is possible to prevent the automatic doubling by
> specifying smaller values with --max-width and --max-height.

I've added:
------------
To get SDL1 "-z 1" behavior with SDL2, use "--zoom 1 --max-width 416 
--max-height 276" (if you don't need borders, 320x200 size is enough). 
Disabling low resolution doubling like this is not recommended for 
Falcon emulation because TOS v4 bootup and some demos switch resolutions 
frequently.
------------


	- Eero