Latest posts of: kitfox - Java-Gaming.org

Show Posts
Pages: [1] 2 3 ... 5

Game Development / Game Mechanics / Should I put a delay in my main game loop?

on: 2013-02-23 15:49:47

I have a game with a main loop that looks like

1
2
3
4
5

while(true)
{
    doGameLogic();
    drawLevel();
}

Someone on another forum said that this is a bad idea because it would lead to 100% CPU usage which would 'be a killer to power and heat consumption'. Is this true? Right now my game is running at about 1000 FPS, but I could add a Thread.sleep(1) command in there if that would make things better for the user. (The game thread is already running at MIN_PRIORITY).

Game Development / Game Mechanics / Faking threads (scripting)

on: 2013-02-23 15:44:00

I'm writing a game and trying to think of a good way to handle complex scripted animation.

Right now the main game loop looks like:

1
2
3
4
5
6
7
8
9

while (true)
{
   for (LevelObject obj: levelObjects)
   {
      obj.performGameLogic();
   }

drawLevel();
}

Right now performGameLogic() is hard coded per object and does something simple like cause the game object to slowly walk back and forth while updating the sprite animation. However, I'd like to do something more complex. It would be nice if I could write something like:

1
2
3
4
5
6
7
8
9
10
11
12
13

class Monster extends GameObject
{
   public void performGameLogic()
   {
      takeStep(Direction.DOWN);
      takeStep(Direction.LEFT);
      if (chest5.isClosed())
      {
         chest5.openChest();
      }
      playAnimation("BeatChest");
   }
}

The trouble with this is that most of the above commands will require several hundred milliseconds to complete (and animate). They should also play sequentially - one after the other. However, the main thread needs to return almost immediately to perform the rest of the game logic and draw the level.

It would be better if I could somehow encapsulate this in a 'thread'. Each time performGameLogic() was called, it would advance this 'thread' as far as it could and then return. (Ie, the 'thread' would run until it blocks, waiting for time to have elapsed or some state to be set.) When performGameLogic() was called again, the 'thread' would pick up again from where it left off and run until it blocks again.

Using real threads to do this would be expensive. I was wondering if there might be some clever way to create this thread-like behavior with arbitrary code.

(At the moment, I have a solution where I create Animation objects and link them together. Each Animation has an advanceLogic() method that is called to advance its state and which will fire an event when it completes. A listener will then detect this event and schedule the next Animation object. While this works, it is tedious and unintuitive.)

3	Java Game APIs & Engines / JOGL Development / JOGL slowdown	on: 2011-07-06 14:43:18
Hi. Hope everyone had a happy fourth of July. I'm posting with a test case for a weird JOGL slowdown issue. I only have one machine I can test this on, so if others could give it a shot and let me know what happens, it would help a lot. The program just generates some images and draws them to screen over and over in a loop. This should be very fast - however, if Firefox 5 or Photoshop are open, sometimes the framerate will drop to something around 2 fps. This doesn't always happen, though, so if you could open Firefox and then run this program 10 or 20 times and let me know if you have a slowdown, that would help. http://kitfox.com/tmp/FBOTest.zip Thanks, Mark

4	Java Game APIs & Engines / JOGL Development / Re: Why are FBOs faster than writing directly to the screen?	on: 2011-07-01 09:13:13
I've got a test case. It runs a simple animation loop drawing many small textures to the screen. I've not been able to run this on other machines, but I did find out more info. You can get the test case here: http://kitfox.com/tmp/FBOTest.zip While working with the test, I learned a few things: -This bug only seems to appear when I have Firefox 5 open in the background. -Whenever I'm using an FBO, rendering speed is always fast -Whenever I'm not using the FBO and Firefox is open, sometimes the program runs fast and sometimes it runs slowly (by slow, I mean about 2 fps with a 640x480 window. By fast, the frames blur together) -I think the longer Firefox has been open, the more likely my program is to run slowly - however, this is hard to test since I would need a couple of hours between tests. However, if I keep running the program with no FBO and Firefox open, I will sometimes get a slow run, even if I have just launched Firefox. - I've not tried this with other web browsers. I have disabled hardware acceleration in Firefox.

Java Game APIs & Engines / JOGL Development / Re: glCreateShader not available in JSR 231

on: 2011-06-30 20:16:47

1	System.err.println("GL version:" + gl.glGetString(GL.GL_VERSION));

is giving me

1	GL version:1.1.0

Not sure why. JOGL 1.1.1 reports

1	2.1.7412 Release.

6	Java Game APIs & Engines / JOGL Development / Re: glCreateShader not available in JSR 231	on: 2011-06-30 17:55:40
I tried without the DebugGL2. Same error.

7	Java Game APIs & Engines / JOGL Development / glCreateShader not available in JSR 231	on: 2011-06-30 12:56:16
I have another weird porting error for JSR 231. While trying to diagnose another problem, I tried getting a program I'm developing up and running on my laptop. It has a cheap ATI Mobility Radeon HD 2300 and runs OpenGL 2.1.7. Now while my program runs fine on my desktop, on my laptop I get an exception whenever I try to call glCreateShader. However, my laptop is able to handle shaders and I'm able to call glCreateShader under JOGL 1.1.1a (albeit in a different program). (I've not run my current program on my laptop before, so I can't say if this call would work for it under JOGL 1.1.1) Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Method "glCreateShader" not available at jogamp.opengl.gl4.GL4bcImpl.glCreateShader(GL4bcImpl.java:3115) at javax.media.opengl.DebugGL2.glCreateShader(DebugGL2.java:28623) at com.kitfox.coyote.renderer.jogl.GLWrapperJOGL.glCreateShader(GLWrapperJOGL.java:189) at com.kitfox.coyote.renderer.CyMaterial.loadShader(CyMaterial.java:38)

8	Java Game APIs & Engines / JOGL Development / Re: GL_FRAMEBUFFER_UNSUPPORTED caused by Firefox	on: 2011-06-29 22:37:13
This is an application. I'm using a GLJPanel since I need it to fit into a Swing framework (it sits inside a JSplitPane). Every now and then I'll switch it to a GLCanvas just to see if it makes a difference, but a GLCanvas does not play nicely with my other Swing components. I'll do some searching on creating my own GLContext. Maybe that will help.

9	Java Game APIs & Engines / JOGL Development / Re: Why are FBOs faster than writing directly to the screen?	on: 2011-06-29 22:30:11
I've tried both small tiles and a single tile the size of the entire screen. In both cases I get the speedup. I've also tried skipping my whole tile pipeline and simply writing everything to a single screen-sized FBO buffer. I get the speed up in that case too.

10	Java Game APIs & Engines / JOGL Development / GL_FRAMEBUFFER_UNSUPPORTED caused by Firefox	on: 2011-06-29 21:37:25
I'm getting a strange FBO error that seems to be caused by other applications (Firefox, Photoshop) affecting my JOGL app. I have code in which I create an FBO and render to it. Most of the time this works. However, if I have Firefox or Photoshop running in the background, sometimes it won't. If I kill these programs, my JOGL app magically starts working again. This is probabaly an NVidia bug. A poster on another forum suggested a solution that involved recreating the context, but as far as I know this is impossible in JOGL: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=298569#Post298569 I'm using a Quadro FX 570/PCI/SSE2 graphics card with the latest drivers and JSR 231.

11	Java Game APIs & Engines / JOGL Development / Re: Why are FBOs faster than writing directly to the screen?	on: 2011-06-29 21:27:00
My drivers are in their latest version and I've upgraded to JSR 231, but am still having the same issue. The FBO error aside, why would drawing everything to an FBO texture and then drawing that to the main window as a textured quad be so much faster than drawing everything to the main window directly?

12	Java Game APIs & Engines / JOGL Development / Re: FBOs not working in JOGL2	on: 2011-06-29 21:06:09
Ah. Silly mistake on my part. Yes, I was generating Buffers instead of Framebuffers.

Java Game APIs & Engines / JOGL Development / FBOs not working in JOGL2

on: 2011-06-29 20:09:56

I'm porting an application from JOGL 1.1.1 to JSR 231. I'm getting a strange error when I attempt to create an FBO:

1
2
3
4
5
6

        GL2 gl = drawable.getGL().getGL2();
        IntBuffer ibuf = BufferUtil.allocateInt(1);
        gl.glGenBuffers(1, ibuf);
        bufferId = ibuf.get(0);

        gl.glBindFramebuffer(GL2.GL_FRAMEBUFFER, framebuffer);

