Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (562)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2
1  Java Game APIs & Engines / JOGL Development / cursor on Linux? on: 2004-03-05 10:51:08
When we run apps using our system on Linux, the cursor leaves a trail as you rotate objects.  We have had a similar problem on Windows 2000 for a long time, and we turn the cursor shadow off.

Is there a way to turn the cursor shadow off on Linux?  Does this symptom show a problem we have somewhere else?

thanks
andy
2  Java Game APIs & Engines / JOGL Development / Picking issues on OSX? on: 2004-03-05 10:48:11
We're occasionally having a weird problem when picking on Mac OSX.  As we traverse our scene tree, we push names onto the picking stack.  There should be at least two names on the stack for anything drawn.  But occasionally the selection buffer reports one hit with no names in the hit record.

This doesn't seem to have a problem using JOGL on Linux or Windows.  By far, most of the code is the same as what is run by many people on Windows with our old Java OpenGL binding.  (We're adding JOGL support, not writing a new system using JOGL.)  I'm fairly confident in our selection code, and I'm pretty sure only one thread is doing any of the rendering stuff.

Is anyone aware of picking issues on a Mac, either in JOGL or underlying code?

For now, I can treat it as if nothing was picked, but it will appear as a bug in that the user will click and nothing will be selected.

Sorry I can't make a test case for this the way I did for the applet problem and the Swing problem.  Maybe I could, but I don't know what it would take.  Ours is a very complex system, and there is a lot going on in the case where we see this problem.

thanks
andy
3  Java Game APIs & Engines / JOGL Development / Re: Opinions on enhancement? on: 2004-03-05 10:35:30
I wanted to say how this has resolved for now.

We are examining paint events by looking for AWT events from the method on the Toolkit.  When we get one for the GLCanvas, we tell our viewer (the parent of the canvas) to repaint.  This has allowed us to quit changing JOGL as I've requested as an enhancement.

However, I do still think it is a mistake for the GLCanvas.paint() call to be lost when NoAutoRedrawMode is true.  There are paints that go there but don't go to the parent, and I'd rather be told about them by the GLCanvas than have to listen for the paint events.

Thanks, GKW for suggesting listening for the paint event, rather than being told by the paint method.  That works for now.  There still may be a way to do what I originally tried, where we let AWT call GLEventListener.display() and then we call our repaint, but I really would prefer only one thread going into invokeGL().

thanks
andy

4  Java Game APIs & Engines / JOGL Development / Re: GLCanvas in JFrame on OSX? on: 2004-03-05 10:26:50
Thanks, I think you're right.  Our product itself doesn't mix the two, but we do have an example appliation that does (and normally works).  We probably ought to change the example, to not encourage that practice.

thanks,
andy
5  Java Game APIs & Engines / JOGL Development / Re: JOGL applet on OSX on: 2004-03-05 10:25:03
No thoughts on this?

andy
6  Java Game APIs & Engines / JOGL Development / Re: GLCanvas in JFrame on OSX? on: 2004-03-03 18:12:21
By the way, we're using OSX 10.2, and Java 1.4.1.

andy
7  Java Game APIs & Engines / JOGL Development / JOGL applet on OSX on: 2004-03-03 18:07:25
This looks similar to the issue I asked about with a Swing application, except this is an applet and not Swing.

We're using OSX 10.2, and Java 1.4.1.

The following applet (included are my HTML file and the java file--you may have to fiddle with the HTML to get it to work) works on Windows, but JOGL fills the whole applet (not just its own part) and draws the picture at the bottom of the applet on OSX.

Is this the Apple problem I've seen mentioned before?  Gregory sometimes mentions a known bug--is this it?

The HTML:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
<HTML>
<HEAD>  

<TITLE>JOGL Applet Test</TITLE>

</HEAD>
<BODY>

<H3><HR WIDTH="400" ALIGN=LEFT>JOGL Applet<HR WIDTH="400" ALIGN=LEFT></H3>
<P>

<APPLET code="JOGLApplet.class" width=400 height=600>
</APPLET>
</P>
<HR WIDTH="400" ALIGN=LEFT>
</BODY>
</HTML>



The applet:

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  
import net.java.games.jogl.*;

