Elysian Shadows

Hello der, everybody.

I'm new here and before I get into what I'm about to mention, I want to introduce myself.
I'm a 14 year old aspiring programmer that started programming in VB6 when I was around 12, now moved to C and C++. I've made a few projects in my life and created my own DirectX8 engine with dynamic lighting and the sorts. I hope that my stay here is great

I've decided on taking the task to convert this into Pure C with DirectX9. But, i've run into a problem with the 'CreateDevice' function, that seems to be only supported in C++.

Here is my code;
It is giving me the error Yes I'm using Visual C++.NET

I've looked on google and have yet to find such answer..
If any of you could help me out that would be fantastic

DirectX uses Microsoft's COM system, which uses objects. I'm pretty sure you can't use pure C with it, since it requires inheritance, so you should use C++. Why would you prefer pure C anyway though? C++ *can* make your code more readable and easier to debug (if you know how to use it properly).

szdarkhack wrote:DirectX uses Microsoft's COM system, which uses objects. I'm pretty sure you can't use pure C with it, since it requires inheritance, so you should use C++. Why would you prefer pure C anyway though? C++ *can* make your code more readable and easier to debug (if you know how to use it properly).

There are plenty of reasons why a person could want to use C... I still prefer it for low-level, driver projects, when interfacing/using a bunch of inline assembly, or for any sort of library that could potentially be used with a C codebase... Most drivers are still written in C to this day.

But yeah, Microsoft is notoriously bad at supporting C (Visual Studio 2010 only supports the c89 ANSI standard to this day). If you want to be a DirectX developer, C is not the language. You should be using C++. There isn't dick that you can do. DirectX is a C++ library.

edit: Although if you're CRAZY, you can always wrap the DirectX API with extern "C" functions and link against the wrappers with a pure C codebase... Not recommended, though.

So, yeah I got this working after reading the header file, by defining CINTERFACE before including the file. After using it for a while I decided that D3D is a programmers hell compared to OpenGL which is much simpler and so much more portable (which in my opinion is one of the main things any programmer should look for). Thanks for the input guys.

Also, I'm using C because I'm not exactly used to OOP(although I'm reading a good book on C++ by the creator of C++). I do hope to move to C++ as it seems more organised and efficient.

Thanks again guys. Loving the series of yours Gyro .

evilbunnie wrote:So, yeah I got this working after reading the header file, by defining CINTERFACE before including the file. After using it for a while I decided that D3D is a programmers hell compared to OpenGL which is much simpler and so much more portable (which in my opinion is one of the main things any programmer should look for). Thanks for the input guys.

Also, I'm using C because I'm not exactly used to OOP(although I'm reading a good book on C++ by the creator of C++). I do hope to move to C++ as it seems more organised and efficient.

Thanks again guys. Loving the series of yours Gyro .

D3D9 isn't that hard. It's all pretty simple when you learn the API. Want a mindfuck? try D3D10 or D3D11 lol. I used to hate D3D's guts, but i learned to accept it, though OpenGL is still my one and only bitch for life.

And i encourage you to start learning C++, it's really not all that hard. The good thing about C++ is that it does not enforce you to stick to the OOP paradigm and you could suddenly go for a functional approach. If you know the C syntax already then C++ should be a breeze.

I don't know... I tend to encourage starting with C first. If you aren't using OOP in C++, it's considered poor design, and you're "doing it wrong." Newbies who start with C++ spend 90% of their time agonizing over unnecessarily complex design decisions that they don't need to be making and only 10% of the time actually coding.

A common first task in OOP game development is to create a "state machine." This usually tends to be some gigantic clusterfuck of abstract classes that can be implemented anywhere, and the goal is always to be completely standalone and generic. What could be implemented (and almost every time SHOULD BE) as a simple enumerated type representing a state and a switch statement, will waste DAYS of the newbie's time, confuse the shit out of them, and ultimately offer FAR SHITTIER performance. What have you gained here? Nothing. They're even more confused than when they started.

When you're first starting C/++, your first priorities should be understanding syntax and underlying mechanics like heap vs stack allocation, pass-by-value vs pass-by-reference, pointers, memory, functions, and low-level language constructs. You shouldn't be spending 5 hours trying to decide how two classes should communicate back and forth as two isolated black boxes before you even understand how the language works... I have gotten SO many messages from confused beginners who fall into this OO trap.

I know that 90% of this forum believes that C++ is an end-all replacement to C, but I don't. I believe it can be very beneficial to start with C first. Just take a second to look around and see how many kiddies are posting about "proper object-oriented design" when they don't even understand how the stack works...

No I never said D3D was hard, it's just cluttered. Look at it then look at OpenGL.

I've pretty much got OOP down, and I've converted most of my work now after pretty much completing the book(Need to revise some of it). But I agree with Gyro, C is defiantly the place to start.

Thanks for the input though, guys.

Well looks can be QUITE deceiving :] ...especially in this case.