This causes a GL_INVALID_OPERATON. According to the GL spec, glBindFramebuffer shouldn't even throw this exception. I am using a DebugGL2 to look for errors the same way I used a DebugGL in JOGL 1.1.1.

1
2
3
4
5

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Thread[AWT-EventQueue-0,6,main] glGetError() returned the following error codes after a call to glBindFramebuffer(<int> 0x8D40, <int> 0x1): GL_INVALID_OPERATION ( 1282 0x502), 
        at javax.media.opengl.DebugGL2.checkGLGetError(DebugGL2.java:32455)
        at javax.media.opengl.DebugGL2.glBindFramebuffer(DebugGL2.java:15587)
        at com.kitfox.coyote.renderer.jogl.GLWrapperJOGL.glBindFramebuffer(GLWrapperJOGL.java:100)
        at com.kitfox.coyote.renderer.CyFramebuffer.init(CyFramebuffer.java:118)

Any idea what I'm doing wrong?

14	Java Game APIs & Engines / JOGL Development / How to get started with JOGL 231?	on: 2011-06-28 17:16:58
I've been using JOGL 1.1.1 for a long time now. I've considered upgrading to 231, but cannot find much information about it. Where is the right place to download the jars I need? How do I integrate them into my program? Is there a handy NetBeans plugin like JOGL 1.1.1 has? (Even since the java.net migration, the JOGL page has been empty). Also, do I need to change any code for things to work with JOGL 231?

