# lemming77

Member

5

1. ## Double and Float based fundamental types (vectors, matrices, etc.) implemented side by side?

Hi, As I'm sure is standard practice, I have written a library to implement types like vectors, matrices, and so on, and it all works quite nicely. However I have hit a hurdle. Using D3D9 for graphics, that seems to like having it's data in the form of single precision floats. Which is fair enough. But I'm feeling the need to do some intense physics simulation using double precision. So what I really want is some means of implementing both without duplicating my entire library. My current implementation lets me switch between Float and Double types before compiling by means of a typedef instruction. But this doesn't quite give me the solution I need, as I'm stuck choosing one over the other. [source lang="cpp"]// The library is called Util. Not a great name, I know. Here's a small excerpt // from Util.h. Define DOUBLE before compiling to use the double type. // Otherwise, use the float type. #ifdef DOUBLE typedef double Real; #define NAMESPACE Maths::Double #else typedef float Real; #define NAMESPACE Maths #endif namespace Util { namespace NAMESPACE { struct Angle; // Euler angle struct Matrix; // 4x4 Matrix struct Quaternion; struct Vector3; } } // An excerpt from Vector3.h namespace util { namespace NAMESPACE { // Vector3, 3D coordinates struct Vector3 { public: Real x, y, z; Vector3(); // x=0 y=0 z=0 Vector3(Real); // x=a y=a z=a Vector3(Real, Real, Real); // x=a y=b z=c /// ... Etc. }; }[/source] Can anyone recommend a means to implement both types into the same library? Preferably while duplicating as little source code as possible. I'm using Visual C++ 2010 Express. Thanks
2. ## Let's have a good POV..

I believe OpenGL is an open standard, rather than being open source. But that's a mistake we all make at some point. My understanding is that the main distinguishing characteristic between C and C++ is that C++ is object oriented, while C is not. My experience with C is limited though, however OO is the dominant kind of programming knocking around right now I believe. If you've ever worked in one of the .net languages, that's OO. One metaphor I find is nice with OO programming is to imagine what you want your program to do is a project you're overseeing, and each of your objects is somebody on your team working on it. You organize them to work on their own parts, and at the end, you get the big picture you want. I'm afraid I can't point you in the direction of a good book or anything, as I approached C++ with lots of prior experience in OO programming. I'm sure there's plenty of people here who can, though! And finally, I'd have assumed your native language was English. You write very eloquently, and use punctuation well. There's people born here in England whose English isn't as clear as yours!
3. ## Double and Float based fundamental types (vectors, matrices, etc.) implemented side by side?

I hadn't thought of it like that. I just assumed that templates came with a huge level of extra functionality which was going to waste. I've done some experiments, and I think you're right. I really like how the template solution has worked out so far. I want to play around with it some more first, to better get to know it. But it's looking very likely that's the way I'll go! Thank you for the help!
4. ## Double and Float based fundamental types (vectors, matrices, etc.) implemented side by side?

Templates do seem like a nice solution, although I can't help but wonder whether it's a bit overkill, since there's only the two versions of each I need. Are there any other ways I could do this for comparison?
5. ## textures textures textures :)

DDS isn't necessarily lossy. DXT compression is lossy, but with DDS images, you have the option of using either that or storing them in an uncompressed format. I'd recommend experimenting with it a bit, as with some maps, this compression isn't a problem, and in others it is. For instance, DXT compressed normal maps tend to have quite ugly artefacts when used in game, but it's much less significant in DXT compressed albedo maps.