5 ms·

As a counterpoint to the "OpenGL needs to start from scratch" discussion, take a look at JWZs blog about porting XScreenSaver to iOS: http://www.jwz.org/blog/20

As a counterpoint to the "OpenGL needs to start from scratch" discussion, take a look at JWZs blog about porting XScreenSaver to iOS: http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-to-the-iphone/ http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t...

ajross 14y ago
Indeed. The death of the immediate draw APIs is something that only driver writers and serious optimization wonks think is a good idea. For everyone else, it simply makes ES2 an API that is basically impossible to learn. Without exception, everyone I know who does any 3D work at all learned first on 1.1 doing flat shaded fixed function stuff. And all those APIs are gone. The amount of code required in ES2 to put anything on the screen at all is staggering. But that said: the per-vertex APIs really are broken from an optimization sense, and serious apps absolutely must do their work on buffer objects. (Display lists have historically been a way to cheat this, at the expense of huge complexity in the driver. This is one of the bad APIs exDM69 is talking about, I suspect.)
- kcbanner 14y ago
  There is really no use for immediate mode anymore; I'm of the opinion that if you lament the loss of immediate mode, you simply don't want to learn the newer, more efficient ways of doing the same thing. Ask yourself this, if immediate mode never existed, would you still say that the ES2.0 method is still "basically impossible to learn"? I assure you that it is very possible to learn.
  - jra101 14y ago
    Immediate mode is very useful for drawing a single triangle that fully covers the viewport, something that is quite common for any sort of image processing or post processing. In these cases your performance will entirely be limited by the complexity of your fragment shader or by raw fill rate and not by the method you used to submit the vertices to the GPU.
    - kcbanner 14y ago
      Agreed, and I would also add that the overhead in terms of development time to set up the boilerplate to render this triangle via immediate mode and the newer methods would be comparable.
  - ajross 14y ago
    Terminology quibble: you don't mean "immediate mode" in the sense it's been used in the community. OpenGL is still an immediate mode API under all circumstances. There is no scene graph. I probably should have said "streamed vertex" or "begin/end" to make things clearer. Did you learn ES2 (i.e. create a buffer object, fill it, pass in attribute pointers, goof up the stride values, do it again, draw)? Or did your first triangle come out via begin/vertex/vertex/vertex/end?
    - kcbanner 14y ago
      My first triangle came out when there was no programmable pipeline, so yep, via immediate mode (any by that I mean begin/end). Then, when OpenGL 2.0 came out, I learned how to use buffers to do it instead. Are you saying that immediate mode should be used in all cases, even for rendering a complex mesh where you will need to spend CPU cycles iterating and uploading vertices to the CPU every frame?
      - ajross 14y ago
        Goodness no. I think you missed the last paragraph I wrote in the note you responded to. I'm saying that the begin/end APIs should not have been dropped from the spec in ES2. There needs to be some kind of equivalent, because high performances games and driver writers aren't the only users of the API.
        rrmm 14y ago
        It seems like the API could probably be replicated in glu or glut, so people who just want the fixed pipeline could get it easily.
        ajross 14y ago
        Sure, it could be. But the problem was it wasn't, so ES2 came out and effectively abandoned huge chunks of existing code the relied on the fixed function pipeline. And they had no answer for what people were supposed to replace it with. Thus the aggrieved flaming from people like jwz who just want to port some software.
- angersock 14y ago
  Though they are very handy, they tend to promote a misunderstanding of the pipeline that can hinder later OpenGL work. Learning the modern way right from the start saves a lot of annoyances, especially as the streaming interfaces have some different weirdness when compared with the newer stuff. Honestly, I view the old GL stuff as a sort of toy language for graphics--and yes, it's annoying to write the boilerplate (oh so much boilerplate) to get a spinning quad onscreen nowadays. At the same time, if people need a toy language to get into graphics, we really should just write a simple layer on top of modern OpenGL, instead of polluting the API and spec with old garbage.
exDM69 14y ago
OpenGL's role in the software ecosystem has changed since GL 1.x was relevant. Back then it was used as a 3D rendering API (with lights and cameras and such). Today it is used as the standard interface to programmable graphics hardware. GL2+ knows almost nothing about "3d" or lighting and is essentially used for drawing triangles, very fast. If you need a 3D engine, use a 3d engine. If you're writing a 3D engine, you use OpenGL. OpenGL should start from scratch and change their name and code naming conventions so no-one would be under false illusions that you can take OpenGL code from 1996 and make it work on OpenGL in 2012. That would have kept JWZ happy and others who complain about the lack of fixed function and immediate mode in OpenGL too. Btw. once you get past the basics in GL 1.x fixed function, everything becomes /ridiculously/ difficult. Look at how Quake 3 did their "shaders" for example.

ajross 14y ago

Indeed. The death of the immediate draw APIs is something that only driver writers and serious optimization wonks think is a good idea. For everyone else, it simply makes ES2 an API that is basically impossible to learn. Without exception, everyone I know who does any 3D work at all learned first on 1.1 doing flat shaded fixed function stuff. And all those APIs are gone. The amount of code required in ES2 to put anything on the screen at all is staggering. But that said: the per-vertex APIs really are broken from an optimization sense, and serious apps absolutely must do their work on buffer objects. (Display lists have historically been a way to cheat this, at the expense of huge complexity in the driver. This is one of the bad APIs exDM69 is talking about, I suspect.)

kcbanner 14y ago
There is really no use for immediate mode anymore; I'm of the opinion that if you lament the loss of immediate mode, you simply don't want to learn the newer, more efficient ways of doing the same thing. Ask yourself this, if immediate mode never existed, would you still say that the ES2.0 method is still "basically impossible to learn"? I assure you that it is very possible to learn.
- jra101 14y ago
  Immediate mode is very useful for drawing a single triangle that fully covers the viewport, something that is quite common for any sort of image processing or post processing. In these cases your performance will entirely be limited by the complexity of your fragment shader or by raw fill rate and not by the method you used to submit the vertices to the GPU.
  - kcbanner 14y ago
    Agreed, and I would also add that the overhead in terms of development time to set up the boilerplate to render this triangle via immediate mode and the newer methods would be comparable.
- ajross 14y ago
  Terminology quibble: you don't mean "immediate mode" in the sense it's been used in the community. OpenGL is still an immediate mode API under all circumstances. There is no scene graph. I probably should have said "streamed vertex" or "begin/end" to make things clearer. Did you learn ES2 (i.e. create a buffer object, fill it, pass in attribute pointers, goof up the stride values, do it again, draw)? Or did your first triangle come out via begin/vertex/vertex/vertex/end?
  - kcbanner 14y ago
    My first triangle came out when there was no programmable pipeline, so yep, via immediate mode (any by that I mean begin/end). Then, when OpenGL 2.0 came out, I learned how to use buffers to do it instead. Are you saying that immediate mode should be used in all cases, even for rendering a complex mesh where you will need to spend CPU cycles iterating and uploading vertices to the CPU every frame?
    - ajross 14y ago
      Goodness no. I think you missed the last paragraph I wrote in the note you responded to. I'm saying that the begin/end APIs should not have been dropped from the spec in ES2. There needs to be some kind of equivalent, because high performances games and driver writers aren't the only users of the API.
      - rrmm 14y ago
        It seems like the API could probably be replicated in glu or glut, so people who just want the fixed pipeline could get it easily.
        ajross 14y ago
        Sure, it could be. But the problem was it wasn't, so ES2 came out and effectively abandoned huge chunks of existing code the relied on the fixed function pipeline. And they had no answer for what people were supposed to replace it with. Thus the aggrieved flaming from people like jwz who just want to port some software.
angersock 14y ago
Though they are very handy, they tend to promote a misunderstanding of the pipeline that can hinder later OpenGL work. Learning the modern way right from the start saves a lot of annoyances, especially as the streaming interfaces have some different weirdness when compared with the newer stuff. Honestly, I view the old GL stuff as a sort of toy language for graphics--and yes, it's annoying to write the boilerplate (oh so much boilerplate) to get a spinning quad onscreen nowadays. At the same time, if people need a toy language to get into graphics, we really should just write a simple layer on top of modern OpenGL, instead of polluting the API and spec with old garbage.

exDM69 14y ago

OpenGL's role in the software ecosystem has changed since GL 1.x was relevant. Back then it was used as a 3D rendering API (with lights and cameras and such). Today it is used as the standard interface to programmable graphics hardware. GL2+ knows almost nothing about "3d" or lighting and is essentially used for drawing triangles, very fast. If you need a 3D engine, use a 3d engine. If you're writing a 3D engine, you use OpenGL. OpenGL should start from scratch and change their name and code naming conventions so no-one would be under false illusions that you can take OpenGL code from 1996 and make it work on OpenGL in 2012. That would have kept JWZ happy and others who complain about the lack of fixed function and immediate mode in OpenGL too. Btw. once you get past the basics in GL 1.x fixed function, everything becomes /ridiculously/ difficult. Look at how Quake 3 did their "shaders" for example.