Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
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  
  Loading shaders possible outside of gleventlistener's init reshape display?  (Read 1983 times)
0 Members and 1 Guest are viewing this topic.
Offline Wild Bill Kelso

Junior Newbie





« Posted 2006-02-14 07:31:43 »

I've got a shader working when I use the GLAutoDrawable parameter passed via the gleventlistener's "init" / "reshape" / "display" methods.

However, if I take this parameter and store it and try to load a shader based on some other action like a button press, it doesn't work - I have to wait and do it from within a "display" call.

I was wondering if anyone could shed some light on why it only works at those times?  It's buggin me.

Thanks in advance,

Wild Bill Kelso
Offline kylix999

Junior Member





« Reply #1 - Posted 2006-02-14 08:04:03 »

you must have active GLAutoDrawable context ,without it loading any shader fails, you probably can not just store it (i may be wrong ), in example of cg use in
jogl: ogl-demos-src 2005-12-06\jogl-demos\src\demos\cg\runtime_ogl\cgGL_vertex_example.java you can find some intresting comment:

1  
2  
3  
4  
5  
6  
7  
public void init(GLAutoDrawable drawable) 
  {
    // Note: we initialize Cg in this init() method instead of main()
   // because Cg (apparently) requires an active OpenGL context in order to
   // initialize correctly (otherwise the CheckCgError() call after
   // cgGLLoadProgram() will fail).
   


without active context you will not be able to initalize or run any shaders, shaders are close to gpu so it is not suprising that Opengl context must be active
Offline cylab

JGO Ninja


Medals: 38



« Reply #2 - Posted 2006-02-14 09:04:28 »

As for the explanation
There are several multithreading constraints while communicating with OpenGL. For one there has to be a so called OpenGL "context" in a state that allows to call OpenGL functions.

JOGL handles this constraints by providing the GLEventListener callbacks. The JOGL framework ensures, that the given GL object can successfully call the native OpenGL functions for the time the GLEventListener interface methods are executed. This is the very reason why the GLAutoDrawable object is passed as the methods argument instead of providing a gobal "getGL()" method or something.

If you store the GL object you get in the GLEventListener method, there is a good chance, that the OpenGL context is not in the right state the next time you call a method on the GL object, so your call will fail. Best practice is, not to store the GL object and implement some kind of action queue to defer OpenGL calls to the display() method. I use a simple GLAction interface for that:

1  
2  
3  
4  
public interface GLAction
{
   public void execute(GL target);
}


and store instances of them in a GLQueue singleton:

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  
public class GLQueue
{
   private static GLQueue instance = null;
   private final ArrayList queue= new ArrayList(16);

   protected GLQueue(){}

   public static synchronized GLQueue getInstance()
   {
      if(instance==null) instance= new GLQueue();
      return instance;
   }

   public void add(GLAction action)
   {
      synchronized (queue) { queue.add(action); }
   }

   public void execute(GL gl)
   {
      // make a copy of the queue to allow thread safe iteration
     ArrayList temp = null;
      synchronized (queue)
      {
         // Only make a copy, if the queue has entries
        if( queue.size() != 0 )
         {
            temp = new ArrayList(queue);
            queue.clear();
         }
      }

      // iterate outside of the synchronization to avoid blocking the queue
     if( temp!=null )
      {
         for (int i=0; i < temp.size();i++)
         {
            ((GLAction) temp.get(i)).execute(gl);
         }
      }
   }
}


so each time, I have to react to a button-press or something I add it to the queue:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public void actionPerformed(ActionEvent event)
{
   GLQueue.getInstance().add(
      new GLAction()
      {
         public void execute(GL target)
         {
            // do something gl related
        }
      }
   )
}


and execute the queue in my display-method:
1  
2  
3  
4  
public void display(GLAutoDrawable drawable)
{
   GLQueue.getInstance().execute(drawable.getGL());
}


There are mechanisms in the new JSR version of JOGL to allow for more control over context and threading behaviour, but I suggest only to touch them, if you reach expert level or really have to for some reasons Wink

Mathias - I Know What [you] Did Last Summer!
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.

Riven (7 views)
2014-07-29 12:53:52

Dwinin (7 views)
2014-07-29 10:59:34

E.R. Fleming (23 views)
2014-07-29 03:07:13

E.R. Fleming (9 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (51 views)
2014-07-17 23:47:54
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!