import java.awt.Button;
//import java.awt.event.AdjustmentEvent;

public class JOGLApplet extends java.applet.Applet implements GLEventListener {
    
    private Button button = new Button();
    
    public void init () {
        System.err.println("In init()");
        setLayout (null);
        setBackground (java.awt.Color.white);

        GLCanvas canvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities());        
        canvas.addGLEventListener(this);
        canvas.setBounds (20, 20, 350, 340);
        add(canvas);
        System.err.println("added canvas");

        add(button);
        button.setLabel("Hi there");
        button.setLocation (20, 370);
        button.setSize(button.getPreferredSize ());
    }
    public void init(GLDrawable drawable) {}
    
    public void displayChanged(GLDrawable drawable, boolean modeChanged, boolean deviceChanged) {}
    
    public void reshape(GLDrawable drawable, int x, int y, int width, int height) {}


    public void display(GLDrawable drawable) {
        System.err.println("In display()");
        GLCanvas canvas = (GLCanvas) drawable;
    
        GL gl = canvas.getGL();
        
        gl.glClearColor(0.f,0.5f,1.f,1.f);
        gl.glClear(GL.GL_COLOR_BUFFER_BIT);
            
        gl.glPushMatrix();
        gl.glOrtho(-1.f,1.f,-1.f,1.f,-1.f,1.f);
        
        gl.glColor3f(1.0f, 1.0f, 0.0f);
        gl.glBegin(GL.GL_TRIANGLES);
        float _x = 0.0f, _y = 0.0f;
        gl.glVertex3f(_x + -0.5f, _y + -0.5f, 0.0f);
        gl.glVertex3f(_x +  0.5f, _y + -0.5f, 0.0f);
        gl.glVertex3f(_x +  0.0f, _y +  0.5f, 0.0f);
        gl.glEnd();
        
        gl.glPopMatrix();
    }
}


thanks
andy
8  Java Game APIs & Engines / JOGL Development / Re: GLCanvas in JFrame on OSX? on: 2004-03-03 10:16:23
Thanks.  A coworker tried nesting this one in different ways, and couldn't get it to work.

I'd really like to know why this works on Windows and not on the Mac.

thanks
andy
9  Java Game APIs & Engines / JOGL Development / GLCanvas in JFrame on OSX? on: 2004-03-02 17:45:34
I know you're not supposed to mix lightweight and heavyweight components.  But on Windows we've not had any problem with our viewer (extends a Panel and contains GLCanvas) in a JFrame and with a JPanel next to it in the BorderContainer.

On OSX, the GLCanvas reports its width and height as we'd expect, but the JPanel next to it gets covered up.

We made a simple testapp.  The behavior for this is different between Windows and Mac OSX.

1) Is this a bug in anything on Apple's side?
2) Is this a bug in Jogl?
3) Is this a bug in this app (using GLCanvas in JFrame)?
4) Is this some other simple bug that I'm just missing?

Here is the code for a simple testapp that reproduces it.

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  
import net.java.games.jogl.*;

import java.awt.*;
import java.awt.event.*;

import javax.swing.*;
import javax.swing.border.*;
import javax.swing.event.*;

public class test extends JFrame implements GLEventListener {
    private JButton _button;

