Re: [hatari-devel] Open Hatari in big window

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Am Thu, 5 Mar 2020 01:54:32 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 3/3/20 8:25 AM, Thomas Huth wrote:
> > Am Mon, 2 Mar 2020 22:58:18 +0200
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:  
> >> On 3/2/20 4:14 PM, Thomas Huth wrote:  
> >>> Looks reasonable to me at a first glance. Do we also want to
> >>> support floating point values for the -z parameter, too? In that
> >>> case, you also have to replace the "atoi()" there.  
> >>
> >> Attached patch does that, but then I needed to
> >> modify also RenderQuality, as linear scaling will
> >> look horrible with non-integer scaling factors,
> >> whereas that's the only one that doesn't blur
> >> the output when using integer scaling factor.  
>  >
> > I don't think that modifying RenderQuality automatically is such a
> > good idea here. That will only cause confusion e.g. when the users
> > have a look at their hatari.cfg afterwards and wonder why the
> > setting was changed...  
> 
> If it's set automatically to the best value,
> user option could be removed. :-)

I'm not sure whether automatic linear scaling is really always the best
value for everbody ... there might be a perfomance impact for this on
old systems, too?

Maybe we should not care about such old systems anymore, but I think
that's rather something that we should revisit after the next release
has been done, and not do it now before the upcoming release.

> > they should change the RenderQuality setting manually instead.  
> 
> In that case, there should be at least command
> line option for it, so that user can set it
> along with the zoom option.
> 
> I'm OK either way.

Thinking about this for a while, I guess the automatic way is likely
better than adding more config options (we've got too many of those
already anyway)... but let's wait for the next release first. I think
after the release, we should do a major clean-up and also remove SDL1
support (SDL1 is decomissioned since more than 6 years now, so
everybody should now really use SDL2 these days).

> 
> Btw. Why there's an option for disabling
> SdlRenderer usage, is it e.g. because it needs
> working GLES support, and all platforms might
> not have that?

Yes, that was the original intention. Not sure whether we still need
this now in 2020 since every recent machine should have GL support
now... maybe another thing to clean up after the next release...

 Thomas



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/