Direct-X in C++ Game Programming [closed] - c++

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am reletively new to c++ programming can anyone please tell me how does Direct-X SDK is helpful and how does it works and how can we use it in game programming.I Downloaded it and I found lots of header files and documentation also tells something about game programming.

DirectX is a library (a large collection of classes, really) that allows you to "talk" to the video adapter, sound card, keyboard, mouse, joystick, etc. It allows you to do it much more efficiently then other "standard" Windows functions. This is important because games need all the performance gain you can get - and DirectX has plenty to offer in this regard. Especially when it comes to graphics programming, because it has functions that enable you to use the 3D acceleration features of your graphics card. Windows doesn't have such functions by default.
The DirectX SDK contains:
Documentation for all the features of DirectX;
Tutorials in the C++ language to get you started if you don't know anything;
Sample applications;
The necessary .h and .lib files to add DirectX support to your program;
The debug version of DirectX (I think, I'm not so sure about this one)
The DirectX redist that you can include with your own programs.
If you're not up to speed with C++ then starting with DirectX development will be quite difficult, as either of these things has a pretty big learning curve.
Btw - you did download the latest version from Microsoft webpage, not a 5 years old copy from some web guy, right?

Your question is way to broad. DirectX can help you create games in more ways that you can (considering youre new) imagine.
Rendering (putting stuff on the screen), input (responding to what happens on the users mouse/keyboard), network (for multiplayer), reading files, fonts, 3D-models, sound. To name a few.
I urge you not to try to write something yourself directly utilizing DirectX. Getting something good out of it is an extremely complex task. Dont reinvent the wheel unless you plan to learn more about wheels. (The wheel here being DirectX.)
If you just want to get up and running and make World of Warcraft 2, I suggest you use premade DirectX implementations (usually called game engines) such as Ogre, Irrlicht or HGE (simpler, but only for 2D games).
Good luck, dont give up and welcome back later with your first real question. :)

I'd like to add that "game programming" does not necessitate graphics programming. DirectX, like OpenGL, provides a basis to create a graphics application; but, as mentioned, it's very low level.
As a professional game developer, I would not suggest just jumping into DirectX after learning C++. It's a difficult endeavor that will move slowly and provide you little motivation to continue. It's definitely something to keep in mind for your future; but, for the moment, it would be more beneficial to play with something complete, possibly start with gameplay programming.
Note: In addition to C++ skills, you will also need some mathematical talents. Linear algebra and trigonometry are the primary concerns.
Check out a lightweight engine like Angel. It's a fairly intuitive starting point and small enough that you can fully understand what's happening within it.
As always, try to make small edits and projects for yourself in the beginning and then move on to bigger and badder tasks!
Good luck!

I'm not entirely sure what you're asking, but Frank Luna's book on DirectX is a very good intro.
But if you're a relative newcomer to C++, DirectX may be too low-level for what you're looking for. I mean, are you looking to create a colorful rotating cube, or do you want to make a semi-complete game? Assuming the latter, you probably want a framework that abstracts away the low-level details of either DirectX or OpenGL. For that, I can heartily recommend Ogre 3D. The tutorials alone will get you up and running before you know it.

Read: The Art of 3D Game Programming with Direct X 2002.

Related

How to display graphics on a C++ program without third party libraries? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I can't seem to find the answer I'm looking for, or I might miss understand this. Either way I am confused.
When I try to find out, there is always videos about C++ console programming, which annoys me because I wanna move away from console stuff by now. I know how to create a simple window, but not how to display real graphics on it. I have heard of stuff like OpenGL and DirectX, but it makes me wonder, what do those libraries have in their source whcih draws actual shapes and other things on the program? What C++ functions do they use in their code?
Well, you could make your own graphics library. In that case I suggest you grab a good math book, and get ready to do some rather serious maths. You'd also have to get going and start right now to learn about Windows graphics drivers and Windows Kernel development, or about the X11 API and Linux Kernel programming, or all of those. The documentation is available on the Net.
What OpenGL and other graphics libraries do is provide a relatively simple API so you don't have to reinvent the wheel, and make your own library which would take years before having anything close to what they provide.
Don't get me wrong, even with these nice API's, there is much room for doing 'magic'. Computer graphics are an art in and of themselves. Mastering some of the techniques offered by the libraries require a good knowledge of the maths involved, and of the possibilities offered by the hardware as well.
But, like everything, it can be learnt. If you are interested in doing graphics on a computer, you should start by finding a good source on the subject, there are many online. And start playing with the APIs. OpenGL is a good place to start, but there are also open source libraries that build on that, since drawing polygons ans stuff involves many other aspects of computing. Ogre3d comes to mind, but there are also others.
Briefly, what graphics APIs have in their source is interaction with the graphics hardware, and telling it to write pixel values in memory. Ultimately this is usually done in an indirect way, such as setting up a scene graph, and and graphics APIs provide an interface to work with low level hardware systems.

