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

[Thomas Huth <th.huth@xxxxxx>]

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