D3DX vs Own
Author
Just to get straight to the point. Is there something besides our own egos and self satisfaction thats hindering most people form using the directx extended libraries for loading textures or for vector calculations ect? Is there something wrong, codewise, with those pre-existant fuctions or are we just to narrowminded to use them?
I don''t know if there''s a speed issue, but I use my own math functions for programming since my program can use either DirectX or OpenGL. It''s just a matter of being able to reuse the code for different APIs through one base class.
~SkilledNewbie
~SkilledNewbie
Sometimes it''s a pain to type D3DXVec3TransformCoord(&a, &b, &c) when, using overloaded operators, you could simply do something like a = b*c, and it''s a pain to cast alot from one type (CEVector or whatever) to another (D3DXVECTOR3), but I actually wrapped overloads around that sort of thing, so it''s okay.
Most are very optimized routines, written to take advantage of special simultaneous-processing functions of modern processors. From what I''ve heard, it''s not worth the crazy optimizing in your own vector/matrix/whatever code when the D3DX code does alot of that for you.
However, there are some things for which I don''t use D3DX. For example, bounding boxes. I have my own set of bounding routines that I use (because it''s more specifically geared towards my end). Same with loading textures, though I think my textures loading functions actually use the D3DX functions.
Some of the D3DX stuff is slower than you''d think, like the D3DXFont stuff (I don''t remember if that''s what it''s called, but the text-drawing stuff is not that great, mostly because it''s so full of features that it does too much and is slower than a basic speedy D3DUtil sort of implementation). The really low-level stuff, transforms, vector calculations, etc, are usually pretty fast though.
Long-winded, but the basic idea is: I use D3DX for transforming coordinates, building and multiplying matrices, etc. I don''t use it for much else.
Use it when you are pretty sure that you can''t get much faster yourself.
Josh
Most are very optimized routines, written to take advantage of special simultaneous-processing functions of modern processors. From what I''ve heard, it''s not worth the crazy optimizing in your own vector/matrix/whatever code when the D3DX code does alot of that for you.
However, there are some things for which I don''t use D3DX. For example, bounding boxes. I have my own set of bounding routines that I use (because it''s more specifically geared towards my end). Same with loading textures, though I think my textures loading functions actually use the D3DX functions.
Some of the D3DX stuff is slower than you''d think, like the D3DXFont stuff (I don''t remember if that''s what it''s called, but the text-drawing stuff is not that great, mostly because it''s so full of features that it does too much and is slower than a basic speedy D3DUtil sort of implementation). The really low-level stuff, transforms, vector calculations, etc, are usually pretty fast though.
Long-winded, but the basic idea is: I use D3DX for transforming coordinates, building and multiplying matrices, etc. I don''t use it for much else.
Use it when you are pretty sure that you can''t get much faster yourself.
Josh
I was always more comfortable using APIs that make use of the basics and challenge us to build the more complicated things ourselves.
That''s the way most programming started out.
Yes, DirectX has a boatload of automatic things in it now. If I knew OpenGL had equivalent routines, and that any other APIs would, I wouldn''t mind so much learning about those things, knowing they would have a parallel in everything else I''d learn.
That is one of the things that hinders me from learning that much about the DirectX side. It drives the design of an engine, rather than being able to decide on our own engine designs and hoping that DirectX offers something to help us towards that.
Of course, those that have decided to learn DirectX in and out don''t have this hesitation. It is a strength for programmers to be willing to make use of something that has already been done but drives how they design things as well. I''m just not there yet.
I''ve wanted to support both OpenGL and DirectX from the beginning. I have yet to get to that common denominator where I do one thing with one API and don''t think I''ll have to add a bunch of stuff for the other.
That''s the way most programming started out.
Yes, DirectX has a boatload of automatic things in it now. If I knew OpenGL had equivalent routines, and that any other APIs would, I wouldn''t mind so much learning about those things, knowing they would have a parallel in everything else I''d learn.
That is one of the things that hinders me from learning that much about the DirectX side. It drives the design of an engine, rather than being able to decide on our own engine designs and hoping that DirectX offers something to help us towards that.
Of course, those that have decided to learn DirectX in and out don''t have this hesitation. It is a strength for programmers to be willing to make use of something that has already been done but drives how they design things as well. I''m just not there yet.
I''ve wanted to support both OpenGL and DirectX from the beginning. I have yet to get to that common denominator where I do one thing with one API and don''t think I''ll have to add a bunch of stuff for the other.
i''m using as much of the D3DX functions as possible, except for the mesh functions.
i''ve wrapped the math stuff into my own classes for ease of use and portability. i don''t see any performance degradation after inlining the functions and it''s a lot easier and cleaner ( imho ) typing in v.TransformCoord( m ) than D3DXVec3TransformCoord( &v, &v, &m ).
i haven''t had any problems with the texture functions so i''ve wrapped them into appropriate classes.
i don''t use the D3DX mesh functions in my "engine" primarily because of a number of problems i''ve encountered with them regarding material usage, multi-texturing, vertex buffer sizing, etc. they''re just not very flexible imho. i will use them for one-off stuff like creating test apps, converting .x files to home-grown or other formats, level editing, etc., but again i''ve wrapped the functions into appropriate classes for the same reasons as noted above.
i''ve wrapped the math stuff into my own classes for ease of use and portability. i don''t see any performance degradation after inlining the functions and it''s a lot easier and cleaner ( imho ) typing in v.TransformCoord( m ) than D3DXVec3TransformCoord( &v, &v, &m ).
i haven''t had any problems with the texture functions so i''ve wrapped them into appropriate classes.
i don''t use the D3DX mesh functions in my "engine" primarily because of a number of problems i''ve encountered with them regarding material usage, multi-texturing, vertex buffer sizing, etc. they''re just not very flexible imho. i will use them for one-off stuff like creating test apps, converting .x files to home-grown or other formats, level editing, etc., but again i''ve wrapped the functions into appropriate classes for the same reasons as noted above.
I use the extended libraries for textures and sprites exclusively, though wrapped in my own classes for simplicity. They''re lightning fast. In my current 2d engine using sprites I''m getting over 1500 frames per second in scenes with multiple sprites.
Anybody who is convinced they can make noticable improvements on efficiency over the extended libraries basic functions is wasting their own time. I don''t like writing code when I have a perfectly good, working implementation (with no restrictions) right in front of me.
Anybody who is convinced they can make noticable improvements on efficiency over the extended libraries basic functions is wasting their own time. I don''t like writing code when I have a perfectly good, working implementation (with no restrictions) right in front of me.
The math functions represent about 1% of D3DX and are there for people who know exactly how to write these functions, but do not want to take the time to develop optimized routines.
Many professional games use D3DX quite extesnivly, even if just as a preprocessing step. D3DXEFFECTS, HLSL, and mesh (for the cache optimizer) are particularlly useful and would requiret a huge investment in r&d to duplicate.
Many professional games use D3DX quite extesnivly, even if just as a preprocessing step. D3DXEFFECTS, HLSL, and mesh (for the cache optimizer) are particularlly useful and would requiret a huge investment in r&d to duplicate.
This may come out the wrong way, but...
Unless you are really needing every single spare clock cycle, there''s not that much point in worrying about using a slightly slower d3dx function than a custom one. I remember way back a discussion about using C++ functions vs custom asm, and I think it''s the same thing here. D3dx may be a little bit slower than custom functions but:
1) Minor increases in processing power negate the performance hit.
2) Chances are that your game is not going to require every single clock cycle, so losing a few is not likely to be a problem.
3) Spending days creating a custom set of tools to gain 1 fps isn''t justified when you can spend the same time optimising your programming logic, database and culling algo''s and gain 10fps.
By all means, re-write a function, but realise that you are doing it for your own interest, rather than any practical purpose... unless you fall into the 0.01% of coders who actually really do need every single clock cycle. But then again, if you''re in that minority, you''ll probably want to go all the way down to ASM anyway... and that''s kind of fun and interesting, but a lot less productive than you''d think.
Unless you are really needing every single spare clock cycle, there''s not that much point in worrying about using a slightly slower d3dx function than a custom one. I remember way back a discussion about using C++ functions vs custom asm, and I think it''s the same thing here. D3dx may be a little bit slower than custom functions but:
1) Minor increases in processing power negate the performance hit.
2) Chances are that your game is not going to require every single clock cycle, so losing a few is not likely to be a problem.
3) Spending days creating a custom set of tools to gain 1 fps isn''t justified when you can spend the same time optimising your programming logic, database and culling algo''s and gain 10fps.
By all means, re-write a function, but realise that you are doing it for your own interest, rather than any practical purpose... unless you fall into the 0.01% of coders who actually really do need every single clock cycle. But then again, if you''re in that minority, you''ll probably want to go all the way down to ASM anyway... and that''s kind of fun and interesting, but a lot less productive than you''d think.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
