next »

[John Nesky]

That's a valid point... but it's still an O(1) operation. Premature optimization and all that.

[muku]

Semi-on-topic-ish remark: the standard C float-to-int cast is indeed a shockingly slow beast, which has historical reasons related to the C standard. It's very useful to know that there are ways to do this conversion about 10 times faster:

http://www.stereopsis.com/FPU.html#convert
http://mega-nerd.com/FPcast/

If you ever need to convert floats to ints in anything remotely performance sensitive, do yourself the favor and use one of those. I've seen dramatic increases in frames per seconds for certain pieces of code just by making use of these things.

[drChengele]

Hey, that should come in really useful! Thanks!

[/derail]

[Will Vale]

IIRC with MSVC the clue is if _ftol() shows up in your profile, you're being bitten by slow runtime library float->int conversions.

Screen coordinates for UI and sprites are a problem. You kind of want them in integers since you're talking about pixels, but (if you're using any graphics hardware) they'll have to be converted to floats to draw them eventually, so maybe it's better to store them in floats. Plus you might have a use for subpixel accuracy. I still don't have a rule of thumb I'm happy with for this

[Average Software]

Semi-on-topic-ish remark: the standard C float-to-int cast is indeed a shockingly slow beast, which has historical reasons related to the C standard. It's very useful to know that there are ways to do this conversion about 10 times faster:

http://www.stereopsis.com/FPU.html#convert
http://mega-nerd.com/FPcast/

If you ever need to convert floats to ints in anything remotely performance sensitive, do yourself the favor and use one of those. I've seen dramatic increases in frames per seconds for certain pieces of code just by making use of these things.

Interesting.  I wonder if different architectures are better at it.  I would never make such an optimization, because I don't like to assume x86.

[muku]

Interesting.  I wonder if different architectures are better at it.  I would never make such an optimization, because I don't like to assume x86.

There's also lrint and friends, which should do this kind of stuff portably (it was also mentioned in the second link, I think). As far as I know it's a C99 thing, so I'm not sure how well-supported it is, and whether it always gives the same speedup. Worth a try I guess.

Even if you don't want to limit yourself to x86, you could still use the preprocessor to disable these optimizations in the unlikely case that you're not on x86.

[Average Software]

Interesting.  I wonder if different architectures are better at it.  I would never make such an optimization, because I don't like to assume x86.

There's also lrint and friends, which should do this kind of stuff portably (it was also mentioned in the second link, I think). As far as I know it's a C99 thing, so I'm not sure how well-supported it is, and whether it always gives the same speedup. Worth a try I guess.

Even if you don't want to limit yourself to x86, you could still use the preprocessor to disable these optimizations in the unlikely case that you're not on x86.

For me it's not unlikely, it's 100% certain, as I build Mac OS X universal binaries for PowerPC and x86.