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

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


Hi,

Thomas, any news on this?  It has been working
fine for me.


	- 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







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