How can I avoid frequent int/float/double casts when developing an XNA application?

Question

I'm making a simple 2D game for Windows Phone 7 (Mango) using the XNA Framework.

I've made the following observations:

• Most of the drawing operations accept floats
• SpriteBatch.Draw accepts a Rectangle which uses ints
• The Math class accepts doubles as parameters and also returns doubles

So my code is full of typecasts between ints, floats and doubles. That's a hell a lot of typecasts.

Is there any way I can get rid of them or I should just not care about this?

Also, do these typecasts present a measurable performance loss?

Answer 1

I noticed this too but unless you notice any speed decrease, it could be considered a micro-optimization. Converting between float and int is relatively expensive whereas converting between float and double is cheap. So wherever you don't need to perform a float to int conversion, you can avoid it. Type casting is generally cheaper than actual conversion (e.g. using Convert.ToInt32). However, all of this is unlikely to be a bottleneck unless you're performing it many times. Also, from this post:

• float, double and int multiplications have the same performance ==> use the right type of number for your app, no worries
• the phone is 4x to 10x slower than the PC I use to develop my apps ==> test with a real phone, don't trust your PC for math operations
• divisions are up to 8x slower than multiplications! ==> don't use divisions, e.g. try to use 1/a then multiply

Unofficial numbers, but I think the last one is quite an accepted method. Also, doubles are often thought to be slower than floats, but this comes down to the system it's running on. AFAIK, Windows Phone is optimized to use doubles, which would explain the Math class accepting those.

All in all, I'd say it's quite common to see casting occur quite a bit with the XNA framework. Of course, it should be avoided whenever possible, but it's unlikely to be the source of bottlenecks for games unless you need to perform it often, in which case other areas may be easier to optimize (or a redesign of the game structure might be required).