Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (600)
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  
  Nasty design constraints when using AWTGLCanvas  (Read 3655 times)
0 Members and 1 Guest are viewing this topic.
Online StrideColossus
« Posted 2008-08-20 15:15:29 »

I started a topic http://www.java-gaming.org/topics/jogl-design-issues/19099/view.html in the newbies forum which pointed me towards AWTGLCanvas.  Having had a play with this canvas class I've got a couple of further questions which are probably best raised in this forum:

First a little background:  I'm designing and implementing an engine that is OpenGL agnostic, i.e. it handles the generic side of a 3D application: models, texture blending, vector maths, etc.  The engine defines a set of interfaces that a specific OpenGL library implements to handle rendering, lighting, texturing, etc.  I've got two implementations, one for JOGL (largely incomplete) and another for LWJGL (largely done Smiley).

The LWJGL implementation initially used the Display class to create the window and Keyboard/Mouse to handle input.  Once I started on the JOGL version I realised that I'd been re-inventing the wheel to some extent - it would much nicer to use standard Java APIs for creating the frame and keyboard/mouse handling, which is why I ended up looking at AWTGLCanvas.

But having altered the LWJGL library to use AWTGLCanvas I've realised that it's screwing the engine architecture and I don't like it.

Like most applications, the engine sets everything up then starts a rendering loop that redraws the scene, updates the game and swaps the buffers:
- open the display
- init the application (build the scene-graph, load models, texture images, etc)
- setup input devices handlers
- rendering loop:
    1. update context (timing, etc)
    2. render scene
    3. swap buffers
    4. update game

But this approach won't work with the AWTGLCanvas.  I (perhaps naively) expected I could just leave the engine as it is and change step 3 above to invoke repaint() on the canvas.  Oh no - null-pointers all over the place.  It appears that the LWJGL context is only created in the paint() method ( Undecided!) of the canvas, and is not valid outside of that method.  Why?  You don't need to be concerned with this context notion when using the Display approach, the GL APIs are globally available.

This forces me to sub-class the canvas, put the initialisation code in initGL() and the scene code in paintGL(), or at least call back to the engine to do it.  I can understand why this is as it is, the developer followed the AWT/SWING paradigm.  It's bad design but that's the way the AWT/SWING developers decided to do things - deal with it you might say.

But I'm not giving in just yet, so:

1. Is what I've written above correct?  i.e. the GL APIs are not available outside of this loop.

2. If so, why?  It works when you use the Display approach.

3. Is there anyway I can get access to the GL APIs outside of the painting loop such that my engine remains largely as it is?  Or am I going to have to start the rendering loop and then wait for the initialisation and painting 'callbacks' from the canvas?

4. As a small aside - should I be using AWTGLCanvas and standard Java APIs for display modes, input devices, etc. in a real-world LWJGL application anyway, or should I be using the Display/Keyboard/Mouse approach?  What is the general approach used out there?

I hope this makes some sense.  Cheers in advance for any suggestions.
Offline jezek2
« Reply #1 - Posted 2008-08-20 15:32:44 »

Hi, there is also another approach introduced in LWJGL 2.0rc1. It allows to embed Display in Canvas, see the Display.setParent method, there is also example in LWJGL sources in src/org/lwjgl/test/opengl/awt/DisplayParentTest.java. It works exactly like Display including input handling Smiley The only drawback is that you can have only one Display at once.
Offline princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2008-08-20 15:42:27 »

Yep, AFAIK we're deprecating AWTGLCanvas in favour of Display.setParent().

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online StrideColossus
« Reply #3 - Posted 2008-08-20 16:13:20 »

OK that sounds a nicer approach, I'll give it a whirl.

Ta  Grin
Offline EgonOlsen
« Reply #4 - Posted 2008-08-21 10:32:40 »

Yep, AFAIK we're deprecating AWTGLCanvas in favour of Display.setParent().
But the AWTGLCanvas allows for multiple instances at a time, while Display.setParent() doesn't. That's great for editors and similar applications that offer multiple viewports. People are actually using this feature. Deprecating it isn't a good idea IMHO.

Offline princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2008-08-21 11:01:01 »

Ah maybe I jumped the gun a bit there then. Forgot about that. setParent() is just so cool Smiley

Cas Smiley

Online StrideColossus
« Reply #6 - Posted 2008-08-21 11:13:15 »

From what I've seen so far (and bear in mind I'm quite new to this - hence this thread) both have their place.  The new setParent() should make integration of a 'real-world' application/game with AWT/SWING much nicer, whereas AWTGLCanvas is ideal for demos, editors, etc. and has the benefit supporting multiple instances.
Online StrideColossus
« Reply #7 - Posted 2008-08-22 16:44:40 »

For anyone that's interested in my conclusions...

Display.setParent() works sweet - it means that for both the 'real-world' case (using the Display approach, generally full-screen) and the AWT/SWING case (using AWTGLCanvas, windowed for editors, demos, etc) I've only had to make minimal changes to the architecture of my engine, which is nice Smiley

Cheers for all the advice.

- chris
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.

rwatson462 (29 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (40 views)
2014-12-09 22:41:13

BurntPizza (75 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (47 views)
2014-11-29 21:32:03

toopeicgaming1999 (113 views)
2014-11-26 15:22:04

toopeicgaming1999 (100 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!