| Re: [hatari-devel] Hatari screen options (was: Hatari manual.html) |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On torstai 27 helmikuu 2014, David Savinkoff wrote:
> I have noticed (for a long time) that "Max Zoomed win"
> in the SDL menu only shows values that are dividable
> by sixteen (probably to make scrolling them faster),
> however, any number works. Note that some resolutions
> (400x300) are not dividable by sixteen. Maybe making
> them dividable by 8 would be better.
That would make require user to do 2x more mouse clicks
to change resolution, current 16 pix is thought to
be OKish compromize. You can set other values from
command line and in config file.
Btw. For VDI resolution selection, the limits come from
TOS, as VDI resolution is Atari resolution, not host one:
- The screen width must be dividable by 16 bytes
(i.e. 128 pixels in monochrome, 32 pixels in 16 color mode),
or the text mode scrolling function of TOS will fail. [1]
- The screen height must be a multiple of the character
cell height (i.e. 16 pixels in monochrome, 8 pixels
in color mode).
- Eero
[1] At least some of the supported TOS versions.
>
> ----- Eero Tamminen wrote:
> > 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