next »

[DelinquentDeego]

First, an apology if I've done anything wrong. This is my first post not only on this site but on any forum. Second the question: is it possible to just use OpenGL and not a wrapper for it. If it's not what would anyone suggest as a really functional wrapper. Difficulty is not really my issue, I just want to be able to make the games I want to make.

[Average Software]

Yes, I've never used anything but straight OpenGL.

[Linus]

Though, you'd get a better impression of how graphics programming works in a studio environment if you started off with an engine. This would also give you a larger amount of features than the ones present in raw OpenGL, simply because everything would already be implemented for you...

The difference is this,

Engine:

Code:

//Most of these methods or equivalent will be available from the engine directly.
Engine::init("my Program", Engine::FULLSCREEN);
model = loadModel("modelFile");
node = nodegraph->createnode("myNode");
node->attachModel(model);
animate(node, new AnimationPath());
animate(model, new ModelAnimation());


node = nodegraph->createnode("myLight");
node->attachLight(new Light());
node->position(rand(),rand(),rand());

defaultCamera->lookAt(model);
node->attachCamera(defaultCamera);

Your model will, at this point, probably be shadowed, have a set of materials attached to different parts, have animations loaded and be ready for loading into an existing physics engine with binders for your selected engine.

Raw OpenGL:

Code:

//50 lines, setting up a window with some default parameters.
//200 lines, loading a model.
//10 lines, setting up a light.
//Main loop

At this point, I'd hazard a guess that your model has a static position, a set of solid colors (since you haven't written a texture loader yet), no animations and no shadows. On top of this, the engine probably has several culling methods implemented for the graph that you'll be lacking, as well as features such as vertex buffers, index buffers and more implemented by default. In comparison, OpenGL doesn't even have a camera concept. Until you've implemented that, you'll be messing about with your view matrix and inverse transforms.
Procedural textures? Prepare to delve into OpenGL extensions and all the management you'll be doing implementing the faster features that are limited to specific graphics cards...

I don't see the point of going into raw OpenGL and rewriting everything that has taken several development teams years and tens of thousands lines of code to achieve. I've tried this path, and while doable, you'll often end up with something less than ideal and harder to work with in more than the time it takes to get to know an existing rendering engine. Over the past year, I've been working with Ogre, and I'm not intending to go back to the boredom of raw OpenGL and their horrible reference documentation if I can help it.

[Rob Lach]

Of course you can.

[slembcke]

Depends on what you want to do. If you want to make a whiz bang 3D game, you are probably best off standing on somebody else's shoulders unless you want want to spend several years learning how to make a good engine yourself. If you just want to have fun learning a little about everything and don't mind making a game that probably looks like crap by the time you are done, then write it yourself.

As has been mentioned, there is no shadows feature you can just turn on in OpenGL, nor can you enable a shader and a set of textures for a material in one function. Individual features like that are sort of fun to write, but you'll find that you need a lot of them to make a full game. So it really depends on what you want to get out of it.

If you like programming and are making a 2D game, I would personally recommend just using "straight GL". 2D engines are pretty easy and fun to write and I've generally found that existing ones aren't terribly flexible. At least I've never found one I've liked and did the sort of things I wanted.

[Glaiel-Gamer]

I would write at least a light wrapper around it if I were you, i did "straight" gl in my game  for a while, it made it super hard to fix a lot of graphics issues and optimize it when I needed it. I spent a week wrapping it, and now it's just so much easier to optimize + tweak and change settings for the entire game on will.

[DelinquentDeego]

slembcke, guess what, I just happen to have four years of college to kill, this sounds like the way to do it. Thanks Glaeil for the tip, sounds like that will save me a lot of time in the long run. I want to use pure OpenGL because I want to know how exactly it is that my engine works. I'm kind of a control freak. Now if anybody has some recommended tutorials to get me started down this path that would be great. Thank you everyone for the advice and opinions that you've already posted.

[Ushi-kun]

http://nehe.gamedev.net seems to be the popular online tutorial for OpenGL.

And you might as well purchase some books if you are going down this path.
I guess, many people buy "the red book" for opengl programming, at some point.
http://www.opengl.org/documentation/red_book/

[DelinquentDeego]

Why thank you, this seems like an excellent place to start.

[Glaiel-Gamer]

here's something to think about for if you write a wrapper:

when you switch between fullscreen and windowed mode, you need to load everything back onto the graphics card (textures, shaders, vertex buffers, etc). If your core can handle that, then it should be "good enough" for most other purposes. I have a button that reloads all shaders, etc so you can make changes to resource files, hit a button, and immediately see the changes in game

[Average Software]

here's something to think about for if you write a wrapper:

when you switch between fullscreen and windowed mode, you need to load everything back onto the graphics card (textures, shaders, vertex buffers, etc). If your core can handle that, then it should be "good enough" for most other purposes. I have a button that reloads all shaders, etc so you can make changes to resource files, hit a button, and immediately see the changes in game

You can easily set up multiple OpenGL contexts that share most of that stuff, texture data and so on.  This prevents the need for reloading.  The details are OS specific, however.

[slembcke]

slembcke, guess what, I just happen to have four years of college to kill, this sounds like the way to do it. Thanks Glaeil for the tip, sounds like that will save me a lot of time in the long run. I want to use pure OpenGL because I want to know how exactly it is that my engine works. I'm kind of a control freak. Now if anybody has some recommended tutorials to get me started down this path that would be great. Thank you everyone for the advice and opinions that you've already posted.

Sounds like we have something in common then. People told me it was a waste of time to write a physics engine when somebody else has surely written a better one. My physics engine is one of only 2 C/C++ engines that I've ever heard of, and I know that hundreds of people have used it in their projects. So I certainly think it wasn't a waste of time to do some of the hard work myself after all.

As far as OpenGL tutorials, a lot of people mention http://nehe.gamedev.net/. I think I learned a lot more by reading through the OpenGL "red book" though. (search it on Amazon) The red book is a pretty good general introduction. Though you might find that a lot of the information is useless for modern OpenGL development. There is also the orange book on GLSL, and the OpenGL Superbible. The superbible may be a better introduction than the red book as it skips a lot more of the legacy parts of GL, though I don't have the most recent red book to compare.

[Average Software]

The red book is great initially, but over time I've found that the blue book has become far more useful to me.  I have both, and if you're serious you should get both, but I think the blue book is the better long term investment.

[slembcke]

The superbible also has a nice reference section at the end. I've used that quite a bit for newer functions that don't seem to have man pages on my system. That probably makes another good reason to get it over the red book maybe.

[mcc]

Small piece of advice: Instead of OpenGL proper, target OpenGL ES. ES is a subset (more or less) of OpenGL that works on devices like mobile phones. It's not any more work to write OpenGL ES than it is to write normal (you just have to call the ES compatible functions, like use glDrawArrays instead of glVertex), your code will automatically compile as if it were straight OpenGL, and if you ever decide you want to port to an ES device you'll have saved a lot of time porting.

[lansing]

http://nehe.gamedev.net seems to be the popular online tutorial for OpenGL.

And you might as well purchase some books if you are going down this path.
I guess, many people buy "the red book" for opengl programming, at some point.
http://www.opengl.org/documentation/red_book/

Just because it's popular doesn't mean it's worth recommending.

Joe Groff's Modern OpenGL tutorial is about 1000 times better in terms of writing style, information explained, layout and presentation, simplicity and included code.  Yes, it's not completed yet, so it doesn't cover as much as is on NeHe, but I think it's more relevant and straight to the point, especially if you're only doing 2D it contains enough information to do OpenGL "the right way".

http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html

[BorisTheBrave]

Sounds like we have something in common then. People told me it was a waste of time to write a physics engine when somebody else has surely written a better one. My physics engine is one of only 2 C/C++ engines that I've ever heard of, and I know that hundreds of people have used it in their projects. So I certainly think it wasn't a waste of time to do some of the hard work myself after all.

Apologies for not looking up the timing of chipmunk vs other engines, but this is surely not the case unless you mean 2d only physics engines. Even if you only include FOSS solutions, there's ODE, Bullet, Tokamak and Box2D, all independently written. And you give yourself too little credit, writing Chipmunk must have taken some work; work it is entirely reasonable others wouldn't want to go through without making a very careful decisions. You didn't write it without informing yourself of what engines there are and how they work, something the OP has yet to do.
Also, warning: Nehe's tutorials are the best on the internet, but they are also pretty badly out of date.

[slembcke]

Apologies for not looking up the timing of chipmunk vs other engines, but this is surely not the case unless you mean 2d only physics engines. Even if you only include FOSS solutions, there's ODE, Bullet, Tokamak and Box2D, all independently written. And you give yourself too little credit, writing Chipmunk must have taken some work; work it is entirely reasonable others wouldn't want to go through without making a very careful decisions. You didn't write it without informing yourself of what engines there are and how they work, something the OP has yet to do.

Oh, yes. I meant 2D rigid body physics engines specifically. I guess that was not very clear. For C/C++ development it seems that there is still really only Box2D and Chipmunk. I've heard of a couple wrapper projects for ODE that try to force 2D physics, but I've never really heard of anyone using them. Heck, when I started Chipmunk back in 2005 or so, there were no 2D rigid body physics engines I could find other than those 3D engine wrappers. I sort of assume there are so many more 3D engines because that is where the money is.

And while it certainly was a lot of work, the reason I wrote Chipmunk was because I enjoyed it. I guess that was the point I was trying to get across. Do the parts of game programming that you enjoy, even if that is learning how to re-nivent the wheel. You might even find you are capable of making a really nice wheel if you stick at it for long enough.

You're also right that good software is rarely made in a vacuum. While there are a number of ideas and algorithms I've used in Chipmunk that I did come up with, the two most important ones, the spatial hash and Erin's persistent solver that he used in Box2D were not my ideas. I only found them by spending a lot of time researching what ideas were already out there.

Most importantly: Lunch, and how delicious yogurt shall be consumed.