If doing this over a large number of pixels, wouldn't using floating point maths be horribly slow? Or maybe it's just my love of horribly unreadable fixed-point maths with much &-ing and bit-shifting that's saying this. [rolleyes]
After all, if you are dealing with the 32-bit integer colour values in the first place, it makes more sense to stick with fixed-point maths than to cast to floats then back again.
SOLVED..... C++ - how does alpha blending work?
It wouldn't necessarily be horribly slow (I mean, what do you buy an Athlon64 FX2 4400+ for?), and premature optimization IS the root of all programming evil, but this would be something to look at during profiling. Much of the FP code is helper functions anyway.
Cheers,
Twilight Dragon
Cheers,
Twilight Dragon
Author
Personally I'm only using these routines to create my character sprites at the start of each level, so even if it is horribly slow, I expect we're still talking about less than a second even if there were hundreds of sprites?
Quote:Original post by TDragonI'm an assembly programmer at heart. I've never had a "premature optimisation" problem, as such, seeing as I'm used to writing everything at a lower level anyway. [wink]
...and premature optimization IS the root of all programming evil...
Quote:Original post by darenkingAh, right. I thought you were writing these functions to be used in your renderer. I doubt the speed difference would be noticable if it's part of a loader.
Personally I'm only using these routines to create my character sprites at the start of each level...
Absolutely; depending on your CPU (anything with a decent FPU, which most modern CPUs have), I'd expect less than a millisecond total from these routines (for 100 sprites).
Author
Much faster than a human could do it by hand, with coloured beads and pieces of cloth for example.
Well, that depends; have you ever watched some of those ladies from Uganda that weave baskets for a living?
;)
;)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
