1. Yes, I try to use references as often as possible. They''re cleaner than pointers and faster than variables for passing large objects as function parameters. (By the way, I don''t use references ''instead'' of pointers. They both have their uses.)
2. C++ is just C with a few extra features. An experienced C programmer can pick up C++ in a day, though getting the hang of OOP takes a little longer.
3. I can''t really tell you how it works without going on and on and on. Best bet: get one of those ''Game Programming'' books. They aren''t too great for actually teaching you programming but they can give you a basic understanding of simple game programming techniques and graphics code.
4. there''s no single solution for all games. A lot of game programmers are from old-school backgrounds, including assembly, which is ''pure'' procedural programming. So, OOP hasn''t really caught on with game programmers quite as much as with other software developers. However, I think this is changing and OOP is slowly becomming the norm.
5. Most people using VB are total newbies, so the language itself is associated with newbies. Also, VB is extremely high-level and doesn''t give you too much low-level control. Finally, VB is too slow and inefficient for anything other than budget games. You can optimize, and I''ve seen optimized VB code run faster than unoptimized C.. but, optimized C will always beat optimized VB code. Oh yeah, and VB is Windows-only.
6. If you actually finish a game and it''s good then I don''t think anybody really cares what language you did it in. It''s just that there''s so many newbies who come on boards and say ''Hey I''m making a game like diablo II in VB but I need help with my new 3d engine!! what is a normal??!?'''' that after a while you tend to associate VB with those newbies, even though there may be some decent developers working with it.
7. The best way to save time in a game is to have a good design. If your code is very well designed and documented even before you start writing it, you shouldn''t have to rewrite it, and that''s the best time saver possible.
8a. Never use GOTO statements. It creates insane spaghetti code (try tracing through JMP statements in aseembly sometime) and is never necessary anyway.
b. Lots of globals is avoided for two reasons: one, it''s confusing, and two, it goes against OOP. If you don''t care about OOP then using globals can speed up some critical sections of code. A few years ago it was common practice to optimize critical functions by passing parameters using globals to avoid pushing and popping them onto the stack. Nowadays, micro-optimizations like that are generally overkill.
c. Multiple inheritance is confusing as hell and buggy on most compilers. Considering how it''s almost never useful in game development, I''d avoid it like the plague.
d. I think this is a common misconceptions and I disagree with it. There''s virtually no performance hit in using classes and nothing wrong with using objects whenever applicable. I''ve worked on many projects where the -only- global function was WinMain (and a handful of macros). But, it''s all a matter of personal style.
d(2). This is a pet peeve of mine: people trying to delve right in to what is very easily the most difficult branch of programming (game programming) immidiately. Believe me, I''ve worked on OS kernels and device drivers before, and I''ve had more problems with DirectDraw than those. You gotta have patience and a good background first.. I don''t think anybody should even think about programming a game until they know their language and they know how to work with their OS.
9. Natural progression. People used to code games in assembly and never complained because there was nothing better available. As each language gets simpler people get spoiled with them and don''t want to go backwards. I mean, when I first bought my old 486 with 8MB of RAM and a CD-ROM drive, I thought it was amazing! But two years later, after I had a Pentium with four times the RAM, the old one seemed like crap
. And now, my old Pentium is crap next to my Athlon.
If you don''t believe me, check out some of the open source for the older games, especially ones using assembly and procedural C, heavy on the goto. And tell me it''s easier to read than modern C++
.
-RWarden (roberte@maui.net)
1.Does anyone here use references instead of pointers? what are there advantages?
2.Why does C++ some so much more huge than C? How long does it regularly take to learn?
3.Can someone explain to me the concept behind creating a game, It hurts my head trying to think of how the lines of code actually turn into objects on the screen, and how variables can actually control graphics. It''s like the language knows what it''s doing, but C doesn''t really understand models or pictures, it''s really confusing me
4.IS OOP really the solution to all games? because people do tend to plan games procedurally. for example, a TODO list for the engine or something, some ppl will write down things they want done then look over each major part and do the most important first, that''s pretty much procedural don''t you think?
5.Why is VB not classified as a "real" programming language?
6.Why do people seem to "care" as to what programming language you use, as long as the project is finished and it''s a good game?
Not to say I use VB, but most C or C++ programmers will say, "VB?! eww" and stuff like that, I think it''s seriously retarded.
7.I had a question earlier that I asked, but noone answered but I thought It was something that needed answering. Do you people have innovative ways to use short-cuts in game development without loss of quality, I mean scripts for example, or anything in general that will speed development of the project up.
8.can someone list some things that are bad to use in C/C++ for my future reference? 
