| Age | Commit message (Collapse) | Author |
|---|
|
the return is not NULL)
|
|
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
|
|
other blitters cleared the memory too
|
|
work for non-8bpp-mapped sprites.
|
|
|
|
(non) animated sprites, so the least expensive variant can be chosen (MJP)
|
|
to prevent unneeded execution of expensive code (MJP)
|
|
|
|
|
|
later on (MJP)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sse blitters (MJP)
|
|
variables in the SSE blitters (MJP)
|
|
"remap" in the SSE2/SSSE3 blitters as well
|
|
others (MJP)
|
|
exists before attempting trying to instantiate an instance
|
|
With 32bpp base set about 15-20% faster in the Draw function (slower with 8bpp base set). Overall, with 32bpp base set, about 5% faster.
|
|
With 32bpp base set about 40% faster than 32bpp-optimized, or about 10% for 8bpp base sets in the Draw function. Respectively about 8 and 1% of total run time
|
|
With 32bpp base set about 35% faster than 32bpp-optimized, or about 10% for 8bpp base sets in the Draw function. Respectively about 6 and 1% of total run time
|
|
With 32bpp base set about 30% faster than 32bpp-optimized, or about 10% for 8bpp base sets in the Draw function. Respectively about 5 and 1% of total run time
|
|
|
|
|
|
|
|
|
|
parameters were added making it non-functional
|
|
|
|
|
|
Eagle_rainbow)
|
|
recolouring to 128.
|
|
|
|
|
|
|
|
far regarding not needing to update the colour mapping when (re)initialising the palette
|
|
|
|
|
|
increase the bytes per pixel
|
|
the amount of compares. This is possible because the function is called with only 2 possible conditions: from 0 to 255 (full palette update, 8bpp only) or from PALETTE_ANIM_START to 255
|
|
|
|
blitter.
|
|
remapping for 32bpp sprites
|
|
out some indirect calls
|
|
blitter so changes of the palette data during the game don't influence drawing (with SDL)
|
|
dirty variables into a single structure
|