    public test () {
        getContentPane().setLayout(new BorderLayout());
        setTitle("Using GLCanvas in JPanel");
        setSize(850, 500);

            // Border layout panel
       JPanel mainPanel = new JPanel(new BorderLayout(3, 3));
        mainPanel.setBorder(new EmptyBorder(5, 5, 5, 5));
        getContentPane().add(mainPanel, BorderLayout.CENTER);

            // UI panel
       JPanel controlPanel = setupInterface();
        mainPanel.add(controlPanel, BorderLayout.EAST);

        GLCanvas canvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities());        
        canvas.addGLEventListener(this);
        mainPanel.add(canvas, BorderLayout.CENTER);
    }

    public void init(GLDrawable drawable) {}
   
    public void displayChanged(GLDrawable drawable, boolean modeChanged, boolean deviceChanged) {}
   
    public void reshape(GLDrawable drawable, int x, int y, int width, int height) {}


    public void display(GLDrawable drawable) {
        GLCanvas canvas = (GLCanvas) drawable;
   
        GL gl = canvas.getGL();
       
        gl.glClearColor(0.f,0.5f,1.f,1.f);
        gl.glClear(GL.GL_COLOR_BUFFER_BIT);
             
        gl.glPushMatrix();
        gl.glOrtho(-1.f,1.f,-1.f,1.f,-1.f,1.f);
       
        gl.glColor3f(1.0f, 1.0f, 0.0f);
        gl.glBegin(GL.GL_TRIANGLES);
        float _x = 0.0f, _y = 0.0f;
        gl.glVertex3f(_x + -0.5f, _y + -0.5f, 0.0f);
        gl.glVertex3f(_x +  0.5f, _y + -0.5f, 0.0f);
        gl.glVertex3f(_x +  0.0f, _y +  0.5f, 0.0f);
        gl.glEnd();
       
        gl.glPopMatrix();
    }
   
    private JPanel setupInterface () {
        // The main UI panel will use a GridBagLayout with two columns.
       JPanel panel = new JPanel(new GridBagLayout());
        panel.setPreferredSize(new Dimension(400, 500));
        panel.setBorder(new EtchedBorder());

        _button = new JButton("Press Me!");
        panel.add(_button);
        return panel;
    }


    public static void main (String[] args) {
        test app = new test();
        app.setVisible(true);
    }
}


thanks
andy

10  Java Game APIs & Engines / JOGL Development / Re: New OSX build.... on: 2004-03-01 16:56:21
Whoops, sorry, my fault.  It was finding my jogl.properties file I'd set up for Linux.  (Should the build directions change in where the MacOSX jogl.properties file should go?  It says ~/Library/Java, but I think it got it from ~.)

Thanks for the pixel format stuff.  It works fine.  Will you be taking the print statement(s) out soon?

thanks
andy
11  Java Game APIs & Engines / JOGL Development / Re: Opinions on enhancement? on: 2004-03-01 16:02:21
Just wondering if I put this another way, whether anybody else will think it makes sense.

I want to use NoAutoRedrawMode (to keep AWT out of the GLContext).  But I think it doesn't make sense for GLCanvas to not report to someone when it gets a paint event.  Thus, I suggested the enhancement.

We are going to look at whether we can see the events some other way, but we're a bit concerned that we might try to miss something that calls paint() on a Canvas.  There is a PaintEvent class, but the doc says it isn't supposed to be used with a listener.  The best way for us to know that the GLCanvas got a paint event is for it to tell us.

