PDA

View Full Version : ok...and now what???


mrloco
03-01-2005, 04:08 PM
now that i know how to use loops classes, and all of that C++ goodness, what next? How would i go about programming something simple, like pong, or asteroids? Or maybe I am on completely the wrong track...help me!

mummey
03-01-2005, 04:12 PM
Inheritance, data structures, and the STL...

Post here again when you've got those done.

ace4016
03-01-2005, 06:43 PM
Along with what mummey said, try working with console a bit to get comfortable, make black jack or tic-tac-toe on the console. When you get the hang of it, you'll know what to do next.

leas5040
03-01-2005, 07:49 PM
I agree. Try something like Tic-Tac-Toe, where it's really easy to make a little ascii grid and fill in characters where they are supposed to go.

I disagree with Mummey about the STL. If he learns a lot about data structures and in the process makes some of his own classes for things like lists, queues, stacks, heaps, trees, etc., then he can reuse the code later in other projects where he needs it. I would definitely recommend creating your own data structures first and then learning the implementation of STL classes later. While the STL is important, it won't do you any good if you don't know what is going on in the first place.

ace4016
03-01-2005, 08:23 PM
But doesnt re-inventing the wheel go against some OO concepts? Might as well use C if your going to invent a class again and again like that. You can still know the STL as well as know how to make the STL for yourself, it just saves time to use code that has been tested and optimized. And if you need something a bit more specific to your application, I am sure inheriting would be a lot quicker then inventing from scratch. Plus, not too many people like to take the time out to re-invent code that has been made already. Just my $0.02, I know the whole thing is debatable.

arramor
03-01-2005, 09:23 PM
I agree with mr.snoopy, sort of. Use STL for now, but try to learn at least a little while you're using it. At least know what each structure does and what's it use. If you wanna do the game thing, that is. There's no need to go into much detail for now. And when you get more used to some of the structures, you might later implement your own.

rakmaya
03-02-2005, 06:04 AM
In programming, the more you know about data-structures (such as queues, vector, blah, blah, blah), the better.

Game and Graphics touches core portions that make most defined utilities such as Vector, Queues etc useless. Most of the time you will find yourself creating things in between Vector and plain Arrays for different uses (performance, time saving issues etc...) So a basic understading of how those things work is very essential. It is also the first few topics taught in any CS classes and in most programming books.

I suggest you make youself comfortable with those to get the grip of C/C++. Then you can start learning the theories of Graphics (if that is where you want to focus). Then start learning one of the APIs (OpenGL/DirectX). Believe me, once you get to know C++ and get good at problem solving skills, all else is peace of cake.

gga
03-02-2005, 06:22 AM
My suggestion: start small and use other people's code as a study guide.
Overall, C++ is not a very nice language to learn how to program in, as it is a rather complex one. My suggestion is to always learn how to code with some introductory language first like ruby, python or visual basic and then move on to C++, if you still need the speed or more functionality.
Anyway, to answer your question... the best way to learn, is to learn from other people's code.

Pick something out of sourceforge or other source code listing. Find a project that it is to your liking that is already finished (ie. beta or later). Ideally, you want something relatively small to begin with, so you won't be overwhelmed. Most likely, this won't be a big application.
Games are usually good as guides, as they are a tad more fun. Play with it a tad. Find something that you'd like to change or improve on it.

Now, delve into the code. If you are using an IDE like msvc, you can easily get a listing of classes and get a broad view of the game, which may or may not help, depending on how easy to read the code is.
Try to find the function or class that is responsible for doing the stuff you want to change. If you have no clue, start at main() and keep using cerr or printf to track what each portion of the code is, as you run the program. If you are familiar with your debugger, you can also use that to step thru the code.
Once you locate the area of the code you want to change, modify it. Keep working at it until you finish your original goal. In the process you'll probably create your own new bugs and so forth. Start with something simple, like changing the values of the score points. Don't try to do gfx stuff as your first thing. Concentrate on changing the logic of the game. If pressing a key moves the character to the left, make the code move the character to the right. If you need 4 rows to get tic-tac-toe, figure how to cheat and win with only 2 rows.
Once you get bored with that, delve into how the graphics are done.

C++, as you might already know by now, has basically no graphic tools in and by itself standard with the language. All that is usually specific to the operating system. As such, C++ relies on libraries (ie. a bunch of .h and .dll/.so files to provide the missing graphic functionality). Usually these libraries are also referred as APIs or SDKs and often come with documentation with the OS or compiler. Sadly, sometimes the documentation of the APIs to those libraries can be three times more than the actual documentation of C++ itself. Fortunately, perhaps, you don't need to learn all of it at once and you can use the library documentation as reference.
Some popular graphic APIs include OpenGL (multiplatform), DirectX (windows only) for 3d graphics. For managing windows, requesters, and 2d drawing, there are many more choices like MSVC Foundation classes (windows only), X11(unix) and others a tad more obscure.
Sadly, once you learn some of them, you will also quickly learn that all those APIs are incompatible with each other.
As popping up windows and so forth is quite common and programmers often like having stuff work both on windows and unix systems, you will also find libraries that manage windows that try to be platform agnostic, hiding all the nasty stuff from you (FLTK, Fox, wxWidgets, etc).
To code a game, you will likely end up having to learn how at least one or two of those apis work. FLTK, for example, comes with a very nice set of introductory demos that show what it can do and can be nice for studying too.
If you want to do 3d games, you will eventually have to learn about opengl or directx.
The game you downloaded, probably also uses its own api to draw windows and so forth, so you need to probably find out what they are using so that you can look up info about functions in the documentation.
The microsoft compiler also comes with an excellent documentation system that documents all of the microsoft apis, opengl, and has some examples. Unix systems usually have all their docs accessible thru the 'man' command.
Often the programmer will mention what APIs he is using in a README file or similar. So, perhaps, the first API you will learn will be more by random choice than out of your own choosing.
OpenGL, FLTK and FOX are usually considered relatively friendly apis. While DirectX, X11, etc. usually take much longer to learn. wxWidgets is probably somewhere in-between.

CGTalk Moderation
03-02-2006, 07:00 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.