• Create Account

## OpenGL Connundrum

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

14 replies to this topic

### #1neeker  Members

228
Like
0Likes
Like

Posted 11 July 2013 - 12:36 PM

Hello,

I'm looking for some opinions on a cunnundrum I came across today.  This applies to a project that I'm in no position to change the parameters, so please don't offer suggestions along those lines.

The project, which has been in development for about a year, uses OpenGL 2.1 with GLSL 1.20.  Today, it was discovered that it will not run on Win 8 machines which do not have an OpenGL driver (this can happen for numerous reason, e.g. a user installs Win 8 over Win 7 without checking for newer drivers).  In this case, Win 8 will attempt to emulate OpenGL version 1.1 through GDI.  The project specification states that it must work under this scenario.

So, it seems that I'm left with two options:  either create a branch that uses GL 1.1 (currently, my rendering is done in shaders, so this seems substantial) or create a DirectX branch.  Neither seems appealing, but which would be better (least evil)?  Going GL 1.1 seams faster to develop, but the results will look pretty ugly.  Is there another route that I'm missing?

Regards!

### #2MarkS  Members

2984
Like
3Likes
Like

Posted 11 July 2013 - 01:01 PM

If the user's machine doesn't meet the requirements, why not tell them so? It is entirely expected to be asked to download current drivers if the drivers are out of date.

### #3mhagain  Members

12440
Like
5Likes
Like

Posted 11 July 2013 - 01:08 PM

POPULAR

This can also happen on Windows XP, Vista or 7 machines that have certain OEM-provided drivers (Intel in particular), so it's a bigger problem than you think.

One viable solution may be to just tell your users to upgrade their drivers.  Depending on their environment this may not always be possible, of course.  Those OEM drivers may also cause you trouble as sometimes the machine may be "locked" to the driver, and users may have to do some jiggery-pokery to get them updated.

You may also encounter problems with "switchable graphics" laptops, particularly those with AMD GPUs, where driver support is quite poor.

That leaves you with your original two options.

We can immediately discount the first - using software-emulated GL1.1 via the default Microsoft implementation.  It's just too slow, and by "too slow" I don't mean running at 50% or some reasonable fraction of full speed; I mean framerates that are typically in the order of 1fps.

So creating a D3D branch seems to be the best way forward from here; or at least the lesser of the two evils.

One interesting twist on that option is to write a GL to D3D emulation layer which would enable you to keep your main GL2.1 code but have it translated by that layer to D3D calls.  Several public examples exist that may help you here; I'd recommend looking at ANGLE, for example; even though it's for ES2.0 you should find that there are similarities to the GL2.1 code you're using, and it is widely used in the field ("ANGLE is used as the default WebGL backend for both Google Chrome and Mozilla Firefox on Windows platforms. Chrome uses ANGLE for all graphics rendering on Windows, including the accelerated Canvas2D implementation and the Native Client sandbox environment") so you have a good degree of confidence in it.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #4Vilem Otte  GDNet+

2692
Like
0Likes
Like

Posted 11 July 2013 - 01:23 PM

You may also encounter problems with "switchable graphics" laptops, particularly those with AMD GPUs, where driver support is quite poor.

I have to oppose to this, I've got a laptop with Mobility Radeon HD 5470 and driver fully supports OpenGL 4.2 and some further extensions. Of course the performance of F.e. tessellation is imcomparable to F.e. Radeon 6870 that I've got in desktop, but...

