Beginner at OpenGL, 2D or 3D first?
Author
I've started learning OpenGL about a week ago. I've learned how to make 3D shapes, texture objects, do simple lighting, and tranlsate/rotate polygons. I'm using Beginning OpenGL Game Programming(great book for those of you that are new to this too!).
Well, now I feel that I'd like to make a simple game with this. My problem is that I'm not sure whether learning to make a 2D game or 3D game would be more benificial to me at this point. I've made a number of other, simple 2D games before, so I have a fairly good understanding of this. I'm completely new to 3D.
What suggestions do you guys have? Also, what would be a good starting 3D game to make?
Thanks in advanced!
I went straight to 3d. (Caveat: I was 90% done with a CS B.S. degree and had just taken a class in graphics)
So I think you should go straight to 3d too.
as far as openGl is concerned, the difference is just whether you add a nonZero Z-coordinate to your polygons
The main difficulty you're probably going to have is camera setup, lots of people starting out in 3d tend to have all kinds of camera rotation questions, usually because they have issues visualizing the matrix transforms and how to order them to get the effect they want. Lots of examples of people getting stuck with trying to make glLookAt work right....
you can avoid the whole issue of course, if you just pushmatrix your own camera matrix in there instead of messing with euler rotations.....
Why not make a 3d Pong or 3d BreakOut game? should be simple enough, fixed camera positions to keep it simple for now.
Easy physics; essentially the same as the physics for normal 2d pong/breakout, but with an additional copy of the same X/Y motion forumulas for Z position...
So I think you should go straight to 3d too.
as far as openGl is concerned, the difference is just whether you add a nonZero Z-coordinate to your polygons
The main difficulty you're probably going to have is camera setup, lots of people starting out in 3d tend to have all kinds of camera rotation questions, usually because they have issues visualizing the matrix transforms and how to order them to get the effect they want. Lots of examples of people getting stuck with trying to make glLookAt work right....
you can avoid the whole issue of course, if you just pushmatrix your own camera matrix in there instead of messing with euler rotations.....
Why not make a 3d Pong or 3d BreakOut game? should be simple enough, fixed camera positions to keep it simple for now.
Easy physics; essentially the same as the physics for normal 2d pong/breakout, but with an additional copy of the same X/Y motion forumulas for Z position...
Author
You say that that camera problems are common for beginners, do you have any tips/tutorials for it?
I'm presonally not into this whole Pong/Breakout/Tetris thing(Fun games, but I would never make them). Its just something about me. Space Invaders I could do. I was thinking of making a straight-forward racing game, similiar to the minigame in KOTOR, but with really bad graphics. So, no real physics, and no vertical movement. I could even keep the camera stationary and just move the objects in the gameworld to create the illusion of a moving camera(something I'm pretty sure I could do with relative ease). Would this make sense for a first game?
I'm presonally not into this whole Pong/Breakout/Tetris thing(Fun games, but I would never make them). Its just something about me. Space Invaders I could do. I was thinking of making a straight-forward racing game, similiar to the minigame in KOTOR, but with really bad graphics. So, no real physics, and no vertical movement. I could even keep the camera stationary and just move the objects in the gameworld to create the illusion of a moving camera(something I'm pretty sure I could do with relative ease). Would this make sense for a first game?
The most difficult part about 3D in opengl is the math as its not difficult to understand the API. So the question is, are you comfortable with linear Algebra and solving quite complex math problems?
I started with 3D because most the books I have concentrated on that, but I quickly realised that I just wasn't getting the math part of it and so changed to 2D. Writting 2D for me is more rewarding because 2d uses trig quite a bit and is easy to understand, the development process is therefore much, much quicker.
I started with 3D because most the books I have concentrated on that, but I quickly realised that I just wasn't getting the math part of it and so changed to 2D. Writting 2D for me is more rewarding because 2d uses trig quite a bit and is easy to understand, the development process is therefore much, much quicker.
Author
I think that I can do the math required for the game I have in mind. I really enjoy math, so I'm willing to put in the effort to figure out how to solve it if I don't get it to begin with.
I'll probably go for 3D, but I'll wait for another post or two just in case.
I'll probably go for 3D, but I'll wait for another post or two just in case.
It seems to me, that the main source of camera and rotation confusion is due to perception of Reference Frame.
Most people do an X,Y, and Z rotation (applied to all objects in the game, or to the camera - its all relative and equivalent) but they base them off some Absolute World Coordinate System X,Y and Z axis. Then get confused when their camera starts pointing strange directions due to a bad combo of rotations leading to a 'gimbal lock'.
It is important to realize that th
e order of rotations are important (imagine a tank turrent vs your shoulder(bad example...but all i can get now)) also, that once your camera has rotated, its axis for successive rotations do not necessarially match the World axis anymore... But people end up applying later rotations to those World axis instead of the Camera's Local axis and get results that don't match expectation.
So the key is to have a Local Coordinate System for your camera, that is separate from the Absolute World Coordinate System. And base your camera view changes off these.
I do this by having 3 vectors (a matrix) as part of my camera class, representing it's local X,Y, and Z axis, and whenever I want to rotate my camera, I change these. Then instead of messing with 3 succesive glRotate's(with the abovementioned issues) I directly plug the camera's x,y,z values into the opengl matrix stack. Once you have this kind of system working and get the idea, its a lot easier to use it everywhere (all my game objects have a similar local coord system and single matrix transform).
So it goes something like....
I want my camera aiming that direction, so set its Z to point that way.
and I want the camera's 'up' direction to point this way, so set its Y to point this way. Then I cross product the Z and Y to get the X ...normalize
Anyway, that kind of system lets you think of the camera as 'where do I want it pointed' rather than 'how many degrees does it need to rotate to point here'.
Ohwell, sorry if that was long and confusing. Been a while since I touched the basic stuff, I just wrote a good self contained camera class, and quit thinking about dealing with the internals afterwards.
Most people do an X,Y, and Z rotation (applied to all objects in the game, or to the camera - its all relative and equivalent) but they base them off some Absolute World Coordinate System X,Y and Z axis. Then get confused when their camera starts pointing strange directions due to a bad combo of rotations leading to a 'gimbal lock'.
It is important to realize that th
e order of rotations are important (imagine a tank turrent vs your shoulder(bad example...but all i can get now)) also, that once your camera has rotated, its axis for successive rotations do not necessarially match the World axis anymore... But people end up applying later rotations to those World axis instead of the Camera's Local axis and get results that don't match expectation.
So the key is to have a Local Coordinate System for your camera, that is separate from the Absolute World Coordinate System. And base your camera view changes off these.
I do this by having 3 vectors (a matrix) as part of my camera class, representing it's local X,Y, and Z axis, and whenever I want to rotate my camera, I change these. Then instead of messing with 3 succesive glRotate's(with the abovementioned issues) I directly plug the camera's x,y,z values into the opengl matrix stack. Once you have this kind of system working and get the idea, its a lot easier to use it everywhere (all my game objects have a similar local coord system and single matrix transform).
So it goes something like....
I want my camera aiming that direction, so set its Z to point that way.
and I want the camera's 'up' direction to point this way, so set its Y to point this way. Then I cross product the Z and Y to get the X ...normalize
Anyway, that kind of system lets you think of the camera as 'where do I want it pointed' rather than 'how many degrees does it need to rotate to point here'.
Ohwell, sorry if that was long and confusing. Been a while since I touched the basic stuff, I just wrote a good self contained camera class, and quit thinking about dealing with the internals afterwards.
Quote:Original post by haphazardlynamed
Anyway, that kind of system lets you think of the camera as 'where do I want it pointed' rather than 'how many degrees does it need to rotate to point here'.
That's because people suffer from the hammer syndrome. "If all you have is a hammer, every problem will look like a nail". Most likely they simply don't know anything but glRotate/Translate and try to reduce every problem to this, resulting in horrible ideas like asking how to calculate Euler Angles to rotate by to make it look in some way instead of just _setting_ it to look that way.
And I further claim that this lack of knowledge about the available "tools" is the result of the annoyingly widespread "show me a tutorial"-mentality instead of a "know a good book covering the basics?"-mind set.
But as the original poster mentioned a book and said he likes math I just assume he is familiar with matrices or can quickly pick up the basics. Meaning he should be able to have box racing down a quad with other boxes as obstacles in pretty short time. It might even more more difficult to understand where the game logic ends and the actual graphics begin, ie. what OpenGL is responsible for and most of all, what not.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
