Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

fireking

warnings or cautions before i dive into direct 3d C++?

This topic is 5388 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi, im getting ready to move from open gl to direct 3d. I''ve been working with open gl for a while (well off and on for a year, but all summed together thats about 2 months).. anyways, i have the book, Programming Role Playing Games in Direct X, and i plan to move to Direct 3d. I was wondering if anyone could give me any warnings/cautions with this transition. I know that when you get used to how something works, and then you move onto to something new that accomplishes basically the same thing, you really really wanna move back to the old thing. I just wanna know some differences between open gl and direct 3d before i move. Because this is going to be a big move. Any choices i make now are going to greatly effect my development time. Thanks, fireking

Share this post


Link to post
Share on other sites
Advertisement
I''ve messed with OpenGL before I moved to DirectX. But not really that much. I just hope your targeting DX9, as they have revamped the interface in the last few DX versions and have made it more OpenGL-like. It still lacks some of the elegance of the OpenGL model (matrix stacks and such), but you shouldn''t have too much trouble adapting.

DX9 takes the state-machine approach like OpenGL. One of the nice things about DirectX is that you don''t have to play the extensions game. For the most part, DX9 relies upon underlying drivers to add in extra feature support, and what it can''t support it usually will emulate for you.

Also, I''ve found that the DX Lib is pretty useful. Things like mesh handling, animation controller, gobs of various math functions, etc.

But take what I say with a grain of salt, I''m still new to DX and 3D.

---
http://www.gapingwolf.com

Share this post


Link to post
Share on other sites
my whole problem with d3d in the first place was all the crap you had to do before you could even draw...

and i still really do not know what a vertex buffer, vertex shader or vertex stream really is...

i think a vertex buffer just holds tons of points used to draw primitives (like in open gl). vertex shader is.... uh it draws the vertex buffer?? and vertex stream does, welll.... it gives the verticies to the shader? i dont know!

plus, the book i have is based off of dx 8.0, so if the interface in dx9 has changed, that means i have to learn 8 then relearn it all over again for 9... ugh..

[edited by - fireking on October 15, 2003 8:23:32 PM]

Share this post


Link to post
Share on other sites
Vertex buffer is a buffer of vertices. If you don't know what a vertex is, you need to reread your d3d book. Vertex Shader is not something you have to worry about for a while, just set it to NULL to set it to the default shading. Vertex stream is a stream of verticies, which means putting a vertex buffer into an area of memory for drawing access (streaming it to the draw surface). If you use D3DX you don't have to bother with it, you only need to use streams when you're accessing the vertex buffer directly for drawing. Usually this means in your model, particle, or sprite object. If you use D3DX you don't have to touch it because D3DX already has those classes.

Yes, the book you have is DirectX 8, but it has some good theory in it and the change is easy enough to discover through the DirectX9 SDK Documents. If I were you I'd try to convert the code while you're learning it--keep the help file open at all times so that when your code doesn't compile you can run a search on the function that doesn't accept 7 parameters (for example) and find out what parameters to use.

[edited by - Erzengeldeslichtes on October 15, 2003 8:29:57 PM]

Share this post


Link to post
Share on other sites
i know what a vertex is

my book spends a few pages talking about matrix''s before it totally dives into them. I understand they are used to change position, rotation, and so on. And there are several conversions that take place before drawing happens. Is this true for everythign drawn? I mean in open gl, you can just go glTranslatef(whatever)... but my book says you need to multiple all the matrixies in a certain order before drawing (using d3dx functions of course), which is very scary when all i wanna do right now is write a comparable program that renders a quad, just like my open gl program that renders a quad

Share this post


Link to post
Share on other sites
OpenGL has Vertex buffers, too, via GL_VERTEX_ARRAY.

It also has vertex shaders and pixel shaders (fragment programs), but currently it's vender-specific ARB extensions.

EDIT:

fireking, glTranslatef just feeds direct coordinates of the primitive to OpenGL (like, a quad or a triangle). In DX9, you must put that in an array, which will then be accessed all at once by DX. (This is the aforementioned vertex buffer.)

Matrices don't need to be involved at all. You could set the vertices of your triangles to their final resting points. If you want to rotate, move, project, or otherwise manipulate your objects however, you should work in local space and then use a matrix to translate it into world space (aka GL_MODELVIEW). Then when ready to cull, you translate it into camera space.

---
http://www.gapingwolf.com

[edited by - FenrirWolf on October 15, 2003 8:54:16 PM]

Share this post


Link to post
Share on other sites
yeah, cuz open gl is hardly ever officially updated

but you dont HAVE to get into all that stuff to draw stuff, with d3d you do.. and i have to understand it more before i can do that...

Share this post


Link to post
Share on other sites
If you're rendering a quad you don't need the matricies (except view and projection), but that's simple. If you want the quad to move, rotate, or scale, you'll then need to use the matricies. It's not hard, and if you put it into a class function you'll probably need to bother with it again.

True, in OpenGL you don't need to do some things to draw that you must set in Direct3D, but sooner rather than later you will need to set those things in OpenGL anyway, at least if you're going to make a game, so why worry about it?

And who said you have to understand it to use it? I haven't a clue how matrix multiplication works (which speaks volumes for the california education system considering I've aced all my math classes--THROUGH Calculus 3 where I'm at now), but I use it quite alot. Nor do I have a clue how D3DXMatrixRotationX works, but it does so I use it. There are many functions described in your book where the author will say "Ignore this, set it to NULL", so you don't have any idea what that parameter does, but since NULL works you use it. To "use" it all you need to know is how to copy. I'm sure the author will inform you of what things do properly.

[edited by - Erzengeldeslichtes on October 15, 2003 8:51:47 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by fireking
yeah, cuz open gl is hardly ever officially updated


WTF are you talking about? OpenGL 1.5 was released after Direct3D. The only reason to learn Direct3D if you know OpenGL is if you want to know both for compatibility, or if you really don''t like OpenGL for some reason.

Share this post


Link to post
Share on other sites
quote:
Original post by Erzengeldeslichtes
And who said you have to understand it to use it? I haven''t a clue how matrix multiplication works (which speaks volumes for the california education system considering I''ve aced all my math classes--THROUGH Calculus 3 where I''m at now), but I use it quite alot.
Heehee. Highest math I''ve had is geometry, and I haven''t had too much trouble with 3d. I understand how matrices work, but I''m shaker on some of the higher level stuff. I''m working through linear algebra right now.

---
http://www.gapingwolf.com

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!