Programming real-time graphics/games in C?

TranquilSea

Newcomer
Hello, all!

I'm a C programmer whose spent most of his time writing console based programs, but I want to go ahead and start writing real-time 3D programs with the intention of writing video games.

What APIs do you all reccomend I learn to use (I'm running a windows-xp machine)? I really, really would like to use C and not C++, since I actually have spent most of my coding career writing C and only have taken cursory glances at C++ code.

Thank you!

-TranquilSea
 
One of the two major APIS: DirectX (DX9 / DX10) or possibly OpenGL.
 
One of the two major APIS: DirectX (DX9 / DX10) or possibly OpenGL.
I guess that DirectX is out of the question here. It's not only OOP but it's also COM-based which means you have to understand the Component Object Model principles. So in TranquilSea's case OpenGL seems to be pretty much the only reasonable solution.
 
Doing it without learning C++ is going to be somewhat of a chore. There are a lot of cases where C++ is beneficial. You could probably get away with using DirectX and just knowing what things do not how they do them.

Basic tasks have been simplified immensely with recent versions of DirectX. I'd recommend downloading the DirectX SDK and reading through the basics to get an understand of just how things are working.
 
I guess that DirectX is out of the question here. It's not only OOP but it's also COM-based which means you have to understand the Component Object Model principles. So in TranquilSea's case OpenGL seems to be pretty much the only reasonable solution.

Noncence. Only because it uses fancy pointers to functions it does not make DX "oop" and basics of COM are grasped within 10 minutes.
 
C99 is just fine. You C++ heretics should all be ashamed of yourself! :p The several things C++ got right doesn't excuse the other things it got wrong and the billions of language abuses made by the average game industry programmer. I know I'm not in the majority on this one (far from it) but heh. And of course, if you want to get an actual job in the industry you'll need be fully fluent with C++.

Anyway, even DirectX10 can be used via C99, but that's probably far from the best way to learn the API. So if you want to start with DirectX, I'm with others that you should learn C++ first. If you're okay with starting with OpenGL (or you'd actually prefer that), then C/C99 is fine; although you will learn an API that'll be obsolete in a couple of months (OpenGL Longs Peak is coming; eventually; maybe...) - still that doesn't make it a bad introduction.
 
Noncence? I cee... Learning COM in 10 minutes will never lead to ref leaks. Oh no...
You dont need to know anything about COM, the DirectX-API is undoubtly influenced by its heritage, but its still enough just to know the DX-API.
Anything else is just pointers to functions as Zengar said. older DX-Versions even had C-Wrappers where this annoyance was hidden in C-Style Macros (not sure about current DX-Versions). You still had to care for destroying created objects, but I dont see why a C-Programmer should have trouble with that if he can handle malloc/free.

But going with C++ would be definitly the better way, you dont have to force classes everywhere because of it, just use it as "Super-C".
 
You dont need to know anything about COM, the DirectX-API is undoubtly influenced by its heritage, but its still enough just to know the DX-API.
Anything else is just pointers to functions as Zengar said. older DX-Versions even had C-Wrappers where this annoyance was hidden in C-Style Macros (not sure about current DX-Versions). You still had to care for destroying created objects, but I dont see why a C-Programmer should have trouble with that if he can handle malloc/free.

But going with C++ would be definitly the better way, you dont have to force classes everywhere because of it, just use it as "Super-C".
I thought that TranquilSea's "I really, really would like to use C and not C++" makes it obvious that the further from C++ the better for him. I do understand your point, believe it or not, but this is not "evangelize me please" thread. It was a simple question with even simpler answer: if you "really, really" don't want to touch C++, use OpenGL.

I haven't seen any OOTB support for C in latest DX SDK. Furthermore many tutorials (and some books) use DXUT as a code backbone. Also COM influences were (back in the days) the main reason for flaws in my code. Right now it does seem stupid, but I know it may be one of those things TranquilSea doesn't want to touch. I know I used to hate it.

My point is: someone asked a simple question with a set of prerequisites. Your answer is: your prerequisites make no sense, change them. Ok, I'm sorry this is not the was I answer questions. :cry:
 
You're kidding, right?

Compared to the OpenGL API, DirectX is a shining example of OOP. :p

Well, you know, I see no real difference between:

somefunc <- QueryFunc(object, "somefunc")
somefunc(object, ...)

and

Bind(object)
somefunc(...)


OOP is more then using that structure-like stuff and function references. It is also about extensibility, and already the fact that you can't derive from DX so called "classes" dismisses it as OOP.
 
