Slashdot Mirror
3D Libraries for a Budding Game Programmer?
Orome asks: "From the point of view of someone who wants to learn 3D Graphics programming, specifically for games, it is currently daunting to see the number of options available. Should I first learn OpenGL to understand the rudiments of 3D graphics programming, or should I try and understand the Direct3D API (which has more to offer but is less easier to understand)? With the DX9.0 SDK available, would it be advisable to jump to the next level and learn how to use the high level shading language? Since shading languages are supposed to be THE next thing in 3D programming would Cg be a better tool to learn since it is cross platform." OpenGL and DirectX are always options, but might there be something a little less daunting for those just starting out?
OpenGL is very simple to use, so you are not gonna need something "less daunting". The principles of 3D rendering are the most important and you will need to grasp these things no matter which API you choose to work with, so get some good books.
:-)
"Real-Time Rendering" by Thomas Möller will get you up to speed quickly. "Computer Graphics: Principles and Practice" By Foley, van Dam, Feiner and Hughes is *the* classic reference - get it too, if you want to understand the basics to the core.
Good luck - 3D real-time rendering is a fascinating and fast moving field
Since DirectX and OpenGL are the only widely supported standards for PC game programming, there's no point in learning any other standard if that's your goal. I would go with OpenGL because it's less bloated and simpler than DirectX. But then again, it would probably be more useful to know DirectX if you want to get a job in the industry.
Repeal the DMCA!
If your looking for game programming in general I highly recommend "Tricks of the Game programming Guru's" its 2d, dx6 stuff so outdated, but its a good base line with a lot of 'e-books' on the cd about 3d software rastorizing. The site by the guy who wrote it "andre lamothe" is also very helpful (if the musics annoying) wwww.xgames3d.com If you want to jump right into 3d I found these handy: www.flipcode.com (all) www.andypike.com (directx) www.gamasutra.com (all) www.two-kings.com (directx) Basically pick what you want and google for "Tutorial direct x" or "tutorial OpenGL" Theres THOUSANDS of pagees of stuff out there. AS for DirectX which sdk, go with 9, they cleaned up the tutorials a lot, gave you a nice interface for working with them and reading with them and expanded them to include some pretty advanced effects (even tagging them 'begginner''advanced' etc) DirectX is not as hard as its reputation makes it sound, its a standandard set of components once you get used to it its actually very very nice to work with
Jesus saves, everyone else takes full damage from the fireball.
Get the Red & Blue OpenGL books.
Download the examples for your platform from opengl.org
Get them to build. Find a simple one you like.
Back it up.
Build the back up.
Start hacking on it. when you finally break it, restore from backup.
Repeat
(Profit???)
Need a break from the above loop?
Play tranquility from www.tqworld.com
As intense an OpenGL app as you'll find anywhere.
I started with DirectX, and I will never use a Microsoft API again. I still have nightmares about it's obscure documentation and techniques. OpenGL is far simpler. If you value your sanity, you will use OpenGL. :]
If you want to try out a full featured game engine library, you should give Crystal Space a test drive. It's really nice and there are currently some games being developed with it, including the very cool Planeshift project.
Overcaffeinated. Angry geeks.
Assuming that you already know C/C++. There's a whole bunch of resources on the web and in print. Get yourself The Redbook. Go here http://nehe.gamedev.net. There are forums at opengl.org. There is the opengl gamedevelops list at fatcity.com. There are irc channels.
The graphic designers give you levels and textured objects and animations. It's your job as the programmer to make sure that John NPC dies when he gets shot in the head and to make sure that Wally the Wonder Beaver stops when you try to walk into a wall. A lot of the low-level grunge work of making sure that things like distant objects apearing infront of close ones and such don't happen is handled by the engine, but you have to have a pretty good understanding of 3d to use the APIs. A graphic artist will give you models to work with, but you need to make them work.
Yes, I know this is all a vast oversimplification. Shoot me.
Try the multiplatform OSG. It's a level of abstraction up from opengl, but scene graphs are easier to understand and organize. There are many examples to start with, and the mailing list is quick to respond to support needs. If you ever want to delve deeper into opengl, osg does not get in the way; vertex shaders are fairly straightforward. Even so, it's LGPL, so you could modify the core code too if it ever suited you. Finally there are a dozen or so loaders included, so you can put pretty models into your scene without much experience.
Also, read opengl.org every few days. They post many good resources from tutorials to example apps.
'nuff said.
> realizing that OpenGL, while not the lib of choice for PC gaming, was used else where. A little searching showed that, IIRC, it is the basis of PS/2 development.
I'm not sure where you're getting your info, but it definitely isn't true. (If you have access to the offical newsgroup, a quick scan of sce.*.gs newsgroups would show this.)
While there is 'ps2gl' available for the PS2, I don't know of any commercial games that shipped with it (mainly because some features will *never* be supported in hardware, aka proper stencil support.) The popular choices are: their own extremely bare-metal GIF packet handling, use the low-level sceGs*() calls (which *finally* has the source provided), or use a middleware solution, such as RenderWare or NetImmerse.
> Is it used in Nintendo?
No, but the API is very much inspired by OpenGL.
> Remember, the console market alone is as Big as the Movie industry...supposedly.
Actually it's bigger. Sony has sold ~ 100 million PS1's, and > 33 million PS2.
Cheers
Don't forget about 3D Engines List which has a lot of source available for various home-brew 3D engines.
Cheers
I'm sorry that I didn't get a chance to look at this topic sooner!
Here at the University of Illinois, I'm a project leader for our game programming club Gamebuilders, so I'm pretty well versed in the rudiments of game design.
Yes, the best thing that I can recommend for anyone starting with game programming is to go the OpenGL route. For better or worse, graphics programming is a major component of game design, and OpenGL is general enough so your skills might apply to any number of systems if you choose to pursue a career in game developlent.
That said, the best way to get started with OpenGL is to use GLUT, the OpenGL Utility Toolkit. It's a great way to learn OpenGL without having to get bogged down in the specifics of the OS you're dealing with.
Also, there are numerous tutorials available on the subject of OpenGL and game programming in general on NeHe's site. If I had to point beginning to intermediate game programmers to one site and one site only, it would be there.
If you have any specific questions about OpenGL or GLUT, feel free to send me an email, as well!
for great justice, this sig has been moved
But really, that is just the tip of the iceberg, and let me tell you, it is a HUGE chunk of ice!
If you really want to learn the math behind 3D graphics, you really need to start with 2D rotations and transforms. Start out first learning to plot a square, that you can rotate, transform and scale. The vertices can be plotted using a simple SIN/COS rotational transform, same as for drawing a circle (ie, X=CX+SIN(A)*R, Y=CY+COS(A)*R - I think that is right).
Once you know how to rotate, transform (simple addition) and scale (scaling is simple multiplication by a scaling factor) using basic equations - then learn matrix math - in order to do the same kind of manipulations. For a 2D system, you will use a 3x3 matrix. The operations are the same as the equation method, but are simply expressed in a different form.
You want to get used to matrix math representations, because that is how most 3D stuff is represented in books, and whatnot. Once you know the matrix stuff for 2D - you will want to move to clipping the lines that make up the 2D square to the viewport.
After learning clipping in 2D - you should then probably try your hand at a simple vector game of Asteroids, with spinning ships, asteroids, explosions, etc - all drawn with lines. If you can do this, you are well on your way to going 3D.
First, attempt to do the same 2D square as a 3D wireframe cube, using equation rotations/transforms/scaling math - for 3D, it gets much harder, but if you do the studying right (I did it once, it was a bitch), you will see how it is just an extension of 2D, done three times (more or less). Then, convert that to matrix math (4x4 matrices, now). You will also need to learn how to project the object from 3D space to 2D space (not that hard - a little simple geometry and trig).
Once you can do a 3D cube, you then need to learn about clipping in 3D (ie, clipping the object to the viewport, as well as to the view frustum). At this point, you can go down two road: 3D world database building and display, or solid modeling.
I would suggest the former over the latter, because if you can't show multiple models from a database, making them solid won't help any - plus you need to learn about how the pipelines go together to get the model from the database through the calcs and onto the display, and how to make them fast - in order to have a fast world.
So, you want to first build a world database, in probably a hierarchical fashion - to store the world coordinates of objects. You will also need to learn object culling (ie, getting rid of objects not likely to be viewed - simple object culling involves calculating distances from the viewpoint, and culling those outside a certain range, or "behind" the viewpoint - more complex versions involve BSP and Quad Trees, then there is such things as portal technology, like was used in Descent - complex stuff), as well as sorting of objects, so objects further away are drawn first (which will be useful later for solid modeling).
Once you know this, try to make a Battlezone clone - vector tanks, bullets, enemies, etc.
The last step is learning to solid model, which at the simple level is triangle rasterization. So, the cube become 2 triangles per face, for 12 triangles. Rasterization involves learning how to draw triangles of arbitrary size and shape, and position, using only horizontal lines (hint, certain triangles are composed of two triangles, one with a flat bottom, then one with a flat top - so you would have three routines). You will also need to learn how to sort faces (ie, planes - the triangles that make up the cube) by distance from the viewpoint, and draw those further off first, so that nearer ones obscure the further off ones, so that hidden surfaces remain hidden (oh, and also investigate how to speed up this process, so that you aren't constantly repainting pixels - first it is best to simply cull those planes never seen in the first place, but you can also learn about Z buffers - and the mysterious S buffer system). Once you can do this, take your Battlezone clone and make it solid.
Now, to give you a level of understanding of where you will be at this step - think around 1993-1994 3D 6DOF graphics. You can, at this point, learn about affine and perspective correct texture mapping (not too difficult to add), simple flat-shading, Gouraud shading, Phong shading, fake versions of these, and others - to make things more realistic. There is also learning how to cast shadows (basically computing the vectors from the light source through the objects vertices to where they intersect the ground, and getting the vertices for a flat "object" from that - that is simple shadow casting). If you can do all of this, and quickly - you may have the basis for a simple game or something.
Now, you are ready to convert you code to OpenGL - most of which will simply translate right over, and some which can be discarded almost completely, because the hardware will handle the most of the issues for you (like projection and culling - though you can do this by hand as well - and simply use OpenGL to render the triangles and texture mapping).
I hope you can see how much work this is - I am not trying to scare you away - in fact, I want to encourage you in what you are doing. You will come away with a new appreciation that is 3D graphics coding and development, and the amount of hard work it takes to develop these engines. Now, knowing how to code an engine, and developing that into a game, are two different things - but it sounds like you are more interested in the 3D stuff.
I hope this helps, and provides you with a little direction. There are a ton of tutorials out there, plenty of source code for both hardware and software engines (I do have to reccommend GLUT as well, plus the 3D Graphics Engine List), in just about EVERY language you can imagine (ok, I haven't seen a BrainF*ck engine yet, but I am sure someone is developing it - anyhow, some of the BASIC engines manage to cause the same amount of trauma)...
Reason is the Path to God - Anon