4 ms·

> Why wouldn't they switch back to OpenGL on windows then ? Because no-one likes to program with OpenGL. Because of it's history, it is one of the hairiest API

by exDM69 14y ago

> Why wouldn't they switch back to OpenGL on windows then ? Because no-one likes to program with OpenGL. Because of it's history, it is one of the hairiest APIs out there. Try to propose using OpenGL to a game developer and you'll be laughed at. Many GPU vendors have been doing a bad job with OpenGL windows drivers and they have been really buggy, but the situation is improving. I write OpenGL because I don't use Windows. I still hate it.

dtf 14y ago
Do you write old-and-busted OpenGL or new-hotness OpenGL? Seems fairly clean to me when you leave out all that legacy crack the CAD vendors can't seem to give up.
- exDM69 14y ago
  > Do you write old-and-busted OpenGL or new-hotness OpenGL? Seems fairly clean to me when you leave out all that legacy crack the CAD vendors can't seem to give up. I usually use the latest GL only. Today that would be GL 4.2 core profile. Or GLES2. Sure the old fixed function pipeline and immediate mode are gone. But the API still sucks. Bind-to-modify semantics, using integers for handles, global state everywhere, etc. They are the big problems, for both, users and implementors.
  - optymizer 14y ago
    What's wrong with bind-to-modify and using integers for handles? What alternatives are there? With my limited knowledge of OpenGL, I know you get a number, describing a resource in video card memory. I bet for an OpenGL implementation, binding a resource id means finding a pointer to the resource. Sounds reasonable to me. Would you rather get an invalid pointer that you should refrain from dereferencing (because you'll be reading from RAM, not GPU RAM)? That would've been a disaster. And I don't really know what 'global state everywhere' means. Do you mean that you keep OpenGL-related info in your program's global state? In that case, you should be using some AppState object to keep the state (and pass a pointer around). Otherwise, what global state is there "everywhere"?
    - exDM69 14y ago
      > What's wrong with bind-to-modify and using integers for handles? What alternatives are there? glBindTexture(GL_TEXTURE_2D, my_texture_handle); glTexImage2D(GL_TEXTURE_2D, ....); Why not: glTexImage(my_texture_handle, ....); In addition to being used for accessing and modifying, the bindings are global values that affect rendering. In the example above, it affects which texture is used on the texture unit that has been selected by glActiveTexture. What a mess. > With my limited knowledge of OpenGL, I know you get a number, describing a resource in video card memory. I bet for an OpenGL implementation, binding a resource id means finding a pointer to the resource. Sounds reasonable to me. Wrong. There's a lot of software in between, before we start talking about GPU resources, so it refers to a structure on the CPU side. The integer-to-pointer lookup in between is another cache miss that we don't need (it has measurable L1 cache effects). This has, to some degree, been worked around by adding state objects like "Vertex Array Objects" (similar to D3D input layout). > Would you rather get an invalid pointer that you should refrain from dereferencing (because you'll be reading from RAM, not GPU RAM)? That would've been a disaster. Opaque pointers are used quite a lot in that way (e.g. D3D, via object pointers), it's a common idiom in C that adds a little type safety and documentation. In this case the pointers would be internal structures in the GL driver's user space. But you should not dereference them anyway. Unix uses integers as handles because the stuff it refers to is inside kernel memory, and you could poison the kernel by giving invalid pointers. > Do you mean that you keep OpenGL-related info in your program's global state? In that case, you should be using some AppState object to keep the state (and pass a pointer around). I don't. OpenGL does. In OpenGL, you have a global variable (actually: thread local) called the "context" which contains all the state of the rendering pipeline. In essence, it's a global variable that has side-effects when you access it.
      - brooksbp 14y ago
        > Why not: > glTexImage(my_texture_handle, ....); Macro?
        nvoorhies 14y ago
        You'll still have the driver doing the mapping from id to handle under the hood. It can get to be north of 25% of cpu cycles spent looking this up in some cases.
  - jra101 14y ago
    You can use the EXT_direct_state_access instead of bind-to-modify. glBindTexture(GL_TEXTURE_2D, texId); glTexImage2D(GL_TEXTURE_2D, ...); vs glTextureImage2DEXT(texId, GL_TEXTURE_2D, ...);
    - exDM69 14y ago
      EXT_direct_state_access is not very well maintained. And bind-to-modify is just one problem, there are others. Everything is mutable in OpenGL (a stark contrast to D3D), and that makes things complicated.
jiggy2011 14y ago
I thought stuff like SDL was used precisely because it abstracted away all the crappy parts of openGL and gave you an easier API to work with?
- eropple 14y ago
  If it meaningfully abstracted away the crap as it was originally billed to do, yes. It doesn't really do that, IMO, and mostly just makes you deal with even more mental state. It's very common to see people use SDL more or less only for creating a window and pulling input (which it does do pretty well). SFML is better, but the developers are pretty uninterested (SFML 1.x was declared "legacy" while there was a bug that prevented it from running on modern AMD graphics cards) and I wouldn't trust it as far as I could throw it.
  - peacemaker 14y ago
    Can you explain why you wouldn't trust SFML? I've been using it for a few months now and haven't had any problems.
    - eropple 14y ago
      I don't trust people who leap to a new, breaking major version while ~40% of people can't run the in-theory-supported old one. Their prerogative, but I won't use their library because of it.
