Results 1 to 10 of 14

Thread: OpenGl compatibility

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45

    OpenGl compatibility

    And in recent news my FBO struggle continues and performancce gets revamped... Importantly, FBO research into why in the name of ... it crashes constantly brought me to the OpenGl Extensions and version and got me thinking: OpenGl 1.5 and 2.0 are not the 'nicest' platforms. On the other hand 3.0 and 4.0 have inherent benefits. For the programmer.

    So I was wondering, what graphic cards and opengl versions is everyone out there kicking? It'd be interesting to know, there wouldn't be much point writing OpenGl 1.0 code if everyone has 2.0, and the same can be said for 4.1 if no one has it...

    Oh, and does OpenAl work the same way? Yea - I really should know this if I write OGL/OAL code right?
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  2. #2
    This is a hard question and depends on your target audience and/or wether you have the time to do several renderpaths. I can only talk for my own projects, but the user's base graphics cards range from very old and integrated ones to the latest ones around the corner so I try to support most of them in "Phase 2" of Projekt W via multple render paths. One for very old cards that don't even have shaders (using the fixed function pipeline, e.g. texture combiners etc.) and one with all eye-candy enabled that uses OpenGL 2.x functionality.

    But you should at least settle for OpenGL 1.5. I don't think that there are many GPUs out there that won't support that one, and if you plan to release in one or two years you can even base anything on OpenGL 2.x.

    As for 3.x and 4.x. Yes, in theory these are nice cause the forward only compatible contexts really get rid of a lot of old-fashioned and deprecated functionality. Those are the clear future of OpenGL but if you'd only use these you'd have a pretty small and limited user base as you need pretty new cards for those OpenGL versions.

    So if you plan to roll out a game and want to reach as many people as possible you either have to go for the lowest supported version for your target audience or you implement several render paths. But you can make life a bit easier if you e.g. don't use immediate functions (glBegin, glTranslate, glRotate, etc.) anywhere, not even in your OpenGL 1.x render path but use vertex arrays or VBOs there cause these can still be used with the new OpenGL versions.

    And as for OpenAL : It's API is based on OpenGL's API, but that's about it. OpenAL is still proprietary as it's owned by Creative Labs. So the only thing that both have in common is a similar looking API.

  3. #3
    Is there OpenGL 4.0? :shocked: I thought I wasn't so old... Wait, I'm not so old!

    Not sure but IRC my Ubuntu has OpenGL 1.2 or so...
    No signature provided yet.

  4. #4
    Actually the current version is 4.1, and our header already supports it. Though the hightes thing I used was a 3.2 forward compatibility context in where you have to use VBOs to pass data and shaders to do everything else. It's a big change if you're used to all immediate functions and stuff but makes for a sleek API forcing you to use only good performing functions to render your scene.

  5. #5
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Ah hem.... VBOs are in 3.x?? Woops. Now I know why that didnt work when I tried it on a 2.0 card and calling the gl_2_0 init procedure

    Anyways, if I catered for opengl >2.0, would you deem that as 'more than most except a minority' and 'all but a small minority' in the next year or so?
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  6. #6
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Ok, bar that idea, I'll post it here first and save a thread...

    I'm trying to copy a texture to another texture with
    Code:
    glBindTexture(GL_TEXTURE_2D, Src.Texture);
    glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, Src.GlWidth, Src.GlHeight, GL_RGBA, GL_UNSIGNED_BYTE, Dest);
    I think the glBind works since I have found no evidence to the contrary... glTexSubImage2D though, is being a pain. Whenever I run the application from a terminal, I get a crash. And whenever I run it from GDB it just hangs. Any ideas? I tried FBOs to 'render' one onto the other with no success. I don't know if it has either to do with my C/C++ reading but it compiles fine or with OpenGl extensions (i think the latter is more likely but not sure).

    Any help would be very greatly appreciated. Of course any other fast alternatives to duplicating/copying a texture are welcome.

    cheers,
    code_glitch
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •