|Re: [hatari-devel] How many colors when rendering in Hatari ?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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.