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?
But you'll likely want to invest in some books about game programming in general.
:-(
The way a bunch of us went about learning game programming was to come up with some game idea and implement it from there.
One guy invented Stick Fighter (a bad Street fighter clone), another wrote a Risk clone, and my own idea never panned out but was eventually made into a claymation movie which went on to make millions of dollars of which I will never see a dime.
But the point is to start with an idea and build from there. You can learn as you go.
Then again, if you are really thinking of becoming a game developer you probably haven't thought much beyond how cool it would be to be one. Reality is a harsh mistress.
I have been pwned because my
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
Seriously, java 3d. OK, its not fps-busting in speed, but it is cross platform without so much as a recompile.
Avoid DirectX unless you like windows
And I recommend doing it with the SDL lib. I would bet this would give you MUCH more of an understanding to all of the vector math needed to write you own engine.
After that you could easily port your software engine to hardware using OpenGL.
All while being cross platform.
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 remember looking into this myself at one poiint and 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 basios of PS/2 development. Can anyone prove right/wrong/insane (ok the last maybe easy). Is it used in Nintendo?
Remember, the consoloe market alone is as Big as the Movie industry...supposedly.
Open Source Identity Management: FreeIPA.org
I'm not trying to testosterone you, but OpenGL isn't really all that hard. You don't need much knowledge of linear algebra, CRT's or anything. Get the red+blue (IIRC) and maybe a tutorial. It is quite hackable for the impatient geek and code crosscompiles with an appropriate interface!
-Sean
I'm not a programmer, so maybe I don't understand the question here. Why would YOU want to learn anything about 3D at all? Surely that's the job of the graphic artist or level designer. The programmer just writes a program to install the game and parse the highscores.txt file, right?
which has more to offer but is less easier to understand
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.
less easier, eh?..... just like that sentence?
-- If you try to fail and succeed, which have you done? - Uli's moose
...now you're saying take both the red and the blue pills?
Liberty uber alles.
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.
Don't go low level unless you really want to. If you want to get a game out either use the torque engine that appears to work and is a whole hundred US. Or for a basic FPS use the Quake engine for nowt.
:)
Dave
I write a blog now, you should be afraid.
For a long time I wanted to be a game developer. I tried learning C++, hacking around with some stuff, etc. This was a few years back, and I never understood C++ at the time. I just started learning C++ again, and this time around, its a lot easier for me to understand. Maybe because I have got a bunch of Scheme and Python under my belt.
Anyway, I don't want to develop games anymore. I don't know why. I've taken to learning Qt, and I'm developing a tool for developers now. I tried making a Half-Life mod, and I discovered that game development wasn't for me, for whatever reason.
Some tips: Get good with C/C++. Very good. If you use C++, use inheritance wherever you can, but don't overuse it. Learn OpenGL, get the Red and Blue books, and hack away. Try SDL for virtually everything else, and stay away from proprietary libraries and compilers, so as to remain as portable as possible.
If you develop a Quake-killer, can you GPL it, too?
Slashdot is a waste of time. I enjoy wasting time.
'nuff said.
Don't forget about 3D Engines List which has a lot of source available for various home-brew 3D engines.
Cheers
An excellent book. We used it in CSE470 and it was also used in the graduate level course. Even if you don't read all of it, you should get a copy. Mine occupies a place of honor on my Bookshelf.
Also consider getting a Beginning or 'basic' Linear Algebra book. It will help you with some of the math in the Graphics Book.
Oh, if you write in Visual C++ make sure you clean up your brushes after EVERY paint operation. The docs don't say anything about it, but those buggers leak memory like a siv!
I've been hanging out in a forum where a lot of aspiring (and professional) game designers hang out, and one suggestion that keeps popping up for people looking to get into writing games is Blitz.
Blitz is a programming language designed for writing games. It started out on the Amiga, and was ported to Windows some time ago. It has very impressive 3d graphics capability built in (if you get the 3d capable version, and not the cheaper 2d only version).
I haven't tried it myself, as my attempts at game writing have been in OpenGL under OSX, but it looks quite impressive.
Not that I have written any major 3D software, or even work in the 3D industry. But at uni we learn't openGL as part of our computer graphics course.
Once you have mastered the coordinate system it is so mind booglingly easy to get graphics on screen it's insane :) Writing good fast graphics is another issue but it makes the creative process so much more fun seeing your work on screen quickly.
For windows development you can even start with openGL for free :) (yes even on windows). I would recommend getting the MinGW compiler which is free, and openGL - again a free download. Information can be found here a quick google search turned up this page and it is a good summary.
use google to find some simple openGL sample programs to work from- and away you go :) Have fun!
If you ever drop your keys into a river of molten lava, let'em go, because, man, they're gone.
Many people read /. with signature lines turned off. Also, your sig won't be included with your post when this thread gets archived, and if you decide to change your sig tomorrow, then your post won't make any sense at all.
Living better through chemicals
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
Small world. I used to work at a company that, due to historic reasons too complex to get into here, shared ownership of some Unix (Suns, if anybody cares, an U60 and a SS20) servers with the guy who coded Tranquility. He was a hell of a sysadmin (due to other historic reasons too complex to get into here, I ended up being the head sysadmin of said company so I interacted with him a lot) and nice guy as well. Never met the guy face to face, he lived/worked in Hawaii and we were based in Houston, just lots of time on the tele and talking back and forth.
News for Geeks in Austin, TX
I would go with OpenGL. There is excellent documentation in the official books and nehe.gamedev.com (both mentioned already,) and it's surprisingly easy to learn (or at least that's what I thought, but I'm a strong math person.) I would definitaly not recommend getting into shaders and fancy stuff like that until you understand the basics of models, textures, transformations, etc.
I have never tried Direct3D programming, so I can't comment on what it's like, but I do know that OpenGL does the job well. Also, computer graphics is, IMHO, a interesting field to work in. Direct3D will let you write windows games, but OpenGL is the standard that works with windows, mac, linux, sgi, sun, etc., and opens up a bunch of interesting jobs in scientific and engineering visualization and other fields.
Most of the effort in creating a 3d Game is not necessarily in the 3d graphics, but rather in the actual application. I would start there first; any graphics libraries can be applied later.
Try to figure out how your going to startup the application, support sound, input devices, load graphics and models, do bounds and surface collision detection, and implement multiplayer *if that's a goal*, etc.
...really an amazing value for a source code tree with ongoing development. And a ready-made marketing solution in place. Built-in networking support is a real bonus but the graphics code alone was worth the price. They have online forums where a lot of information and problem-solving goes on. Very impressive.
I just dabble personally but I got more than I expected. And I have a lot of the classic texts on graphics and DirectX stuff. Torque makes things easier all the way around. A commercial quality engine but a great study tool.