5 replies to this topic

[Tset_Tsyung]

Hi all,

Allow to state that I am still a learner (read FNG) at game coding. Same could apply to coding in general but let's not go there for now... I've only just finished the logic for my basic Tetris-clone.

My friend and I recently purchased "Programming a Multi-player FPS in DirectX", but have since found that alot of the DirectX functionality mentioned in the book (DirectMusic and DirectPlay for starters) is no longer available in the latest SDKS's, meaning that we have to relearn new API's. Now doubt we are not the only ones in this boat...

Now please forgive me if I've been naive or even ignorant, but I felt that I was better off learning DirectX BECAUSE it was an all-in-one API. Everything we had was all under one roof (to coin toy's-r-us' catchphrase). Now with them having removed these features are we merely left with a fancy Graphics API?

So this brings me onto my following questions (sorry for the rant - I've had a bad day before I realised all this);

1. Are Microsoft replacing the networking and music API's? Forgive me if I've missed any ALREADY in place functions.
2. Is OpenGL 4.3 comparable with Directx for 'prettiness'?
3. Since OpenGL is pretty much cross-platform compatible (from what I understand) does it make sense to learn this so that any games we write can be cross-platform compatible?
4. Carrying on from 3 since Valve seem to prefer OpenGL (http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows) does it not make sense to follow them?
5. Assuming that we decide to follow the OpenGL are there any particular considerations we should bare in mind?
6. Any tips on good sound, music, input and networking API's would be greatly appreciated.
3. [I reserve the right to add more question when I can think more clearly :-)]

I know that to get anywhere in game coding (be it a career or a hobby) I need to keep up to date with the tools out there. Since I've only JUST found out about this I realise that I need to jump up my game, so to speak. As it stand I feel that Microsoft had made a VERY nice looking graphics system that makes the best use of the hardware out there. But if OpenGL does the same then why should I give Microsoft (the money grabbing monster that they are) my attention? I always prefer the underdogs anyway, lol.

Mike - sorry for the ranting nature of this post. Although I seem to be a hot headed angry man (which, to be fair, I am) I always humbly consider viewpoints and opinions so, please, bestow with your wisdom oh great coders! Goodness know I need it

[kuramayoko10]

Now with them having removed these features [from DirectX] are we merely left with a fancy Graphics API?
1. Are Microsoft replacing the networking and music API's? Forgive me if I've missed any ALREADY in place functions.

I have not been using DirectX, but looking at microsoft website you can see that they just changed names but they still have their libraries for input, sound, math, etc.

2. Is OpenGL 4.3 comparable with Directx for 'prettiness'?

I believe in OpenGL's power.
Until now the only applications I built using OpenGL were kinda of handcrafted so that I could understand the basics of the calculations (matrix operations), pipeline and algorithms that the library implements. Because of that, my simple 3D games are ugly and not the best on performance.
However there are so many powerful libraries out there that let you build amazing games (with heavy textures) and still run on 60+fps. An example for Java is JMonkey. I bet there are some similar stuff for C++.

3. Since OpenGL is pretty much cross-platform compatible (from what I understand) does it make sense to learn this so that any games we write can be cross-platform compatible?

That depends on the game and the audience.

4. Carrying on from 3 since Valve seem to prefer OpenGL (http://www.extremete...even-on-windows) does it not make sense to follow them?

hahaha. I don't think Valve prefers OpenGL. They had to use OpenGL on their Left4Dead 2 port for Linux.
The article is showing that they got a better performance running on linux and using OpenGL. But this is not so simple. Read Valve's article to learn more about the 4 things they had to accomplish on this port.
Note: Valve is using DirectX on Dota2. So, I don't think they are migrating to OpenGL just yet.

5. Assuming that we decide to follow the OpenGL are there any particular considerations we should bare in mind?

During my course on Computer Graphics, my professor guided us during the semester to code the OpenGL pipeline.
This was so much rewarding and we learned a lot from it. We didn't implement every OpenGL feature, but still we got simple 3D shapes running on screen (translating, scaling, rotating ).
(Just a learning tip for 3D initiation).

Hope this helps somehow. ;)

[Tset_Tsyung]

@Kuramayoko10,

