OpenGL and Game Graphics

[Kyon]

I have some experience in game creation (understanding the necessary relationships, etc) and have a good understanding of C++, however. Now I wish to go on with creating my first game in C++. I was checking Amazon.co.uk the other day and came across two books:
Beginning OpenGL Game Programming, Second Edition - Luke Benstead (Paperback)
Advanced 2D Game Development - Johnathon Harbour (Paperback)
Which of these two books is best for a novice/amateur C++ programmer?

Furthermore Im wondering whether OpenGL is the way to go if I want fast real-time rendering, good results and compatibility over different OSs.

[Seraphimsan]

OpenGL is the ONLY way to go if you want fast real-time rendering, good results and compatibility over different OSs

[Kyon]

So.. thats one question answered.. Now. What book should I take of the above two or even, in what ORDER should I read them?

[Seraphimsan]

Havent read them so I couldnt tell you.

[Return 0]

seraphimsan wrote:

OpenGL is the ONLY way to go if you want fast real-time rendering, good results

Not so fast... OpenGL is a great API, but its not the only one out there and the only real advantage it has is cross platform... but really... who cares about those mac users anyway? :) :P. Ogre 3d and Direct3d are both equals, it just depends on the games requirements.

Regarding the books. I have read both of them. Beginning OpenGL Game Programming... So many are deceived by the "Beginning" term. This does not mean it's for complete beginners. You must have in depth knowledge of C++ before you can even open this book and its really just a short OpenGL reference... its also already out of date... althought most of the book is valid. You might be better off with the OpenGL Superbible or REd book.

Advanced 2d Game Development. Again not a bad book, but you need to be confident in your C++ skills. This focuses on direct input with Direct X.

The problem with both of these books is it really doesn't teach you how to create a game. There is so much more to game programming than putting graphics on the screen. There's all the logic behind it, such as Path finding, etc... where the real work is done.

[Seraphimsan]

It is the only one that fits ALL of his requirements :P you know, including the one you left out when you quoted me.

Of course there could be another cross platform API out there thats better than OpenGL that I dont know about.

[Return 0]

Ah... I just noticed the OP stated over different OSs... so you are correct OpenGL is the way to go. Ogre 3d should also be of interest.

[helios]

Ogre 3d and Direct3d

OGRE is a rendering engine, not a graphics abstraction layer.

[Return 0]

Yes I know, the point is it's used in indie game development and should be of interest. It is not to be compared directly with OpenGL or Direct.

[Kyon]

I really do want to start with understanding rendering, so that I have an alternative next to the old rusty console outputting. When I grip that concept I can start my learning process on game production. Any good books to learn OpenGL (not just references, but real tutorial books)?

[Kyon]

Double posted, all hail Internet Explorer's crashes.

[AngelHoof]

The usual learning curve is to go with 2D before 3D, and jumping into OpenGL/DirectX right away is definetly not recommended.

Start small, with 2D - try SFML/SDL (I personally recommend SFML though), once you've got a decent game made using that, you may be confident enough to move onto the more advanced API's. Namely OpenGL or DirectX .

[chrisname]

Is the book "Zen of Graphics Programming" by Michael Abrash still considered good? I've heard good things about it.

I originally started programming because I wanted to make games (like a lot of people, although I didn't have the "I have been programming for two minutes, it's time to make a 3D FPS" mentality) but I became more interested in operating systems. I still am greatly interested in operating systems (I think the fact I paid £50 for Tanenbaum's book is a testament to that) but I want to try my hand at game development as well. I've had what I think is a good idea for a game that I'd like to work towards making.

[AngelHoof]

Time to Download Game Maker, chris :)

Nah, but.. Seriously, you should take the step ahead and play around with some API's man!

[chrisname]

Game Maker

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!

The thing is, the game I'd like to make will be difficult. I wanted to make a scary game. Basically you would start at the top floor of a big building (an office building or perhaps a house, although the latter is a little cliché) and have to work your way down the building. Sounds easy, right? Well, there would be "things" that you would never see (I could just use sounds to obviate that there was something there, and perhaps the odd flicker of movement) and perhaps traps that you could walk into. Still sounds easy. But you would have no weapons.

The way you would beat the game would be to lead a monster that you don't know exists into traps. All you would know is that something is following you.

I have no idea how any of that would work.

[tortillahead]

That sounds like a good idea for a game.

[NGen]

Seems like a good idea for a prequel, but there's a lot more that I could see you doing with that concept.

This isn't the kind of game that I'd expect to need the speed that C++ has, so Game Maker would work as a substitute. There's nothing wrong with using a tool that is simpler, so long as it gets the job done in a way that works for you. But if you want to stay away from Game Maker for whatever reasons (my current reason is that GML is too simple and uninteresting to be used in complex games), I understand.

You need several things:

- Map Editor
- Collision System
- Input System
- Rendering Engine
- If there are multiple enemies, then Processing Stacks/Stages
- Resource Handler

If you make the base correctly, you can use that base to program both your map editor and your actual game. I'm assuming you'll be using something like SFML, so input shouldn't be too difficult. I'm not entirely sure how much you know about programming something like this, so I'm going to explain pretty much everything in fair detail.

