Re: [hatari-devel] Hatari screen options (was: Hatari manual.html)

[David Savinkoff <dsavnkff@xxxxxxxxx>]

----- Eero Tamminen wrote:
> Hi,
> 
> On tiistai 25 helmikuu 2014, David Savinkoff wrote:
> > Previously, I had made the comments (below) and mentioned
> > that Hatari regressed. Hatari probably has not regressed.
> > 
> > I believe that I would get the same results if I used
> > the same method to discover video modes as I did with
> > my CRT monitor years ago.
> > 
> > The reason is that Hatari requests and gets the 416
> > when providing 416x276 or 416x288 etc.
> > Then the monitor then selects the best it can do.
> > (416x312 for CRT // 416x312 scaled to 832x624 for LCD)
> > 
> > When requesting 400x300:
> >
> > resolution limit:
> >         400 x 300
> > limited resolution:
> >         1 * (32 + 320 + 32) x (29 + 200 + 47)
> >         = 384 x 276 (+ statusbar)
> > SDL screen request: 384 x 276 @ 0 (windowed)
> > SDL screen granted: 384 x 276 @ 32
> 
> Above shows that Hatari does what it's supposed to do:
> - screen.c asks resolution.c for smallest resolution
>   where max ST screen size fits
> - resolution.c checks that, and if user's max size is
>   smaller (or no suitable resolution was found), returns
>   user's max size instead
> - screen.c selects zoom level and border sizes that
>   fit into that size
> - screen.c requests frame buffer of that size from
>   SDL, and based on above output, gets it

What Hatari needs to do here is USE the user-supplied
resolution (if available), and crop the picture if necessary.
There is no need for Max Size because the picture gets
cropped if it is larger than the window.
In the situation where the user requests a nonexistent
resolution, Hatari will have to select one that is closest.

> SDL will then select suitable resolution for that frame-
> buffer and center the framebuffer to that resolution [1].
> What it selects, is resolution equal, or next up from size
> Hatari requested for framebuffer.  If no user max size is
> specified, SDL selected resolution is same as reported limit.

SDL's selection logic is the last resort when all else fails.
 
> [1] With earlier SDL versions Hatari needs to do the padding
>     / centering itself, newer SDL versions do it for Hatari.
> 
> The purpose of what Hatari does is avoid Hatari aborting
> because it asked for too large (non-existing) resolution.
> 
> Purpose of user specified max size is to help in that,
> and limiting Hatari window size in windowed mode
> (very useful for Falcon mode).
> 
> 
> > Then the monitor then selects the best it can do.
> > (400x300 for CRT // 400x300 scaled to 800x600 for LCD)
> 
> So this is what you actually wanted?

Intuition would suggest that if you requested a resolution
that actually existed, Hatari would request it and get it.
Here Hatari requests something different and accidentally
gets the correct resolution.

> > It looks like Hatari could be improved though.
> > Hatari should be primed with standard video modes so
> > that it can make smarter requests.
> 
> Smarter how?

By using the resolutions provided in this email.

If a user requests one of the resolutions in this email,
Hatari should unconditionally request it from SDL.
If the request fails, Hatari should make the request
that it currently does.

> > My suggestion is
> > to prime Hatari with the xrandr results that I gave
> > for my LCD monitor (unless you can find a more
> > inclusive list). Note that the important video modes
> > are the low resolution modes, or multiples thereof.
> 
> Hatari uses SDL, not Xrand.  SDL is portable, Xrandr not.
> 
> 
> 	- Eero
> 
> > (below)
> > **** EXHIBIT (1) *************************************
> > I asked for 416x312 and got 416x276 because
> > Hatari has regressed from when I tested years ago on
> > my CRT monitor (by laboriously incrementing through
> > sequential numbers with the Hatari SDL GUI to observe
> > video modes. Notably, being able to see when 400x300
> > and 416x312 popped up).
> > 
> > Hatari used to provide the resolution requested with
> > the status bar disabled. Now the user-requested
> > resolution is ignored and replaced with something else.
> > 
> > I did not notice because the visual impact is insidious.
> > 
> > ******************************************************
> > !!!   SURPRISE   !!!
> > 
> > I ask for 416x312
> > Hatari requests:
> >  SDL screen request: 416 x 276 @ 0 (windowed)
> >  SDL screen granted: 416 x 276 @ 32
> > I say WRONG and WRONG
> > Monitor says (on screen independently):
> >  832x624
> > I get a full screen at 416x312 (see xrandr below)
> > *******************************************************
> > 
> > $ xrandr
> >  SZ:    Pixels          Physical       Refresh
> > *0   1280 x 1024   ( 361mm x 292mm )  *60
> >  1   1280 x 960    ( 361mm x 292mm )   60
> >  2   1280 x 800    ( 361mm x 292mm )   75   70   60
> >  3   1280 x 768    ( 361mm x 292mm )   85   75   70   60
> >  4   1280 x 720    ( 361mm x 292mm )   85   75   70   60
> >  5   1152 x 864    ( 361mm x 292mm )   75   70   60
> >  6   1024 x 768    ( 361mm x 292mm )   75   70   60   85
> >  7    832 x 624    ( 361mm x 292mm )   75
> >  8    800 x 600    ( 361mm x 292mm )   75   72   60   56   85
> >  9    720 x 400    ( 361mm x 292mm )   70   85
> >  10   640 x 480    ( 361mm x 292mm )   75   73   67   60   85
> >  11   640 x 400    ( 361mm x 292mm )   85
> >  12   640 x 350    ( 361mm x 292mm )   85
> >  13   640 x 360    ( 361mm x 292mm )   85   75   70   60
> >  14   416 x 312    ( 361mm x 292mm )   75
> >  15   400 x 300    ( 361mm x 292mm )   85   75   72   60   56
> >  16   320 x 240    ( 361mm x 292mm )   85   75   73   60
> >  17   360 x 200    ( 361mm x 292mm )   85
> >  18   320 x 200    ( 361mm x 292mm )   85
> >  19   320 x 175    ( 361mm x 292mm )   85
> > Current rotation - normal
> > Current reflection - none
> > Rotations possible - normal
> > Reflections possible - none
> > 
> > xrandr output looks very reasonable. Resolutions
> > 416x312 and less appear undocumented for the LCD
> > monitor. Maybe the R100 [Radeon 7200 / All-In-Wonder]
> > video card does something.
> > 
> > Sincerely,
> > David Savinkoff
> 
> 
>