Thank you so much for the reply. I really appreciate your input on this.

1. Hmm, so can still carry on with DirectX - although getting a more up2date book would help lol.
2. If we decide to go down OpenGL, will DEFINITELY look into the libraries out there.
3. Fair point!
5. When you say "pipeline" I take it that's the world translation/camera translation/squashing 3D into a 2D screen?

I think we'll have to get together and discuss this more at length...

Since DirectX still has all that functionality and OpenGL is very powerful think we'll still be stuck. Will have to look at other factors.
*goes into corner to think*

Mike.
P.S. Thanks Again bud!

[Acharis]

I have been using both DirectX and OpenGL. I liked OpenGL much better. The main advantage is, OpenGL does not change its interface all the time (I can still copy paste my ancient OpenGL code from 10 years ago and it will work, while my whole DX knowledge is absolutely obsolete nowadays). Generally, DX is less "user friendly", especially if you just learn in order to use it later (in case of DX you just need to use it right away, before it become obsolete, which is really annoying). Another point is portability, with DX you are tied to PC, with OpenGL you can port to everything (in theory).

Note that DX is better in some cases and OpenGL has problems too. Also, I have heard modern DX is friendlier than in the past, so maybe I would not speak about it that harsh if I learned it recently. Still, my recommendation is OGL.

[clb]

I develop and maintain a graphics engine that works on a number of platforms, and it abstracts Direct3D11, OpenGL3, GLES2 and WebGL. If line counts are any measure, my Direct3D-specific codebase is 3094 lines, and my OpenGL-specific codebase is 3576 lines.

My opinion is that Direct3D11 is way easier to work with and I think developing the Direct3D codepath was considerably easier and I faced way fewer cryptic bugs and issues when implementing Direct3D11 path than the OpenGL path. Some notes:
- Direct3D11 actually has a debug layer that gives out *very* helpful error messages in the debug console while developing. These are diagnostics like "hey, you don't seem to have a render target bound." and "hey, your vertex buffer did not have a position stream.". The typical "oops, I'm an idiot" stuff is very often detected by D3D11 debug layer. Additionally, the returned HRESULT error codes are descriptive and give out good differentiated error messages.
- In OpenGL, there is no debug layer. There is no diagnostics. Silent failure and "hmm why is this just rendering black" are very common. There is only like 5 or 6 different error codes returned by OpenGL, and they are generally unhelpful to getting a clue of what is wrong.
- Direct3D11 is typesafe. In OpenGL it's all GLints and GLenums. Strongly typed API always trumps a weakly typed one.
- The Direct3D way of using vertex declarations, input layouts and vertex buffers is an explicit and easy-to-comprehend way to structure the renderable data. In OpenGL, the corresponding terms are VBOs (Vertex Buffer Objects) VAOs (Vertex Array Objects) and there's also the terms GL_ARRAY_BUFFER and GL_ELEMENT_ARRAY_BUFFER. I think the OpenGL nomenclature alone is something that is easily confused.
- In Direct3D, you have explicit guarantee of the features that work when you initialize a certain feature level. In OpenGL, you'll have to work with enumerating extensions, and hunting down extension specifications. You'll need to bind function entry points, or incorporate libraries like GLEW or GLEE or similar. There's an annoying amount of overlap with the extensions, i.e. the extensions tend to be vendor-oriented, and not feature-oriented (see e.g. how many different extensions there are for enabling VAO support for different vendors).
- In OpenGL, the VAOs and FBOs (FrameBuffer Object) are oddly functioning cache objects. The API for applying and defining a VAO and a FBO is the same. It's easy to forget a VAO or an FBO bound to the device, and overwrite their state accidentally when specifying new state. This is a very common bug I've often seen beginners get caught with.

Note however that as a 3D developer, you probably won't have the luxury of choosing, but you'll have to learn both, as there's a market segment for both APIs. Whichever you choose, be sure to familiarize yourself with PIX, nVidia Parallel nSight, Direct3D11 debug layer for D3D, and gDebugger for OGL, since they'll save you a ton of grief when things go wrong.

[sheep19]

I suggest learning openGL because you can use it on android (openGL ES) and in web browsers (webGL).