Keyboard input should be stored two ways - By event and by key state. SFML gives you the event objects, so that's already done for you. You just need to also keep a key state version (assuming that SFML doesn't give this, which, if it's anything like the SDL, it doesn't), which would allow you to hold down a key and move left or right without the key-repetition that the OS does for you. I do this by creating a bool KeyStates[0x80];, each position in the array representing a character. Of course, all key states are initialized to 0 to represent that the key isn't currently being pressed. When you get an event that a key has been pressed, simply set the corresponding state in the array to true. KeyStates[KEY] = true; When the key is released, set its state to false. You can then use this KeyStates array for moving around. Keeping the events also allow you to check for key presses rather than just checking the state of the key, which can be used for something like jumping and creation of UIs.

Collision systems tend to get a bit messy no matter what way you set it up, you just have to try to keep it as clean as possible. What I'm currently doing in my engine is having two lists of hgeRect objects (hgeRect is a class that contains the bounding box representing the general area of a sprite), one is just for collision masks and the other is for collision handlers. Collision masks are just hgeRect objects with an ID. Collision handlers are objects containing both the hgeRect and ID as well as a reference to either a function or a method that would be called in the case of a collision. When we check for collisions (which is done all at once during this process) we loop through the collision handlers and check for intersecting bounding boxes if the ID of the handler and the ID of the mask match. Obviously you're going to have a different reaction to colliding with the floor from colliding with a spike, so this ID system works. To further optimize it, you can use a map with the ID as a key and a list as a value to prevent looping through objects without the same ID.

That collision system has a problem however, the easiest way to do gravity is (semi-sudo-code):

y += VerticalSpeed;
VerticalSpeed += Gravity;
Tile *CollidingTile;
if ( CollidingTile = CollidingWithSomething ( &ThisBoundingBox ) )
{
      y = CollidingTile->y - CollidingTile->UpperSpriteDifference - this->LowerSpriteDifference;
      VerticalSpeed = 0;
}

In this case, collision checking is done outside of the collision event. For this particular issue, functions will be needed that simulate the collision checking process, but it only checks against the bounding box passed to it. If you want, you can also add the ID to check for as a parameter.

The rendering engine should be fairly simple, SFML makes that part a bit easy for you in this case, but you may run into some problems later on with this method. You can simply make a list for each rendering type and then render them in order. The problem with this is that, along with complete lack of drawing order, if you want to do a bunch of things while drawing, or if you want do get specific variables to do a certain thing while rendering, you don't have that option. I did something similar to the collision handler for my rendering system, I have a list of objects that contain, for the most part, just a pointer to a function or a method. You can guess how I'd use them.

A lot of the time, order in which things are processed is VERY important. For example, say you have an object that follows the player. If the follower updates its position first, and then the player updates its position, the following object won't be up to date. (I suppose using pointers would fix that problem, but that's not the point.) To fix this I have a map with an integer as a key, and a list as a value. The key represents the processing stage, and the list gives all of the callbacks to be used during that stage (this, for my system, also works similarly to the rendering system). This way we can keep our objects ordered during processing.

The resource handler is mostly a method for obtaining and releasing resources en masse. I'm still working on this part myself, as I'm trying to get some edits for the rendering library (HGE, it's like SFML, but Direct3D-reliant and is designed for game creation) finished so I know exactly what rendering API we'll be using, but those two ideas that I just stated are key. If you want to avoid global variables you need some place to store them all. Virtual members aren't a good idea because then when you begin to write the cleanup functions for the game, there are a lot of resources you have to release manually. A universal resource handler would be able to free them all at once, allowing you to easily add and remove resource-dependent classes from the game.

That's somewhat similar to what I have for a base API. Only, I'm setting mine up to be used for online, so I have some networking protocol classes in place along with some quad-tree optimization in my collision handler.

This whole thing is, of course, assuming that you're planning on using 2D, since modeling people isn't exactly easy. Even then, most of the described systems would still work just fine.

[chrisname]

Well the game I described is one that I want to make 3D, but I'm obviously not going to start with 3D, I will work my way up to it.

Thanks for the detailed description, too.

A universal resource handler would be able to free them all at once, allowing you to easily add and remove resource-dependent classes from the game.

This was an idea I had: to create a resource manager class which stored references to variables in vectors with names (each one is in a struct). The resource manager has functions to add, get and remove variables from the appropriate vector. At the end of the game, anything left in the vector is released and freed. It's extremely simple, which is the best kind of extremely.

Edit: I'm also "buying" 4.92 GiB of game development books. I don't need all of them, but if anyone wants them you have only to ask.

[NGen]

I spent about a year trying to get a game engine done, simply just coming up with stuff as I came along. As I'd get into development with an engine, I'd find it incredibly difficult to use, maintain, and debug. At some point I decided to just sit down and plan out a system which would allow the most flexibility, and what I described is part of what I came up with. I also created a method to keep track of variables by name to allow for command-line editing of variables at runtime, but that's hardly difficult to implement.

Basic 3D isn't too difficult, it's about as easy as 2D. But as soon as you touch shaders or physics, it's all over. If you want the game to look good, however, you need a very good 3D modeler that's either willing to work for free or at a price you're willing to pay. 2D graphics are much easier to make, and you can't go wrong with 8-bit style graphics.

[chrisname]

I like 8-bit graphics. 8-bit games were the best; they were about fun and not "OMFG LOOK AT THAT GUY'S ARM COME OFF IN REALISTIC 3D MOTION WITH REALISTIC BLOOD SPLATTER OMGOMGOMG"

Edit: also: http://i29.tinypic.com/2qjlw82.png