Re: [hatari-devel] --force-max not working in 2.0.0

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 12/19/2016 09:39 AM, Thomas Huth wrote:
> On 18.12.2016 23:15, Eero Tamminen wrote:
> > Thomas, any news on this?  It has been working
> > fine for me.
>
> I did some quick-n-very-dirty performance measurements with "top", and
> it seems to me that 32-bit rendering is some percents slower here.
> So I think a good solution would be:
>
> - If nForceBpp is set, use that value
>
> - If nForceBpp is zero, use 16 bpp unless screen recording is enabled

For screen recording, it may be enough to document best practice
(and problems) in doc/video-recording.txt.


> I'll try that out sometime after X-Mas, but this week, I do not have
> time for this.

Ok, thanks!


	- Eero
>  Thomas
>
>
> >     - Eero
> >
> > On 11/30/2016 09:02 AM, Thomas Huth wrote:
> > > On 30.11.2016 00:05, Eero Tamminen wrote:
> > > > Hi,
> > > >
> > > > On 11/29/2016 11:49 PM, Thomas Huth wrote:
> > > > > Am Tue, 29 Nov 2016 18:55:57 +0100 (CET)
> > > > > schrieb Anders Eriksson <ae@xxxxxx>:
> > > > > > There is a bug in all versions of Hatari I've tried; if you record a
> > > > > > Falcon video, and it change the screen size, the recording will abort
> > > > > > if you are using 32-bit rendering. Only with 16-bit the recording
> > > > > > will continue. Yes this is with --force-max.
> > > > >
> > > > > I think this happens because we're rendering Falcon hi-color mode
> > > > > always with 16 bpp by default, while the indexed resolutions are
> > > > > rendered into 32 bpp. So if a demo switches between hi-color and
> > > > > indexed mode, the recording has to be stopped because the bpp of the
> > > > > host screen changed.
> > > > >
> > > > > Maybe we should rather always use 32 bpp nowadays, e.g. with a patch
> > > > > like this:
> > > > >
> > > > > diff -r df34f122c82a src/falcon/videl.c
> > > > > --- a/src/falcon/videl.c    Mon Nov 28 11:01:05 2016 +0100
> > > > > +++ b/src/falcon/videl.c    Tue Nov 29 22:44:59 2016 +0100
> > > > > @@ -863,10 +863,8 @@
> > > > >  /* User selected another zoom mode, so set a new screen resolution
> > > > > now */
> > > > >  void VIDEL_ZoomModeChanged(bool bForceChange)
> > > > >  {
> > > > > -    int bpp = videl.save_scrBpp == 16 ? 16 :
> > > > > ConfigureParams.Screen.nForceBpp;
> > > > > -
> > > > >      Screen_SetGenConvSize(videl.save_scrWidth, videl.save_scrHeight,
> > > > > -                          bpp, bForceChange);
> > > > > +                          ConfigureParams.Screen.nForceBpp,
> > > > > bForceChange);
> > > > >  }
> > > > >
> > > > >
> > > > > @@ -903,7 +901,7 @@
> > > > >      }
> > > > >      if (change) {
> > > > >          LOG_TRACE(TRACE_VIDEL, "Videl : video mode change to
> > > > > %dx%d@%d\n", videl.save_scrWidth, videl.save_scrHeight,
> > > > > videl.save_scrBpp);
> > > > > -        Screen_SetGenConvSize(videl.save_scrWidth,
> > > > > videl.save_scrHeight, videl.save_scrBpp == 16 ? 16 :
> > > > > ConfigureParams.Screen.nForceBpp, false);
> > > > > +        Screen_SetGenConvSize(videl.save_scrWidth,
> > > > > videl.save_scrHeight, ConfigureParams.Screen.nForceBpp, false);
> > > > >      }
> > > > >
> > > > >      if (vw < 32 || vh < 32) {
> > > > >
> > > > >
> > > > > ... but this needs a bit of testing before I dare to commit it, to see
> > > > > whether it has performance impacts or other problems...
> > > >
> > > > Hm, isn't it rather allowing user to force
> > > > the bitdepth (which is preferable), instead
> > > > of using fixed 32-bit bitdepth?
> > >
> > > Yeah, sure, I just had in mind that likely 99% of all users are using
> > > the default value for nForceBpp and thus the code will use 32 bpp here
> > > with my patch.
> > >
> > >  Thomas