Well I've been learning C++ on and off but I plan to stick with it and I'm going to try to program at least two hours a day everyday for the rest of summer and hopefully when school starts again if I can. How often do you guys program? (just curious)

What I wanted to ask you all today is how much C++ should I know before I can/should start learning a graphics API, since I want to make a game.

I'm not the best programmer, I try really hard but there is so much to know about C++. I know the procedural part pretty well, and I'm on operator overloading, I've already covered a bit of inheritance and obviously encapsulation. I'm learning the object oriented part now. But what else is there?

Sorry for the long post, I'm very passionate about programming. :D

If you want to deal with graphical API, you should probably know everything. If you are practicing two hours a day for the summer (this will probably turn into 4-5, because once you get drawn into a project its hard to quit), you should be able to basically accomplish this. The hard part is not learning the language, but properly using what you know.

Thanks a lot for posting!
It does end up turning into a little more time than I expect and that's good for me to practise. Very true about using what you know properly.

Another question, if I may, what is there that I should learn after OOP and templates and all that...

I am using http://www.learncpp.com/ to learn mostly. Is this enough or is there a better tutorial (meaning more features of c++ explained). I always see people talking about things concerning C++ that I've never even heard about and it worries me that my knowledge is nowhere near up to par.

Well if your able to get OOP down, which is the heart of c++, your pretty much good to go. The other things you pick up as you start creating your own applications(std library and such). You'll run into problems that you will have to research how to accomplish something.

Other then that, it would probably be a good idea to learn some fairly standard algo's and such, including linked list, the different kinds of linked lists, error handling using try, throw and catch. To list a few.

Also, when you see something that you don't understand what people are talking about in forums, you should simply google it so you can understand. I think that's one of the best ways to learn. Good luck and stick with it!

I pretty much use up my free time on C++ (It's addictive :D). I've used c++ for about 2 years on and off now(still nowhere as good as most people) but i'm comfortable with my knowledge, once you get to the point to where you just pick something up after a couple of tries then you should move on to APIs(currently i'm working with SDL). most of my knowledge is through trial and error and help from communities like DW(Best communities IMO has all my programming needs from ASM to C++ and many many more :P). Focus on complex and or nested loops and keeping track of them they will drive you nuts when your ide spits out "expected } at the end of input" then you go man i knew i was forgetting something.

I don't know whether its the amount of time i have been coding or luck but when im coding i can usually tell if a bit of code will do what i want it too (probably luck since some of the stuff i do i don't fully understand).
Ive never been to college or had any training in c/c++ just your normal layman essentially. In case you haven't noticed i have the worst grammar this century which is weird in the sense that im a pretty good speller(note that im also not very articulated and sometimes i can be plain ignorant of some stuff :{ )
also i tend to get off topic sometimes ????? :O

here is a few resources you might find useful:
I learned Pretty much everything there (beside what DW helped me with Big thanks guys(and gals i think(besides dani :P) ?))

http://www.cprogramming.com //Misleading name C & C++
http://www.cplusplus.com  //extensive documentation on the std library :D

Thank you LevyDee and avarionist!!

YOu were very helpful and thanks again. C++ is addictive, I agree. I don't usually have problems with nested loops but I suppose it can get messier as I go along. THanks a lot for the link, I'll make sure to use them after I'm done with learncpp :)
I used to program python/pygame so I have a wee bit of exp in SDL (:
I was thnking I might use OpenGL or Allegro though for my game

Thank you LevyDee and avarionist!!

YOu were very helpful and thanks again. C++ is addictive, I agree. I don't usually have problems with nested loops but I suppose it can get messier as I go along. THanks a lot for the link, I'll make sure to use them after I'm done with learncpp :)
I used to program python/pygame so I have a wee bit of exp in SDL (:
I was thnking I might use OpenGL or Allegro though for my game

as a side note opengl(i still like opengl Though WAAAY more than DX) can be difficult and allegro i'm sure is a good library but its awkward for my taste. It would be cool if you could teach me a bit about sdl/python i would really like to get a grip on python its fast and very flexible I like it as much as i like perl (probably a bit more.) :D

Well, I have more than 12 years of experience in OOP programming and I started as a teen with 3D game programming (now doing more multi-body dynamics simulation, robotics control software and artificial intelligence). I jumped right into OpenGL from the start and painfully rammed through it all. I recommend being a little more cautious but still 3D gaming is exciting and it's hard to go slowly once you get a few things running. One link I highly recommend to learn openGL is http://nehe.gamedev.net (it is where I learned and all my friends in the gaming industry too, awesome tutorial, simple, clear and detailed).

How much C++ do you need? Well, you can start programming games from knowing nothing or you can start after having a Computer Science degree (which really won't make that big a difference to be honest). That I know of, there is only one way to learn, that is practice, practice, practice... It seems you understand that you can't just read books and expect to be a good programmer (as you say you practice a few hours every day). Personally, I have had many little projects one after the other, making a game engine, then a physics engine, then a better game engine, then a 3D model editor, then a particle system, then a better physics engine, etc. etc. I think now I have iterated to my 5th or 6th completely new physics engine (or now multi-body dynamics simulator) and about the same for the game engines. So you see, it's all about trial-and-error. Start a "big" project that you would like to achieve, think about the software architecture for a good while (that's the most important part) and then program it, solving problems as they come, until you're stuck. Then start new with a new plan or architecture. The software engineering is a huge part to learn and it's the most difficult part, but it's the most important (in my current project, I spent 2 years slowly preparing the software architecture, not a single line of code, just letting ideas battle around my head, and about 3 months to program it all (about 40 000 LOCs), and now it's working great!).

What after OOP and templates? well I'm still learning stuff on OOP and templates today, these two things are extremely powerful concepts and they are really open-ended. During all the past years I have thought I was a good programmer, an "expert", but every year I get disgusted by the poor quality of the code I wrote just a year before. Anyhow, one thing to look at is programming paradigms and idioms, these tell you how to push OOP and template concepts to their limits and how to program better, more intelligently and more productively.

For computer game: C++, OpenGL / GLSL, SDL or GLUI, Boost libraries, ODE (if you don't want to bother programming physics), ... and Linux! or cross-platform, which none of the above violate.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.