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

[ Thread Index | Date Index | More Archives ]


Video recording Falcon emulation still doesn't work well with SDL2. Where did this thread from 2016 end up? Was the 32-bit rendering patch merged and so the "only" issue still left is to implement scaling to max resolution for SDL2 as well?

(Sorry for bad quote - I've switched email service and cannot bring up the old thread easily)


From: Eero Tamminen <oak@xxxxxxxxxxxxxx>
Date: Tue, Dec 20, 2016 at 11:56 PM
Subject: Re: [hatari-devel] --force-max not working in 2.0.0
To: hatari-devel@xxxxxxxxxxxxxxxxxxx


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


    - Eero

On 11/30/2016 09:02 AM, Thomas Huth wrote:

On 30.11.2016 00:05, Eero Tamminen wrote:


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 :
     Screen_SetGenConvSize(videl.save_scrWidth, videl.save_scrHeight,
-                          bpp, bForceChange);
+                          ConfigureParams.Screen.nForceBpp,

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


Mail converted by MHonArc 2.6.19+