C++ Tutorial Excercises
Hi, I'm starting a set of excercises and tutorials that will accompany the C++ tutorial here on this site. The goal is to start out (requiring no prior programming knowledge) as a set of accompanying exercises, designed to test and reinforce your understanding of C++ as you work your way through the tutorial supplied by cplusplus.com. As you complete the tutorial however, the excersises will begin to branch off and explore some mathematical equations for matrices as well as collision detection on a 2D plane. We will study, in detail, data management and pointers (pretty dense stuff), eventually leading up to the creation of an ASCII based game engine (running out of a standard command shell). This game engine will handle collision detection, “graphics” rendering and “screen” buffers, z-order, file loading, and much more. This course will be designed to be as friendly and inviting as possible, and any constructive criticism is welcome.
I have released the first practice set on my blog: http://und3rgroundh3ro.wordpress.com/category/programming-tutorials/ , and was wondering if there is any intrest in this? If so, does anybody have any tips or critisizms they would like to add? Any advice would be appreciated. Thanks in advance =)
I have released the first practice set on my blog: http://und3rgroundh3ro.wordpress.com/category/programming-tutorials/ , and was wondering if there is any intrest in this? If so, does anybody have any tips or critisizms they would like to add? Any advice would be appreciated. Thanks in advance =)
| eventually leading up to the creation of an ASCII based game engine (running out of a standard command shell) |
Why do so many people tend to veer towards this archaic and difficult medium?
Why not just introduce a graphic library and jump right into drawing actual graphics. It's not like it's any more difficult -- in fact it's usually easier.
| Z order? Didn't you say it's 2D? |
Yes, it is 2D, however if one graphic occupies the same space as another graphic on the screen, the engine needs to know which graphic to draw on top.
| What library are you using for text output? |
The entire engine will use the standard libraries. For text input and output it will be using stdio and iostream.h
| Why do so many people tend to veer towards this archaic and difficult medium? Why not just introduce a graphic library and jump right into drawing actual graphics. It's not like it's any more difficult -- in fact it's usually easier. |
The purpose of this is to teach you how to make your own library using nothing but the standard c++ libraries, not to rely on 3rd party libraries built by other people. It is to teach you the core mechanics of building your OWN game engine, not mashing together libraries that are already on the market.
The ascii engine is the simplest way of going about this because it is much less complex. We will only need a 2D array of chars approx. [100][100] in order to keep an entire screen of data. This means there is only 10,000 "pixels" (for lack of a better term) for the entire scene. Importing "graphics" is much simpler as well because all you need to do for an ascii engine is to import a .txt document.
If you wanted to jump strait to graphics, we could use windows.h to draw every pixel, but we would have to have a MASSIVE 2D array of a declared pixel structure (consisting of an RGB value) approx. [1000][1000] if not larger. On top of that you would have to use advanced algorithms for simply drawing a diagnal line (which pixels does a line with this slope and this length occupy?). Also you would have to write your own file i/o algorithm to import graphics for every file type you would want to support.
Jumping strait to drawing actual graphics using the built in c++ libraries seems like it would be a little to far over a newbie to c++'s head.
| The entire engine will use the standard libraries. |
Aren't you kinda new to this whole programming thing to be writing a tutorial?
| we would have to have a MASSIVE 2D array of a declared pixel structure (consisting of an RGB value) approx. [1000][1000] if not larger. |
| On top of that you would have to use advanced algorithms for simply drawing a diagnal line |
And most graphics libraries take care of rendering primitives for you, anyway.
| Also you would have to write your own file i/o algorithm to import graphics for every file type you would want to support. |
http://www.libpng.org/pub/png/libpng.html
http://www.libtiff.org/
Or, if you're feeling lazy,
http://freeimage.sourceforge.net/
| Jumping strait to drawing actual graphics using the built in c++ libraries seems like it would be a little to far over a newbie to c++'s head. |
DO NOT REINVENT THE WHEEL.
| Let's say the screen is 1024x768x24. That would take 1024*768*3==2359296 bytes, or 2.25 MiB. Hardly what I would call "massive". |
It's not massive in terms of size, but massive in terms of dealing with. As opposed to making the new programmer manage an ASCII based engine that refreshes the screen only when it recieves input from the user, and is only around 10000 "pixels" in size. The windows.h version for a screen 1024x768 would use 786,432 pixels every game loop (which in the case of video games is usually around 60 frames per second, translating into saying "This pixel is this color" 47,185,920 times every second, roughly 5000x that of the ASCII engine). It makes managing and actually seeing what their programming is doing on the screen a little easier.
| DO NOT REINVENT THE WHEEL. |
This tutorial is designed to give those people who want to make the tools that people like you use to build your games and programs a place to get their footing, as well as teach people what most graphics libraries are doing for you. Some people start out programming to build programs and games, some people start out programming because they want to build engines like the Unreal Engine, and some people start out programming because they want to create or work on libraries like OpenGL. I'm in the small group of people who want to be in the latter 2 groups, thats why I use C++ and not java. I know I'm not alone in this, however when it comes to tutorials I have found that almost everyone writing tutorials assumes you want to be in the first group. I think you missunderstand my motives, it's not to reinvent and try to replace the wheel, its to teach people how the wheel works on a basic level so I'm not just telling them to wave their magic wands and saying "DO" and letting the little faires under the hood of the car take over (I think this metaphore is getting out of hand). Now if you want to argue that graphics engines deal directly with the video cards and drivers, however true it might be, I don't believe I will be writing a tutorial on that any time soon =P
DO NOT BUILD A CAR IF YOU DON'T UNDERSTAND THE ENGINE ;-)
Aren't you kinda new to this whole programming thing to be writing a tutorial? |
What makes you think I'm new to programming? I've been programming hardcore in c++ for about 2 years now and playing around in it since I was around 12 years old (6 years ago). I've built matrix engines, collision engines, vector algebra engines, a ASCII graphics engine (which I'm now going to write the tutorial on) and more. I've also built 2 full video games handled using c++ and a graphics library:
1. A Pong game with 2 play modes, classic (self explanatory) and arena mode where you and your opponent are in a circular ring and you can move around the outside of the ring blocking your opponents movements.
2. Letter Bricks - A brick breaker game where, in liue of dropping powerups, broken bricks drop letters that you collect with the paddle. The game keeps track of what letters you've collected and displays them next to the playing area. After breaking all the bricks it brings you to a "Wheel of Fortune" like game where you have to spell as many words with the letters you collected as you can. It imports the entire unabridged english dictionary.
I'm new enough to remember what It was like starting out using tutorials and always wondering "how does this engine do this?", but seasoned enough to say "this is how".
You don't need to refresh the screen continuously. Depending on the type of game, you may be able to get away with refreshing on demand. Then it's even cheaper even if there's constant motion on the screen, because the screen rarely has to be entirely refreshed. For example, a game of Asteroids only has to draw the background under each particle and then the particle itself; usually less than 50% the cost of drawing the background entirely and then all the particles.
Your philosophy is entirely counter-productive. The point of a black box is precisely that it allows you to not know how the engine works if you need to build a car. The people who built the engine are the ones who need to know that. Sure, you can build your own engine, but unless you know what you're doing, it'll be much crappier than the one that already exists, and even then you'll have to invest a lot of time in testing until you reach the quality of the existing one. Of course, that doesn't mean that you should never build your own engine. If you're building an engine to find out how to build it, go right ahead, but if you're interested in the car, and not the engine, however.
Now, just because you're building an engine, doesn't mean you should go mine for some iron and make your own screws. What I'm trying to say is, sure, build your own engine if you want, but don't be stupid. Don't waste time writing your own image format handling routines. It's been done. Man hours are too expensive to be wasted on solved problems.
Well... The fact that you're using streams for non-stream output is very suspicious.
If you still want to use text output, I would suggest, instead of doing something as utterly retarded as using streams, to use one of the curses libraries. Linking to external libraries is a vital subject in software development that's not covered in nearly any tutorial I've seen about C or C++.
| DO NOT BUILD A CAR IF YOU DON'T UNDERSTAND THE ENGINE ;-) |
Now, just because you're building an engine, doesn't mean you should go mine for some iron and make your own screws. What I'm trying to say is, sure, build your own engine if you want, but don't be stupid. Don't waste time writing your own image format handling routines. It's been done. Man hours are too expensive to be wasted on solved problems.
| What makes you think I'm new to programming? |
If you still want to use text output, I would suggest, instead of doing something as utterly retarded as using streams, to use one of the curses libraries. Linking to external libraries is a vital subject in software development that's not covered in nearly any tutorial I've seen about C or C++.
| Your philosophy is entirely counter-productive |
Not really, it drills you with the basics of C++ programming (arrays, data managment, file i/o, etc) while teaching you some of principles of computer science. If there isn't any support for this, I won't waste my time making a tutorial, but I thought it would be a fun way to teach people new to c++ nested for/while loops and 2D array data managment.
I didn't say it wasn't an effective teaching method. Maybe it is, maybe it isn't. I said it was counter-productive.
If you're going to write something that encourages wheel reinvention, then please don't bother. Newbies tend towards that without any encouragement. If you want to show how a couple wheels are made as a didactical help, then at least add a disclaimer that one doesn't normally deal with such minutiae when they're irrelevant to the work at hand.
| Man hours are too expensive to be wasted on solved problems. |
If you're going to write something that encourages wheel reinvention, then please don't bother. Newbies tend towards that without any encouragement. If you want to show how a couple wheels are made as a didactical help, then at least add a disclaimer that one doesn't normally deal with such minutiae when they're irrelevant to the work at hand.
Okay, so the question still stands, would anybody be intrested in a tutorial like this?
Topic archived. No new replies allowed.