Removing access to pointers

Does anyone see any mileage in producing a wrapper for the LWJGL OpenGL binding that abstracts away pointers but still looks and behaves as OpenGL?

My first thought on how this would be implemented is something like the following (note: all defined here in default package):


public class SafeGL
{
      private GL gl ;

      public SafeGL() throws Exception
      {
            gl = new GL() ;
            gl.create() ;
      }

      // Lots of methods like this!
      public void color4fv(Color4fv color)
      {
            gl.color4fv(color.address) ;
      }

      // Also proxy the "normal" methods, destroy(),
      // vertex2d(), getString() etc. etc.
      public void destroy()
      {
            gl.destroy() ;
      }
}

The class defining the specific type of native buffer wrapper would be as follows:


public class Color4fv
{
      FloatBuffer buffer ;
      int address ;

      public Color4fv(float r, float g, float b, float a)
      {
            buffer = ByteBuffer.allocateDirect(16)
                  .order(ByteOrder.nativeOrder())
                  .asFloatBuffer()
                  .put(r).put(g).put(b).put(a) ;
            address = Sys.getDirectBufferAddress(buffer) ;
      }

      public float getR() { return buffer.get(0) ; }
      public float getG() { return buffer.get(1) ; }
      public float getB() { return buffer.get(2) ; }
      public float getA() { return buffer.get(3) ; }
      public void setR(float r) { buffer.put(0, r) ; }
      public void setG(float g) { buffer.put(1, g) ; }
      public void setB(float b) { buffer.put(2, b) ; }
      public void setA(float a) { buffer.put(3, a) ; }
      public float[] getRGBA() { return buffer.array() ; }
}

And you’d use it like this:


            SafeGL gl = new SafeGL() ;

            Color4fv red = new Color4fv(1.0f, 0.0f, 0.0f, 1.0f) ;
            gl.color4fv(red) ;

What do y’all think about something like that? I don’t feel a burning need for it myself, but if it would encourage people to use LWJGL might it be worth doing?

I think the main problem would be the sheer number of classes you’d need! For the colour buffers you have 3 or 4 arguments, for each of b, s, i, f, d, ub, us and ui == 16 new classes. Vertexes require an additional 12, etc etc.

Maybe a better approach is to just define a “Float4” and share the class among all methods that take a four-element array of floats?

Anyone got any thoughts on the concept?

I thought about producing something similar but the amount of work required to maintain the large number of classes made it non-trivial for the amount of gain. What I ended up doing was providing a wrapper for all of the vertex,color, etc buffer classes and adding in something to wrap their address so it was easier to use.

'srite. And if you’re actually using glColorxxv methods you deserve all the evil that happens to you, because they’re very, very slow. Just stick to glColor3f and forget the vector versions (they might have been efficient in OpenGL1.0 but these days they’re the second slowest way to draw anything, and the slowest - the non-vector versions - is only going to cost you 2 cycles or so).

Cas :slight_smile: