Directx or OpenGL

Started by
26 comments, last by m.r.e. 7 years, 5 months ago
Dirextx or Opengl is better.for windows? ps: i know.c++ and javara and using dev++ or virtual studio.
Also i know with a game engine itll be easier but i prefer to do it from scratch :)
Advertisement
Okay so this debate will cause alot of controversy mainly because neither is really "better" both are low level APIs that communicate with the GPU to submit triangles and buffers. Open gl is full of awkward depreciation but it's not too bad really. Directx is a bit more solid but documentation can sometimes be wrong otherwise its fine.

The answer mainly comws down too needs, you only want to target windows? The n directx for sure. Want to target other platforms then you will need open gl. Open gl es and other platforms specific APIs like Sony uses gnm I believe.

I'm building a multi-api engine, I'd suggest doing the same cause then you can use any API with your engine, essentially make the engine in depednet to the api.

And for me personally visual studio.

PS , wouldn't from scratch mean building yoru own rasterizer (barycentric coordinates etc) ?
IMHO to make my life as a graphics programmer easiest:
D3D for Windows.
Metal for Mac/iOS.
GLES for Android because you don't get a choice.
GL for Linux because you don't get a choice.
WebGL for HTML5 because you don't get a choice.
On consoles you don't have a choice but to use their custom API.

D3D / GL are equivalent, but on Windows, D3D has a cleaner/simpler API, and is more robust because it's implemented once by Microsoft (whereas there's three separate implementations of GL - one each from NVidia/AMD/Intel, which means you must always test your code one at least 3 PCs to make sure it works for all three GLs...)