Where can I find popular video game code in C++? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
i'm learning c++ in my high school computer science class and I wanted to look at what actual c++ coding looks like, I feel like we spent the whole year on such a small portion of the programming language and my knowledge feels useless. I want to see if I can understand it to know where I stand with it, I am also just curious. My teacher told me that only a small percentage of games are made with c++ but, some he mentioned that might be made with (mostly) c++ were Halo, Diablo and some online role playing games. I read that its illegal to look at the code or you cant get it but if you have the game on your computer shouldn't the code be on there too? How do you extract/view it? Thanks
Doom 3 is available for reading and is written in C++, it is well regarded as well. Note that it doesn't use C++11 or other modern methodologies.
On the topic of game making, the vast majority of AAA games are made in C++. Counting individual games other languages win out, but that is due to mobile platforms being so easy to publish to.
Id software's quake was released on GPL:
Quake on Github
You can also look for other open source games.
I read that its illegal to look at the code or you cant get it
That would be referring to decompiling/disassembling/reverse-engineering someone else's code which depending on where you are from and the reasons is illegal
but if you have the game on your computer shouldn't the code be on there too?
On your computer would be the compiled binary which is not in a human readable form and would require being decompiled/disassembled/reverse-engineered
My teacher told me that only a small percentage of games are made with c++ but, some he mentioned that might be made with (mostly) c++ were Halo, Diablo and some online role playing games.
That would depend on when the game was made and what the target platform was, C++ was used for a lot since it was known as being the most efficient along with C so it was seen as necessary for games. Now however there have been improvements in the processing speeds of computers as well as the efficiency of the languages themselves opening the realm to many languages. Java on Android, Objective-C/Swift on iOS, C# on XBox, etc.
On a PC at this point almost any language can be utilized to write a game, it all depends on what the development team is familiar with and any other factors each team needs to consider for themselves.
DOOM-3 along with many other pieces of id-Software were open sourced years after their release if you wish to browse the source of an actual game. https://github.com/id-Software/DOOM-3

Learning Curve in OpenGL vs Direct3D + other game components [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Not to start a flame war....
but i am in chapter 4 of the OpenGL superbible and the books organization is NOT helpful for a beginner,
I've been doing a little research on the backstory of each API also but a lot of fingers are pointing towards Direct3D as the future easier API considering their ability to actually progress, add new features and get them out there.
Mainly though, i'm wondering if either have a steeper learning curve since i'm finding OpenGL pretty hard to get going with using my book...
Should I switch to Direct3D if it's easier to learn, and maybe return to OpenGL later if they get going and catch back up to Direct3D again?
by the way i'm hping to learn this stuff in context of studying C++ for a year and future game programming so i would also need to figure out how to get audio, ai, etc set up later too.....
Thanks!! =)
Should you switch to Direct3D? Ask yourself the following questions:
Do you want to be bound to developing for Windows only? [YES/NO]
Are you ready to invest time learning a new API design every time the major version of the API increases? [YES/NO]
Are you okay if new GPU generations' capabilities are available to you only with some major delay until the next major version of the API is released? [YES/NO]
If you answered any of the above with YES, then Direct3D is the right choice. Otherwise I recommend OpenGL:
OpenGL is available on all major operating systems and plattforms as well as on more obscure ones.
OpenGL's API design is astonishing stable, the basic principles have not changed over a decade. Take a look at the open source game Nexuiz Classic, which is largely based on the Darkplaces engine which is a overhaul of the open sourced Quake2 engine (written for OpenGL-1.1) and has been updated to support all modern whistles and bells of shader based rendering.
OpenGL's extension mechanism allows GPU vendors to give access to newest generations' capabilites at release date. With Direct3D you're forced to wait until the next version is released by Microsoft. When NVidia released their GeForce8800 in 2006 it took half a year until Joe Average Developer could write Direct3D code for its new features. However through OpenGL extensions it was immediately accessible for OpenGL programs; I remember the day I bought my GeForce8800 (4 days after official release) built it into my machine and started hacking away with the geometry shaders the same evening.
It sounds to me like you have most of this backwards.
OpenGL is definitely easier to learn than Direct3D -- in particular, you can use immediate mode for simple stuff where you don't care a lot about performance, and delay dealing with vertex buffers and pixel buffers, and so on.
OpenGL used to have a significant performance disadvantage compared to Direct3D, and relatively slow progress in adding new features. New development was turned over to Khronos a while back. While there's some controversy about some steps Khronos has taken, they have done quite well at feature parity, and it's been a few years since I've seen any real performance advantage for Direct3D either.

