Re: [hatari-devel] How many colors when rendering in Hatari ?

[ Thread Index | Date Index | More Archives ]

On 16/04/2013 21:09, Eero Tamminen wrote:

Currently this checking & updates are done in very fine-grained way,
long at the time I think.  The proposal was to do this check line
at the time, as this can be done much more generic way, just using

I never measured this, but I'm surprised doing a memcmp (so doing 1 read of source and 1 read of destination, before a possible write) is faster that doing a "brute force" memcpy (1 read of source and 1 write to dest).

Of course the memcmp can avoid to do the ST memory -> SDL conversion when nothing change too much on screen.

At least from my 68000 experience on the ST/Amiga, the direct memcpy would be faster.

But what is the balance point ? If the screen is updated each vbl (case of a scrolling in a game or most demos), doing a memcmp is clearly a loss of time, doing the copy immediatly would be faster. In the game of a gem desktop, it's quite possible resfresh are less frequent and not on the whole screen.

So, at what percentage of screen change is it faster to do a direct copy/conversion instead of first comparing buffer ?

I think this would need to be measured in a reproducable way to see what's gain of memcmp in different cases/bpp.


Mail converted by MHonArc 2.6.19+