Author
Topic: How to Hardware Mode (Read 11744 times)

Why should it print out "dispose" if you are actually trying to enable it? I'm not sure about the order in which you enable/disable things, but the software enabling path is definitely missing a disabling of the AWTGLRenderer (just disable it like the "normal" GLRenderer). Maybe that helps...

The AWTGLRenderer doesn't really draw anything when you are calling draw(), but it enqueues the calls to be executed in the AWT event thread dispatch instead (i.e. in the AWTGLCanvas' paint()-method). Your code works, you just don't get any repaint events for the applet, which is why nothing moves. Maybe it's not possible in all cases to schedule a repaint() from inside paint()...i'm not sure. However, i've modified your applet slightly to start an additional thread that just makes the applet repaint itself, i.e. execute your drawing code.Personally, i wouldn't do it that way, but make my own thread that does the calculations and leave the applets paint() alone. That way, you'll benefit from a feature of the AWTGLRenderer: It runs multithreaded, i.e. calculations in one thread, drawing in another (in the AWT event dispatch thread in this case). In your code, both operations happen in the AWT EDT. I haven't modified your code to work that way (i.e. move the code from paint into that thread's loop), because it requires some more work: Your mouse listeners are modifying jPCT objects directly, but jPCT isn't thread save, i.e. you shouldn't modify a jPCT object from another thread than the rendering thread. Instead, the listeners should just flag what they want to do and let the calculation thread execute the operations. Anyway, here's the modified example:

i had faced same repaint and multi-thread issue. one point you havent possibly faced yet is, repaint thing works well for simple scenes (where cpu is relatively idle) but begins to behave strange for larger scenes. it skips some frames etc. awt system may skip some repaint requests. indeed this way is almost identical to using a timer. have a look at http://www.jpct.net/forum2/index.php/topic,282.0.html thread for an early discussion of this.

for multi-threading: i also use swing/awt components. instead of passing data from awt thread to rendering thread, i decided to do all my work in awt thread. so my game loop is something like:

Thanks for the post, raft. This is one thing I want to get a better understanding of. I hate sounding like such a noob, but I have had zero experience using multiple threads. Is there any chance I could get you to post the code for an entire JApplet that uses your above loop? (something simple - doesn't have to do anything, just initialize a world and get into the game loop.) Thanks for your advice on this topic!

the loop part is almost the same as i use in karga. this way you are free to do any jPCT things in awt thread but only in awt thread. if in any other thread you need to do such things, just wrap them in a:

enableRenderer( IRenderer.RENDERER_OPENGL );Which renders onto that darn pop-up instead of the applet frame. When I try to use enableGLCanvasRender, it causes the applet to no longer refresh (and the JAVA Console doesn't show it initializing the AWTGLRenderer). Does anyone have any ideas about what I need to change? Here is the complete code for my applet, as it looks now:

The paintGL-method of jPCT AWTGLRenderer is obviously never called, so no initialization happens, therefore no message appears. However, the rest of your program is still running. I'm not sure what the reason for this is. To me, it looks like as if the canvas isn't really added to the applet or it remains invisible or something. It could also be a bug in jPCT, but i can't find one ATM. Have to tried this outside an applet in a normal application? I'll try to investigate this further tomorrow.

Ah, that's a good idea. I will try it out in an application and see if it works there. I'll also do a little more research on dynamically adding canvases, validate(), etc. to see if maybe I am doing something wrong on that part. Yes, you are right - it definitely does look like it would if the canvas were either not added or not visible. Thanks!

Please do that. I can't find anything wrong on my side...that doesn't mean that there is nothing, but if it works in an application, it's most likely an applet problem. If it doesn't work there either, we have an easier to debug test case.

As you can see, in this case, I am using keyboard inputs instead of mouse input, and only listening to keyboard input from either the canvas (when in hardware mode) or the main JFrame (when in software mode). The interesting thing about that is: whenever the application tries to switch back to hardware mode and has the problem, it stops getting keyboard inputs. That is exactly what I would expect in a case where the canvas were either not added or not visible. That's a little more confirmation of what we suspected earlier.

[UPDATE]I have been doing some various tests, and found that adding the following into paint():

buffer.enableGLCanvasRenderer();myCanvas = new Canvas(); And I'm drawing a rectangle in paint(). The canvas is drawing the rectangle fine the first time, but when I right-click (remove the canvas), then right-click again (add a new canvas), it does not refresh. Then, when paint() tries to access myCanvas.getGraphics(), it throws the "null pointer exception".

This means there is not a bug with jPCT. As you suspected, I am somehow adding the canvas incorrectly. I just can't seem to figure out what I am doing wrong, lol. I'll try digging around on some different forums to see if anyone else has had a similar problem dynamically adding and deleting canvases before. I really appreciate the help!

Apparently removeAll() prevents you from ever adding anything to the applet again later. Switching between hardware mode and software mode works beautifully!

Here is the code for the working applet, for anyone else who wants to do something similar. I think being able to dynamically switch between software and hardware mode could be a really useful feature:

Yes it does. The code for switching modes also works if you are using an application, in which case you have to include the lwjgl.jar into your classpath and point the VM to the native dll's when starting your application.