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...