Interrupting

OpenGL Development JOGL Development
#1

I’m reasonably new to JOGL but have been using OpenGL through C++ for many years. It’s nice to finally have a 3d graphics environment and a decent GUI environment in one language for once.

I have a slight problem with interrupting drawing. It appears to ignore my attempts to through an InterruptedException when I want to stop drawing and restart with a new set. Any ideas why this might be?

Alternatively, if anyone has an example of how to generate compiled lists outside the display routine I’d be very grateful.

Dave.

#2

Ok, I finally figured out that the mouse events run in the same thread as display() so the mouse will never be able to interrupt the display() method.

Surely other people have this same problem? What happens if the user triggers an input whilst you’re building a complex scene that changes the requirements for building the scene and should cause the scene build to be aborted?

Why oh why did we abandon pre-emptive multi-tasking user interfaces…

#3

If you’re using the Animator class for continuous rendering, then the display method is not executed in the AWT thread. Also note that in this case you should not place the display call to the actual input event handler. Basically, this allows interruption of building scenes:


void display(...)
{
    if (sceneDirty)
    {
        while(!interruptedByUserFlag) // set by a custom interrupt method
        {
            rebuildPartOfScene();
        }
    }
    renderScene();
}

Cheers

#4

But what happens when display is called by the GUI thread? I did try using a separate rendering thread but it didn’t work well and required lots of work to redraw the image when the GUI required it (like after a reshape etc.). Maybe I could decide what drawing to do based on the current thread?


public void display()
{
   Thread th = Thread.currentThread() ;

   if ( th == drawThread() ) 
   {
      try
      {
         buildImageLists() ;
      }
      catch( InterruptException ex )
      {
      }
   }

   renderLists() ;
}
#5

[quote]But what happens when display is called by the GUI thread? I did try using a separate rendering thread but it didn’t work well and required lots of work to redraw the image when the GUI required it (like after a reshape etc.).
[/quote]
I see your point. The problem is that you cannot use InterruptedException to trap the user interruption, since your thread is not waiting on any I/O which could be interrupted (sockets, etc.). I would suggest that you create your own renderer so that the building of scene actually happens in a separate thread, something like the following:


public class MyRenderer
extends Thread
{
private GL gl;
private boolean renderRequested;
private boolean sceneRebuildRequested;
private boolean interrupted;

public MyRenderer(GL gl)
{
    this.gl = gl;
}

public synchronized void render()
{
    renderRequested = true;
    this.notify();
}

public void interruptSceneRebuild()
{
    interrupted = true;
}

public synchronized void rebuildScene()
{
    sceneRebuildRequested = true;
    this.notify();
}

public void start()
{
    setDaemon(true);
    setPriority(Thread.MIN_PRIORITY);
    super.start();
}

public void run()
{
    while(true)
    {
    // Wait for request
    synchronized(this)
    {
        try
        {
            this.wait();
        }
        catch (InterruptedException ignored)
        {
        }
    }

    if (renderRequested)
    {
        //renderScene(gl);
        renderRequested = false;
    }
    else
    if (sceneRebuildRequested)
    {
        // Rebuild scene in smaller pieces to allow user interruption
        //for(int i = 0; !interrupted && i < objectsInScene; ++i)
        //rebuildSceneObject(gl, i);

        sceneRebuildRequested = false;
        interrupted = false;
    }
}

}

I hope you got the idea from the crude example :).
ps. How to indent the code correctly? Aaargh, my perfectionistic eye hurts!

#6

Hi guys! :wink:

I'm facing a similar problem. I tried to program a "generic" framework for 3D games using a simple concept: entities ::). My program is based on an event system including, for example, the following messages:

  • msgOnLoad: dispatched when the game loads the entities.

  • msgOnStart: dispatched when the game starts.

  • msgOnUpdate: dispatched to update all the entities.

  • msgOnRender: […] render the entities.

  • msgOnStop: […] when the game stops.

    I don’t want my game state dependent of the frame rate, i.e. logic updates should be called wher/whenever I want, outside of this &@#% display(GLDrawable drawable) method >:( For example, in a logic update, or simply its onLoad() method an entity may have to load a texture, or an other asset requiring an access to OpenGL. Until then I felt compelled to dispatch the msgOnLoad message in the display method. But it does not please me at all :frowning:

    This difficulty is that I’ll encounter the same problem for my entites onUpdate() methods from then on they require any access to OpenGL. So I imagined me coding a scheduler and delay tasks called in display(GLDrawable drawable) method to do the stuff… NIGHTMARE ! ???

    So, is there any real mean of accessing OpenGL outside of this bloody method ?

