| Re: [hatari-devel] Hatari screen options (was: Hatari manual.html) |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On keskiviikko 26 helmikuu 2014, David Savinkoff wrote:
> What Hatari needs to do here is USE the user-supplied
> resolution (if available), and crop the picture if necessary.
Attached patch does that.
Downsides of what you request are following:
* If you disable borders from Hatari settings, you get non-optimal [1]
resolution unless you re-calculate and change the user-supplied
resolution.
* Requesting larger framebuffer from SDL than is strictly needed,
uses more memory.
So it doesn't make sense to make that default.
- Eero
[1] While it might match your screen ratio better, screen coverage
and performance wise it's worse.
> 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
diff -r 9488d40040dc src/screen.c
--- a/src/screen.c Sun Feb 23 17:40:23 2014 +0200
+++ b/src/screen.c Wed Feb 26 21:38:40 2014 +0200
@@ -431,13 +443,19 @@
SBarHeight = Statusbar_GetHeightForSize(maxW, maxH);
/* re-calculate statusbar height for this resolution */
Statusbar_SetHeight(maxW, maxH-SBarHeight);
+
+#if !SAVE_MEMORY /* request resolution gotten from SDL or user max settings, Hatari does screen padding */
+ }
+#endif
/* center Atari screen to resolution */
PCScreenOffsetY = (maxH - Height)/2;
PCScreenOffsetX = (maxW - Width)/2;
/* and select desktop resolution */
Height = maxH;
Width = maxW;
+#if SAVE_MEMORY /* request minimum sized framebuffer from SDL to save memory, SDL does screen padding */
}
+#endif
sdlVideoFlags = SDL_HWSURFACE|SDL_FULLSCREEN/*|SDL_DOUBLEBUF*/;
/* SDL_DOUBLEBUF helps avoiding tearing and can be faster on suitable HW,
* but it doesn't work with partial screen updates done by the ST screen