JOGL in a game loop is wierd! No rendering

OpenGL Development JOGL Development
#1

It makes no sense.
JOGL renders everything within it’s display method but when I get a handle to it, it wont perform rendering.
All the GLEventListener methods have this code:


this.glDrawable = arg0;

Just like it was suggested but it still doesn’t work.


private void run()
	{
		GamePlugin game = new GameEngine();
		
		Animator anime = new Animator(canvas);
		anime.start();
		
		while(!game.isFinished())
		{
			if(frame.isVisible() && frame.isFocused())
			{
				GLDrawable gl = renderer.getContext();
				
				game.addInputs(
					listener.getMouseClick(),
					listener.getKeys()
				);
				
				game.doInput(gl.getGL(), gl.getGLU());
				game.doLogic();
				game.render(gl.getGL());
				
				listener.reset();
			}
			
			Thread.yield();
		}
		
		anime.stop();
	}
#2

I got it working but it’s a poor hack.

I passed the “game” context into the renderer class (It implements GLEventListener) and that class is calling the game methods except for the “addInputs” method inside GLEventListener’s “Display” method.

Here is my ugly hack.


public void display(GLDrawable arg0)
	{		
		arg0.getGL().glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);
		arg0.getGL().glLoadIdentity();
		
		if(plugin != null)
		{
			if(plugin.hasStarted()) {
				plugin.doInput(arg0.getGL(), arg0.getGLU());
				plugin.doLogic();
				plugin.render(arg0.getGL());
			}
		}
	}
#3

In the JOGL library (although this will change in the JSR-231 APIs) the only means of interaction with OpenGL is through the GLEventListener interface. This means that you have to force JOGL to call your GLEventListener’s display() method by calling GLDrawable.display(). In your example you don’t need an Animator, but you do need to register a GLEventListener with the GLCanvas so that you can call game.render(gl) from your GLEventListener’s display() method. You can call GLCanvas.display() directly from your game loop.

This may seem confusing but it seems to be the best way of interacting with a window system (AWT/Swing) where the underlying window can be removed from the widget hierarchy and added again at any time. Please see the JOGL demos for examples of how to structure applications. The Gears demo is the simplest; the JRefract demo shows how to animate multiple GLDrawables from one thread. The HWShadowmapsSimple and InfiniteShadowVolumes demos show how to redraw the canvas only when necessary, keeping CPU usage to a minimum.

#4

I’ve just looked through the Gears demo and it implements the same ugly hack that I came up within 2 minutes.
So I guess this is an issue with JOGL at this moment.

Thanks.

#5

Hi, I don’t understand why you call this a hack…
It’s a way of doing things and it may not be the most used in games programming but it’s not so awful, don’t you think?

#6

Flexibility is key in any game.

Being forced into a design is not a good thing.
It’s a semi implementation that forces you to change your design just so it can work. This is why I call it a hack.

#7

Okay guys, I’ve decided to work WITH the design rather than against it.

Main initialises the canvas, frame and the GLEventListener class.
The GLEventListener class instantiates the game class.


public void init(GLDrawable arg0)
	{
		this.gl = arg0;

                 ...
		
		//game init
		this.game = new RunGame(this.gl.getGL());
	}

The game loop is executed like this:

	public void display(GLDrawable arg0)
	{
		this.gl = arg0;
		
		gl.getGL().glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT);
		gl.getGL().glLoadIdentity();
		
		game.run(gl.getGL());
	}

Best design I could come up with.

#8

Well I use the same kind of design and so far I’m quite happy with it…
I Hope it will work for you.

#9

So far it works fine.
Written a fragment program with the design just to test it out.

It’s in OT. :slight_smile: