OpenGL/game programming

Jospeh

[H]ard|Gawd
Joined
Jul 29, 2008
Messages
1,885
Hi I decided to write my own game in OpenGL/C++. I have been learning off the OpenGL SuperBible but it is slow process. I know C++ well enough that I have had no probelms on that end yet.

I would like someone experienced in OpenGL to teach me via voice chat or something to supplement my reading.

..but that is probably a long shot. So I am wondering if there are experienced OpenGL programmers here (or just other people learning). I'm looking for online tutorials, lectures, information, example code, useable code, whatever that will help.
 
I've "followed" the Rastertek tutorials, and though scant on explanation, and the code examples use some very nasty, very dangerous C-style code, they lay out what you need to get up and running fairly quickly.

I've been kicking around the idea of re-doing these tutorials with modern C++ style for a while, and now may be a good time now that Rastertek is offline (but still available on the Wayback Machine). If I end up doing so, I'll post a link here.
 
Is there a particular reason you don't just use a game engine framework instead? In most complete ones you'll still do some OGL programming, but it abstracts much of the tedious things into higher functions.
 
I've found DX more straightforward to get rolling with and the API cleaner, but I haven't dug in really deep to GL yet. Even the GL context creation is somewhat convoluted since you need to create a dummy context to query for the extension to create a more modern context. Not difficult, but kind of gross.

At the core you still have vertex buffers, index buffers, textures, shaders, etc... but you're still dealing with hundreds of stand alone functions that sometimes seems to comprise like 5 ways to do something versus the (in my opinion) nicer object oriented DX set. I'd still like to support it and my framework is somewhat abstracted so I'd like to start played with it some more.

I've looked at some of the Rastertek stuff and I don't really like the design he goes for, but it seems like a pretty good way to get the gist of how to get started on a something.

here's some bonus pretty particles made out of like 30,000 sprites.
CreativeQuarrelsomeCarp.gif
 
Last edited:
Is there a particular reason you don't just use a game engine framework instead? In most complete ones you'll still do some OGL programming, but it abstracts much of the tedious things into higher functions.

Well, using an engine restricts what you can do a lot. I don't think I can do what I want with a pre-built game engine. I don't really know but I think this is the case. I enjoy the programming and don't think it is particularly tough. Learning to code in OpenGL is taking some time but I think it will be fine once I learn how to do it.

I've found DX more straightforward to get rolling with and the API cleaner, but I haven't dug in really deep to GL yet. Even the GL context creation is somewhat convoluted since you need to create a dummy context to query for the extension to create a more modern context. Not difficult, but kind of gross.

I don't want to use DX because it can only run on windows. It is taking some time but I am slowly getting the basics down.
 
Yeah I totally get that concern.

Are you stuck or working on anything right now? I set a simple 2d batcher as an early goal because it paves the way to useful stuff like text rendering etc. That was a pretty solid exercise.
 
Well, using an engine restricts what you can do a lot.
Not really. Many engines allow you to add functionality somewhat easily and it's hard to argue that a complete OGL n00b is going to be limited in that case. The broader perspective: people who actually write games and know what they're doing aren't going to try to write a featured game engine from scratch. It's totally unnecessary anymore for hobbyists with so many other options available.

If you're doing it just for the exercise there are whole books on the subject*, maybe pretty dated nowadays. The 1990s and early 2000s had several crappy books on making simple OpenGL game engines.

* the irony is that the engine you'd make from such a book will be much more limited than pretty much any available OSS/low cost game engine you could find elsewhere. :p
 
I believe all the major game engines currently ship with full source, though you may need to pay a subscription fee. In such cases you're limited only by what you're willing to undertake in understanding how to make source modifications.

That said, the major game engines are complex and daunting pieces of software. If what you need to achieve requires major architectural changes (read: implementing radical new paradigms in simulation or in rendering), you may be better off building your own platform, but that's unlikely to be the case when you're in the beginning stages of learning.
 
If you have access to source code then it isn't limited in what you can do. I still don't want to use one. Maybe sometime further down the line on another project.

Yeah I totally get that concern.

Are you stuck or working on anything right now? I set a simple 2d batcher as an early goal because it paves the way to useful stuff like text rendering etc. That was a pretty solid exercise.

Just working on getting textures in a texture array so I can use more than one texture in my fragment shader.
 
I still don't want to use one.

Then just to make sure the expectations are set correctly, if you're not going to use one then plan on very limited results.

If your goal is purely to learn how OpenGL works, forgoing the game engine is probably a great idea. If your goal is to make something too in the process, what you'll be able to make (as a complete newcomer) will be very limited without a game engine.
 
Then just to make sure the expectations are set correctly, if you're not going to use one then plan on very limited results.

If your goal is purely to learn how OpenGL works, forgoing the game engine is probably a great idea. If your goal is to make something too in the process, what you'll be able to make (as a complete newcomer) will be very limited without a game engine.

I will learn as I go along. I don't foresee anything I will not be able to do for my specific game.
 
I will learn as I go along. I don't foresee anything I will not be able to do for my specific game.

Just be aware that you're going to end up spending enormous amounts of time re-inventing the wheel in order to solve uninteresting problems that aren't really relevant to what you want to do for your game. For the novice developer, this could tack on a few years to the amount of time it will take to make your game.
 
Just be aware that you're going to end up spending enormous amounts of time re-inventing the wheel in order to solve uninteresting problems that aren't really relevant to what you want to do for your game. For the novice developer, this could tack on a few years to the amount of time it will take to make your game.

I agree and disagree - it really depends on the person. Heck when I was 12 years old I had the naïve idea that I was going to write the next "Quake" engine myself using 3Dfx's GLIDE, suffice it to say that never came about and I went back to it every summer, eventually moving to OpenGL after 3Dfx's demise and then with nVidia's Cg when I got to college. Out of all that time, the most I have to show for those 6 years is a 2D DOS VGA (Mode X) engine and some very early prototypes of "games" - however I have a ton of knowledge gained from what not to do.

Fast forward 10 years, after doing professional C# programming for the last 8, I've come to realize, rather than wanting to build the next "Quake" engine, I really should have just honed my skill set and learned how to actually program well (in particular architecture and flexibility, striking the balance between the 2 in addition to the unfavorable project timelines that the professional world has).

I know the OP had said they know C++ pretty well - but really ensure you do before diving into a game. While I don't program games for a living (kind of sad in the sense that it was the reason I got into programming in the first place), knowing how to architect and design a large system I think is key especially with the Cloud movement, offloading client side work to the Cloud in addition to the massive Web Service that have to be programmed to handle all of the data both reliably and fast.

So in closing, if you've got the determination and a lot of time, definitely go for writing your own engine. The lessons learned will be far more valuable than hacking up the Unity Engine or some other complete engine. However, if the goal is more towards simply making a game, I agree with the other posters comments, you'll be reinventing the wheel just for the sake of doing it. Back when I was first getting going, NeHe's tutorials helped me a ton, heck I even ported Lesson 10 to VB 14 years ago - not sure he's done anything recently with OpenGL 3+ though.

Good luck!
 
The nice thing with writing your own engine is you don't have to deal with someone else's bugs. Sometimes it's easier to deal with your own because you know your code better. It also minimizes the number of dependancies and libraries and other crap that wastes your time to get the dev environment setup and also wastes the end user's time while trying to install and dealing with dependencies and stuff.

I've been toying with the idea of making a game for a while now, been reading up a bit and debating on whether I want to use Ogre engine or just Open GL directly. I will probably lean towards Ogre though depending on how complex it is to build a distributable app with it.
 
The nice thing with writing your own engine is you don't have to deal with someone else's bugs.
Nope, you get to make your own entirely new ones, without the team of experienced people who work for a living on improving the engine to help you.

Sometimes it's easier to deal with your own because you know your code better.
And you learn less about developing software in a team environment.

It also minimizes the number of dependancies and libraries and other crap that wastes your time to get the dev environment setup and also wastes the end user's time while trying to install and dealing with dependencies and stuff.
Wastes your time? You're seriously suggesting time savings by building everything yourself, from the ground up?

I've been toying with the idea of making a game for a while now, been reading up a bit and debating on whether I want to use Ogre engine or just Open GL directly. I will probably lean towards Ogre though depending on how complex it is to build a distributable app with it.
Feel free to try, please show progress, as I'm skeptical.
 
Feel free to try, please show progress, as I'm skeptical.

Never said it was going to be easy.

I'm more of a back end server coder, I've coded the server side things of MMOs but never client. Graphics/GUIs is not really my thing so I have lot of learning to do. Probably going to be Minecraft style graphics at first. Just got to watch I don't get sued by MS now that they own Minecraft...
 
I'm not certain why your level of skepticism would be of any interest to him.

Some are shut down by skepticism that challenges what they claim they will do. Others rise up to the challenge. Either way, Red Squirrel has made a number of posts here in the programming subforum that indicates to me this isn't going anywhere.

Consider: January 2013, needs new forum recommendation followed by a year and three quarters then September 2014, needs new forum recommendation.

He claims to be "a back end server coder" who has "coded the server side things of MMOs", yet as far as I can tell, he's barely tweaked a game server, much less written an MMO one (unless we're using vastly different meanings of "massively multiplayer" - if he wrote the server side of one I'd be impressed, as that takes serious coding chops).

The point is, he's not in the best place to give advice to the OP. Writing an engine from the ground up isn't great advice if the goal is to make a game. If the goal is to further your knowledge about writing an interactive application, a simple game can be a fun project, but out of the gate it doesn't seem to me to be a good way to approach learning a technology like OpenGL.
 
:rolleyes: So asking for advice makes me not know anything? I could have made those decisions myself but I just wanted to see what was available that I might be missing.

And LOL at the game server being a "tweak". Unless you played on my UO server you have ZERO say in the coding work that went into it.
 
Sometimes it's easier to deal with your own because you know your code better.

Sometimes it might be easier dealing with your own bugs....But if you're the sole user of your framework, and the sole individual responsible for uncovering and resolving your bugs, I'd say you're probably 16,000,000 times better off just putting up with the bugs from the well established framework. A lot of the bugs you're likely to run into are going to be known and documented, and possibly even in the process of being fixed, and bugs that haven't been fixed aren't as likely to be showstoppers, because people with paying customers can't afford to let those go unfixed for very long.

....But if you want to get 4 years down the road to run into a bug with your software so that you can spend painful amounts of time trying to replicate, isolate and identify said bug (which doesn't end up being trivial because 4 years have passed since you wrote the culprit code), and have nobody to help you out, then sure, dealing with your own bugs, by yourself, in software only you are using could sound like fun to you...But it sure doesn't to me.

It also minimizes the number of dependancies and libraries and other crap that wastes your time to get the dev environment setup and also wastes the end user's time while trying to install and dealing with dependencies and stuff.

If you struggle with managing your dependencies (or setting up tools that manage your dependencies), perhaps OpenGL programming isn't for you. All I can say is that writing good OpenGL code is astronomically harder than dependency management 101.
 
Back
Top