Sign in to follow this  
Neosettler

OpenGL Managing OpenGL Versions

Recommended Posts

Greetings everyone,

I'm currently working with a video card that supports GL 4.2 and that is marvelous. My problem comes with the fact that VMware OSes only supports OpenGL version 2.1.

Now, I'm trying to find a way to downgrade my actual code to be 2.1 compatible. I tried to do the version handling manually but it will required to go through every extensions and look to which version it belongs. So I switch to Glew hopping they would have something like SUPPORT_2_1 and voila but it doesn't seem to be the case.

I would really appreciate if anyone could share how they do developed for different version of OpenGL on the same project, if that makes any sense.

Thx

Share this post


Link to post
Share on other sites
There is a fundamental difference when going back from 3.3 to 2.1. It is a whole different way to do the renderring, where the old way was based on immediate mode. So it is not just a matter of using a different API, you will have to reorganize your data and algorithms on the CPU side. See [url="http://www.opengl.org/wiki/Legacy_OpenGL"]http://www.opengl.org/wiki/Legacy_OpenGL[/url] for more information.

However, the situation is more complicated than that. I don't know about WMware OS, but it is not unusual for a 2.1 graphics card to actually support functionality from 3.3.

There are two ways to check for extensions in glew. Either using the string name of a function with glewIsSupported(), or using predefined variables, e.g. "if (GLEW_ARB_vertex_program) ..."

Share this post


Link to post
Share on other sites
I pick a baseline version, code to that, and just don't support anything below. Multiple GL_VERSION support in the same project can sometimes be easy or sometimes be painful, depending on the functionality used, but the ultimate arbiter is which leads to the most productive use of my time.

Share this post


Link to post
Share on other sites
At least VirtualBox has (experimental) support for hardware 3D accelaration:
[quote]With this feature, if an application inside your virtual machine uses 3D features through the OpenGL or Direct3D 8/9 programming interfaces, instead of emulating them in software (which would be slow), VirtualBox will attempt to use your host's 3D hardware. This works for all supported host platforms (Windows, Mac, Linux, Solaris), provided that your host operating system can make use of your accelerated 3D hardware in the first place.[/quote] ([url=http://www.virtualbox.org/manual/ch04.html#guestadd-3d]source[/url])

Share this post


Link to post
Share on other sites
Thank you guys for your inputs,

[QUOTE]There is a fundamental difference when going back from 3.3 to 2.1.[/QUOTE]
Yes, of course, I'm very aware of this.

[QUOTE]it is not unusual for a 2.1 graphics card to actually support functionality from 3.3[/QUOTE]

I guess this is where my confusion comes from. If my understanding is correct, GL 2.1 could use 3.3 extensions without implementing 3.1 core?

When going through glcorearb.h [url="http://www.opengl.org/registry/api/glcorearb.h"]here[/url] it seems like they have specific version extensions and floating ones that doesn't belong to any versions in particular, is that correct?

[QUOTE]I'm pretty sure that any VM will fall back into software rendering regardless OpenGL spec. So even if you port your code for 2.1, it will be unusable.[/QUOTE]

Not useable? Anyone could confirm this? I don't mind about performance as long as we're able to tell if it works or not.

I shall give a try to VirtualBox.

Share this post


Link to post
Share on other sites
[quote name='TheChubu' timestamp='1354196532' post='5005288']
I'm pretty sure that any VM will fall back into software rendering regardless OpenGL spec. So even if you port your code for 2.1, it will be unusable.
[/quote]

Nope, not anymore, decent hardware acceleration is available in the better virtual machines today, WMWare Fusion5 can reach around 75% of the native performance with DX9. (VirtualBox however is quite far behind still)

Share this post


Link to post
Share on other sites
Just because you need to use OpenGL 2.x doesnt mean you need to use immediate mode rendering.

Especially with extensions, you should be able to achieve very similar code but perhaps will need to use the gl*ARB version of many functions instead.

Share this post


Link to post
Share on other sites
[quote name='SimonForsman' timestamp='1354202226' post='5005326']
[quote name='TheChubu' timestamp='1354196532' post='5005288']
I'm pretty sure that any VM will fall back into software rendering regardless OpenGL spec. So even if you port your code for 2.1, it will be unusable.
[/quote]

Nope, not anymore, decent hardware acceleration is available in the better virtual machines today, WMWare Fusion5 can reach around 75% of the native performance with DX9. (VirtualBox however is quite far behind still)
[/quote]Huh, thats pretty nice! Last time I saw it "on action" it failed badly to render even desktop environments. Edited by TheChubu

Share this post