15	Java Game APIs & Engines / JOGL Development / Why are FBOs faster than writing directly to the screen?	on: 2011-06-28 10:46:02
I recently modified a program of mine that blits textured 2D shapes to the screen. Previously, I had broken my viewport into tile regions, created a tile sized FBO, and then for each tile rendered it's content to the FBO and then blited the FBO to the screen (using a GLJPanel). Thinking this was way to complicated, I decided to do away with the tiling and simply draw everything directly to the GLJPanel with no FBO at all. I was very surprised to find my once responsive program had slowed to a crawl. I thought it might have something to do with the GLJPanel's pBuffers, but using a GLCanvas without FBOs didn't speed things up much. Unfortunately, FBOs have a drawback. If I'm using any other application on my system that uses my graphics card (Firefox, Photoshop), my FBO using Java app will often fail with an error message saying that the particular FBO I requested isn't supported. If I kill my other programs, Java FBOs magically start working again. While this is a work around for debugging, I can't ship like this. It's also a pain to have to keep closing my other programs. Any idea what's going on? Is there a way I can get my super speed without having to use a redundant FBO? (I'm using JOGL 1.1.1. All the JSR 231s I can find are still in beta).

16	Java Game APIs & Engines / JOGL Development / JOGL missing some important methods	on: 2009-05-01 19:12:28
At the moment JOGL only exposes an immediate mode version of glDrawElementesInstancedEXT: GL.glDrawElementsInstancedEXT(int, int, int, Buffer, int) According to the OpenGL spec, this method only works with VBOs. Hence this method should accept a long instead of a Buffer. Unfortunately, JOGL does not provide a VBO version of this method. Also, these two methods are missing entirely: CgGL.cgSetCompilerIncludeCallback() CgGL.cgSetCompilerIncludeString() This makes it really difficult to combine shaders. Are there any plans to add these features to JOGL?

17	Java Game APIs & Engines / JOGL Development / Re: Frame Buffer Object doesn't render properly	on: 2007-04-27 00:53:36
Looks like I shouldn't have made a call to glEnable(GL.GL_RECTANGLE_ARB). I was texturing my object with the background buffer.

Java Game APIs & Engines / JOGL Development / Frame Buffer Object doesn't render properly

on: 2007-04-26 21:40:31

I'm trying to shoehorn JOGL into doing some 2D compositing for me. The clear operation works correctly; unfortunately, whenever I render to my frame buffer object after that, instead of an overlay operation occuring it seems a multiply is done instead. I've fiddled with lots of parameters, but can't stop this.

The depth test should always pass, so there really isn't a need for a depth buffer, but the problem happens with or without it. The blend function should be glBlend(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

What's the right way to draw new images over top of whatever's in my back buffer?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176

public class FBOPanel extends javax.swing.JPanel implements GLEventListener
{
    private GLCanvas canvas;
    
    int frameBufferId;
    int depthId;
    int texId;
    
    int destWidth = 512;
    int destHeight = 256;
    
    /** Creates new form TexRectanglePanel */
    public FBOPanel()
    {
        initComponents();
        
    }
    
    public void addNotify()
    {
        super.addNotify();
        canvas = new GLCanvas(new GLCapabilities());
        canvas.addGLEventListener(this);
        
        add(canvas, BorderLayout.CENTER);
    }
    

    public void init(GLAutoDrawable gLAutoDrawable)
    {
        GL gl = gLAutoDrawable.getGL();
        
        //-----------------------------------------------
        IntBuffer ibuf = BufferUtil.newIntBuffer(1);
        
        gl.glGenFramebuffersEXT(1, ibuf);
        frameBufferId = ibuf.get(0);
        ibuf.rewind();
        gl.glBindFramebufferEXT(GL.GL_FRAMEBUFFER_EXT, frameBufferId);
        
        gl.glGenRenderbuffersEXT(1, ibuf);
        depthId = ibuf.get(0);
        ibuf.rewind();
        
        gl.glGenTextures(1, ibuf);
        texId = ibuf.get(0);
        ibuf.rewind();
        

        gl.glBindRenderbufferEXT(GL.GL_RENDERBUFFER_EXT, depthId);
        gl.glRenderbufferStorageEXT(GL.GL_RENDERBUFFER_EXT, GL.GL_DEPTH_COMPONENT,
                destWidth, destHeight);
        gl.glFramebufferRenderbufferEXT(GL.GL_FRAMEBUFFER_EXT, 
                GL.GL_DEPTH_ATTACHMENT_EXT, GL.GL_RENDERBUFFER_EXT, depthId);
        
        
        ByteBuffer imgData = BufferUtil.newByteBuffer(destWidth * destHeight * 4);
        
        gl.glEnable(GL.GL_TEXTURE_RECTANGLE_ARB);
        gl.glBindTexture(GL.GL_TEXTURE_RECTANGLE_ARB, texId);
        //Create empty texture
        gl.glTexImage2D(GL.GL_TEXTURE_RECTANGLE_ARB, 0, GL.GL_RGBA, 
                destWidth, destHeight, 
                0, GL.GL_RGBA, 
                GL.GL_UNSIGNED_BYTE, imgData);
        
        //Attach texture back buffer
        gl.glFramebufferTexture2DEXT(GL.GL_FRAMEBUFFER_EXT, 
                GL.GL_COLOR_ATTACHMENT0_EXT, GL.GL_TEXTURE_RECTANGLE_ARB, texId, 0);
        
//        gl.glTexEnvf(GL.GL_TEXTURE_ENV, GL.GL_TEXTURE_ENV_MODE, GL.GL_REPLACE);
        
        int status = gl.glCheckFramebufferStatusEXT (GL.GL_FRAMEBUFFER_EXT);
        switch (status)
        {
        case GL.GL_FRAMEBUFFER_COMPLETE_EXT:
                System.out.println("FrameBuffer Created");
            break;
        case GL.GL_FRAMEBUFFER_UNSUPPORTED_EXT:
            System.out.println("FBO configuration unsupported");
            break;
        default:
            System.out.println( "FBO programmer error" );
            break;
        }        
    }

    public void display(GLAutoDrawable gLAutoDrawable)
    {
        GL gl = gLAutoDrawable.getGL();
        
        gl.glBindFramebufferEXT(GL.GL_FRAMEBUFFER_EXT, frameBufferId);
        gl.glPushAttrib(GL.GL_ALL_ATTRIB_BITS);
        
        gl.glViewport(0, 0, destWidth, destHeight);
        
        gl.glEnable(GL.GL_BLEND);
        gl.glBlendFunc(GL.GL_SRC_ALPHA, GL.GL_ONE_MINUS_SRC_ALPHA);

        gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);


        gl.glMatrixMode(GL.GL_PROJECTION);
        {
            gl.glLoadIdentity();
            gl.glFrustum(-1, 1, -1, 1, 1.5, 20);
        }
        gl.glMatrixMode(GL.GL_MODELVIEW);

        gl.glColor3f(1, 0, 1);
        gl.glLoadIdentity();
        
        GLU glu = new GLU();
        glu.gluLookAt(0, 0, 5, 0, 0, 0, 0, 1, 0);
        gl.glScalef(1.0f, 2.0f, 1.0f);
        GLUT glut = new GLUT();
        glut.glutWireCube(1);
         
        gl.glFlush();

        gl.glPopAttrib();
        gl.glBindFramebufferEXT(GL.GL_FRAMEBUFFER_EXT, 0);
        
        //Save image
        ByteBuffer imgData = BufferUtil.newByteBuffer(destWidth * destHeight * 4);
        gl.glGetTexImage(GL.GL_TEXTURE_RECTANGLE_ARB, 
                0, //Mipmap level
                GL.GL_RGBA, GL.GL_UNSIGNED_BYTE,
                imgData);
        
        BufferedImage img = new BufferedImage(destWidth, destHeight, BufferedImage.TYPE_INT_ARGB);
        imgData.rewind();
        WritableRaster raster = img.getRaster();
        for (int j = raster.getHeight() - 1; j >= 0; j--)
        {
            for (int i = 0; i < raster.getWidth(); i++)
            {
                raster.setSample(i, j, 0, imgData.get());
                raster.setSample(i, j, 1, imgData.get());
                raster.setSample(i, j, 2, imgData.get());
                raster.setSample(i, j, 3, imgData.get());
            }
        }

        try
        {
            ImageIO.write(img, "png", new File("fboImage.png"));
        } 
        catch (IOException ex)
        {
            ex.printStackTrace();
        }
    }

    public void reshape(GLAutoDrawable gLAutoDrawable, int i, int i0, int i1, int i2)
    {
    }

    public void displayChanged(GLAutoDrawable gLAutoDrawable, boolean b, boolean b0)
    {
    }
    
    /** This method is called from within the constructor to
     * initialize the form.
     * WARNING: Do NOT modify this code. The content of this method is
     * always regenerated by the Form Editor.
     */
    private void initComponents()
    {

        setLayout(new java.awt.BorderLayout());

    }// </editor-fold>                        
    
    
}

