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

[Troed Sångberg <troed@xxxxxxxxxxx>]

Hi,

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)

regards,

Troed

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

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