Which Compiler should I use?

Hi. I'm just beginning to learn C and C++. So far its going good. I'm trying to learn for as cheaply as possible. I am teaching myself. I have Bloodshed's compiler but I eventually want to be able to make 2D and 3D games and I heard that is hard to do on Bloodshed's. I heard Microsoft Visual C++ is the best. I don't want to spend 6 months learning on Bloodshed only to get good enough to make a game and discover that I can't do it on Bloodshed.

Someone please tell me what this Microsoft Visual Studio is and what Microsoft Visual C++ is and what the differences are. What is the latest version of Microsoft's compiler.

Just want to be able to use DirectX later on when I get good.

Look at the FAQ.

Use MSVC 6. And why wait till you get good to learn DirectX??

thanks. Well, I got Microsoft Visual C++ 6.0 now and bloodshed's so I guess I'm all set with compilers.

I went to Allegro and found some awesome 3d games and unfinished games with source code that I'm going to analyze.

BTW, I went to the faqs and didn't find anything that helped with my compiler decision. I love Microsoft's debugging feature.

I'm really new so I don't understand graphics all that much. I went to the Ogre website that talked about a graphics engine.

Also, I downloaded this unfinished offroad racing game that looked incredible. He said that he used ODE (open Dynamics Engine), Allegro, AllegroGL, and OpenGL libraries. I might want to go that route because the game looked so good.

Can I use either OpenGL or DirectX with MSVC++ 6.0. I know I have direct X on my system but don't know about OpenGL.

Thanks for your replies.

yeah you can use both GL and DX with VC++ 6.0.

VC++ 6.0 should come with OpenGL libraries in the directory "/include/gl" (wherever you installed VC++ at).

>>And why wait till you get good to learn DirectX??
To make the learning experience rather less frustrating? Unless he's uber-smart and has a photographic memory, if he's "just starting" to learn C/C++, chances are if he jumps in right away he'll be wrestling with common syntax and logic errors on top of the errors from figuring out DirectX, and have trouble figuring out which are which :)

Quote:

---

found some awesome 3d games with source code that I'm going to analyze.

---

Wish you luck :rolleyes:

I personally use MSVC6, and although I've heard people badmouth it, I haven't run into any serious problems yet except for at school on the learning edition which sucks, and is installed on horrible computers that are even more screwed up than the crippled 'learning' compiler.

So far Bloodshed's good enough for me... so... would the experts please tell me what I *cant* do with it? Not to change the subject or anything...:D

You can't write MFC code and use other Microsoft class libraries. However, you can use the winapi and the opensource class libraries out there.

I think I'm done with bloodshed. Too many wierd errors that weren't even errors. I tried to compile a game that I knew was perfect because I copied it from an instructional cd and it wouldn't compile so I opened it in MSVC and had no problems whatsoever.

I don't think bloodshed tells you exactly what the problem is when there is an error but MSVC does.

Quote:

---

I tried to compile a game that I knew was perfect because I copied it from an instructional cd

---

Bad assumption to make :) There's a lot of buggy and compiler-specific instructional cd's out there.

Go to www.amazon.com under books->computers->programming->DirectX


Very good books there. They will help you if you are interested in learning DirectX. And no, DirectX is not confusing, its very simple and straightforward much like OpenGL is.

All of these books explain matrices, the math, or at least some of it, behind 3D, and how to get DirectX and Direct3D up and running. Most of them are under 40 USD and I've had not trouble whatsoever with any of the providers on the page. Very good resources.

Learn DirectX. Learn DirectX. Learn DirectX. Forget 32-bit DOS as much as I love it, it's simply not realistic to learn to program for an ancient platform.

Books that I've read and will recommend highly.

1. Tricks of the Window Game Programming Gurus, volume 1, by Andre Lamothe.

This will explain DirectX in a nutshell and is probably one of the most comprehensive explanations of DirectX including DirectSound, DirectInput, and DirectMusic. It does not cover Direct3D, but the companion CD does and has some very good resources on it.

2. Introduction to 3D Game Programming with DirectX 9.0 by Frank D. Luna.

This covers Direct3D in a very easy to understand format. As well he covers a lot of math at the beginning of the book. If you have problems with vectors or matrix math this is the book for you.
Extremely good book that covers much of Direct3D and makes it simple to use as well as provides a helper header file that will get Direct3D up and running for you. Face it, most of the init code for Direct3D and DirectX never changes - so why rewrite it every time? This book covers vertex shaders and pixel shaders via HLSL (High Level Shader Language) and is very very good and easy to understand. It also covers meshes, progressive meshes, how to load, create, use and texture them as well. It covers cameras, floating cameras, walking over terrain, etc., etc.

I don't understand you Bubba. Did you learn DirectX before you'd gotten your classes, functions, templates, containers, etc. learned? The week after you got your first compiler?

No. But I did start coding games my first week of learning C.

My opinion is that any game will present enough challenges for any new coder to efficiently learn C/C++, though I rarely use C++.
Much of game programming is not really about code anymore but more towards efficient algos and design. Most of the nitty gritty is done for you. A simple intro to C book would be more than enough to get someone started in DirectX.

Now in DOS code this was not true, but anymore it is. DirectX does most of the hard nitty gritty stuff for you. And, because of this, it's not always necessary to know exactly how it does it especially since each driver and GPU implements the DX functions differently in the HAL.

So my advice is learn C/C++ and get started in DirectX or OpenGL. Most of the C language is not even used anymore in a game. You will find that you are really only using a very small subset of the entire language for any one game. COM does most of the work and its all about pointers and interfaces.

Its just not that hard anymore to produce really good graphics in a very small amount of time and it gives newbies an interactive way to learn C whilst at the same time 'seeing' the result of their work.

So I'm not saying dive in w/o learning C but nor am I saying you must be an expert at C before you try DirectX or OpenGL. Beginner to intermediate level C programmers should have no trouble learning one of the graphic API's. Then when they want better ways to store their graphics, meshes, etc., they can move on to the STL, linked lists, and other more advanced C topics.

Jut my opinion for what its worth. But a lot of these guys get discouraged because we continually tell them they must be very good at C to use DirectX and/or OpenGL and I simply do not agree with this philosophy anymore.

Also I rarely use templates or any other structures for the sake of being considered an advanced OOP program. If it doesn't fit my structure, design, or my ultimate goal, I chuck it. Too many times I've tried to finesse my way through a project with oodles and oodles of new structures and hierarchy only to find out the dang thing was too hard to use. KISS - keep it simple stupid and you will thank yourself for doing so. Templates are frieking ugly no matter how you look at them and classes tend to confuse the simple issue at hand especially when designed poorly. Look at some of Silvercoord's posts and he, too, I believe agrees with me in this design aspect. I want my engine to be easy to use, easy to modify, and easy to create a game with. Using a class for everything and inheritance simply obfuscates the code - especially after a couple of derivations from a base. In my humble, yet probably worthless opinion, COM is a much better OOP design philosophy.

I guess that's true, you don't need to be expert at the language to start DirectX/OpenGL. But oodles and oodles of COM, pointers and interfaces, can be especially difficult if you haven't had much time to learn the language itself, and the syntax is totally foreign to you.

Quote:

---

Much of game programming is not really about code anymore but more towards efficient algos and design.

---

If you don't know anything about the language, you're going to have a hard time making efficient algos and designs. The STL containers, for example, can save you a LOT of headache of manually deleting/re-allocating dynamic arrays and copying the original contents, etc... I say this from experience :)

Yes they can, but you do not have to know how to use them to get the job done. So you have proven my point. When you get sick of manually doing all that stuff you will search for a better way. You will see the STL and a light will probably go on in your head that 'hey, I've been reinventing the wheel.' It is this type of learning that I think is most effective.

You remember that 2D code I sent you Hunter? It was full of classes and inheritance and it worked....but it was rather confusing. So I chucked it and started over. Besides I came up with a faster way to do tiles that didn't use Direct3D and now that I know how to use Direct3D I could do it another way.

All of this is part of the learning process and as you have basically said

...the lessons most remembered are the one's you have taught yourself.

>>When you get sick of manually doing all that stuff you will search for a better way
Or, not realizing that there's an easier way to do it, you'll decide that programming is way over your head and just quit ;) I guess there's a balance to be struck... know enough to know that there's a whole lot more out there, but you don't need to know it all.

It also depends on your personality. If you're persistent and determined to make the darned thing work, then jumping in would be ok. But if you're a "I'll smack it around a bit and if it doesn't shape up then I'm tossing it" type of person, it might be a better idea to know more before going big.

Well if you quit, then I guess you'll realize that you don't have what it takes to code.

I don't think that's always true, but there is some validity to it. Determination is a great virtue to have when you're a programmer, but you don't necessarily need a warehouse full of it.

Anyways, I think I'll stop talking, because this discussion is turning pointless :rolleyes: Thanks goes to me for starting this retarded debate.