- exDM69 14y ago
  > I thought stuff like SDL was used precisely because it abstracted away all the crappy parts of openGL and gave you an easier API to work with? No. SDL only deals with the platform specific parts like windowing and OpenGL initialization. It does not do any OpenGL for you. GLFW is another popular tool for the same purpose.
JabavuAdams 14y ago
Simply not true. If you're new to real-time 3d I'd ignore this advice. If you're experienced, then you probably have enough info and project-specific knowledge to make up your own mind.
- brooksbp 14y ago
  +1 I am having a flippin blast working through this: http://www.arcsynthesis.org/gltut/ http://www.arcsynthesis.org/gltut/
darkstalker 14y ago
id Software writes all of it's games using OpenGL, and they always create state of the art engines
- naitbit 14y ago
  Yes but Carmack also said that he now prefers D3D[1] and that difference between OpenGl and D3d does not really matter: "It’s interesting how little of the technology cares what API you’re using and what generation of the technology you’re on. You’ve got a small handful of files that care about what API they’re on, and millions of lines of code that are agnostic to the platform that they’re on." [2] [1]http://news.ycombinator.com/item?id=2313661 http://news.ycombinator.com/item?id=2313661 [2] http://www.maximumpc.com/article/features/e3_2008_the_john_carmack_interview_rage_id_tech_6_doom_4_details_and_more http://www.maximumpc.com/article/features/e3_2008_the_john_c...
- cobrausn 14y ago
  It isn't because OpenGL is better. It's simply inertia. Don't take my word for it - take Carmack's. http://www.tomshardware.com/news/john-Carmack-DirectX-OpenGL-API-Doom,12372.html http://www.tomshardware.com/news/john-Carmack-DirectX-OpenGL... I do all my graphics work in OpenGL, but I'm aware of its shortcomings.
huggyface 14y ago
Try to propose using OpenGL to a game developer and you'll be laughed at. OpenGL dominates the massive mobile industry (those billion or so Android and iOS handsets run and live on OGL ES 2.0), and OpenGL was the premiere desktop gaming API until relatively recently. Then it fell behind not because it was a defective API, but rather because the OpenGL working group was far too slow to adapt to hardware improvements -- mired in infighting and bureaucratic BS -- while DirectX raced ahead with things like geometry shaders. Of course mobile has completely changed the equation, and suddenly people are writing OpenGL engines that only make sense to use against all other targets (Windows, Linux, etc)

by exDM69 14y ago

dtf 14y ago

Do you write old-and-busted OpenGL or new-hotness OpenGL? Seems fairly clean to me when you leave out all that legacy crack the CAD vendors can't seem to give up.

exDM69 14y ago
> Do you write old-and-busted OpenGL or new-hotness OpenGL? Seems fairly clean to me when you leave out all that legacy crack the CAD vendors can't seem to give up. I usually use the latest GL only. Today that would be GL 4.2 core profile. Or GLES2. Sure the old fixed function pipeline and immediate mode are gone. But the API still sucks. Bind-to-modify semantics, using integers for handles, global state everywhere, etc. They are the big problems, for both, users and implementors.
- optymizer 14y ago
  What's wrong with bind-to-modify and using integers for handles? What alternatives are there? With my limited knowledge of OpenGL, I know you get a number, describing a resource in video card memory. I bet for an OpenGL implementation, binding a resource id means finding a pointer to the resource. Sounds reasonable to me. Would you rather get an invalid pointer that you should refrain from dereferencing (because you'll be reading from RAM, not GPU RAM)? That would've been a disaster. And I don't really know what 'global state everywhere' means. Do you mean that you keep OpenGL-related info in your program's global state? In that case, you should be using some AppState object to keep the state (and pass a pointer around). Otherwise, what global state is there "everywhere"?
  - exDM69 14y ago
    > What's wrong with bind-to-modify and using integers for handles? What alternatives are there? glBindTexture(GL_TEXTURE_2D, my_texture_handle); glTexImage2D(GL_TEXTURE_2D, ....); Why not: glTexImage(my_texture_handle, ....); In addition to being used for accessing and modifying, the bindings are global values that affect rendering. In the example above, it affects which texture is used on the texture unit that has been selected by glActiveTexture. What a mess. > With my limited knowledge of OpenGL, I know you get a number, describing a resource in video card memory. I bet for an OpenGL implementation, binding a resource id means finding a pointer to the resource. Sounds reasonable to me. Wrong. There's a lot of software in between, before we start talking about GPU resources, so it refers to a structure on the CPU side. The integer-to-pointer lookup in between is another cache miss that we don't need (it has measurable L1 cache effects). This has, to some degree, been worked around by adding state objects like "Vertex Array Objects" (similar to D3D input layout). > Would you rather get an invalid pointer that you should refrain from dereferencing (because you'll be reading from RAM, not GPU RAM)? That would've been a disaster. Opaque pointers are used quite a lot in that way (e.g. D3D, via object pointers), it's a common idiom in C that adds a little type safety and documentation. In this case the pointers would be internal structures in the GL driver's user space. But you should not dereference them anyway. Unix uses integers as handles because the stuff it refers to is inside kernel memory, and you could poison the kernel by giving invalid pointers. > Do you mean that you keep OpenGL-related info in your program's global state? In that case, you should be using some AppState object to keep the state (and pass a pointer around). I don't. OpenGL does. In OpenGL, you have a global variable (actually: thread local) called the "context" which contains all the state of the rendering pipeline. In essence, it's a global variable that has side-effects when you access it.
    - brooksbp 14y ago
      > Why not: > glTexImage(my_texture_handle, ....); Macro?
      - nvoorhies 14y ago
        You'll still have the driver doing the mapping from id to handle under the hood. It can get to be north of 25% of cpu cycles spent looking this up in some cases.