Which way to go in Linux 3D programming? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm looking for some answers for a project I'm thinking of. I've searched and from what I understand (correct me if I'm wrong) the only way the program I want to make will work is through 3D application. Let me explain.
I plan to make a studio production program but it's unique in the fact that I want to be able to make it fluid. Let me explain. Imagine Microsoft's Surface program where you're able to touch and drag pictures across the screen. Instead of pictures I want them to be sound samples (wavs,mp3,etc). Of course instead the input will be with the mouse but if I ever do finish the project I would totally add touch screen input compatibility! Anyway, I'm guessing there's "physics" to do with it which is why I'm thinking that even though it'll be a 2D application I'll need to code it in a 3D environment.
Assuming that I'm correct in how I want to approach my project, where can I start learning about 3D programming? I actually come from PHP programming which will make C++ easier for me to learn. But I don't even know where to start. If I'm not wrong OpenGL is the most up to date API as far as I know.
Anyway, please give me your insights guys. I could really use some guidance here since I could totally be wrong in everything that I wrote :)
I would like to add that I'm most likely looking for tutorials, Linux 3D programming sites, source/demos (google failed me for the most part).
Note: I also understand this is not a project I'll finish in weeks, months and might take years. That's fine, I want to get C++ under my belt however long it takes. I'm just looking for opinions, sources, tutorials and things that might help me (as stated above).
I don't know much about the MS Surface, but I'm a musician and multimedia artist working mostly with code, so... My advice is very much different - it doesn't matter if it's Irrlight, Orge, pure OpenGL or anything else. If you don't know much about 3D prgramming you'd better start with something different. There are several environments for artists to work with graphics, multimedia and code. Try one of them and watch the projects made in each of them on the project's websitees and on Vimeo. I think most of what you want to do is already done, but still can be very inspiring. The environments that come to my mind are:
Processing - great prototyping environment by Ben Fry and Casey Reas. I use it always before coding anything serious as it provides me with all the multimedia and communication libraries i need, it's simple like hell and it's Java so you can easli deploy your apps after all! (As far as I remember there is touch surface library for Processing)
openFramewoks - same as above but C++, but it's less clean and still under development. It's very easy to prototype in Processing and code finally in openFrameworks as the latter was very much influenced by the former. (The touch surface library is implemented for oF for sure)
NodeBox - great and very powerful environment in Python. Has a very strange but great and intuitive (after all) GUI with some very unique methodolody of work!!
SuperCollider is a wonderful sound processing and algorythimc composition programming language with a very easy to code GUI library and graphics API. It gives you everything you ever imagined about sound programming functionality.
Pure Data - graphical approach toward programming. Made by Miller Puckett (the co-author of Max/MSP) with OpenGL (GEM extension) functionality provided by the guys from IEM in Austria.
Final good advice: Books!!! Programming Interaction (O'Reilly), a few books on Processing website, classic work - Computer graphics for Java programmers (great one, really!!). Read as well all the chapters about domain languages and domain knowladge in "97 things every programmer should know". It can really help!!
BTW: if you don't concider heavy real-time procedures thing about Java (Java2D, Java3D, JOGL) - it's millions times easier then C++ and Processing is actually Java, so you have a very good prototyping environment that can produce ready to use Java classes and applets. I used Processing in real-time theatre productions where stage movement was controlling the sound (syths and hardware samplers) all made in Processing, so this "heavy real-tme" means HEAVY real-time!!
If any further questions about this particular domain programming - don't hesitate to email me.
Coming from PHP won't make C++ any easier to you as riding a bicycle won't make driving a car easier.
Now, I think for Linux, your only choice is OpenGL as an API, and use any of the many wrappers, 3D programming frameworks, and what not available.
Maybe you can go into an easier language, like Python, and if there are OpenGL bindings (which I am pretty sure there is) you can use that, that would make the learning curve more easy and fast.
Update:
Today I wouldn't recommand Ogre3D for a lot of reasons (including very poor long-term interface, which defeat the purpose of a dependency for long term usage - although it does have nice performance sinc v2.1).
There is currently a lot of other alternatives which work well on Linux.
Ogre, using OpenGL on Linux-based OSes, will save your life and time, compared to using OpenGL that is your sole alternative.
That said, to use Ogre, you'll have to know a fair amount of knowledge and practice in C++.
And you will have to know about "graphic pipeline".
You can use C with OpenGL, that seem simpler, but it make you loos time by not providing higher abstraction of the graphic pipeline as Ogre does.
And almost all graphic engines are written in C++ anyway.
Now, if you try to learn C++, take a good book like "Accelerated C++", take a deep and long breath and please forget all you learnt about php before. Be humble in your search for knowledge and you'll get it faster.
You'll be interested in:
OpenGL (obviously)
Box2D (a 2D physics engine)
SDL (a portable media library)
You can find basic tutorials for them on the web. However, think if you really want to code in C++. The language is very powerful, but not easy to learn, and really hard to master. Wouldn't it be better to use a rapid development language like Python with PyGame?
Don't get me wrong -- I love C++ and it's my language of choice, but unless you're working on top-notch performance, operating systems or compilers, it may be overkill to learn C++'s up and downsides the hard way.
You need neither 3D graphics or a physics engine for this. The UI could even be done in a browser using some funky javascript.
However, the audio engine for something like this is going to be a pretty complex, performance-oriented beast, and is probably best done in C++ (or maybe OpenCL).
Finally, are you sure you're not reinventing Pure Data?
I prefer Irrlicht as a lighter, easier-to-learn, but less feature-complete API than OGRE.
It's literally possible to write a prototype in a few minutes in Irrlicht, and the code itself is easier to understand.
The best thing about it is that it would interface seamlessly with Irrklang, a sound library that may help you with your project.

What 3D graphics framework should I use for a real world game engine? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a C++ programmer with very extensive server programming experience. I'm however fairly bored at the moment and I decided to tackle a new area: 3D game programming, for learning purposes. Additionally I think this learning project may turn out to be good resume material in the future should I decide to work in this area.
Instead of creating a 3D engine from scratch I decided to emulate as exactly as I'm able an existing one: World of Warcraft's. If you are curious as to why (feel free to skip this):
It's a real world successful game
All the map textures, models and what not are already done (I'm not interested in learning how to actually draw a texture with photoshop or whatever)
Their file formats have been more or less completely reverse engineered
There is already an identical open source project (wowmapview) that I can look at if I'm in trouble.
ok, that was a long preface.. Now, my main question is the following: Should I use DirectX, OpenGL, wrapper libraries such as sdl, or what?
What's the most used one in the real world?
And, something else that perplexes me: World of Warcraft appears to be using both! In fact, normally it uses DirectX, but you can use opengl by starting it with the "-opengl" switch via command line.
Is this something common in games? Why did they do it? I imagine it's a lot of work and from my understanding nobody uses OpenGL anyway (very very few people know about the secret switch at all).
If it's something usually done, do programmers usually create their own 3d engine "wrapper", something like SDL made in house, and based on switches / #defines / whatnot decide which API function to ultimately call (DirectX or OpenGL)? Or is this functionality already built in in sdl (you can switch between DirectX and OpenGL at will)?
And, finally, do you have any books to suggest?
Thanks!
I realize you already accepted an answer, but I think this deserves some more comments. Sorry to quote you out of order, I'm answering by what I think is important.
Instead of creating a 3D engine from scratch I decided to emulate as exactly as I'm able an existing one: World of Warcraft's.
However I wanted to focus on the actual 3d and rendering engine, not the interface, so I don't think I will be using it [lua] for this project.
From these two snippets, I can tell you that you are not trying to emulate the game engine. Just the 3D rendering backend. It's not the same thing, and the rendering backend part is very small part compared to the full game engine.
This, by the way, can help answer one of your questions:
World of Warcraft appears to be using both! In fact, normally it uses DirectX, but you can use opengl by starting it with the "-opengl" switch via command line.
Yep, they implemented both. The amount of work to do that is non-negligeable, but the rendering back-end, in my experience, is at most 10% of the total code, usually less. So it's not that outraging to implement multiple ones.
More to the point, the programming part of a game engine today is not the biggest chunk. It's the asset production that is the bulk (and that includes most game programming. Most lua scripts are considered on that side of things, e.g.)
For WoW, OSX support meant OpenGL. So they did it. They wanted to support older hardware too... So they support DX8-level hardware. That's already 3 backends. I'm not privy to how many they actually implement, but it all boils down to what customer base they wanted to reach.
Multiple back-ends in a game engine is something that is more or less required to scale to all graphics cards/OSs/platforms. I have not seen a single real game engine that did not support multiple backends (even first party titles tend to support an alternate back-end for debugging purposes).
ok, that was a long preface.. Now, my main question is the following: Should I use DirectX, OpenGL, wrapper libraries such as sdl, or what?
Well, this depends strongly on what you want to get out of it. I might add that your option list is not quite complete:
DirectX9
DirectX10
DirectX11
OpenGL < 3.1 (before deprecated API is removed)
OpenGL >= 3.1
OpenGL ES 1.1 (only if you need to. It's not programmable)
OpenGL ES 2.0
Yep, those APIs are different enough that you need to decide which ones you want to handle.
If you want to learn the very basics of 3D rendering, any of those can work. OpenGL < 3.1 tends to hide a lot of things that ultimately has to happen in user code for the other ones (e.g. Matrix manipulation, see this plug).
The DX SDKs do come with a lot of samples that help understand the basic concepts, but they also tend to use the latest and greatest features of DX when it's not necessarily required when starting (e.g. using Geometry shader to render sprites...)
On the other hand, most GL tutorials tend to use features that are essentially non-performant on modern hardware (e.g. glBegin/glEnd, selection/picking, ... see the list of things that got removed from GL 3.1 or this other plug) and tend to seed the wrong concepts for a lot of things.
What's the most used one in the real world?
For games, DirectX9 is the standard today in PC world. By a far margin.
However, I'm expecting DirectX11 to grab more market share as it allows for some more multithreaded work. It's unfortunately significantly more complicated than DX9.
nobody uses OpenGL anyway (very very few people know about the secret switch at all).
Ask the Mac owners what they think.
Side question, do you really think hardware vendors would spend any energy in OpenGL drivers if this was really the case (I realize I generalize your comment, sorry)? there are real world usages of it. Not much in games though. And Apple makes OpenGL more relevant through the iphone (well OpenGL ES, really).
If it's something usually done, do programmers usually create their own 3d engine "wrapper",
It's usually a full part of the engine design. Mind you, it's not abstracting the API at the same level, it's usually more at a "draw this with all its bells and whistles over there". Which rendering algorithm to apply on that draw tends to be back-end specific.
This, however, is very game engine dependent. If you want to understand better, you could look at UE3, it just got released free (beer) for non-commercial use (I have not looked at it yet, so I don't know if they exposed the backends, but it's worth a look).
To get back to my comment that game engine does not just mean 3D, look at this.
I think the primary benefit of using OpenGL over DirectX is the portability. DirectX only runs on windows. However, this is often not a problem (many games only run on Windows).
DirectX also provides other libraries which are useful for games which are unrelated to graphics such as sound and input. I believe there are equivalents which are often used with OpenGL but I don't think they're actually part of OpenGL itself.
If you're going to be locking into windows with DirectX and you are willing to/interested in learning C# and managed code, I have found XNA to be and extremely easy platform to learn. It allows you to learn most of the concepts without dealing with a lot of the really tricky details of DirectX (or OpenGL). You can still use shader code and have the full power of DirectX but in a much friendlier environment. It would be my recomendation but again, you'd have to switch to C# (mind you, you can also put that on you're resume).
You might want to look at some projects that encapsulate the low level 3d api in a higher level interface that is api independent such as Ogre3D. As you are doing this to learn I assume you probably will be more interesting in implementing the low level detail yourself, but you could probably learn a lot from such a project.
if you are really only interested in the rendering part, i can suggest ogre3d. it is clean, c++, tested and cross-platform. i used it in two projects and compared to other experiences (torque3d for example), i liked the good support (tutorials/wiki/forum) and the not so steep learning curve. i think someone can also learn a lot by looking at the sourcecode and the concepts they have used in the design. there is a accompanying book as well, which is a bit outdated, but it is good for the start
the problem with this is, you will be thinking inside this engine and soon you will need gameplay-like (timers, events) elements for simulating and testing your effects or whatever you want to do. so you will end up working around ogre3ds shortcomings (it is not a game engine) and implement in on your own or use another middleware.
so if you really want to touch 3d rendering first, i would take some computer graphics books (gpu gems, shaderx) and see some tutorials and demos on the web and start building my own basic framework. this is for the experience and i think you will learn the most from this approach. at least i did ...
I'm doing some OpenGL work right now (on both Windows and Mac).
Compared to my midnight game programming using the Unity3D engine, usingOpenGL is a bit like having to chop down your own trees to make a house versus buying the materials.
Unity3D runs on everything (Mac, PC and iPhone, Web player, etc) and lets you concentrate on the what makes a game, a game. To top it off, it's faster than anything I could write. You code for it in C#, Java (EDIT: make that JavaScript) or Boo. (EDIT: Boo support has been dropped)
I just used Unity to mock up a demo for a client who wants something made in OpenGL so it has it's real world uses also.
-Chris
PS: The Unity Indie version recently became free.