Prerelease of LWJGL 0.7

OpenGL Development
#1

This is just a small notice to notify you guys that a prerelease of 0.7 has been released!
get it while it’s hot:
http://www.lwjgl.org/

#2

Just to confirm - you create an instance of GL with the specification of the window you require in the constructor and create() it, then use static methods to make your usual OpenGL calls, then destroy the instance when you’re done?

And the LWJGL-specific methods (tick, paint etc) are called on the instance you’ve created, not statically on the class?

I think I’m a little confused here… ;D

#3

That particular problem might be my doing. Matzon completely agrees with you (he can’t defend himself in his next week of vacation).

My reasoning is this: the static gl calls are on the current gl context, and the current gl context can either be a Pbuffer or a gl window. For me, it’s irrelevant that there can only be one window at a time. Massive critics will probably change my oppinion though in time for 0.7 final. So in my view, the gl window should be in a separate class, not along with the gl calls.

  • elias
#4

I was siding with Matzon on this one because it’s more consistent with the other APIs but I’m coming round to the idea of the window being a separate entity from GL.

Cas :slight_smile:

#5

I think I like what Elias is saying here. Let me just make sure I get it.

I think what you’re saying is CoreGL should no longer extend Window. That in fact the process would look something like this:

– Pseudocode –


  Window w = new Window(x, y, width, height, pixeldepth);
  GL.setContext(w);
  
  while(appIsRunning) {
    GL.drawABunchOfShit();

    w.paint();
    w.tick();
  }

Actually, it seems to me that a system like this could have multiple windows if it wanted to. But maybe I’m way off base here. Elias?

Paul

#6

Not quite. Here’s what I’m saying:

The inheritance tree is right now:

Window<-BaseGL<-CoreGL<-GL
Pbuffer

What I want is something like:

Window<-BaseGL(probably named GLWindow or something)
Pbuffer
CoreGL<-GL

Thereby making the gl function set (CoreGL, GL) a separate structure from the possible gl contexts (Pbuffer, BaseGL). The reason Window exists is because of Cas’ and Matzon’s wish to create a LWJGL 2d window someday. Like this:

Window<-BaseGL
<-Base2D

Window therefore contains the window specific handling, like message loops and abstract methods like paint() and tick().

Allowing multiple windows would not be that hard really, but I’m not sure we want to go that way, design-wise. After all, who need two GL windows anyway? 99% of the time you want multiple windows, you really want multiple contexts in the same window, maybe mixed with some swing.

  • elias
#7

Ah, I see. What’s confusing currently is that GL has both the static methods and a constructor. That definitely should change one way or the other. And personally, I like the idea of the static methods being separate from the Window object.

Paul

#8

Plenty of people “need” more than one window… but they’ll be using JOGL :smiley: We’re trying to design a system that’ll work on everything from a phone through to a PC without horrid kludges.

The new heirarchy you’ve outlined is much more sensible now we’ve ditched the GL-is-an-object idea, which is why it grew into the strange shape it did in the first place.

Cas :slight_smile:

#9

The line that’s currently annoying me is:

if(gl.isMinimized())

I mean, logically that make no sense at all. Probably worth splitting the two up just to avoid “Huh?!” moments like that.

Ach, I’m sure it’ll all work out in the end. I tend to adapt quite quickly… ;D

Edit: Typo