#7

[quote]So, is there any real mean of accessing OpenGL outside of this bloody method ?
[/quote]
There’s always the initialize method :).

#8

LOL ;D

Anything else ?.. :wink:

#9

[quote]Anything else ?.. :wink:
[/quote]
Well, if you feel rebellious and really brave… you could just store the GL/GLU instances where ever you need them and use them at will. Shhh! Remember, I did not give you this hint .). A short excerpt from the short JOGL user’s guide:

“It is strongly recommended that applications always refetch the GL and GLU objects out of the GLDrawable upon each call to the init(), display() and reshape() methods and pass the GL object down on the stack to any drawing routines, as opposed to storing the GL in a field and referencing it from there. The reason is that multithreading issues inherent to the AWT toolkit make it difficult to reason about which threads certain operations are occurring on, and if the GL object is stored in a field it is unfortunately too easy to accidentally make OpenGL calls from a thread that does not have a current context. This will usually cause the application to crash. For more information please see the section on multithreading.”

Cheers

#10

Well, thank U. It seems to be a bit difficult to use threads and I’m not multi-threading god programmer ;D So I give up for this time and simply use an Animator object then call my Game.loop() method in GLEventListener.display(). First I read the Animator code in JOGL sources but I found a hack for the NVidia’s driver!.. Finally I decided to give up wirting my own animator because if using multi-threading is so tricky it doesn’t worth it! :wink:

Cheers!

(PS: Is my english correct? :))

#11

Take a look at this simple example. It shows what I was talking about in the previous post. I tried keep it as simple as humanly possible:

http://www.g0dmode.com/javastuff/jogl-simpledemo.zip

Hope this clears things up for you.

ps. Your english seems perfect to me - but what do I know, since it’s not my mother tongue either… :wink:

#12

[quote]I don’t want my game state dependent of the frame rate, i.e. logic updates should be called wher/whenever I want, outside of this &@#% display(GLDrawable drawable) method >:( For example, in a logic update, or simply its onLoad() method an entity may have to load a texture, or an other asset requiring an access to OpenGL. Until then I felt compelled to dispatch the msgOnLoad message in the display method. But it does not please me at all :frowning:
[/quote]
If you want to make your game logic update rate independent from your frame rate, it sounds like you will have at least two threads involved, one performing your game updates and one performing rendering based on the state updates of that thread. If you also want to be able to perform OpenGL tasks from the game update thread, you will either need to mediate access to the OpenGL context being used by the rendering thread, or create a new GLDrawable for your game update thread that shares textures and display lists with the rendering thread’s GLDrawable. In the game update thread’s GLDrawable you could call GLDrawable.display() once, never return from that method, and use the GL object at will knowing that the context is current and will never be freed.

There are a lot of alternative ways you could structure your application without using multithreading. One way would be to keep manual control over your main loop and call GLDrawable.display() on demand when you want to perform a render. This does have the disadvantage that you would need to defer texture loads until you called display(). However, if you’re going to use the single-threaded approach, it seems to me that you might as well just have your GLEventListener’s display() method call the rest of your application’s framework, and you would have the GL context available at all times. You could probably make a small adapter class to do this without impacting the rest of your framework.

#13

Hi everybody! :wink:

First, thank U for your replies. I was not very productive these last days. I just made my super input layer based on AWT and I avoid JInput (this API is not very clean as to me...). But I wonder if I'll be able to include gamepads management in my framework whithout JInput... Anyway, I've no money to buy a gamepad and test so the problem is solved ;D. Finally I opted for the single-thread way and call my game loop in the [b]display()[/b] method of the GL listener. This implies that FPS is the maximum rate for my game logic to update. Oh! I forgot, I've also made my wondrous schedule layer :D Now I have scheduled tasks and one is precisely for the game logic update, given a period of execution (10 ms, mom is that great? ;)). Multi-threading appears to be a complex part of software programming and I'm a bit lazy for the moment to study it properly ;) But I think I'll "throw an eye" (french expression, raw-translated in english LOL) on it in the future! For example it'll be useful for non-blocking loadings. Uh oh! Is that the part I'm working on? ;) Ok, for the moment I'll use a different thread from my current game thread and incorporate a "loading" flag in my game class with some appropriate accessors to have the game "wait" (loading screen)...

Well, that’s all for today,
I’ll give U some news about my framework because I’m convinced it’ll interest some of U :-* (I’m too lazy to create a java game project, and by the way I don’t know how to proceed to ;))

“Byyyye!” (Terry - Zelda, the Wind Waker)
“Thaaaaaank U!”

;D

TigRoO°