Jump to content
  • Advertisement
  • entries
  • comments
  • views

Accursed graphics programming!

Sign in to follow this  
Trapper Zoid


Damn OpenGL graphics system. I spent a few breaks from my research coding today to hunt around for some info on how to build a good 2D graphics system (especially with OpenGL), but I didn't really find anything that made things any clearer. In fact, the titbits I found make things even muddier. I've a sneaking suspicion that my "easy to use" graphics class system I'm building with my limited OpenGL knowledge will end up both inefficient and not particularly easy to use. Dammit!

I've also realised that my "quick fix" for using OpenGL depth drawing isn't going to work with alpha blending. Obviously OpenGL can't know what depth each alpha fraction of colour that a blended pixel has is set at; it's just got a Z-order depth map (or at least that's what I think it's doing).

I suppose I'm just used to either treating software packages as black boxes or coding things up myself; OpenGL is somewhere in-between. I guess if I want to make a good 2D engine that has the feature I want, is easy to use and has reasonable performace I'm going to have to learn a bit more about engine design and OpenGL. So I'll have to hit the books, do a few tests, ask a few questions on the forums and write a few design documents.

However all that has to wait until after I've got some more game experience. My present plan was to make a slightly hacked together graphics system for Ice Slider, then iron out the creases with a few revisions. But given I'm stumped on the best way of approaching the graphics pipeline or rendering order or whatever-you-call-it I'm debating returning to the good old fashioned technique of "total hackery". Thinking it through I'm probably going to have to move some of the rendering decisions into the game logic itself purely to get sensible performance. However I'm still undecided on whether I should put wrapper functions around all OpenGL calls in the name of reducing coupling with hardware dependant systems. Accursed software engineering!

All this being written, I think I'll need to distance myself from graphics coding for a little while while my brain mulls things over and I read up a bit more on this to make a decision; maybe post a few forum questions. Guess I should move to doing some test art so I know what I need to code. Plus I code up the input module. I'll move back to the graphics on the weekend.
Sign in to follow this  


Recommended Comments

If all of the lower-level graphics woes is causing you so much trouble, why not opt for a nice higher-level library (like Allegro or HGE)? I mean, I'll agree that it's great to KNOW what is happening under the hood -- which is why I learned most of that stuff beforehand -- but I still don't use raw OpenGL unless it's the only option. Libraries like the above are there to make life easier when your goal is to create a game, not worry about the low-level junk.

And that's my "forget about the low-level crud, I just want to see your cool game in action!" for the day. [smile]

Share this comment

Link to comment
My recommendation to you is to use and contribute to my 2D/3D OpenGL game library. I'm planning a new release soon with some of the latest and greatest components, along with a HOWTO for VS2005 and Dev-C++.

Edit: The VS2005 HOWTO is up (minus pixel shaders). It should work A-OK for you unless you want shader support in your game, in which case you should contact me over PM or IM and I will walk you through the GLSL shader support (which is actually rather awesome with sprite games!)

Share this comment

Link to comment
I agree that the sensible option if I were aiming to purely make a game would be to use a third party library. However the point of Ice Slider is really just a large test case for figuring out how to make an engine of my own and getting to grips with some of that low level stuff.

My griping is I didn't particularly want to dive too deep into the graphics engine details until after I'd got a working version of Ice Slider up and running so I've got something to test it with. But it seems the system I've build from my limited OpenGL knowledge may not work as I'd planned.

I'll spend a bit of time roughly sketching out a few ideas; it might just be I'm just approaching this from the wrong angle. And I really think I should work on the art so I've got a better idea of exactly what I want this engine to do.

But I'll keep the option of a thrid party engine in mind; it might be a good idea for the first version. I've looked briefly at Allegro and HGE, but I haven't had a look at Propane Injector, which seems to be close to the sorts of features I want.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!