Quote: Original post by Yodaman Jer
Hello all,

I've been wondering, what is the difference between developing things with OpenGL or DirectX? Is it harder to code things in OpenGL?

The reason I'm asking is because I want to start developing games with XCode on the Mac (once I get an iMac, of course), and I read that I would need to use OpenGL since DirectX is a Microsoft-only technology. I figure it won't be too hard once I learn. Can anyone recommend a place for me start (books, websites, etc.,)?

Thanks!

Honestly, I would not go with either. If you want to make games, you should probably start with a full game engine. Typically, you only use basic DirectX or OpenGL if you are interested in learning low-level graphics programming. Beginning game developers will often get bogged-down and frustrated by starting with DirectX or OpenGL because it just takes so much code to even put a triangle on the screen, much less to make a full game. Once you get competent with a game engine, and have lots of experience creating games, you could go back and start learning OpenGL. However, if your goal is to make indie games, there really is no reason to, because you will just be re-inventing the wheel.

I wish I could give you some engine suggestions, but I am not sure what is competently cross-platform or Mac-oriented.

I learned mostly from the OpenGL Superbible. It's a good resource to have handy too.

I think that when it comes to learning about games, writing from scratch may be educational but I agree that starting with an existing game engine will be easier and faster for making games.

I can't vouch for Direct3D but OpenGL, in my experience, isn't too bad providing you use tried-and-tested third party libraries like GLUT to handle the dirty work for you.

All those endless

glPushMatrix(); glBegin(GL_WHATEVER); glVertex3f(x,y,z); glEnd(); glPopMatrix(); 

constructs get old quick, though.

Quote: Original post by ukdeveloper
I can't vouch for Direct3D but OpenGL, in my experience, isn't too bad providing you use tried-and-tested third party libraries like GLUT to handle the dirty work for you.

All those endless

glPushMatrix(); glBegin(GL_WHATEVER); glVertex3f(x,y,z); glEnd(); glPopMatrix(); 

constructs get old quick, though.

immediate mode OpenGL, gah! Unless you are changing vertices every pass, you should really be using vertex buffers. Easily 2 times better performance wise.

Quote: Original post by ukdeveloper
All those endless

glPushMatrix(); glBegin(GL_WHATEVER); glVertex3f(x,y,z); glEnd(); glPopMatrix(); 

constructs get old quick, though.

Yeah, 'old' is about the right word here: all of the OGL commands you listed there were deprecated and removed from modern OGL a while ago :)

Quote: Original post by KaptainKomunist
immediate mode OpenGL, gah! Unless you are changing vertices every pass, you should really be using vertex buffers. Easily 2 times better performance wise.

If you are changing vertices every frame then you should:

a) Rethink your algorithm. There's a big chance that you could use static geometry instead, and do everything on the GPU directly.

b) If you must use the CPU, then use dynamic VBOs. Immediate mode is dead. Entirely. For everything.

Oh, and any figures given for performance increase are meaningless. Speed differences between IM and VBO can be anywhere between 0 and over x100, depending on where exactly your bottlenecks are.

OGRE tends to be the definitive answer for everyone who actually wants to do something other than fiddling around with the low-level details of your API of choice (and hey, if you're doing AAA next-gen wankery or you just enjoy that stuff, go ahead).

Windows/Mac/Linux, OpenGL and DirectX renderers, and plenty of C++ OO goodness.

Quote: Original post by drakostar
OGRE tends to be the definitive answer for everyone who actually wants to do something other than fiddling around with the low-level details of your API of choice (and hey, if you're doing AAA next-gen wankery or you just enjoy that stuff, go ahead).

Windows/Mac/Linux, OpenGL and DirectX renderers, and plenty of C++ OO goodness.

Yeah, OGRE has been a blast so far. I'm not really interested in getting dirty with DirectX/OpenGL and especially not the issues that crop up when you want both to work in your game so it can be crossplatform.

It has to be one of the best managed O/S projects out there. The community is awesome, which was a pleasant surprise to me. If you haven't checked it out and if you're looking to make a game and not an engine, it's a great start.

Thanks for the replies everyone!

I think for the time being, I'll just stick with DirectX and develop PC games. In fact, I think programming is all that I'm going to use Windows for, and that's for the C# programming language. Someday I'll learn OpenGL (maybe in college).

Quote: glPushMatrix(); glBegin(GL_WHATEVER); glVertex3f(x,y,z); glEnd(); glPopMatrix();

The strange thing is, I like the looks of programming like that. I can definitely see where that would get boring after a while, but I can also see enjoying it because it means putting graphics on the screen.

The problem is, doing it like that is the slowest method possible when it comes to rendering which isn't overly helpful.

Quote: Original post by ukdeveloper

glPushMatrix(); glBegin(GL_WHATEVER); glVertex3f(x,y,z); glEnd(); glPopMatrix(); 

constructs get old quick, though.

thanks to my computer graphics instructor, I wondered why my games are too slow with only a few polygons.

I really don't think directx is easier to learn. I first started in glut and now I am working with directx. I can say that using glut was much easier than using directx (espacially if you use codes like uk developer's example =))

Quote: The strange thing is, I like the looks of programming like that. I can definitely see where that would get boring after a while, but I can also see enjoying it because it means putting graphics on the screen.

problem with that code is that you are sending the coordinates for each vertices to gpu everytime you draw something on screen, which causes a bottleneck.