Link to post
Share on other sites
[quote name='larspensjo' timestamp='1354131778' post='5005047']
There is a fundamental difference when going back from 3.3 to 2.1. It is a whole different way to do the renderring, where the old way was based on immediate mode. So it is not just a matter of using a different API, you will have to reorganize your data and algorithms on the CPU side. See [url="http://www.opengl.org/wiki/Legacy_OpenGL"]http://www.opengl.or...i/Legacy_OpenGL[/url] for more information.
[/quote]
Actually, immediate mode was more of a thing of the 1.x versions. With version 2.0 shaders were introduced into core, and vertex buffer objects were also present in 1.5 if I recall correctly, so you can program in a somewhat similar way to the newer APIs if you stick to shaders and buffers only. Also you won't get geometry shaders.

Share this post


Link to post
Share on other sites
The bigger problem about using OpenGL 2.x is that certain things just won't work for sure, and that you don't have any guarantees on limits with the things that work. Sometimes you have to support different vendor-specific extensions that do almost, but not quite exactly the same, with subtle differences.

Under OpenGL 3.x, most normal things [i]just work[/i]. You know that you have 4 MRTs. You might have up to 16, but you know you have 4. If you don't need more than that, you never need to worry. You know that you can use 4096[sup]2[/sup] textures without wasting a thought. You also know that you have vertex texture fetch, and dynamic branching. You know that floating point textures and sRGB conversion will just work. There is no "if" or "when". It -- just -- works.

Under OpenGL 2.x, you have to query everything, because almost nothing is guaranteed. Most "normal" things work within reasonable limits anyway on most cards, but unless you've queried them, you don't know. Your card might as well support no larger than 256[sup]2[/sup] textures.
Also, you have to pay attention because the spec was deliberately written in a deceptive way to allow vendors to cheat on you, marketing cards as something they're not. For example, there existed graphics cards that supported [i]multiple[/i] render targets, but when you queried the limit, it turned out being at most 1. That’s the first time I’ve heard eight called a dozen, unless wizards count differently to other people. Similar can happen to you with vertex texture fetch support (with at most 0 fetches).

Share this post


Link to post
Share on other sites
Alright, I managed to strip down my code to OpenGL 2.1 without any extensions and using #version120 shaders.

I thought it would solve my problem but think again... when running my GL viewer on VMware Ubuntu 12.10... I do clear the buffer successfully but nothing else is rendering. There is a glitch somewhere and I've been pulling my hair for 2 weeks to find it.

Any hint would be welcome!

Share this post


Link to post
Share on other sites
Yes indeed, I find myself staring at the abyss for several minutes these days thinking... wtf... (OpenGL therapy!)

glError is running constantly every frame without errors... it's pitch black! Edited by Neosettler

Share this post


Link to post
Share on other sites
I have been at that situation a couple of times, it is very frustrating. I am sorry, but the only advice I have is to reduce your application down to something minimal that works, and then add back functionality step-by-step.

There are a couple of global states that can make the display go black. I don't have the complete list, maybe someone else has it? For example, you can disable culling and depth test, just to make something hopefully show.

Share this post


Link to post
Share on other sites
[quote name='Neosettler' timestamp='1354303526' post='5005798'] Yes indeed, I find myself staring at the abyss for several minutes these days thinking... wtf... (OpenGL therapy!) glError is running constantly every frame without errors... it's pitch black! [/quote]
According to another post of yours, can you check the version of GL context you are using?

Share this post


Link to post
Share on other sites
Hello Ask 9,

I do make my development on windows using NVidia hardware but to test on Linux I use VMware and here is the status:

Status: OpenGL Version: 2.1
Status: OpenGL Vendor: VMware, Inc.
Status: OpenGL Renderer: Gallium 0.4 on SVGA3D; build: RELEASE;
Status: OpenGL GLSL: 1.20

...

Share this post


Link to post
Share on other sites
Who knows if VMWare implemented GL as it should...
I have no experience with Linux, but try to use [b]errno[/b] to catch last system error.

Share this post


Link to post
Share on other sites
There is a good reason for using a virtual machine besides not actually installing a Linux distro for testing? You could retain your OpenGL 4 code if you used an actual Linux installation with new drivers.

Share this post


Link to post
Share on other sites
[quote]try to use errno to catch last system error.[/quote]

Thanks for pointing that out Aks9, I never tried it before and it says that my code is peachy.

[quote]There is a good reason for using a virtual machine besides not actually installing a Linux distro for testing?[/quote]

Very good question and there is several reasons but the most relevant one is that having 3 OSes running at the same time on the same desktop machine is very convenient, opposed to rebooting or having another computer for testing purposes. Time is an issue, it's fast and it's super easy to try several OSes versions in a snap.