19	Java Game APIs & Engines / JOGL Development / Passing variable length arrays to shaders	on: 2007-03-11 15:38:00
I'd like to write a shader to animate a system of particles. To work, I'd need to pass extra data per vertex. The problem is, the amount of data will change quite a bit depending on the current state of the program. Each vertex will need a set of n 4x4 matricies and a set of n floats to weight the matricies. The shader will then computer a weighted sum for each vertex to determine it's final position. Unfortuantley, I have no idea how to pass this information, as I wil not know in advance what n is. (Inface, n will likely change over the course of hte program). As far as I can tell, OpenGL SL will only accept fixed length information. I suppose I could try to cram everything into a texture and access it through a sampler, but this will be resolution and tricky to code. Is there any way I can pass arbitrary data to a shader?

20	Java Game APIs & Engines / JOGL Development / Display lists slow when used with textures?	on: 2007-03-07 16:22:11
I recently decided to add a skybox to my program, and was surprised how much everything slowed down. My 60fps program dropped to 23, and I spent half a day tweaking everything, thinking that it was related to texture processing. When I finally got rid of the display list that I built to render my skybox and just redrew everything directly each frame, I was amazed that my frame rate went back to 60fps. I thought display lists were the fast way to do repetative things? Granted, when I rendered my skybox without using textures, it did not hurt my framerate. But as soon as I added a texture binding to my list, my speed went way down. Am I not supposed to combine the two? Can I render my skybox in a display list? Would it save any time?

21	Java Game APIs & Engines / JOGL Development / Re: How expensive is an occlusion test?	on: 2006-12-06 12:14:22
The functionality you say is rumored for the next major release of OpenGL (OpenGL 3.0, I presume?) sounds just like what I'm looking for. Is there any estimate about when it might be released? Where could I track it's progress? Also, would you have any idea if queries could be nested? (Ie, the conditional instructions themself contain conditional instructions)