Or learn another, more convenient language. It all depends on what you indent to do. If you want to become a serious game rogrammer, seeking employment in one of the serious companies, C++ is still unfortunately your best bet. But if you just want to write smaller, casual games (alone or in a small team), you may also go for a programing language that will speed up your developemenet, like Java or one of the .NET languages. Of course, your game will be then probably about 20% slover then C code (depending on how you utilize the CPU/GPU parallelization etc.), but this won't make huge impact on modern machines.
 
Eh, it really looks like I'll have to learn C++, doesn't it? Might as well bite the bullet now, I guess.
It's really not that bad - don't be irrationally scared of it :) Honestly what it does is give you more expressive power and convenience via the language than C. The best programmers don't go nuts and make everything a class for instance, but C++ provides some undeniably useful tools in the hands of an experienced programmer. From that point of view, knowing C is a good precursor to learning C++ and will make you a better C++ programmer in the long run.

And people can bitch all they want about problems with C++ - and they certainly exist! - but it's still "the best we have" for many types of work, (large-ish) games included. Conspiracy theories aside, the whole industry is not suffering from some sort of collective insanity on this point... there's a reason why you need C++ experience to get a job at many game companies.

Crappy code is a constant... you'll find it in any project and has more to do with the programmers than the language in most cases. The tools that C++ provides are generally quite useful and can produce both clean and efficient code when used properly. Of course you can shoot yourself in the foot (and blow your whole leg off ;)) with C++... so don't :)

Seriously, if you want to avoid C++ though, you can certainly look at some of the higher-level languages like C# for instance, which tie in nicely to DirectX even. It seems like those languages wouldn't exact fit what you're trying to accomplish either though. Really though, you should choose the language best suited for what you're trying to accomplish, and for graphics that's indubitably C++ right now, if only because of API support.
 
Last edited by a moderator:
If you've got a good handle on C, C++ really isn't that bad. Took me a few months and a few readings of The C++ Programming Language to really feel comfortable with most of it (and there are parts of it I just completely avoid, like most of the crazier template and multiple inheritance features, simply because they aren't useful to me on anywhere close to a regular basis), but it wasn't some huge shift or anything. When people talk about C++ being evil, they're really talking about C++ in the sense of using everything that the language offers you in the same project. I've seen codebases where you have a template inside a template inside a template inside a template inside a template, and all of that is in a class that inherits from eight different superclasses and has all kinds of virtual inheritance. It kind of made me question my sanity (I didn't write it, don't worry). But if you're a sensible person, and you use templates and multiple inheritance and all of these features sparingly and only when you really need them, then things won't spiral out of control and become completely incomprehensible.

Plus C is the best language. That means C++ is pretty rad, too. Also, Bjarne Stroustrup is an interesting guy, and I respect his opinions on plenty of things (especially CS education and how it sucks).
 
TranquilSea, my advice is go with ogl and stay away from c++ until you start feeling confident enough with ogl as used from c. trying to get the hang of an advanced 3d api while simultaneously learning a new language seldom produces good results. once you're ok with ogl you can move on to c++ (the necessary evil everybody is sucking up to) or whatever other oop language you feel like doing - you can get ogl bindings to virtually anything.
 
Well, you know, I see no real difference between:

somefunc <- QueryFunc(object, "somefunc")
somefunc(object, ...)

and

Bind(object)
somefunc(...)


OOP is more then using that structure-like stuff and function references. It is also about extensibility, and already the fact that you can't derive from DX so called "classes" dismisses it as OOP.
What? Of course you can. That's the entire point of COM interfaces.

But inheritance in COM is different to what you'd usually think of as inheritance in C++. Inheritance in COM is used for inheritance of interface, and not inheritance of implementation. In C++, it's both. Inheritance of implementation is handled differently in COM, IIRC.
 
Last edited by a moderator:
I don't think about inheritance as in C++ or whatever, i think of it as inheritance in object-oriented programming. That is, you have a class (interface is a class descriptor) and can create your own objects implementing this class. The whole point of OOP is making a bunch of different objects that all implement similar interfaces/classes/templates/whatever but do that all their own way. That is why programming GUIs was a big success for OOP, as idea of GUI, as a collection of components with similar properties maps the idea of objects very well. Given a OOP GUI framework, you can create your own objects that implement some framework mechanisms and integrate them back into the framework. So, your application lives as an objects, it *is* actually an object. DirectX, on the other hand, is a procedural API, only hidden behind OOP-like structures. You can't create your own objects and let them "live within" DX as you do with GUI frameworks. Well, ok, besides shaders, but this is another story.
 
Back
Top