Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (578)
games submitted by our members
Games in WIP (499)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Removing access to pointers  (Read 1792 times)
0 Members and 1 Guest are viewing this topic.
Offline cfmdobbie

Senior Member




Who, me?


« Posted 2003-02-10 22:41:23 »

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):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
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:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
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:

1  
2  
3  
4  
            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?

Hellomynameis Charlie Dobbie.
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #1 - Posted 2003-02-10 23:20:35 »

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.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2003-02-10 23:33:31 »

'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 Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (27 views)
2014-04-15 18:08:23

BurntPizza (24 views)
2014-04-15 03:46:01

UprightPath (39 views)
2014-04-14 17:39:50

UprightPath (21 views)
2014-04-14 17:35:47

Porlus (37 views)
2014-04-14 15:48:38

tom_mai78101 (61 views)
2014-04-10 04:04:31

BurntPizza (120 views)
2014-04-08 23:06:04

tom_mai78101 (220 views)
2014-04-05 13:34:39

trollwarrior1 (187 views)
2014-04-04 12:06:45

CJLetsGame (194 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!