3D Libraries for a Budding Game Programmer? 59
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?
You didn't mention (Score:4, Interesting)
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.
Re:You didn't mention (Score:2)
Re:You didn't mention (Score:1)
Haven't you read [slashdot.org] his other comments?
It's "Chicken Run".
(To keep from being offtopic: I got into game programming using SDL with Dev-C++, it's a free way to learn the software side and determine whether or not it's really for you).
Less daunting? (Score:5, Informative)
"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
"Computer Graphics: Principles and Practice" (Score:1)
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!
Re:"Computer Graphics: Principles and Practice" (Score:2)
Please note that I did not tell you to learn to spell or anything like so many here, I was just trying to help.
I have no advice on game programming.
Re:Less daunting? (Score:1)
agree, that's *the* classic reference for people who interested to write a replacement of opengl, or a software render engine. not for a game programming novice.
openGL - starting points on the web (Score:2)
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 [latrobe.edu.au] a quick google search turned up this page and it is a good summary.
use google to find some simple openGL sample programs [opengl.org] to work from- and away you go :) Have fun!
Java 3D (Score:2)
Avoid DirectX unless you like windows
Re:Java 3D (Score:2, Insightful)
Or your customers run Windows.
Re:Java 3D (Score:2)
Re:Java 3D (Score:1)
DX gives you sound, input, AND graphics. DX != OpenGL. D3D == OpenGL.
Re:Java 3D (Score:1)
Build a rasterizer in software first (Score:5, Insightful)
After that you could easily port your software engine to hardware using OpenGL.
All while being cross platform.
Re:Build a rasterizer in software first (Score:1)
Re:Build a rasterizer in software first (Score:2)
I agree entirely. And the book to read is Fundamentals of Computer Graphics [amazon.com] (note: it's an associate link. feel free to avoid it, buy the book anyway.) This book is by the guy I had for a graphics class (on building a rasterizer) last year, and we beta'd the book for the class. I'll be perfectly frank and say that it's a book that will be better in the second edition, but even now it really is the best there is. If your goal is to understand 3D graphics, not just futz around until things look good by trial and error, you have to read this.
Go with OpenGL (Score:5, Informative)
Beginners (Score:5, Informative)
Re:Beginners (Score:1)
Re:Beginners (Score:2)
--trb
OpenGL (Score:4, Informative)
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.
Re:OpenGL (Score:1)
Including Doom 3? :-)
Re:OpenGL (Score:2)
Re:OpenGL (Score:1)
The blue book is a printed copy of the API documentation available online. Even though some people find it easier having a paper copy, I prefer searching on the computer. Plus, keeping the online documentation on my laptop saves me a lot of weight to carry around.
When I downloaded the OpenGL API documentation, it was available on sgi.com somewhere, but you can find it in other places as well.
ot: tranquility (Score:1)
OpenGL is used in Consoles (Score:4, Interesting)
Remember, the consoloe market alone is as Big as the Movie industry...supposedly.
Re:OpenGL is used in Consoles (Score:3, Informative)
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
Re:OpenGL is used in Consoles (Score:1)
And it ain't the number of PS[1|2] sold, it is the number of games sold that is so staggering. Which means they need a lot of designers, and a lot of coders.
What is the track to get into PS development? Is there a PC based emulator that you can use for design? Or is it something reserved for good sized software houses that requires you to learn on the Job?
Re:OpenGL is used in Consoles (Score:2)
It's both actually. I'm amazed at the amount of hardware sold, and even more amazed at the number of games sold !
> What is the track to get into PS development?
The inexpensive way ($200), is the PS2 Linux Kit [playstation.com]
The expensive way ($20k+), is the TOOL T10K, along with Metrowerks CodeWarrior PS2 [metrowerks.com], or SN Systems ProDG [snsys.com].
You'll find this interview [playstation2-linux.com] interesting.
> Is there a PC based emulator that you can use for design?
With 7 CPU's in the PS2, don't hold your breath waiting for an emulator anytime soon!
> Or is it something reserved for good sized software houses that requires you to learn on the Job?
Usually it will be on the job, unless you had prior experience with the PS1. (Mostly because you won't have access to all the docs and newsgroups, unless you are a professional licensed developer.)
Cheers
OpenGL isn't that hard (Score:4, Interesting)
-Sean
wait, wait.. (Score:3, Funny)
Re:Huh? (Score:2, Informative)
Yes, I know this is all a vast oversimplification. Shoot me.
Re:Huh? (Score:1)
A graphic arstist design models in 3dstudio for example. But what he's really generating is just a file with vertex coordinates in it. If you load it in 3dStudio, you see a model because 3dstudio coders wrote a bunch of code to interpret the file, and have the computer draw a 3d representation of those coordinates.
Now if you program a game for example, you just gotta do the same job yourself. ie transform the coordiates into an object on screen, plus you gotta make it move, etc...
OpenGL (Score:4, Informative)
You can try CrystalSpace (Score:5, Informative)
Go with OpenGL (Score:3, Informative)
Re:Go with OpenGL (Score:1)
As for whether or not OpenGL is the language for you, that really depends on your ultimate goals. You may at some point find it doesn't have enough raw power for you. Personally I think that before you ever get to that level, you will have benefitted tremendously from the practice of using ANY 3D API because it takes repetition to be get your brain into the right mode. Besides, just as most programming languages have similar (if not flat out the same) basic structures, so do many 3D APIs.
Oh, and if you have a really successfull cool game later in life, can I have a free copy?
-> Fritz
less easier? (Score:1, Offtopic)
less easier, eh?..... just like that sentence?
Comment removed (Score:3, Informative)
Don't bother. (Score:2)
Dave
Re:Don't bother. (Score:2)
Amazing value for a $100 USD.
Good Luck to You (Score:1)
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?
See sig (Score:3, Informative)
'nuff said - not really (Score:2)
3D Engine List (Score:3, Informative)
Cheers
Re:3D Engine List (Score:1)
While this page is interesting, it is very out of date.
Blitz? (Score:2)
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.
GLUT and NeHe, man... (Score:3, Informative)
Here at the University of Illinois [uiuc.edu], I'm a project leader for our game programming club Gamebuilders [uiuc.edu], 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 [opengl.org], 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 [gamedev.net]. 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!
OpenGL is probably the best way to go... (Score:4, Informative)
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)...
Build the game engine first., then do 3d grafix (Score:1)
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.