so many open gl extensions...

This is a discussion on so many open gl extensions... within the Game Programming forums, part of the General Programming Boards category; sry for asking a question here again, but here it goes: which are the most important extensions? well for sure ...

  1. #1
    Registered User
    Join Date
    Aug 2001
    Posts
    244

    so many open gl extensions...

    sry for asking a question here again, but here it goes:

    which are the most important extensions?
    well for sure the ones for creating index/vertex buffers, fragment/vertex shaders and textures.

    but what other extensions provide functionality that cannot be accomplished by the extensions used for doing the already listed stuff (index/vertex buffers, fragment/vertex shaders and textures)?

    it seems that some extensions can be completely replaced by shaders - so there is no real point in using them except for convenience - or does it just seem that way?


    edit: i'm simply asking this to figure out which extensions are worth taking a closer look at. the goal is currently writing a simple(*) shooter but the code should be VERY extensible.


    (*) just some spheres representing players and projectiles and cylinders representing the lookat directions :P
    Last edited by Raven Arkadon; 08-24-2006 at 10:05 PM.
    signature under construction

  2. #2
    Registered User
    Join Date
    Aug 2001
    Posts
    244
    hmm well.... ive just taken a look at the IDirect3DDevice9 interface and i'm surprised: my interface looks like a subset of it - even i have pointers to interfaces everywhere - the major difference is, that i don't use plain pointers in the interfaces, but pointer-objects which can hold any type derived from IPointer (a pointer interface).

    the rule for the render device is, that all resources created with it (e.g. vertex buffers, index buffers) must managed - and must be guaranteed to work with at least reference counted pointers (so cyclic dependencies of managed pointers are allowed to cause troubles). so if all pointer objects pointing to a certain object go out of scope/are reassigned/are deleted then the resource must be release too.

    no matter how the pointer object is implemented (so no matter what garbage collection strategy it uses) the interface remains the same.

    so that would be some interfaces
    Code:
    template <typename T>
    class _IPointer
    {
    public:
      // operators like ->, *,  comparision etc... so all operators you'd use with a pointer to a single object (not arrays)
    };
    
    class IVertexBuffer
    { .. };
    
    class IIndexBuffer
    { .. };
    
    // _AnyPtr is the magic pointer template that can hold any object
    // that is derived from the IPointer interface. also _AnyPtr provides the IPointer
    // interface itself.
    // that way _AnyPtr has the same interface and behaviour as the wrapped object.
    // so the most important attribute of _AnyPtr is a boost::any attribute.
    typedef _AnyPtr<IVertexBuffer>         AnyVertexBufferPtr;
    typedef _AnyPtr<IIndexBuffer>          AnyIndexBufferPtr;
    
    class IRenderDevice
    {
    public:
      virtual
        AnyVertexBufferPtr create_vertex_buffer(unsigned     size, 
    					    EBufferUsage buffer_usage,
    					    const void   *p_data = NULL) = 0;
    
      virtual
        AnyIndexBufferPtr  create_index_buffer (unsigned     size, 
    					    EBufferUsage buffer_usage,
    					    const void   *p_data = NULL) = 0;
    ...
    };

    and that would be an implementation:
    Code:
    class RenderDeviceOpenGl
      : public IRenderDevice
    {
      // same signatures as in the interface
    };
    Code:
    AnyVertexBufferPtr
    RenderDeviceOpenGl::create_vertex_buffer(unsigned size, 
    					 EBufferUsage buffer_usage,
    					 const void *p_data)
    {
    ...
      // SRefCntPtr<T> is a template for a simple reference counted pointer, which is derived from IPointer<T>.
      // since _SRefCntPtr<IVertexBuffer> is derived from IPointer<IVertexBuffer> it can be stored in an
      // _AnyPtry<IVertexBuffer> object.
      return _SRefCntPtr<IVertexBuffer>(new VertexBufferOpenGl(...));
    }
    i called it simple reference counted pointer because i did a simple implemenation of it - although more sophisticated methods are possible

    and just for fun we use a different smart pointer type for the index buffer
    Code:
    AnyIndexBufferPtr
    RenderDeviceOpenGl::create_index_buffer(unsigned size, 
    					 EBufferUsage buffer_usage,
    					 const void *p_data)
    {
    ...
      // _SophisicatedRefCntPtr<T> must be derived from IPointer<T> again
      return _SophisicatedRefCntPtr<IIndexBuffer>(new IndexBufferOpenGl(...));
    }
    fun - is it?

    ok, i was pretty much talking to myself with this... its almost 7:30 am in the morning, i've been reading tons of docs, and i need to go to the doctor in 30 min anyway - so i just spent the time thinking the whole thing over again - but i think its not bad the way i have done it.

    the overhead for accessing the object pointed to by the smart pointer compared to an ordinary pointer is none, since _AnyPtr<T> caches the pointer to the object itself (and operator->() is an inline function).
    Last edited by Raven Arkadon; 08-24-2006 at 11:27 PM.
    signature under construction

  3. #3
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    hmm well.... ive just taken a look at the IDirect3DDevice9 interface and i'm surprised: my interface looks like a subset of it
    Not surprising. A common goal usually yields for the most part common code. There are, after all, a finite number of ways to peel a potato.

  4. #4
    The Right Honourable psychopath's Avatar
    Join Date
    Mar 2004
    Location
    Where circles begin.
    Posts
    1,070
    Back to the extensions bit...

    It depends on what you want to accomplish, and how, and in some cases on what platform (ATI, NV, APPLE, SUN, etc prefixed extensions).

    No extention is really more important than another. Extensions are just there to provide functionality that isn't a part of the core OpenGL spec, and usually not availbable in the OS OpenGL implementation. On Windows for example, the shipped OpenGL library is only OpenGL 1.1, which is why it seems like everything needs to be accessed through extensions. Shaders became part of the OpenGL 2.0 spec, but there is no available OpenGL 2.0 implementation on Windows. One thing to remember about extensions, is that ARB extensions are "official". These extensions will work on all graphics card platforms, and they often become part of the OpenGL core spec (for example, multitexturing was an ARB extension, but has long since become part of the OpenGL spec). Vendor specifc extensions like ATI, NV, SUN etc usually provide functionality for that specific platform.

    so there is no real point in using them except for convenience
    Again, it depends on what you want to do. For example framebuffer objects must be used via GL_EXT_framebuffer_object. This feature is not an ARB approved extension, but it is not vendor specific, hence the generic EXT prefix.

    Hopefully that made sense. I kind of lost myself halfway through.
    Memorial University of Newfoundland
    Computer Science

    Mac and OpenGL evangelist.

  5. #5
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    Sheesh. Glad I don't have to wade through that mess.

  6. #6
    The Right Honourable psychopath's Avatar
    Join Date
    Mar 2004
    Location
    Where circles begin.
    Posts
    1,070
    Yeah, you already have the DirectX API to deal with.
    Memorial University of Newfoundland
    Computer Science

    Mac and OpenGL evangelist.

  7. #7
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,590
    LOL. Ok I had that coming for sure.

  8. #8
    Registered User
    Join Date
    Aug 2001
    Posts
    244
    Quote Originally Posted by Bubba
    Sheesh. Glad I don't have to wade through that mess.
    hehe, well i once posted an idea, where following could be done:

    assume you have a function, that should return an object with a certain interface.
    like:
    Code:
      Foo generate_foo(const std::string &r_id);
    now you realize you want to be able to return objects that all have the same interface, but
    different implementations.

    (e.g. a direcx vertex buffer or an opengl vertex buffer or just a malloced piece of memory - all things are buffers, but they are treated differently)
    and you also want them to be scoped (so ordinary pointers not appropriate).

    here is one solution to that:

    first: define an ordinary interface.

    Code:
    class MyInterface
    {
    public:
      virtual int my_method(void *blah) = 0;
    };

    step 2: create a type that
    .) can hold arbitrary objects with a certain interface
    .) provides the interface itself

    Code:
    class AnyMyInterface {
    privated:
      boost::any    any;
      MyInterface *p;
    
    public:
      // the constructor and assignment operator are the same for every "Any*"-type
      // so actually they can be macro'd
      template<typename T>
      AnyMyInterface(const T &r_object) {
        (*this) = r_object;
      }
    
      // beginning of hard part
    
      template<typename T>
      AnyMyInterface& operator = (const T &r_rhs)
      {
        // check if r_object is derived from AnyMyInterface
        // (isn't there a template-based way to check wheter a class is derived from another?)
        MyInterface *p_dummy = static_cast<MyInterface*>(&r_object);
    
        if(typeid('this) == typeid(r_rhs))
          any = r_rhs.any;
        else
          any = r_object;
    
        p =  &boost::any_cast<T&>(r_this.any));
      }
    
      // end of hard part
     
      // for each method in MyInterface write a similar method definition:
      // (note that p is a pointer to an object of type MyInterface)
    
    
      int my_method(void *blah)
      {
        return p->my_method(blah);
      }
    }
    
    };
    the _AnyPtr template is an extension of this concept.

    edit: i wonder if that concept has a name - or if it is too stupid to have been named
    Last edited by Raven Arkadon; 08-25-2006 at 11:40 AM.
    signature under construction

  9. #9
    Registered User
    Join Date
    Aug 2001
    Posts
    244
    oh sry, forgot to say thx for your replies
    signature under construction

  10. #10
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Actually, there are OpenGL 2.0 implementations for Windows: ATI and NVidia both provide them with their graphics drivers. It's just that MS doesn't provide one.

    I recommend, if you haven't already done so, that you get the OpenGL Extension Wrangler. It's the most comfortable way of accessing OpenGL functionality.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #11
    Registered User
    Join Date
    Aug 2001
    Posts
    244
    is the wrangler similar to
    http://www.opengl.org/registry/SDK/ ?

    it seems to me that way on first glance.
    signature under construction

  12. #12
    The Right Honourable psychopath's Avatar
    Join Date
    Mar 2004
    Location
    Where circles begin.
    Posts
    1,070
    Quote Originally Posted by CornedBee
    Actually, there are OpenGL 2.0 implementations for Windows: ATI and NVidia both provide them with their graphics drivers. It's just that MS doesn't provide one.
    As in a library that actually implements the OpenGL 2.0 spec? opengl32.lib is OpenGL 1.1, and I have yet to run into any lib that is OpenGL 2.0.
    Memorial University of Newfoundland
    Computer Science

    Mac and OpenGL evangelist.

  13. #13
    Registered User
    Join Date
    Aug 2001
    Posts
    244
    ok, another question:
    so i was reading through the specs but i couldn't find an answer to that question...
    it seems that in open gl shaders need to be compiled from source everytime before you can use them.
    (so CreatShader, ShaderSource, CompileShader, CreateProgram and eventually LinkProgram)
    so is there also a way to retrieve the executable and load that everytime the app starts (instead of compiling the sources everytime)?
    or is the format of the executable open-gl implementation-dependent (*)? (and only the glsl is defined).

    (*) its very nice that the way of converting a shader source into a shader executable in open gl is similar to compiling a c program. first compile the sources - then link them - voila: an executable.
    so because of all that similarity i would assume that the executable depends on the open-gl implementation similar to an "ordinary" executables which can only be run on certain platforms/processors.
    and i would guess that direct3d allows creating a shader from an executable. is that correct?
    signature under construction

  14. #14
    The Right Honourable psychopath's Avatar
    Join Date
    Mar 2004
    Location
    Where circles begin.
    Posts
    1,070
    I'm not entirely sure what you mean, but a shader isn't compiled into a binary or executable. The compiled shader program is sent directly to VRAM on the graphics card. The shader program can then be referenced by the API.
    Memorial University of Newfoundland
    Computer Science

    Mac and OpenGL evangelist.

  15. #15
    Registered User
    Join Date
    Aug 2001
    Posts
    244
    open gl spec page 72:
    A program object is then linked, which generates executable code
    from all the compiled shader objects attached to to the program. When a linked
    program object is used as the current program object, the executable code for the
    vertex shaders it contains is used to process vertices.
    yes, in open gl the process of creating a "shader executable" is the same as the creation of a [edit] executable from a [/edit] c program.
    open gl:
    you have some source files in glsl, which you compile with CompileShader.
    all those compiled shaders are then attached to a program object and are then linked. the result of linking is an executable.

    c/c++:
    you have some source files in c/c++. which you compile with gcc/g++ (with the -c option (thus no linking)).
    then you call the linker and give him all your compiled source files and as a result it gives you an executable.

    (unless there are errors of course)

    i've also read that the glsl is built INTO open gl - not on top of it. so the glsl is really the only way of specifying a shader in opengl as far as i understand this.
    Last edited by Raven Arkadon; 08-25-2006 at 02:43 PM.
    signature under construction

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Open GL ?
    By swgh in forum C++ Programming
    Replies: 2
    Last Post: 07-27-2005, 10:05 AM
  2. Open GL v.s Direct X
    By Frantic- in forum C++ Programming
    Replies: 21
    Last Post: 01-28-2005, 10:55 PM
  3. open gl
    By nerdyneo in forum Game Programming
    Replies: 2
    Last Post: 11-14-2003, 03:33 PM
  4. problem with open gl engine.
    By gell10 in forum Game Programming
    Replies: 1
    Last Post: 08-21-2003, 04:10 AM
  5. Ghost in the CD Drive
    By Natase in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 10-12-2001, 05:38 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21