- jra101 14y ago
  You can use the EXT_direct_state_access instead of bind-to-modify. glBindTexture(GL_TEXTURE_2D, texId); glTexImage2D(GL_TEXTURE_2D, ...); vs glTextureImage2DEXT(texId, GL_TEXTURE_2D, ...);
  - exDM69 14y ago
    EXT_direct_state_access is not very well maintained. And bind-to-modify is just one problem, there are others. Everything is mutable in OpenGL (a stark contrast to D3D), and that makes things complicated.

jiggy2011 14y ago

I thought stuff like SDL was used precisely because it abstracted away all the crappy parts of openGL and gave you an easier API to work with?

eropple 14y ago
If it meaningfully abstracted away the crap as it was originally billed to do, yes. It doesn't really do that, IMO, and mostly just makes you deal with even more mental state. It's very common to see people use SDL more or less only for creating a window and pulling input (which it does do pretty well). SFML is better, but the developers are pretty uninterested (SFML 1.x was declared "legacy" while there was a bug that prevented it from running on modern AMD graphics cards) and I wouldn't trust it as far as I could throw it.
- peacemaker 14y ago
  Can you explain why you wouldn't trust SFML? I've been using it for a few months now and haven't had any problems.
  - eropple 14y ago
    I don't trust people who leap to a new, breaking major version while ~40% of people can't run the in-theory-supported old one. Their prerogative, but I won't use their library because of it.
exDM69 14y ago
> I thought stuff like SDL was used precisely because it abstracted away all the crappy parts of openGL and gave you an easier API to work with? No. SDL only deals with the platform specific parts like windowing and OpenGL initialization. It does not do any OpenGL for you. GLFW is another popular tool for the same purpose.

JabavuAdams 14y ago

Simply not true. If you're new to real-time 3d I'd ignore this advice. If you're experienced, then you probably have enough info and project-specific knowledge to make up your own mind.

brooksbp 14y ago
+1 I am having a flippin blast working through this: http://www.arcsynthesis.org/gltut/ http://www.arcsynthesis.org/gltut/

darkstalker 14y ago

id Software writes all of it's games using OpenGL, and they always create state of the art engines

naitbit 14y ago
Yes but Carmack also said that he now prefers D3D[1] and that difference between OpenGl and D3d does not really matter: "It’s interesting how little of the technology cares what API you’re using and what generation of the technology you’re on. You’ve got a small handful of files that care about what API they’re on, and millions of lines of code that are agnostic to the platform that they’re on." [2] [1]http://news.ycombinator.com/item?id=2313661 http://news.ycombinator.com/item?id=2313661 [2] http://www.maximumpc.com/article/features/e3_2008_the_john_carmack_interview_rage_id_tech_6_doom_4_details_and_more http://www.maximumpc.com/article/features/e3_2008_the_john_c...
cobrausn 14y ago
It isn't because OpenGL is better. It's simply inertia. Don't take my word for it - take Carmack's. http://www.tomshardware.com/news/john-Carmack-DirectX-OpenGL-API-Doom,12372.html http://www.tomshardware.com/news/john-Carmack-DirectX-OpenGL... I do all my graphics work in OpenGL, but I'm aware of its shortcomings.

huggyface 14y ago

Try to propose using OpenGL to a game developer and you'll be laughed at. OpenGL dominates the massive mobile industry (those billion or so Android and iOS handsets run and live on OGL ES 2.0), and OpenGL was the premiere desktop gaming API until relatively recently. Then it fell behind not because it was a defective API, but rather because the OpenGL working group was far too slow to adapt to hardware improvements -- mired in infighting and bureaucratic BS -- while DirectX raced ahead with things like geometry shaders. Of course mobile has completely changed the equation, and suddenly people are writing OpenGL engines that only make sense to use against all other targets (Windows, Linux, etc)