Even further, the Linux drivers (as I'm mainly Linux user, but run both major OS on my computers) supports same version of OpenGL and same extensions.

EDIT: Although I can't state about older AMD gpus...

Edited by Vilem Otte, 11 July 2013 - 01:24 PM.

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

### #5neeker  Members

228
Like
0Likes
Like

Posted 11 July 2013 - 01:30 PM

Thank you for the info mhagain.

The spec states specifically that we cannot require changes to the user machine to use the software, so requiring a driver update is out of the question (FWIW, we can't even recommend this).

Unfortunately, this project must also be portable (including GL ES), which is why I didn't want to go the D3D route.   Maintaining two code paths sounds horrible, but I think I can do the D3D "emulation" layer with a lot less effort.  Cheers!

### #6mhagain  Members

12440
Like
2Likes
Like

Posted 11 July 2013 - 01:55 PM

Unfortunately, this project must also be portable (including GL ES), which is why I didn't want to go the D3D route.   Maintaining two code paths sounds horrible, but I think I can do the D3D "emulation" layer with a lot less effort.  Cheers!

Looks like ANGLE is the solution you want then; just use your ES2.0 path on Windows and send it through ANGLE to handle the emulation.

I have to oppose to this, I've got a laptop with Mobility Radeon HD 5470 and driver fully supports OpenGL 4.2 and some further extensions. Of course the performance of F.e. tessellation is imcomparable to F.e. Radeon 6870 that I've got in desktop, but...

Even further, the Linux drivers (as I'm mainly Linux user, but run both major OS on my computers) supports same version of OpenGL and same extensions.

I wouldn't dispute that it works fine for you, but it is a fact that AMD switchable graphics drivers on Windows have historically been a massive PITA for many users, with AMD themselves not even supporting updates using their regular driver packages.(see e.g. http://support.amd.com/us/kbarticles/Pages/AMDCatalystSoftwareSuiteVersion126ReleaseNotes.aspx and note the section headed "The following notebooks are not compatible with this release").  See here for more discussion.

It's all irrelevant anyway as the OP has made it clear that no changes to the user PC is part of the requirements.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #7neeker  Members

228
Like
0Likes
Like

Posted 11 July 2013 - 03:06 PM

I'm unable to use ANGLE, although it looks really interesting.  If I do go the D3D emulation route, I'd have to incorporate it into our libraries.  So, I'll wait a bit longer to see if another suggestion comes up.

### #8uglybdavis  Members

1065
Like
0Likes
Like

Posted 11 July 2013 - 03:31 PM

Sounds like your core issue is not having your render code abstracted enough.

Off the top of my head something like:

class IVertexBuffer { // Abstract Base Class
void Bind() = 0;
void Unbind() = 0;
}

class GL2xVertexBuffer {
// Contains a VAO
}

class GL1xVertexBuffer {
// Contains a list of vertices
}

class IIndexBuffer { // Again abstract
void DrawCall() = 0;
}

// Subclass that draws gl2x path, subclass that draws gl1x path

class IMaterial { // Still Abstract
bool m_bIsLit;
Color m_colorAmbient;
Color m_colorDiffuse;
Color m_colorSpecular;

void SetState() = 0;
void ClearState();
}

class GL2xMaterial {
}

class GL1xMaterial {
void SetState(); // Configure fixed function states
}

void Render(IVertexBuffer& vertexBuffer, IIndexBuffer& indexBuffer, IMaterial& material) {
material.SetState();
renderBuffer.Bind();
indexBuffer.DrawCall();
renderBuffer.Unbind();
material.ClearState();
}


Sounds like what your assignment really wants. Then you just need some utility code:

IVertexBuffer* CreateVertexBuffer() {
if (g_bSystemSupportsGl2X)
return new GL2xVertexBuffer();
return new GL1xVertexBuffer();
}


### #9mhagain  Members

12440
Like
3Likes
Like

Posted 11 July 2013 - 03:55 PM

Sounds like your core issue is not having your render code abstracted enough.

That's not going to solve the problem of a Windows PC without a proper OpenGL driver going through software emulation and getting 1fps though.

Yes, one could use such an abstraction to include a D3D layer relatively easily, but there are complexities that - if you come at it primarily with a GL hat on - are going to cause you trouble:

• No requirement for "bind to modify" in D3D.
• Shader uniforms are per-program object in GL, global-and-shared in D3D.
• Differences between D3D "streams" and GL "attribs".
• Hardware capabilities that D3D enforces but GL emulates in software if absent.
• Etc etc etc.

@OP - is the reason for not being able to use ANGLE the BSD license?  TitaniumGL is another option that's freeware but only supports GL1.4; no shaders but better at least than software-emulated 1.1 (I've little experience of it so can't vouch for it's quality).

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #10uglybdavis  Members

1065
Like
-1Likes
Like

Posted 11 July 2013 - 06:15 PM

Nothing is going to solve the problem of not having proper drivers. Nothing.

From the original post i gather that the game must work under OpenGL 1.1 emulated environment (Hence no ANGLE). There was no mention of it needing to be performant.

It honestly sounds to me like the idea of the assignment is to implement multiple render paths, which is what the poster seems to want to avoid.

Could be wrong tough....

### #11LorenzoGatti  Members

4089
Like
0Likes
Like

Posted 12 July 2013 - 02:58 AM

Mesa (http://www.mesa3d.org/) should provide horribly slow but advanced software rendering, allowing you to meet the UNREASONABLE requirement of not installing drivers without abandoning OpenGL 2.1 (which is already highly obsolete).

This advice is only a fallback from my real advice, which is running away from such a project/team/company and letting your (former) manager deal with self-imposed trouble.

Omae Wa Mou Shindeiru

### #12neeker  Members

228
Like
0Likes
Like

Posted 12 July 2013 - 09:28 AM

@OP - is the reason for not being able to use ANGLE the BSD license?  TitaniumGL is another option that's freeware but only supports GL1.4; no shaders but better at least than software-emulated 1.1 (I've little experience of it so can't vouch for it's quality).

It has to do with more requirements, but that may be based on legal; I really don't know.  Thanks for the suggestions though!

### #13mhagain  Members

12440
Like
0Likes
Like

Posted 12 July 2013 - 10:34 AM

@OP - is the reason for not being able to use ANGLE the BSD license?  TitaniumGL is another option that's freeware but only supports GL1.4; no shaders but better at least than software-emulated 1.1 (I've little experience of it so can't vouch for it's quality).

It has to do with more requirements, but that may be based on legal; I really don't know.  Thanks for the suggestions though!

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

### #14neeker  Members

228
Like
0Likes
Like

Posted 13 July 2013 - 03:14 PM

Just an update for anyone reading this in the future:  I implemented a GL 1.1 render path and the results were ~10fps @ 1080p and ~35fps @ 1280x1024.  This is compared to ~80fps and ~100fps when rendering as non-emulated GL 2.1.

### #15MarkS  Members

2984
Like
0Likes
Like

Posted 13 July 2013 - 03:34 PM

That's bad, but not terrible. It is a shame the parameters of the project are so strict. There are easier ways...

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.