| Re: [hatari-devel] Re: reverting Max window size setting to Hatari v1.4 size? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On keskiviikko 25 tammikuu 2012, Nicolas Pomarède wrote:
> On 24/01/2012 22:54, Eero Tamminen wrote:
> > On tiistai 24 tammikuu 2012, Laurent Sallafranque wrote:
> >> That's OK for me.
As nobody seemed to be against this, I commited the change.
> speaking about window's size, I think the current behaviour for STF/STE
> is really hard to use. Having to specify an x/y resolution (such as
> 640x400 for example) to get x2 zooming on X and x2 zooming on Y looks
> not easy to use.
The default limit was your screen resolution. User would need to care
about it / change it only if he wanted smaller Hatari window size[1].
[1] Especially in earlier Hatari versions where resolutions weren't
constrained to screen resolution (support for finding that was
only in recent SDL versions) and too large ones caused
Hatari aborts or X crashes.
> Many users might understand it anyway, but what about
> specifying the resolution to get double pixels on X/Y + overscan borders
> ?
User doesn't need to do anything. He sees that by default.
Or then his screen doesn't support large enough resolution
for that.
> So, leaving apart extended VDI/falcon mode with really extra large
> resolution, and just focusing on STF/STE, I would propose the following
> settings :
>
> low res : - zoom X (yes/no, to double X res)
> - zoom Y (yes/no, to double Y res)
>
> mid res : - zoom Y (yes/no, to double Y res) (only zoom Y, width
> is already 640 pixels)
Why somebody would want a squashed resolution where medrez isn't zoomed
vertically or lowrez is zoomed only in one direction?
No real monitor on Atari showed such a thing.
> borders (common to low/med/hi res)
> - left border : no or a number of pixels (multiple of 16)
> - right border : no or a number of pixels (multiple of 16)
> - top border : no or a number of pixels
> - bottom border : no or a number of pixels
>
> No more reference to an absolute number of pixels for X or Y, I don't
> think that an useful information : the user wants bigger window and
> borders or not.
In which case user wouldn't want to see everything, when borders
are enabled?
Only case I can think for this is where all of these are true:
* User runs Hatari in a mobile phone which resolution isn't
large enough for everything
* Current Hatari code which clips the content from center of
the full area hides some potentially interesting thing in
one of the borders
* User knows it's there and wants to offset Hatari on his screen
so that he sees this interesting thing
I think this is very much of a corner-case.
> This would also be more consistent with the fact that we still have the
> "-z" command line option, but no more option in the UI to change zoom
> factor.
>
> Not everything could fit in the same window ; we could have one for the
> zooming mode, and another one for the borders settings (unless someone
> here wants to submit some ascii art to design a single window with all
> options in it).
>
> What do people think ?
Fine by me as long it's somebody else who implements the SDL GUI part.
And more importantly, makes sure that the code in screen.c still handles
the case when user's screen supports smaller resolution that what
the options he's selected in Hatari settings would require.
Because without that, and such settings being saved with fullscreen enabled,
Hatari would abort on every startup.
- Eero