SDL: Passing Float to blit functions...?
I'm following the tutorial here, and have gotten the best performance I've ever gotten with SDL, which is great.
(The source is in the tutorial... just scroll down until you reach it.)
The tutorial is an OOP tutorial to help programmers put together working games. However, something that irks me is the fact that he passes so many float variables into parameters that are designed to take 32-bit integers...
In the code, a float is multiplied with a variable that is added to an int representing the position of a sprite.
I'm on Ubuntu Linux 64-Bit edition, and G++ spits out warnings about this... but the program works, even when cross-compiled...
This practice of using floats instead of ints has risks, I know... I've tried replacing them with integers, but then that takes away the benefit of having values slowly incrementing to 1, which basically means that nothing moves, since anything less than 1 is rounded down to 0.
My question is:
If this makes the program less portable, is there any other way of doing this...?
Is there any safe way to cast them to ints at certain places to make this behave the same way in different platforms?
One can use static_cast<int>(somefloat). This will truncate the floats, so that effectively anything beyond the decimal point will be ignored. To get rounding that one might expect, you can use static_cast<int>(somefloat + 0.5f).
Thanks! That worked perfectly. After all calculations are done with floaters, I just cast the values before they are sent to SDL_Blit.
This is just a guess, but static seems to mean that there's only one of this object. A static variable in a class will be the only one there, needless of how many (or none) instances there are.
So a static_cast must be where the object that is called is the same as the object returned. Am I right? And does this mean that normal casts create a new object with the same handle?
So a static_cast must be where the object that is called is the same as the object returned. Am I right? And does this mean that normal casts create a new object with the same handle?
(int)somevar is a C style cast any may be unsafe depending on the actual type of somevar whereas static_cast<int>(somevar) is a C++ style cast which is more type safe. static_cast does not allow arbitrary cast as C style casts do. For this reason there are other cast types such as const_cast, dynamic_cast and reinterpret_cast where the later can basically do everything the C style cast can do. Using C++ style casts in your source code should be prefered since they are more verbose and if something goes wrong because of a cast the error can be tracked down more easily.
A performance note: Casting floats to integers (no mater which casting operator you use) is a potential performance problem if you do it too often. In such a case it would be advisable to use a special float2int function instead of the buildin. I think Nvidia's homepage has some info about why casting is a performance problem and how to avoid it.
A performance note: Casting floats to integers (no mater which casting operator you use) is a potential performance problem if you do it too often. In such a case it would be advisable to use a special float2int function instead of the buildin. I think Nvidia's homepage has some info about why casting is a performance problem and how to avoid it.
static_cast is a cast operator that performs a limited number of relatively safe conversions. For example, it can cast numeric types to numeric types or reverse any standard conversion sequence. As such it is more limited in scope than a C-style cast such as (int), which will apply pretty much any transformation in the language to get it to cast. For example, you can use (int) to cast a pointer to an integer type, but that kind of cast will fail if you use a static_cast. static_cast is to be preferred over C style casts as it can help catch stupid mistakes. For example:
float foo(void);int x = (int)foo; // compiles, will cast the function pointer to an integerint y = static_cast<int>(foo); // won't compile
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement