Recommended Method of Creating Games

I hope a broad question such as this hasn't been asked already but I couldn't find anything through searching.

I'm interested in making games for Windows as a hobby using C++. I've made games in the late 90s using the win32 API as a hobby and it worked fine. I've spent my time since writing business applications on UNIX and Windows; absent of video games, naturally. Now, in 2005, what method would be recommended: win32, MFC, .NET/C#, GTK?

The reason I ask is because while I can pick up the win32 API set quickly again, I'd rather spend my time learning something that will carry me into the next years.

From what I can gather--and news straight from MS is always a bit shaky--future editions of Windows will be using .NET along with Avalon, making the win32 API depreciated.

Where would my time be better spent?

Graphics libraries like OpenGL, SDL and Allegro seem to be use a lot more commonly than libraries targeted at standard apps.

Absolutely. I plan on using OpenGL for any 2D/3D graphics that will be needed beyond the basic resource bitmap drawn.

Direct3D is an option.

Managed Direct3D via C#. Theres a section for making games in Direct3D with C#/.NET at http://msdn.microsoft.com/coding4fun...t/default.aspx

I've found so far that the OpenGL and D3D graphics libraries are what you want to know, as far as what to use, If you want something better than a downloadable compiler go with visual C++, if you want something top of the line buy (or download the trial) of Borland C++ builder 6.0, I believe that is the program most professional companies use

Thanks for all the suggestions everyone.

I've already started learning C# and WinForms and will be using managed DirectX (MDX) for graphics--started with GDI+ first to get the hang of WinForms first.

I'm sure I'll be posting in the C# forum soon enough.

Borland?? C++?? Builder?? I tried that stuff and I'd say that first of all it doesn't support all the standard headers that visual C++ does.. And it's interface is really ugly.. And Dev-C++ (latest release) is much better that borland.. ok it doesn't have a gui for designing windows, menus etc (but vc does) and the catch is that's it's completely free and you're guaranteed that if you use standard headers (no windows headers).. it'll compile in unix too (gcc) .. and i heard that unix (linux) can run opengl and sdl applications :) right?

You can still use Avalon with C++ cant you? Wouldnt win64 API come out before win32 API is depreciated? Even though its suppose to be backwards compatible.

Damn, "C# and WinForms and will be using managed DirectX", yeah thats what you call Windows intensive indeed.

I'm personally choosing C++ with win32 API (till win64 API) using OpenGL graphic support.

Quote:

---

Originally Posted by OP

C# and WinForms and will be using managed DirectX

---

Woohoo I win!

Quote:

---

Originally Posted by Dae

I'm personally choosing C++ with win32 API (till win64 API) using OpenGL graphic support.

---

Not that I've done much of it, but to need the extra performance gained from going so low level I'm pretty sure you would need to write a very very graphics intensive/very big application, ie Doom 3. For anything with a small team (ie just the OP), especially as a learning process, I can't see him really NEEDING those benefits, and considering he's experienced with C# it's would seem the better alternative. Each to his own though.

No one needs to see that shit! Put a shirt on!


Quzah.

Quote:

---

Originally Posted by Ruski

and i heard that unix (linux) can run opengl and sdl applications :) right?

---

For Linux, you can create applications using SDL or OpenGL to drive graphics, yes. You can also use Qt, GTK+, and wxWidgets as the API along with much lighter graphics use. Also applications written in GTK+ and Qt (with a nice fee of course) can be easily ported to Windows using their Windows counterparts.

There are probably at least a dozen other APIs that I've left out.

So if you're trying not to be a "Windows intensive" programmer, you can choose any of the APIs above before going "C++ with win32" (why not go with MFC if you're going to do C++?).

win64, for most of the hobby projects we'll be creating on this board, from what I've seen, is beyond overkill. The only benefit I can see is early adoption, but this early in the game you know Microsoft will be changing the API again and again in the next few years.

Besides, I keep hearing that .NET is the future of Microsoft.

I'm choosing C# with MDX for the simple challenge that it'll provide. That, and after MDX I'm sure any heavy OpenGL will be a breeze to learn. C# will also come in handy in the future with any company I'll be employed at.

Well, currently Managed DirectX + C# isn't really, uh, `approved' among game creators, you could say, it's growing on them, though, but C++ is still standard. However, C# DX is still really, really good combo though.

The MFC is about twelve times more robust and confusing than most game programmers will need to deal with. So you don't really need to worry about that.


I have to say Managed DirectX and C# is the way to go if you wanna make games as a hobbiest, it's a language that makes things get done quick (a Windows Forms app in C# is about 35 lines with a C Win32 app is about 80, which isn't horrible, it's just longer while the C# version will be slower,) and really easy to use and learn if you ask me. It's not as fast as C++, naturally being a part of .NET, but it's good enough. I have seen a lot of cool games with C#.

I wish I could help you more, but unfortunately I am working off a immensely unstable kernel with an Operating System Microsoft completely deny's creating (WinME,) so while I can do C# with the .NET 1.0 framework, I can't do standard .NET 1.1 coding with DirectX in C#, which ........es me off, and that thus means I can't support all the cool tools that .NET 1.1 guys can. So I'm forced to use C++ DirectX (which isn't bad, I just really wanted to use C# and DirectX :[.)

I suggest you go grab a copy of Visual C# Express Edition (free,) and read the following book I got on my server for Windows C# programming:


http://austin.youareinferior.net/boo...sharp(pdf).rar

Once you read that you should have a good grip on Windows Forms programming, so then read this:

http://users.pandora.be/riemer/
Awesome DX9 C# tutorial, it'll really jump start your learning.



Good luck.

Quote:

---

Originally Posted by stovellp

Woohoo I win!


Not that I've done much of it, but to need the extra performance gained from going so low level I'm pretty sure you would need to write a very very graphics intensive/very big application, ie Doom 3. For anything with a small team (ie just the OP), especially as a learning process, I can't see him really NEEDING those benefits, and considering he's experienced with C# it's would seem the better alternative. Each to his own though.

---

He said he was experienced in win32 ;) he just posted not long ago that he took up C#, thats no biggy.

But yeah.. since hes going WINDOWS programming as a HOBBY, then he's picked a great combo.

Thanks Mad_guy for the words, and the Charles Petzold PDF (I have a few of his older books, great stuff). I'll be studying that book for the next few weeks.

While managed-anything with .NET is slower, I've heard at times up to 15% I think it was, it does provide quite a lot of nice features for your program. Besides, at this stage I won't be making any kind of games that that kind of drawback will make any difference anyway. (And then there's the whole Murphy's law about computer speed that will make this worry a thing of the past in the next 3 minutes while CPU speeds quadruple.)

Why is .NET slower anyway? I mean, what makes C++ faster than C#?

And why is visual basic .net syntax different from vb6 (i know it's an off-topic question.. but speaking about .net...)

... Okay, let me smack into shape.


First off, .NET and C#.

.NET is slow because it is, in fact, an Object-Oriented psuedo language much like Java. Java is run through the JVM, which interprets ByteCode. ByteCode isn't machine code, or Opcodes. Bytecode is a special format that is interpreted by a Virtual Machine such as the JVM. The JVM takes the bytecode and translates it into Opcodes, which theoretically is what makes Java work *everywhere.* The Bytecode isn't platform and architecture dependent like Assembly or Win32 code. The JVM interprets it accordingly.


.NET is compiled into CIL I believe, which is just interpreted to the computer by the CLR. .NET works by doing JiT compilation or Just-in-Time compilation. The ideology behind JiT is `hunks' of bytecode are thrown into the interpreter/VM at a time and THEN translated into opcodes to feed. This way, the program is throw into opcodes as it is run.

The reason frameworks like .NET and The JDK are slow is because it takes a signifincatly larger amount of time to translate these pieces. In fact, I also bet that when the VM interprets .NET or JDK code, it probably produces and feeds the CPU badly made Opcodes as well.

That's the same reason languages like C++ are slower than their brother C. C++ is Object-oriented, therefore when it's compiled it comes out to more opcodes to accomodate the language, so it takes longer for the CPU to run them. That's why a C++ app that's big will take a long time to execute and lag sometimes.

This is also the reason, why Assembly is so damn fast, you control every step of how the computer mov's (bad joke) and thus it is compiled into the smallest, fastest and most lean opcodes.



This also, brings us to VB.NET and VB6.

As I mentioned earlier, .NET is object oriented. Therefore all the languages of .NET inherit this (another bad joke.) VB6 and VB.NET are built off totally different frameworks, one is Object-Oriented and one is not.

Hence why in a procedural language like C you would do strlen(string); but in VB.NET you might do string.Length(); because in that sense the string variable is not a variable, but an object to a string class with it's own methods and data.