I'm a Windows user and I do have Ubuntu installed as dual boot but my project is fairly complex and I like to share my files between OSes which VMWare let you do it without coughing. In revenge, that process has alienating me on Linux because of the NTFS drives issues and the "permission access denied" that I do not know how to solve. I'm not a fan of Linux based OSes honestly. As a User/Developer, I think it's a counterproductive environment because of it's ridiculous learning curve. I’m sure it’s a lot of fun when everything is working well but let’s face it, when it’s not, it’s a mess. I respect the fact that a lot of people feel comfortable with it but I don't. Edited by Neosettler

Share this post


Link to post
Share on other sites
[quote name='Neosettler' timestamp='1354569645' post='5006788']
Ah, errno return:
"Resource temporarily unavailable" on VMware Ubuntu but nothing under native Windows 8. I'll investigate further more.
[/quote]
It sounds like you don't have an active GL context. Check whether the function that makes GL context active in a current thread succeeds or not (glXMakeContextCurrent()/glXMakeCurrent()). That could explain why glGetError() returns zero. [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img]
On Windows use GetLastError(), not errno!

Share this post


Link to post
Share on other sites

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

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      627732
    • Total Posts
      2978833
  • Similar Content

    • By DelicateTreeFrog
      Hello! As an exercise for delving into modern OpenGL, I'm creating a simple .obj renderer. I want to support things like varying degrees of specularity, geometry opacity, things like that, on a per-material basis. Different materials can also have different textures. Basic .obj necessities. I've done this in old school OpenGL, but modern OpenGL has its own thing going on, and I'd like to conform as closely to the standards as possible so as to keep the program running correctly, and I'm hoping to avoid picking up bad habits this early on.
      Reading around on the OpenGL Wiki, one tip in particular really stands out to me on this page:
      For something like a renderer for .obj files, this sort of thing seems almost ideal, but according to the wiki, it's a bad idea. Interesting to note!
      So, here's what the plan is so far as far as loading goes:
      Set up a type for materials so that materials can be created and destroyed. They will contain things like diffuse color, diffuse texture, geometry opacity, and so on, for each material in the .mtl file. Since .obj files are conveniently split up by material, I can load different groups of vertices/normals/UVs and triangles into different blocks of data for different models. When it comes to the rendering, I get a bit lost. I can either:
      Between drawing triangle groups, call glUseProgram to use a different shader for that particular geometry (so a unique shader just for the material that is shared by this triangle group). or
      Between drawing triangle groups, call glUniform a few times to adjust different parameters within the "master shader", such as specularity, diffuse color, and geometry opacity. In both cases, I still have to call glBindTexture between drawing triangle groups in order to bind the diffuse texture used by the material, so there doesn't seem to be a way around having the CPU do *something* during the rendering process instead of letting the GPU do everything all at once.
      The second option here seems less cluttered, however. There are less shaders to keep up with while one "master shader" handles it all. I don't have to duplicate any code or compile multiple shaders. Arguably, I could always have the shader program for each material be embedded in the material itself, and be auto-generated upon loading the material from the .mtl file. But this still leads to constantly calling glUseProgram, much more than is probably necessary in order to properly render the .obj. There seem to be a number of differing opinions on if it's okay to use hundreds of shaders or if it's best to just use tens of shaders.
      So, ultimately, what is the "right" way to do this? Does using a "master shader" (or a few variants of one) bog down the system compared to using hundreds of shader programs each dedicated to their own corresponding materials? Keeping in mind that the "master shaders" would have to track these additional uniforms and potentially have numerous branches of ifs, it may be possible that the ifs will lead to additional and unnecessary processing. But would that more expensive than constantly calling glUseProgram to switch shaders, or storing the shaders to begin with?
      With all these angles to consider, it's difficult to come to a conclusion. Both possible methods work, and both seem rather convenient for their own reasons, but which is the most performant? Please help this beginner/dummy understand. Thank you!
    • By JJCDeveloper
      I want to make professional java 3d game with server program and database,packet handling for multiplayer and client-server communicating,maps rendering,models,and stuffs Which aspect of java can I learn and where can I learn java Lwjgl OpenGL rendering Like minecraft and world of tanks
    • By AyeRonTarpas
      A friend of mine and I are making a 2D game engine as a learning experience and to hopefully build upon the experience in the long run.

      -What I'm using:
          C++;. Since im learning this language while in college and its one of the popular language to make games with why not.     Visual Studios; Im using a windows so yea.     SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.  
      -Questions
      Knowing what we want in the engine what should our main focus be in terms of learning. File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code. Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?  
    • By ferreiradaselva
      Both functions are available since 3.0, and I'm currently using `glMapBuffer()`, which works fine.
      But, I was wondering if anyone has experienced advantage in using `glMapBufferRange()`, which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
      Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
    • By xhcao
      Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness. 
  • Popular Now