|Re: [hatari-devel] Open Hatari in big window|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
This is a multi-part message in MIME format.
On 3/28/20 9:17 PM, th.huth@xxxxxxxxx wrote:
Am 13.03.2020 23:26 schrieb Eero Tamminen:
Ok, I'll wait until Thomas is back and has
commented on it, and if everything looks OK,
include it for the release.
I'm currently stuck at the other side of the globe, without any
possibility to get back within the next days (there are hardly any
planes flying anymore), and reviewing patches is a pain without a proper
Computer... So here are just some quick comments:
1st patch: Did you check with sizeof(CNF_STRUCT) that this really makes
a difference? Otherwise just drop the patch, please.
CNF_SOUND size isn't changed, it's 4112 with both, so I dropped that
part of the patch.
CNF_SCREEN size decreases, so I left that:
- SDL2: 64 -> 56
- SDL1: 56 -> 48
+ if (zoom >= 1.0)
+ if (zoom >= 2.0)
+ ConfigureParams.Screen.nMaxWidth *= 2;
+ ConfigureParams.Screen.nMaxHeight *= 2;
One if should be enough.
That was already gone with the change I mentioned.
New version attached.
Please also do not separate pfmt from rm, gm and bm.
Format is needed to re-create the texture, but
red, green & blue are needed only for surface
Are you saying that I should re-create also
surface whenever scale factor is changed, although
that is redundant?
3rd and 4th patch look ok to me at a first glance.
In latest version ST-low res is always doubled
with SDL2. It was too weird getting mono and
other resolutions doubled, when 2x zooming factor
was saved to Hatari config (as result of using
that to get reasonable sized ST-low res).
That way things work as with real monitor, as
the size of the monitor doesn't change based
on resolution. :-)
To get 320x200 window for ST-low with the patch
set on SDL2, one would need to limit Hatari max
window size to <640x400, and set Zoom factor to 1.
I think that change is acceptable now that GPUs
and high resolutions are common.
That sounds pretty confusing, too.
It's something that almost nobody should need or
want. Even with my 10 year old monitor, smallest
supported resolution is 640x480.
Only use-case I can think where user would
actually want 320x200 resolution for ST-low,
is for video recording, due to PNG compression
overhead, but I can update "video-recording.txt"
to document that.
(Eventually we should use some other compression
format for video frames than PNG, or e.g. pipe
the data directly to FFmpeg for compression,
potentially with e.g. VA-API HW acceleration.)
Maybe specifying a zoom factor is the
wrong approach these days, and we should rather provide an option to
select the preferred window size instead?
I think forcing exactly the same size e.g. for
ST-low and TT-high would look too bad. I want my
emulated pixels to be sharp, not blurry & with
If one would need to specify different sizes
for different resolutions and machines in SDL GUI
(+ Python GUI & Mac GUI), and on command line,
I think it would be too complicated.
IMHO SDL window being user resizable is enough for
... Then hatari can decide completely internally
> wether the x2 low res renderes should be used or