A few quickies
Hi all, while reworking my can'o'worms I like to call a game some things popped up. Not problems really as they do work more or less. But are they efficient? Im deciding which way to go as I move it to OpenGL/SDL. A fun process in itself, right? ;o)
----
Including/defining a class for some common functions vs using a namespace? Im using both at the moment.
Degrees vs radians? I use degrees to keep track of each objects orientation, and converting them to radians when needed.
floats vs doubles? I have read in a couple sites that in hardware floats are converted to doubles anyway, so there is no benefit in using them.
uint16 vs 32. SDL uses 32 for time so I stuck with that for all the time variables. Perhaps instead use 16, and convert time via SDL_GetTicks to 16?
And last, for variables... using constants vs defines. I use both also.
Im sure anyone reading all this code would scream. Thanks :o)
For Degrees vs. Radians, I prefer to use degrees, just 'cause they're easier for me to think in. YMMV.
Floats vs. Doubles... if you have to worry about this on modern hardware, you're probably doing something wrong or doing a LOT of heavy math. For the down-low, floats take less space in memory and are thus faster to load and store. Doubles are more accurate though, and once they're actually loaded into the processor they use the exact same hardware representation.
Uint16 vs 32... again, it shouldn't matter. Use 32.
Constants vs. defines... I would use defines, but I'm not a C language-lawyer.
In general, my experience is it really doesn't matter WHAT coding style you use, as long as you do it CONSISTANTLY. I'm guilty of being bad at this too, don't worry. ^_~
And in terms of efficiency, I really doubt any of the above things are real issues. Concentrate first on writing efficient algorithms, and only worry about bit-counting issues like these in very extreme cases. PROFILE your code!
Floats vs. Doubles... if you have to worry about this on modern hardware, you're probably doing something wrong or doing a LOT of heavy math. For the down-low, floats take less space in memory and are thus faster to load and store. Doubles are more accurate though, and once they're actually loaded into the processor they use the exact same hardware representation.
Uint16 vs 32... again, it shouldn't matter. Use 32.
Constants vs. defines... I would use defines, but I'm not a C language-lawyer.
In general, my experience is it really doesn't matter WHAT coding style you use, as long as you do it CONSISTANTLY. I'm guilty of being bad at this too, don't worry. ^_~
And in terms of efficiency, I really doubt any of the above things are real issues. Concentrate first on writing efficient algorithms, and only worry about bit-counting issues like these in very extreme cases. PROFILE your code!
Quote:
Constants vs. defines... I would use defines, but I'm not a C language-lawyer.
Depends on debugger. Macros/Defines are harder to trace. Constants are fine.
Quote:Original post by Sammy0037
Hi all, while reworking my can'o'worms I like to call a game some things popped up. Not problems really as they do work more or less. But are they efficient? Im deciding which way to go as I move it to OpenGL/SDL. A fun process in itself, right? ;o)
----
Including/defining a class for some common functions vs using a namespace? Im using both at the moment.
Degrees vs radians? I use degrees to keep track of each objects orientation, and converting them to radians when needed.
floats vs doubles? I have read in a couple sites that in hardware floats are converted to doubles anyway, so there is no benefit in using them.
uint16 vs 32. SDL uses 32 for time so I stuck with that for all the time variables. Perhaps instead use 16, and convert time via SDL_GetTicks to 16?
And last, for variables... using constants vs defines. I use both also.
Im sure anyone reading all this code would scream. Thanks :o)
OpenGL uses floats for calculations the last I looked (defined as GLfloat), so using double for that stuff would have it converted to a float.
uint16/32: I use int for standard stuff. Most processors store everything as 4 bytes anyway, so it just pads the 2 extra bytes unless you specify it to compact the storage.
using define (in the wrong situation) can be dangerous, and if you can use const, it would probably be better.
I don't work with degrees/radians much, but if it isn't a bottle neck then whichever is easier to read would be better.
Constants/Defines:
Constants always. The traditional argument always seems to be that debuggers have less trouble with constants but frankly I have never cared much for this line of argument. The main reason to use constants is that they obey scoping rules. Macros have no concept of scope or namespace so if you call a local variable (for example) the same name as a macro, your variable name will be replaced with the value of the macro. There is no performance penalty for using constants rather than defines anyway. (If you don't believe me, consult your friendly C++ standard document)
Constants always. The traditional argument always seems to be that debuggers have less trouble with constants but frankly I have never cared much for this line of argument. The main reason to use constants is that they obey scoping rules. Macros have no concept of scope or namespace so if you call a local variable (for example) the same name as a macro, your variable name will be replaced with the value of the macro. There is no performance penalty for using constants rather than defines anyway. (If you don't believe me, consult your friendly C++ standard document)
Quote:Original post by Sammy0037
Degrees vs radians? I use degrees to keep track of each objects orientation, and converting them to radians when needed.
Personally I prefer to use vectors to keep track of orientation in 2d, a matrix if its 3d. Conceptually its easier to visualize; the object is simply facing in the direction of the vector, or in the case of 3D in the direction the Z column of the matrix(assuming its orthogonal).
However I suggest you have a pair of conversion functions handy for degrees to radians and radians to degrees as you properly will need both at some point or another. The functions in math.h for example work with radians, OpenGL on the other hand uses degrees.
In some ways matrices still seem like voodoo to me. Nah not really. Im not at the point yet where I can just look and one and voila soak it in. But Im getting there ;o)
If using a vector only, how is a rotation of say 45 degrees done? I dont exactly get quarternions yet (Ive been told dont worry about 'how' they work, just that they do). Is this what you mean? Conceptually I understand yawpitchroll the most. But then I have been reading here that its use is becomming somewhat less common.
I thought glRotate can use both radians and degrees. But then I dont know how it would tell which one '3' refers to. Unless its a matter of whether something is a float or int I guess.
One thing Im working to do is get rid of as many divide operations as I can. Also maybe using sin/cos tables. Perhaps with math coprocessors these arent really a concern?
If using a vector only, how is a rotation of say 45 degrees done? I dont exactly get quarternions yet (Ive been told dont worry about 'how' they work, just that they do). Is this what you mean? Conceptually I understand yawpitchroll the most. But then I have been reading here that its use is becomming somewhat less common.
I thought glRotate can use both radians and degrees. But then I dont know how it would tell which one '3' refers to. Unless its a matter of whether something is a float or int I guess.
One thing Im working to do is get rid of as many divide operations as I can. Also maybe using sin/cos tables. Perhaps with math coprocessors these arent really a concern?
Quote:Including/defining a class for some common functions vs using a namespace? Im using both at the moment.
Pick one or the other, and stick with it. At run time, it pretty much doesn't make any difference at all, it will just make it easier for you to maintain your code.
Quote:Degrees vs radians? I use degrees to keep track of each objects orientation, and converting them to radians when needed.
Using radians is marginally more efficient, since that is what functions that use angles pretty much always take as input, and the conversion takes time. However, the time is miniscule, and I would be very, very surprised if it is a bottleneck. The time doesn't matter, but what does is that you have to use radians sometimes, even if it is only when you are directly using functions from other libraries, but you can get away without degrees in most cases. It is best to have just one or the other because if you ever forget to convert at an appropriate time, it creates errors which are can be very hard to locate. Use degrees if you like, but be careful.
Quote:floats vs doubles? I have read in a couple sites that in hardware floats are converted to doubles anyway, so there is no benefit in using them.
It isn't actually true that there is no benefit from using them; I once had an application that needed double precision, and I found a way to hack around the hardware limitations. However, the only reason I needed double precision was because I was trying to write a system that would let me place objects anywhere within the solar system to one tenth of a meter accuracy, all at a realistic scale. Double precision was just barely sufficient for this, but it is far, far more than is needed for just about anything else. Stick to floats because the hack is ugly and floats are great for almost anything.
Quote:uint16 vs 32. SDL uses 32 for time so I stuck with that for all the time variables. Perhaps instead use 16, and convert time via SDL_GetTicks to 16?
In most cases, 32 bit integers are actually supposed to be faster to use on modern processors than 16 bit integers, since the processors are 32 bit. If you plan to have massive arrays of integers, you might consider using 16 bit integers there to save space, but it probably isn't worth it even then. Just use 32 bit integers. And definitely don't convery the result of SDL_GetTicks to 16 bit; that would only allow you to time continuously for a matter of minutes before the numbers got to large to hold at the necessary precision (millisecond, for most games).
Quote:And last, for variables... using constants vs defines. I use both also.
This isn't really a problem. You might find your code a little cleaner if you would stick to one or the other, but it doesn't matter at all in terms of speed, and not much more for anything else.
Quote:If using a vector only, how is a rotation of say 45 degrees done? I dont exactly get quarternions yet (Ive been told dont worry about 'how' they work, just that they do). Is this what you mean? Conceptually I understand yawpitchroll the most. But then I have been reading here that its use is becomming somewhat less common.
I recommend against using vectors unless it seems more intuitive to you; it will just require that you include more conversions. Stick to a single float for 2D, a triad of floats for 3D, or a matrix for either. There's nothing wrong with yaw/pitch/roll.
Quote:Original post by Sammy0037Its really very simple. Like I said Conceptually the object is facing in the direction of the vector. So in 2d a 45 degree rotation is simply a vector pointing at a 45 degree angle. At 45 degrees rise = run or x = y; so if you have a vector (1,1) that’s a 45 degree angle. (1,0) is facing along the x axis or right, (0,1) is facing along the y axis or straight up. (0,-1) is straight down, and (-1,0) is left;
In some ways matrices still seem like voodoo to me. Nah not really. Im not at the point yet where I can just look and one and voila soak it in. But Im getting there ;o)
If using a vector only, how is a rotation of say 45 degrees done? I don’t exactly get quarternions yet (Ive been told don’t worry about 'how' they work, just that they do). Is this what you mean? Conceptually I understand yawpitchroll the most. But then I have been reading here that its use is becomming somewhat less common.
in 3D you use a matrix and its true you don’t have to worry about the implementation, but to find out what direction you just look at the 3rd column which represents the Z axis in the objects local space.
|1 0 0|
|0 1 0|
|0 0 1|
Here the third column is (0,0,1) which is pointing down the worlds Z axis. if the last column is (1,0,0) then the object is facing down worlds X axis.
In general we use the third column to indicate the direction something is facing because in 3D graphics generally Z axis is pointing in to the screen X is to the right and Y is up so for a virtual camera the direction of the third column is the direction it’s looking.
Quote:Original post by Sammy0037
Including/defining a class for some common functions vs using a namespace? Im using both at the moment.
It Depends (on what they do, and whether there's any conceivable use for object instantation), but I prefer to use namespaces. OO is not be-all and end-all, especially in C++.
Quote:Degrees vs radians? I use degrees to keep track of each objects orientation, and converting them to radians when needed.
This approach is reasonable, but I would suggest instead storing everything in radians internally and converting to degrees for *display* if desired. In any case, any conversion back and forth is another source of inaccuracy. Consider making constants for common angle values, e.g. "const double 45_DEGREES = (PI * 45.0)/180.0;"
Quote:floats vs doubles? I have read in a couple sites that in hardware floats are converted to doubles anyway, so there is no benefit in using them.
Floats will potentially be converted to doubles within the registers, for doing the math. If you have a big array of values, you will definitely save space by using the floats, however. But all the same, I would recommend sticking with doubles unless you actually find a good reason not to.
Quote:uint16 vs 32. SDL uses 32 for time so I stuck with that for all the time variables. Perhaps instead use 16, and convert time via SDL_GetTicks to 16?
Honestly, use "int" unless you know you need a specific size.
Quote:And last, for variables... using constants vs defines. I use both also.
Definitely, DEFINITELY use constants. As a general rule, only ever use the preprocessor when you *have* to. After all, who do you trust more: a program that promises "I will read your code and try to translate it into what the computer speaks", or a program that promises "I will do blind text-substitution of X for Y in your file, and basically have no concept of code whatsoever?" (As an exercise, try using the preprocessor to help you write a boring English essay - but you probably shouldn't hand it in! - you should be able to find flags for your compiler that will tell it to just run the preprocessor, and this will drive home the point about it being basically just a dumb text-substitution engine.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement