Like mentioned within my Code...
To speed it up you have to remove some comments - it's only for me using the method to precalculate some sprites which get dynamically positioned on some backgroundsprites.
If you "deactivate" the calculations for multiplying and lightning my code should get a small boost - but then you end up ignoring alpha channels, but since its "pixel by pixel" it will never win the race ;D.
I don't think there is a proper "faster" way of doing it without touching the whole part of allocated memory, pointers and some magic calculations with no need to read RGBA separately.
So one my test if he/she can calculate the resulting color as ONE integer without separating RGBA - this will speed up things.
But like mentioned, I don't use my code for real-time, just for precalculation. And yes, it's no problem to colorize the sprites giving additional parameters for percentively change RGB-Values (eg creating different colorized playersprites placed on one image for performance issues).
bye MB
To speed it up you have to remove some comments - it's only for me using the method to precalculate some sprites which get dynamically positioned on some backgroundsprites.
If you "deactivate" the calculations for multiplying and lightning my code should get a small boost - but then you end up ignoring alpha channels, but since its "pixel by pixel" it will never win the race ;D.
I don't think there is a proper "faster" way of doing it without touching the whole part of allocated memory, pointers and some magic calculations with no need to read RGBA separately.
So one my test if he/she can calculate the resulting color as ONE integer without separating RGBA - this will speed up things.
But like mentioned, I don't use my code for real-time, just for precalculation. And yes, it's no problem to colorize the sprites giving additional parameters for percentively change RGB-Values (eg creating different colorized playersprites placed on one image for performance issues).
bye MB