[hatari-devel] FYI: new --desktop option

[Eero Tamminen]

Hi,

On maanantai 28 maaliskuu 2011, Nicolas Pomarède wrote:
> Today, Hatari doubles Y so that in the end a high res screen takes the
> same surface on the emulator's screen as a med res screen.
> 
> But technically, the shifter only displays 200 lines, and you get the
> feeling of a Y-stretched image due to the interlacing on a TV.
> 
> Now, if you'd like to record a video of a med res screen, it would be
> more efficient to record it without doubling Y (and then double Y while
> playing the video if you like).

Right, I hadn't thought of that.


> In a more general way, if we want to handle one day some kind of filters
> to zoom x2 or x3, we need to have a non-zoomed image as source, so
> having a parameter to double Y could be useful.

Well, the zooming should retain the aspect ratio and for low-rez that always
means scaling both directions, so I don't think just Y-scaling to be very
useful for low rez.  If your code does that internally, it's fine, but I
think it to be just wasting space[1] in the UI.


> >> The user might want it or not, so he can change the value as he likes,
> >> 
> >> but from the point of view of :
> >>    - maximum emulation accuracy
> >>    - developping demos under Hatari as close as possible as a real ST
> > 
> > Why showing full borders on screen would prevent that, wouldn't on real
> > machine/monitor one anyway see some extra pixels?
> 
> I don't really understand what you mean.

I mean showing full 460 pixels that you mention below and just blanking rest
of the pixels instead of changing the window size.

Changing window sizes are pretty annoying, just try with older versions of
Hatari (that don't have my code that tries to keep the window size stable)
some of the Falcon demos that change resolution often... :-/


> >>    - recording videos that match the result of a real ST

Window size changes in middle of recording sound annoying too...?


> > What if user instead could specify for the video recording either how
> > wide the borders are or how many pixels will be cut from borders....?
> 
> You can hide some parts of the borders (ie crop) the image while
> recording (in fact it's already implemented in my avirecord.c and it's
> used to remove tthe status bar for example), 

Yes, that's why I suggested adding that to recording settings.

> but you can't increase the border to see missing pixels.

And show full borders instead of changing window size.

In the recording part of the SDL "Hatari window settings" dialog there's
also free space[1] for such settings unlike in the rest of the Hatari window
settings dialog.

[1] Your ASCII layout proposal was lacking indicator and frameskip parts, so
it wasn't really useful yet.  With all the info there the *whole* dialog
should fit within about 64x25 characters, otherwise it doesn't fit within
Hatari window.  Even then it might already be too large to be opened with
some of the smaller Videl resolutions. :-/


> An overscan line is max 460 pixels, with 48 pixels in left border. This
> leaves approx 92 pixels for right border (minus hi/lo stabilizer).
> 
> Today, we only render 320+48+48 pixels in the internal video buffer ;
> what I'd like to do is to always render 460 pixels and then extract a
> part of those 460 pixels to copy it to the SDL buffer (using convert/*c
> functions), depending on the size of the border chosen by the user.
> 
> So the cropping would happen during the internal buffer -> sdl
> conversion.

Cropped based on what the demos do?  Or based on what user has set in Border
settings / Max window size?


	- Eero