I do both, which has some advantages including being able to read books written for both. I do DX11 and OGL4 (haven't learned Vulkan of DX12 yet, which take things to a whole new level [mostly multi-threading]). And I do 3D and never 2D, not because there's anything wrong with 2D - I just don't do it and so couldn't really say much about what it's like in either of these environments although they both seem a bit over-kill for 2D in general. There's been a book or two written for DX more than OGL. Once you really "get" one, it shouldn't be that hard to get the other.

I find DX to be a bit more complicated, but then when I do DX, I don't use libraries. Everything is from scratch unless it's part of DX, Win32, STL, or C++. I use whatever libraries are available for OGL, which I find makes OGL WAY easier. OGL, because of the libraries, is more like using something higher level like XNA/MonoGame.

DX in some ways discourages the use of libraries. Right from the start, when you do DX it's always in Windows and you're not going to support any non-Microsoft platform, so you might as well connect directly to the OS with Win32 or WinRT or whatever. (I do Windows 7 and not 8 or 10, which is part of the reason I'm not doing DX12).

The main reason I use libraries like crazy with OGL is because of multi-platform support. I'm not going to learn how to make calls to every operating system out there. Learning Win32 was trouble enough. I can't imagine learning that all over again for Mac, Linux (which strongly discourages it because all the Linux C++ programmers I've found want multi-platform development), Android, and whatever else is out there. Instead, I can just link in GLFW and it can deal with whatever OS the code is running on. That alone, makes OGL a whole lot easier when you're getting started. It was good experience learning to talk directly to the OS, but now that I've done that, I'm not too concerned about using a library especially since I gain multi-platform support.

So, with the libraries, I find OGL to be a lot easier to learn. The hard part is finding good lessons for it. I find the Khronos Group literature to be "not very helpful". I've been reading Orange Book and it's like reading a dictionary in order to learn a language; you probably want to have a dictionary on your shelf when you need more information on something, but learning from it is difficult to say the least. If I had not already learned 3D game programming in two previous environments, I would have been so lost with OGL even though it's actually significantly easier. Someone pointed out a really good website for learning OGL.and I've been pointing people to it every since. I haven't had time to actually go completely through it, but at a glance it looks really good.

DX too can be tough to learn, especially if you don't use libraries. But at least there are a few decent books out there for it like this one, which is extremely technical but detailed (and probably more of an intermediate if not advanced book), or this one which is kind of the standard for learning DX (and you could even jump straight into DX12 with his DX12 book if you have Win10 and a DX12 card, although he avoids the subject of multi-threading which is kind of the whole point of using DX12 over DX11).

OGL and DX both do basically the same thing. You're probably going to be doing C++ with either of them, although technically you can use other languages with either. Knowing both helps you read books written on game programming that may use either one and shader books that are written for HLSL, or GLSL.

Then there's also which vision of the future you want to support: one that believes they need to install their ransom-ware on your computer in the middle of the night whether you want it or not and license your life back to you for you to rent from their cloud, or the other that believes in open source software and freedom. It appears PC's powerful enough for gaming are becoming toys for hobbiests while the world buys dumb terminals to access their life in the clouds. Reminds me of the old days when personal computers were for the die hard hobbiests and mainframes were where the real work was done. What does this mean for the future of low level PC game programming? In the future, will you be able to write games for anything commercial without going through an engine? Will Microsoft completely drop DX like they dropped XNA? How does DX even work in the cloud? I suppose that's something to consider.

In the end, you'll have to make your own decision about which way to go. You might start with OGL from that link I posted above. Once you get the basic concepts down on how to manipulate things with matrices and vertex buffers and such, you'll be doing basically the same thing in DX. So, learning DX will go a whole lot smoother, although until you learn to talk to the OS with Win32 or whatever, it may be confusing as to what's Win32 and what's DX. (You don't necessarily have to learn a lot of Win32 as all you really need from Windows is a process, a window, and a very small attachment to the even loop for the most part. It's just that you'll probably have to study Win32 much deeper than that to understand why you wrote that small amount of code.) And you don't necessarily have to go as hard-core with DX as I did and write your own model class and stick with DDS textures because that's the only thing DX natively supports. You can use Assimp and an image library like FreeImage whether you're using OGL or DX. It's just that in my opinion, if you're gonna do DX you're doing it because you want to learn how to do things for yourself at the lowest level, and that purpose is defeated if you start using libraries. If you're not there to learn things at the lowest level, you could be using Unity where everything is done for you and you could be getting far more actually accomplished towards writing actual games. I learned things at the lowest level with DX, then took it up a level and started using libraries to do those same things with OGL. That way if I don't like the library, I can write my own, but the library saves time and whatnot while still giving me low enough level access to learn new things at a low level.

So, I guess my recommendation is to learn both. Pick one and get started. :-)

PS , wouldn't from scratch mean building yoru own rasterizer (barycentric coordinates etc) ?

No. If you want to get pedantic (like I do all the time), "from scratch" would be using stone tools to mine and smelt your own ore for the circuit board, or at the very least hard wiring your own rasterizer. ;-)

But in DX, or especially OGL, you'll learn how the rasterizer does it's job and all the math behind it. So, "from scratch" could generally mean understanding all the math and algorithms at their lowest possible level outside of writing your own operating system or building your own graphics card and writing a driver for it.

There's a world of difference between Unity and OGL or DX. It's like a totally different way of thinking. So, I think it's fair to characterize OGL or DX as being "from scratch" as opposed to Unity where you can pretty much buy everything from the Unity Asset Store and assemble it without making anything yourself. (Not knocking Unity there, although that's a very real danger - that you won't actually learn anything by buying components and assets - and you may be completely lost if you have to debug components that were never designed to work with one another in the first place. You can easily get lost in the "weeds" studying OGL or DX and not ever get a single game actually put together. So, they all have their advantages and disadvantages.)

For your first API, and given the fact that in the OP Windows is specified, I suggest Direct3D; specifically Direct3D 11. Of course in the longer term you should learn both, but Direct3D 11 is a better modern(ish) API to start with.

Reason 1 is that tool and GPU support for it is well established and absolutely robust. Even today it's possible to get a GPU that doesn't support the latest OpenGL; that just doesn't happen with Direct3D 11.

Reason 2 is that OpenGL is a mess of deprecation, legacy API features and multiple code paths to do the same thing. Even in core GL 4.5 you still get this: consider DSA vs non-DSA, immutable vs mutable storage, sampler objects vs texture parameters, etc. Mix in legacy GL and you're just going to have a more difficult time identifying the API calls you should be learning vs those you shouldn't. You don't get that with D3D 11 - it typically offers just one way of doing things.

Of course OpenGL gives you multi-platform, but since the OP has specified Windows that doesn't apply. OpenGL is also not a magic bullet to multi-platform support; you still need to deal with platform-specific code for windowing, memory, sound, networking, input, etc; something that multi-platform proponents seem to frequently forget.

Once you've learned Direct3D 11 you can then go learn OpenGL, and so long as you learn the equivalent GL calls to what you're using in Direct3D 11 you shouldn't stray too far from the modern API.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Than k you all, i want to make a 3D mmo, so from what u rsaying ill choose Direct 3D( is it the same with DirectX ?) also with which program can i make the 3D models? Ive been using Sketch Up, but i dont know if its compatible with D3D. also i know C++, but can i write scripts with java inside the game ? and make some files with XML to be static rather than using MySQL? thx in advance

sry fordouble post , but which directx is the best to use? ive seen that directx11 is the simpliest and with most factions

Directx SDK (June 2010) is the directx 10?

Than k you all, i want to make a 3D mmo, so from what u rsaying ill choose Direct 3D( is it the same with DirectX ?) also with which program can i make the 3D models? Ive been using Sketch Up, but i dont know if its compatible with D3D. also i know C++, but can i write scripts with java inside the game ? and make some files with XML to be static rather than using MySQL? thx in advance

Err okay so i think you may be getting ahead of yourself, building an engine is no easy task its quite complicated before you start you need to cover trigonometry and linear algebra and 100% cover the core programming concepts and data structures/design patterns. Put the mmo on the back peddle until you make a engine which could take a while.

You asked about compatibility between sketch up and D3D this shows a lack of understanding on what 3D representation really is so you need to cover that too, but to answer the question anything is compatible if you make it compatible i recently finished writing a binary converter which takes obj to my custom format. I will be expanding this to fbx and maybe even.blend basically any format can be converted if i write the converter for it. With Directx or opengl there low level you can't just drop models in it and it work's you need to build EVERYTHING your-self from scratch as you said.

Sketch fab allows you to export in these formats so write a compiler for them: https://help.sketchup.com/en/article/3000153

For scripting yeah i believe you can use java it may need some embedding interpreter system though but someone else will answer this more adequately, mike mcshaffry game coding complete talks about lua scripting with engines seems to be the go too language and easily embedded into the engine.

also with which program can i make the 3D models? Ive been using Sketch Up, but i dont know if its compatible with D3D.

D3D/GL are low level ways to send code for execution on the GPU. They don't have the concept of a model - it's your job as an engine programmer to define what a model is and tell the CPU how to load the data into RAM and tell the GPU exactly how to draw it.

If you want to make a game instead of reinventing this low level stuff, then you should use an existing game engine like Unity or Unreal.

This topic is closed to new replies.

Advertisement