Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (636)
Games in Android Showcase (178)
games submitted by our members
Games in WIP (686)
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 4208 times)
0 Members and 1 Guest are viewing this topic.
Offline StrideColossus
« Posted 2008-08-20 15:15:29 »

I started a topic 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/ 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: 625
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
Offline 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: 625
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

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

Dwinin (68 views)
2015-11-07 13:29:08

Rems19 (77 views)
2015-10-31 01:36:56

Rems19 (70 views)
2015-10-31 01:32:37

williamwoles (104 views)
2015-10-23 10:42:59

williamwoles (91 views)
2015-10-23 10:42:45

Jervac_ (105 views)
2015-10-18 23:29:12

DarkCart (132 views)
2015-10-16 00:58:11

KaiHH (115 views)
2015-10-11 14:10:14

KaiHH (154 views)
2015-10-11 13:26:18

BurntPizza (167 views)
2015-10-08 03:11:46
Rendering resources
by Roquen
2015-11-13 14:37:59

Rendering resources
by Roquen
2015-11-13 14:36:58

Math: Resources
by Roquen
2015-10-22 07:46:10

Networking Resources
by Roquen
2015-10-16 07:12:30

Rendering resources
by Roquen
2015-10-15 07:40:48

Math: Inequality properties
by Roquen
2015-10-01 13:30:46

Math: Inequality properties
by Roquen
2015-09-30 16:06:05

HotSpot Options
by Roquen
2015-08-29 11:33:11 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‑
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!