Loading... |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Hi,
Is it possible to create a thread that does continuous rendering with a cached GL context? I'm trying to add PC support to my game that is using OpenGL ES for BlackBerry and Android. It's a pretty large change for me to try and support paint methods. Thanks. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
|
Sure. All you'd have to do is:
- Make sure your window is set not to erase its background (so the windowing system won't overwrite your GL graphics unpredictably) - Create a rendering thread (separate from the windowing system's main thread) - Create a GL context and make it current on your rendering thread - Render continuously in a loop ![]() However, depending on your app, you might still need callbacks. If your app is windowed instead of full-screen, you'd need a resize callback to adjust the OpenGL viewport, and a paint callback to re-render when the user drags another window across yours. But since your GL context is always current on your rendering thread instead of the windowing system's main thread, your callbacks wouldn't access the GL object directly -- they'd pass a message to your rendering thread to do it for them. |
Loading... |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Thank you for your response but I haven't been successful. I have verified that my setup is correct by getting SimpleScene found on the wiki to compile and run. When I try and render outside of the callback I get the following:
Exception in thread "main" javax.media.opengl.GLException: Unable to create temp OpenGL context for device context 0x6d0130a2 at com.jogamp.opengl.impl.windows.wgl.WindowsWGLContext.createImpl(WindowsWGLContext.java:297) at com.jogamp.opengl.impl.GLContextImpl.makeCurrentLocking(GLContextImpl.java:404) at com.jogamp.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:350) What I'm doing is the following (just the main ui thread for now): GLProfile.initSingleton( true ); GLProfile glp = GLProfile.getDefault(); GLCapabilities caps = new GLCapabilities( glp ); GLCanvas canvas = new GLCanvas( caps ); canvas.setFocusable( true ); canvas.requestFocus(); canvas.setSize( width, height ); canvas.setIgnoreRepaint( true ); canvas.setAutoSwapBufferMode( false ); Frame frame = new Frame(); frame.add( canvas ); frame.pack(); frame.setLocationRelativeTo( null ); frame.setResizable( false ); frame.setVisible( true ); frame.addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent we) { System.exit(0); } } ); GLContext context = m_Canvas.getContext(); context.makeCurrent(); Crash |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
|
Oops, looks like I spoke too soon!
I tried this myself, and I couldn't get it to work either. Without the canvas (which you can't access outside the main window thread), it seems like I can't make the context current correctly, so accessing it from another thread doesn't draw anything, and I just see a black screen. I tried in SWT and AWT, and couldn't make it work either way. I guess calling your main rendering method from inside GLEventListener.display() is the way to go -- hopefully that won't require too much change to your app. |
Loading... |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
No problem. Thanks anyway. Since my BlackBerry and Android versions queue up work, I was able to make a JOGL version that consumes in the display callback instead of a thread. It wasn't as big of a change as I thought.
|
Free forum by Nabble | Edit this page |