(We have a separate thread for rendering, and don't want to call display repeatedly.)

thanks,
andy
12  Java Game APIs & Engines / JOGL Development / Re: New OSX build.... on: 2004-03-01 15:51:52
Thanks for doing this.  I just went to try it, and I can't compile anymore.  We're using MacOSX 10.2, and it does say you can't use earlier than 10.3, but I've built it a number of times before.

Did the status of whether I can use 10.2 change?

It is complaining about not finding JAWT.

thanks
andy
13  Java Game APIs & Engines / JOGL Development / Re: canvas.setGL(new DebugGL(canvas.getGL())); on: 2004-02-24 11:45:52
I usually get an Out of Memory error when I try to do something when the context isn't set up right.

If you use the debug version, it will test the state of the OpenGL error after every operation.  But the glGetError() itself seems to be an error at some points.  The method that checks this calls glGetError() repeatedly, until the error clears, and appends the errors in a string buffer.  If the glGetError() itself returns an error, it'll never clear, and the buffer just expands until memory is used up.

It seems to me that some limit on calls to glGetError() would be appropriate.  If that limit is hit, seems an error message about that would be helpful.

So look to make sure that all your OpenGL calls are only done inside GLEventListener.init() and .display() methods, when all is ready.

andy
14  Java Game APIs & Engines / JOGL Development / Re: Opinions on enhancement? on: 2004-02-20 17:49:41
Thanks, that's the sort of thing that makes the most sense to me.  I really don't think I want to add a Swing component between my Panel and the Canvas.

Looking for alternative ways to know I need to refresh may be the best idea.

That would save me from having to make changes to Jogl, the way I am now.  But it matches the existing system (which uses an old JNI OpenGL project also called jogl, which we've been extending over the years) better to have the GLCanvas.paint() call its parents paint().

Now if I could get it to not swap the buffers after calling display() on the listeners, so that I could just do a pick in that call, I'd be a bit better off.  Smiley

Thanks for your comments.

Anybody else?

andy
15  Java Game APIs & Engines / JOGL Development / Re: Opinions on enhancement? on: 2004-02-20 15:36:36
I have NoAutoRedraw set because I don't want the GLCanvas to do any Jogl stuff when paint() gets called, because it will be in the AWT thread.

Do you mean why do that in addition or instead of setting the rendering thread?  I guess I wanted to stop the AWT thread from getting any further at all.  The invokeGL method in GLCanvas is syncronized, and I'd rather AWT didn't go into that at all.  The current implementation of NoAutoRedrawMode (it might change, according to the User's Guide) stops the AWT thread at the paint() method, which is fine with me.  The Guide also doesn't build a lot of confidence in setting the rendering thread always preventing AWT from getting into rendering.


I've currently got the GLCanvas inside a class extending a Panel.  GLCanvas gets paint() calls that the Panel does not.  You're saying the JPanel would actually get those?  Any problem with having a swing component in between a Panel (my viewer) and a Canvas (GLCanvas)?

thanks,
andy
16  Java Game APIs & Engines / JOGL Development / Re: Opinions on enhancement? on: 2004-02-20 15:08:26
As far as I can tell, calling setRenderingThread with my rendering thread just means that attempts to call display() from the AWT thread won't do anything.  This seems to be a similar effect to setting NoAutoRedrawMode to true.  (It is handled in a different place, though.)

What I'm trying to do:
I don't want the AWT event thread rendering--I have a separate thread that should do the rendering.  But I do want to know when AWT thinks I need to paint, because I'm not calling display() continuously.  That's why I feel like I fall in between the two cases mentioned by the User's Guide.

If I don't make the suggested change, I can set NoAutoRedrawMode to true and call GLDrawable.display() whenever I want to render.  But because the GLCanvas is eating the paint event, I don't know when AWT is telling me I should repaint.  If I expose the window, for example, AWT calls paint() on GLCanvas, but it isn't telling me that it happened.

If GLCanvas would call its parent's paint method (which I can override) when it isn't going to display itself, then I can render when I initiate something (user rotates view) as well as when AWT initiates something (because it'll tell me it needed to paint, and I can tell my rendering thread to go do it).

Any clearer?  Thanks for responding.

andy
AVS
17  Java Game APIs & Engines / JOGL Development / Opinions on enhancement? on: 2004-02-20 10:33:32
Hi.  I created issue #63 to request an enhancement, and I'd like some opinions on it, please.  I don't know how many developers of Jogl are on the forum (vs developers using Jogl), but I'd appreciate thoughts about whether there is another way to do it, whether it makes sense, and whether there is a chance it would be done.

https://jogl.dev.java.net/issues/show_bug.cgi?id=63

Here's a summary.  The Jogl User's Guide, in the Multithreading Issues sections, mentions two ways of interacting with Jogl: rendering on demand in the AWT thread, or continuously calling display() in a separate thread.  Our system is in between, repainting on certain events rather than continuously, but using a separate thread from AWT so AWT can update controls while we're rendering.

Currently, if I set NoAutoRedrawMode to true and call display when needed, an app using our system looks fine while I'm rotating or making other updates that I know about.  But when the GLCanvas gets a paint event, I'm never told about it, because the paint method does nothing when the NoAutoRedrawMode is true.  I'd like to know about this paint event so I can redraw in this case.  I don't want to go through all the context stuff or do a swap--that will all happen when I call display after I know about the paint event.

What I've done is to make a change to the GLCanvas.paint() method.  I added an else to the condition for no auto redraw mode, where if it does not call display, it will instead call its parent's paint method.  That parent is our viewer, and we've overridden the paint method, so we'd get this call and can render.

If GLCanvas were not final, I'd extend that and override the paint() method.

This seems to me to be a small change, and if you didn't want it to be the default, could be implemented with a flag to say whether no auto redraw mode does this, say a CallParentPaint property.  I think it does add another way to use Jogl without me having to implement GLCanvas myself.

However, a lot of you have developed a lot of stuff with Jogl, and I'd like to know if I'm missing something.  Does this open up troubling issues with Jogl?  Is it unnecessary?  (If so, tell me why!)  Make sense?


If (in addition to the above) I could also call display() without a swap buffers automatically happening, I'd be all set.  This is because when I want to do a pick, I call GLDrawable.display(), get the GLEventListener.display() call with the context all set up, and then do my pick work.  I'm not updating the back buffer, and don't want to swap at the end.  Even a boolean parameter to GLDrawable.display(), saying whether to swap at the end, would help.  There are already a couple of enhancement requests related to this, so I didn't add another.

Thanks
andy
AVS

18  Java Game APIs & Engines / JOGL Development / Mac OSX pixel capabilities? on: 2004-02-11 17:42:19
Not to put pressure on whoever is responsible for these things, but trying to find out:

Does anyone know when the known issue about the hard-coded pixel capabilities for the mac will be solved?  I need accumulation bits.  My GLCapabilities does specify 16 bits for each of red, green, and blue, and that works on my Win2K machine.  But 0 bits are specified in the Mac's hard-coded pixel format.  I changed that to 48 and recompiled JOGL, and my accumulation works now.

I don't think this is related to similar Linux capabilities stuff I've read about here, but correct me if I'm wrong.

I did see a note in a Linux-related thread that said pixel choosing was being worked on.
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1074549614


thanks
andy
19  Java Game APIs & Engines / JOGL Development / Re: GL selection on Mac OS X 1.3 on: 2004-02-11 17:25:25
Take another look at the User's Guide (on the main Jogl page).  You aren't supposed to make any OpenGL calls except within the context of the calls in GLEventListener.

From the guide:
Quote
It is generally recommended that applications perform as little work as possible inside their mouse and keyboard handlers to keep the GUI responsive. However, since OpenGL commands can not be run from directly within the mouse or keyboard event listener, the best practice is to store off state when the listener is entered and retrieve this state during the next call to GLEventListener.display().


If you want to get a display() call, you can call display() on the GLCanvas, or repaint() (so that AWT will call display on the GLCanvas).

You pretty much need to decide what you're going to do when display() is called, then do it when you're told you can.  How that's supposed to work for things like reading pixels, I don't know.

An issue for you here is that you don't need the buffers to be swapped when you try to get display() to run just so you can have OpenGL correctly setup.  There have been requests to be able to turn off swap buffers.  I could see possibly having another method on GLEventListener, which would be be called to do things like what you are doing, without intending to swap.

andy
20  Java Game APIs & Engines / JOGL Development / Re: Another look at threads... on: 2004-02-09 11:31:24
Ever feel the more you know, the dumber you feel? Smiley

It didn't occur to me until today that the more complicated way I was trying to handle a separate thread rendering Jogl was causing AWT to do the swap buffers, even if I just used the GLEventListener.display() method from AWT to tell my rendering thread to start and not making any OpenGL calls while in the AWT thread.  I didn't need that swap.

So that's another reason why I'd like to see something like my enhancement request in issue #63.  Smiley

andy
21  Java Game APIs & Engines / JOGL Development / Re: JOGL on Java 1.4.2 for OSX? on: 2004-02-09 11:27:07
I wasn't able to get the CVS checkout to work until I logged in, then followed the instructions, which were updated with my name, instead of guest.

You can get source files from here as well:
https://games-binaries.dev.java.net/build/index.html

andy
22  Java Game APIs & Engines / JOGL Development / Re: Another look at threads... on: 2004-02-06 16:07:29
As I mentioned on glenn's thread, I decided I liked the idea of GLCanvas calling its parent's paint() method if it doesn't call its display() method because of the NoAutoRedrawMode.  This has allowed me to really clean up my code, and it is a lot better.

I've submitted an enhancement request (issue #63).  Don't know if it will help anyone else, but it might help Glenn as well as me, because handling rendering on your own thread while still knowing that your canvas needs to be painted seems tricky in Jogl as currently done.  (I wouldn't mind being shown what I'm missing if there's a way to do it without changing Jogl or making AWT notify me through GLEventListener.display().)

andy
23  Java Game APIs & Engines / JOGL Development / Re: building jogl on windows on: 2004-02-06 16:00:54
While I'm replying to myself, I'll answer this one.  It is the same problem that came up in another recent forum post: I was using the latest version of ant, 1.6.  When I downloaded the version mentioned in the building instructions, it worked fine.

I guess I usually assume "version X or greater" if instructions don't say that you should not use the latest version, but the directions really do say to use 1.5.3.

So, anyway, I can build fine now with ant 1.5.3.

andy
24  Java Game APIs & Engines / JOGL Development / Re: strange repaint problems on: 2004-02-06 14:46:03
Never mind, I don't want to add a method like this to the GLEventListener, because those methods are distributed using the invokeGL stuff in GLContext, and that will have some of the same thread problems.

Maybe it would be OK if it just called its parent's paint.

andy
25  Java Game APIs & Engines / JOGL Development / Re: strange repaint problems on: 2004-02-06 14:41:11
Sounds similar to what I'm looking at.

As far as I can see, calling GLCanvas.display() sets up and calls your GLEventListener.display() right then, in whatever thread you're in.  Setting the rendering thread does not mean that when you call GLCanvas.display() on the AWT thread it will switch to the other thread and call GLEventListener.display().

I've been able to get a rendering thread to start (and then call GLCanvas.display()), getting the GLEventListener.display() in the right thread.  But if I use the AWT's call to GLEventListener.display() to tell my rendering thread to go, then I start having problems with thread synchronization, plus a new issue I found in the Feb 4 nightly build.

So what I'd like to do is have AWT tell me to start my rendering thread without going through Jogl.  But GLCanvas is final, so I can't extend it to override the paint() method.  So if I initiate the rendering, I'm fine.  But if I expose the thing, the GLCanvas gets the paint, and doesn't say anything about it.  If there were another method in GLEventListener to tell me that a paint event came in, then I could start my rendering thread, which could be the only thread to talk to Jogl.

As I said on my post, I get the impression that I'm between the two expected ways to use Jogl:

* just using the AWT calls to display()
* calling display() continuously

andy
26  Java Game APIs & Engines / JOGL Development / Another look at threads... on: 2004-02-06 12:26:16
I've written about issues I'm having with a fairly complex arrangement of multi-threading with Jogl.  I want OpenGL calls on a separate thread from AWT, but I'm not planning to make calls continuously.  I end up switching Jogl back and forth between AWT calling display on paints and my rendering thread calling display when it has been told it needs to render, and it causes problems.

I could simplify a lot by not having AWT call Jogl.  What I'd like is for paint calls to allow me to tell my rendering thread to get going and call GLCanvas.display().  But GLCanvas is eating its paint calls (with noAutoRedrawMode set to true) without telling me about them.  I get redraws as I rotate my image, but not when I expose the window (for example).  I could find out about the paints by allowing the autoredraws, but then I'm back to switching Jogl back and forth and sharing it between two threads.

What I'd like is for GLCanvas to call some other method in my listener when it doesn't call display because of no autoredraws.  If it would tell me that its paint had been called, but not do the Jogl stuff, I could gig my rendering thread, and it could go call GLCanvas.display() again.

So GLEventListener could have an additional method, painted() or something, which the drawable calls instead of its own display call when not doing auto redraws.  Of course, the whole autoredraw thing seems temporary at the moment.

Does that make sense?

I'd override GLCanvas if it weren't final.  I had trouble building Jogl, but I'm tempted to try again, so I could either just get rid of final, or add in something else to let me know that GLCanvas's paint method was called.  But I'd like to not have to replace all of the GLCanvas and GLContext stuff, and use things as standardly as possible.

Anybody else using Jogl in a multi-threaded fashion, without calling display() continuously?  It seems to be in between the two ways the user's guide discusses using Jogl.

andy
27  Java Game APIs & Engines / JOGL Development / Re: swap buffers (Windows, multi-threaded) on: 2004-02-05 13:54:26
I know I'm responding to myself a lot, but if I raise the questions Huh, I like to give some answers.  Smiley

Turning off hardware acceleration messed up the colors because we typically assume accumulation buffers.  There were some available, but the default GLCapabilities assumes 0, so the capabilities with 16 accum bits were over-qualified.  I set the accum bits in the capabilties, and that works.

But I'm not any closer on the glGetError() thing or my original threading issues.  Time to make a separate testapp to show what I mean.

andy
28  Java Game APIs & Engines / JOGL Development / Re: swap buffers (Windows, multi-threaded) on: 2004-02-05 11:16:49
I'm switching between TraceGL and DebugGL, since I get different things.  DebugGL checks glGetError() more often, but crashes as it keeps appending to the same string--glGetError() doesn't seem to be clearing the error.  TraceGL doesn't hit that error, but there's an effect later, as it tries to swap buffers at the end.  It does let me look for whether I've got too many begins for the same number of ends, though--and I don't see any.

The checkGLGetError() method in DebugGL does have a check for whether it is called in between a glBegin and glEnd, and it doesn't think it has been.


So now I'm calling glGetError() at the beginning and end of each pass through my GLEventListener.display() method.  Before and after the AWT thread calls it, I get no error.  Before and after my rendering thread calls it, I get 1282 (which is 0x502, which is invalid operation).

So my three questions now are:
1) What caused that error after the last call to display (either by my rendering thread or AWT, where the last OpenGL call was to glGetError(), returning 0)?  If we were after a glBegin() and before a glEnd(), I could see getting continual errors when calling glGetError().  But the last OpenGL command that TraceGL tells me about (though on another thread) is glGetError(), with no error.

2) What changed between the September build and the current one?

3) If the glGetError() is not being called between glBegin() and glEnd(), how come it isn't clearing the error?


Any chance I'm mixing one jogl.jar file with the wrong jogl.dll file?  Are there version checks between the two?  I did search for other files, but didn't find anything in a path that I thought I'd pick up accidentally.

I tried turning off hardware acceleration, and got the same behavior in the trace.  However, the colors in my picture were all wrong.  That surprises me, as I'm used to being able to turn off hardware acceleration and get a pretty stable OpenGL.

I'm running Windows 2000, with a GeForce4, driver version 6.14.10.5216.

andy
29  Java Game APIs & Engines / JOGL Development / Re: swap buffers (Windows, multi-threaded) on: 2004-02-04 18:38:31
So I pointed my IDE to a source directory, even though I didn't build it myself, and started following Jogl through the generated code.

In DebugGL, when I call glClearDepth(), I get to a loop in checkGLGetError().  This loop is supposed to get all the accumulated OpenGL errors.  As far as I can tell, it is looping so many times (reporting invalid operation), that it eventually fills up the string buffer it is using for a message, and has an out of memory error.

Have I really put that many invalid operation errors on the thing, or is there a problem with this code?

thanks
andy

30  Java Game APIs & Engines / JOGL Development / Re: swap buffers (Windows, multi-threaded) on: 2004-02-04 17:14:10
Right after you ask a big question, you always find out something else.   Smiley

I have been switching a lot of things around, and the swap buffers issue seems to be what you get when you don't use DebugGL to find there is a problem before you get to swap buffers.  So I put that back, and I'm getting something else.  It is a java.lang.OutOfMemoryError.  That's what I seem to get when I have problem with my rendering threads, etc.  So I've got some debugging to do.  But I still wouldn't mind talking with someone who is using the rendering thread stuff at a complex level.

thanks
andy
Pages: [1] 2
 

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

The first screenshot will be displayed as a thumbnail.

BurntPizza (21 views)
2014-09-21 02:42:18

BurntPizza (15 views)
2014-09-21 01:30:30

moogie (15 views)
2014-09-21 00:26:15

UprightPath (25 views)
2014-09-20 20:14:06

BurntPizza (27 views)
2014-09-19 03:14:18

Dwinin (42 views)
2014-09-12 09:08:26

Norakomi (73 views)
2014-09-10 13:57:51

TehJavaDev (97 views)
2014-09-10 06:39:09

Tekkerue (49 views)
2014-09-09 02:24:56

mitcheeb (70 views)
2014-09-08 06:06:29
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!