C++
by Moose or Chuck » Apr 4, 2001 @ 9:37am
by Jaybot » Apr 4, 2001 @ 9:46am
by Moose or Chuck » Apr 4, 2001 @ 9:47am
...by Moose or Chuck » Apr 4, 2001 @ 9:52am
by Dan East » Apr 4, 2001 @ 12:49pm
I guess I'll ease into the fray. First off, let me clarify something. A programming language, such as C, C++, Pascal, etc., is a very generic thing. It's useful only for allocating and manipulating chunks of numbers using very rudimentary math, while applying branches to do different things for different conditions. Period. To do anything useful you have to interact with the real world. Old school technique is direct access to the hardware, which these days is a no-no for many different reasons. Enter Micro$oft and the Windows API. 80% of my programming effort and frustration comes in trying to get Windows (CE, 2000, ME, etc) to do what I want it to do. The Windows API (which can also be abstracted using the Microsoft Foundation Classes in C++) is it's own world, and has nothing directly to do with a particular programming language. If you want to code for Macintosh, Palm Pilot, X-Windows (Linux/Unix), etc., then you enter an entirely different world with each. Visual C++ is designed to help write C/C++ software that interacts with the Microsoft Windows API, particularly with the MFC. What languages like Visual Basic do is provide a very high level of abstraction and data / object encapsulation to make it easier to interact with Windows. This is at a huge cost to overhead (compared to C++). For those that go to the trouble to directly make Windows API calls from within VB, I would say you would be far, far better off to learn C++ syntax so you can lose all the VB overhead you keep just to stick with what you already know. Starting off with Visual C++ with MFC is a good way to begin, as it provides a great deal of templates and automatic class member creation to handle various messages related to windows and other controls. This provides some similarity to VB (ie myWindow.Move(x,y,w,h) type syntax). Basically, all structured programming languages (C, C++, Pascal, VB, Java, etc) have very similar capabilities and logic flow. Thus adapting from one to another is primarily a matter of syntax, as opposed to having to go about solving a problem or thinking in a totally different way (like with Lisp/Scheme).<br>I have a comment about 3d, 2d, whatever programming. First off, if I were to write a 3d game, would I sit down with a blank sheet of paper, and discover for myself the various key algorithms used for transforming, rotating, etc. matrixes? No. No more then I would reinvent the Pythagorean theorem to find the ratio of the sides of a right triangle. All a programmer needs is the algorithm, which they can then attempt to code in an optimum way for the type of data it will use. When I was a student at YSU, I traveled around the US and Canada in various programming contests. I was the coder in a team of three, in which the other two members were mathematicians with little programming ability. While I would generate my own solutions to problems which were within my realm, I would also code algorithms produced by the mathematicians which I did not understand fully how it accomplished what it did (I would always know what it accomplished, but not necessarily the theory behind how it did it). This principle can be applied to game making. If you know that a particular algorithm, given a matrix, will rotate that point around another matrix, well, there you go. You don't need to know the actual geometrical theory to make full use of that function in your application. Further, these days you can find many such algorithms already coded in a variety of languages. I have never (unless it was an accident) utilized anything I learned in Calculus in programming. In fact, the math I deal with primarily in programming (especially the conversion of Quake's floating point math to fixed point) is binary and hexadecimal math, which is probably only touched on in advanced math courses such as number theory.<br>Back to C/C++. I guess the single most important piece of advice I can give a newbie programmer for that language is to always think of variables (structures, arrays, even simple types) as raw chunks of data. If you keep in mind that a variable is block of bytes, it will help you visualize what pointers are, and how pointers can be directly manipulated. Other languages, such as Pascal, VB, and Java, abstract and type cast the data higher than C/C++, so you need not understand what the data really is. C is so flexible it will let you get by with many bad things, so it is important to fully understand at a low level what is going on.<br><br>So, that was my quick blurb on the topic. <br><br>Moose, Phat: if stars were assigned by words as opposed to posts, I would have more than you! 
<br><br>Dan East<br>
, JK.<br>Ugh, I feel like I need to defend myself and re-affirm that I know stuff. But all of you know that already so I won't bother.