22	Java Game APIs & Engines / JOGL Development / Re: How expensive is an occlusion test?	on: 2006-12-06 02:43:02
Thanks, I'll take a look at the docs. What do you mean by a z-only pass to save fill rate?

23	Java Game APIs & Engines / JOGL Development / How expensive is an occlusion test?	on: 2006-12-06 00:56:06
I have the objects in my scene roughly sorted according to a painter's algorithm and am rendering them front to back. To speed things up, I want to first render their bounding box with writes to the color and depth buffers disabled and use a Query object to count the number of fragments that make it onto the screen. If 0 fragments are drawn, I do not draw the bounded object. While this lets me throw away a lot of geometry, every Query will require the pipeline to be flushed. Would I save more time than I loose with this technique? Is there a way to speed this up?

24	Java Game APIs & Engines / JOGL Development / Can I push shader state?	on: 2006-12-05 16:36:43
Is there some flag I can pass to glPushAttrib() that will let me push the shader I set with glUseProgram()? Or is this something that must always be changed manually?

25	Java Game APIs & Engines / JOGL Development / Re: Are all GLEventListeners on same GLContext called on same thread?	on: 2006-12-03 19:54:12
What are the chances this could change in the future?

26	Java Game APIs & Engines / JOGL Development / Are all GLEventListeners on same GLContext called on same thread?	on: 2006-12-03 16:00:48
I have several GLEventListener, all of which are attached to GLCanvases that share the same GLContext. I would like to create an object that tracks which lights are currently on (every time I enable or disable a light, I will flip a bit in this data structure), and other light data. For this to work, whenever the display() method of one GLEventListener is called, I must not be inside the display() method of any other GLEventListener attached to the same GLContext. Am I guaranteed thread mutual exclusivity while in display()? Do I need to chop my display() code in synchronized blocks?

Java Game APIs & Engines / JOGL Development / Re: Issuing GL commands outside of display()

on: 2006-11-24 10:42:29

Do you mean something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

if (glContext.makeCurrent() != GLContext.CONTEXT_NOT_CURRENT)
{
  Threading.invokeOnOpenGLThread(
    new Runnable()
    {
      public void run()
      {
        GL gl = glContext.getGL();
        //do stuff with gl
      }
    }
  );

  glContext.release();
}

Will this work? Or did you mean something else? I can't find much information on either GLConext or Threading.

28	Java Game APIs & Engines / JOGL Development / Detecting Sharing	on: 2006-11-23 15:39:28
I was just reading through some of the javadoc regarding sharing: http://download.java.net/media/jogl/builds/archive/jsr-231-beta5/javadoc_public/overview-summary.html#SHARING In light of this, how do I know if two objects have been shared? If my first GLDrawable creates a texture with name 2, does this mean a second GLDrawable will never create a texture with name 2 until the first GLDrawable releases texture 2? How does my second drawable determine what is shared and what is not?

29	Java Game APIs & Engines / JOGL Development / Issuing GL commands outside of display()	on: 2006-11-23 14:32:05
It woudl be useful to do some OpenGL work outside of the four methods defined by GLEventListener. Is there a way to define textures, vbos, shaders, etc using just by calling methods on the GLCanvas or Pbuffer? At the moment, I've created a message queue that I'm using to buffer things I want to do wwhen I'm outside of display(), and then executing all of them the next time the display() method runs.

30	Java Game APIs & Engines / JOGL Development / Sharing VBOs in multiple windows	on: 2006-11-23 14:16:40
I've used the trick of creating a Pbuffer and then passing the Pbuffer's GLContent to the constructor of every GLCanvas I create to share textures and shader objects. I'd like to share VBOs this way too, but I don't seem to be able to. At the moment, I've created a Pbuffer and added a GLEventListener to it that creates and adds the data to my VBOs in it's display() method. My GLCanvases are created with this Pbuffer's GLContext passed in their constructor. However, when I'm rendering a GLEventListener attached to my GLCanvas, all points in the VBO are treated as if they are (0, 0, 0). Is there a way to share VBOs across several windows?

Pages: [1] 2 3 ... 5

Check out our latest community projects!

Ads by Project Wonderful! Your ad here, right now: $0