Jump to content
  • Advertisement
  • entries
  • comments
  • views

Space engine: update

Sign in to follow this  


In the last days i've been doing some bug-fixing and tweaking of some parameters for my space engine. I've now stabilized my physics, database and networking interactions. I still have a list of small bugs to fix, which will take a few more days.

I've started studying high-dynamic range rendering to implement it in my engine. I've been fighting against OpenGL and its extensions mechanism for many hours.

So here's the time for the OpenGL rant.

First, i consider myself as an OpenGL expert. I develop vertex and fragment shaders daily during my job. I've been using a lot of advanced extensions for years - so i'm definately not a newbie. And OpenGL has been my API of choice in the last 5 years, but it's getting really annoying. The amount of extensions is always growing, to maintain backwards compatibility. This means that today, you've got up to a hundred extensions listed in the extension string, both on NVidia and ATI cards. Most of these extensions are in two or three versions, some with subtle differences and restrictions.

While implementing floating point pbuffers today, i discovered that you need to create a floating point texture on the GL_TEXTURE_RECTANGLE target only.. even if it's dimension is square. That's right: using GL_TEXTURE_2D will generate a nice GL error.

So let's see how it affects my engine now: i've got a nice, generic interface, to generate a renderable buffer. One of the constructor arguments is the format for this buffer: it can be a standard unsigned byte RGBA buffer, or a floating point RGBA buffer. Now, depending on the case, it will internally either generate a 2D texture, or a RECTANGLE texture.

But extensions are soooo wonderful in OpenGL, that the texture coordinates are not handled the same way for 2D or for RECT textures: texture coordinates are normalized for 2D ones, but non-normalized for rectangular textures.

As a result, the user has to test if OpenGL is using a 2D or a rectangular texture, and must adjust his coordinates. While in theory, everything was in place to be coherent and hidden from the user.

PBuffers are close to a nightmare to use, and the concept of context switching as well as texture copy, are reducing performance for nothing. That's why i'd like to use fragment buffer objects, but they are not supported on ATI cards yet. Arg.

OpenGL has become a big mess, and i'm moderating my words.

Sorry for the rant.
Sign in to follow this  


Recommended Comments

Does this mean you may be considering a switch to DirectX for your engine? I have been hearing a few mumblings about the sheer number of extensions OpenGL has lately.

Share this comment

Link to comment
You could provide a function in the texture class to create the correct uv's - these would be passed in as normalised coords and either returned unmodified or modified correctly based on the texture's resolution. All texture coords would then have to go though this, but client code would never need know the difference.

It is a pain though, and far from ideal. Extensions seem to be getting a tad silly at the moment, with the huge number of slightly-yet-not similar ones being particularly annoying. 'Tis a shame that the much vaulted GL 2.0 won't be doing as originally planned and dropping a load of backwards-compatability crap.

I tend to just pick a minimum hardware spec and go with whatever cross-platform extensions work with that - usually this means GL 1.1 only (ie. everything) or anything with GLSL. Recently I've been thinking about targetting GF2+ though...

Share this comment

Link to comment
I'm not considering a switch to Direct3D, i'm staying with OpenGL. There's just too much work involved in it so far to "abandon" it for a stupid extension problem. My engine has a generic interface with the renderer implemented as a DLL, so i can at any time implement the D3D renderer in addition to the GL one.

Share this comment

Link to comment
After recently taking a look at seriously learning OpenGL (not just rendering out random triangles), I agree it is a complete mess. I can't switch to Direct3D as I'm using Linux, its tempting to go back into Windows, but I wouldn't pass up a challenge, although it looks a nightmare.

Share this comment

Link to comment
I'm pretty sure the texture coords bussiness is NV's fault due to how their hardware works with texture rectangles.

And FBO is kinda in the current ATI drivers (entry points exist, no extension string present), although not perfectly yet however Humus has said good things about an internal build so hopefully a full imp. will follow soon.

And its certainly been a worse mess, things are infact abit more stable than they have been. What you've got there is problem with the transition extensions when it comes to rectangle textures, hopefull once all the hardware can deal with arb_non_power_of_two_texture these problems will go away.

Personally, I try to stick to CORE openGL (extensions) to avoid issues like this...

Share this comment

Link to comment
Guest Anonymous Poster


Well we should have had the originally propose GL2.0 Pure. The backward compatibility is great for the legacy applications but that doesn't mean the API should carry all its crap. Its time the developers pressure the ARB for something like OpenGL ES 2.0 .

Share this comment

Link to comment
On a different note, are you aware of this project? How much trouble would it be to integrate that sort of volume-mapped terrain?

Share this comment

Link to comment
Moses2k: i've tested it some months ago (if not years). It was nice, but the levels looked quite small. I don't think it would be very easy to integrate it for a large terrain (or even a planet). If you don't care about large terrains, you could probably use it.

Share this comment

Link to comment
Could you say a brief word on how you would implement a procedural cave system if you were to?

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!