Mr. Pierce and I noticed that most of the parameters to the Create API are encapsulated in a Display object.
Why not pass one of the Display objects returned by the query of available modes to the Create API? It seems to make much more sense.
And we don’t have to play games to get the refresh rate 
The funniest part of it all is that nCreate takes everything else we need EXCEPT a refresh rate.
That’s a bit odd, I’m sure it had a refresh rate in there too.
We do it that way so we don’t have to wank around in JNI getting fields out of a Java object. It’s far easier to do it in Java.
Cas
If that is the best reason you can come up with then I think it should be changed.
We can can write the codes to read the Display fields once in the library, which would also be able to easily handle changes in the Display class (e.g. new fields) without users of the library changing their code at all.
The way it is now every user of the library has to dig the parameters out of the display object. The refresh rate is missing from the Create call… but if the Display object was passed, even if the refresh rate was some how missing from it, it could be added easily without breaking anything.
I vote for a API change before it is too late.
er, how old is the version you’re working with? Because I’ve just realised I’ve got no idea what you’re talking about.
Display has no create(), just a setDisplayMode method, and we’re doing it in JNI now anyway.
Cas
The Create call is not in the Display class. I’m talking about BaseGL.nCreate.
It’s really the constructors of BaseGL that should take a Display…
I’m saying it should take a Display as a parameter instead of the many params it has now… width, height, bpp, etc… (but no refresh)
Not having the refresh rate in nCreate is a problem. Since nCreate is private we can add some parameters without breaking stuff… so you could still pick out the bits of the Display that you need in Java. the main point is at that point you don’t have a Display object and it seems logical that you should.
Ah no, you’ve got it all wrong.
Display takes care of the physical characteristics of the display - that means the resolution, colour depth, and refresh rate.
GL is a subclass of Window. The GL window has some peculiar GL characteristics all of its own; it has independent colour depth, alpha depth, stencil, etc. and importantly independent dimensions. The two different constructors determine whether it’s meant to fullscreen or not but we’re not sure this is a great way to do it. Fullscreen mode is meant to be the default as windowed mode is actually a debug mode for developers - we don’t officially support windowed mode (ie. guarantee it to be available). As of course windows are not available on all conceivable platforms.
Cas
Ok… I know I’m not up to speed on programming with LWJGL, but still it is nCreate that creates the display… logically it would base some things on a Display object. Particularily when it currently is not passed a refresh rate, so the OS X code has the refresh hard coded to 60Hz.
I’m not familiar enough with the LWJGL API yet… so I’ll just ask… Where is a Display object passed back to the LWJGL APIs? Does it not make sense that selecting full screen GL display properties work that way? By passing one of the known supported Display objects to some method to create the display?
Looking at the examples (BaseWindow.java):
protected void createGLWindow(int width, int height, int bits, boolean fullscreenflag) throws Exception {
fullscreen = fullscreenflag;
try {
int mode = -1;
DisplayMode[] modes = Display.getAvailableDisplayModes();
for (int i = 0; i < modes.length; i ++) {
if( modes[i].width == width &&
modes[i].height == height &&
modes[i].bpp >= bits) {
mode = i;
break;
}
}
gl = new GL("LWJGL Example", 50, 50, width, height, bits, 0, 0, 0);
gl.create();
glu = new GLU(gl);
Keyboard.create();
Keyboard.enableBuffer();
Mouse.create();
//Mouse.enableBuffer();
resizeGLScene(width, height);
initGL();
}
catch (Exception e) {
throw new Exception("Problem initialising Lesson", e);
}
}
Notice something… the available display modes are queried, then scanned for a match… THEN IGNORED. The GL constructor is simply called with the original width, height, depth, regardless… and no refresh.
Ok, here’s my take on the API:
- The Display class cannot be instantiated, and only contains static methods to:
a) query available monitor display mode, returning an array of DisplayMode. The modes contain possible widthheightrefresh combinations.
b) Set the monitor to a specified DisplayMode, use this when going fullscreen
c) reset the monitor to the “normal” display mode in effect before lwjgl was started - The GL class which is not static (but actually it should be). An instance of this class creates an OpenGL window, whether it’s a “real” window to be used in windowed mode, or a fullscreen window with no borders. This class could very well be used without Display (especially when you want to run in windowed mode). The constructor expects width*height of the window and minimum pixel format (bpp,depth,alpha and stencil).
- The rest of the API. Input objects like Mouse and Keyboard simply uses the current OpenGL window, and OpenAL is highly independent.
So, why does create need a Display object?
(BTW, I will be very unhappy if the policy of pulling java fields from JNI is adopted, simply because the primitive types policy is so much easier to get right. I use the JNIEnv object as little as possible. In fact, I hate the current policy of setting java fields like the minimized and closed field from JNI, but I have been too lazy to fix it.)
Edit: regarding the example code that ignores display modes: That’s probably because it only wants to run in windowed mode, which doesn’t need the Display class. The code should still be removed however.
- elias
Sorry… I’ve been using ‘Display’ when I mean ‘DisplayMode’
Widowed mode is not supported… it is only a debugging tool. That much has been made clear. The OS X version will not support windowed mode at all.
Therefore all displays of any significance will be full screen. But that is still not the point.
The function that is creating the display (which will almost always be fullscreen) BaseGL.nCreate doesn’t get a needed parameter - refresh rate.
My proposed solution (before I looked too hard) was to pass in a DisplayMode (I said ‘Display’… that was my fault). I agree that it is more tedious to get object field values in the JNI code… but of course once it is done, it’s done. Either way, it doesn’t matter so much. nCreate is private and so we can change the parameters as needed.
I propose an alternative to the fullScreen flag of BaseGL.createGLWindow… Instead I suggest we pass a DisplayMode reference, which can be null. Null will mean to use the existing display… so in effect you get a window on the current display -if possible. If windowed mode is not supported and null is passed, the best fitting DisplayMode can be used… possibly making an effort to match the current refresh rate.
We can extract the refresh rate from this mode in Java and add a parameter to nCreate if that’s what everyone wants to do.
Again, I appologise if I’m just too clued out with respect to LWJGL for any of this to make sense.
Refresh rate is physical display property and has nothing to do with opengl drawing characteristics, which is what we pass into the constructor of GL.
Cas
Ok… then what do we use as the refresh rate in the native implementation of nCreate? We need to give some value to the OS routines. My whole point here is that nCreate does create a fullscreen display - but is not given enough information to do it right.
And lets fix the example code. BaseWindow is misleading at the moment, querying DisplayModes looping through them and then just ignoring that it ever did that.
I’m sorry to hear that windowed mode will be unsupported - it has recently been promoted to a “real” feature because Matzon and I pushed for it. So if you don’t mind, windowed mode on the macosx would be a nice thing to have.
Other than that - why does GL.nCreate need a refresh rate parameter? You are changing the display mode in Display, not in GL, right?
- elias
I will have to see Mr. Pierce’s latest changes. He was working getting the OS X stuff up to speed with the latest architecture on the weekend.
The code in CVS creates the display in GL.create(). Which was the basis for this thread. If all of this is changing… then perhaps the stuff I’m complaining about just goes away.
And none of the examples in CVS call setDisplayMode… so I didn’t have much to go on.
here’s a question. Why does BaseGL have any responsibility for creating native window code at all? If Window is for window functionality and Display is for Display related functionality - why is this chunk of code in nCreate in the Windows implementation?
// 1. Create a window
const char * titleString = env->GetStringUTFChars(title, NULL);
if (!createWindow(titleString, x, y, width, height, fullscreen == JNI_TRUE ? true : false)) {
env->ReleaseStringUTFChars((jstring) title, titleString);
closeWindow();
throwException(env, "Failed to create the window.");
return;
}
env->ReleaseStringUTFChars(title, titleString);
Because sometimes special treatment has to be done a window creation time for things like OpenGL to work. At least that’s what happens on linux (you have to have an OpenGL compatible pixel format before you create the window). So that makes it harder to separate BaseGL from Window.
EDIT: Yes, a lot of changes have hapened in 0.6 - in 0.5 swpalmer was right. Display mode changes and window creation both happened at once. Now, display mode change is a separate story from windows, which is exactly the way it works at the OS API level (at least on linux and win32)
- elias
I think the design of this API is somewhat lacking in this area.
It seems that BaseGL takes over responsibilities of Display and Window in some really icky ways. If BaseGL is going to create the window… should it not be interacting with the Window class?
As it is, it seems that the three classes Display, Window and BaseGL do not play nice with each other. Surely some serious cleanup and clarification should happen in this area. And the examples can be updated to do things the right way. BaseWindow.java doesn’t use Display or Window… it just relies on an apparent side-effect of BaseGL to create the window.
It isn’t a side effect - BaseGL is a window, and Window is the abstract superclass all window types will inherit. Like if we ever get to implement lwjgl2d, a Base2D class will be implemented inheriting from Window.
Display is kind of irrelevant here - it only handles the physical display modes, and has nothing to do with the rest of the system per se. TO be practical though, Display has to be used to complete the fullscreen experience - a borderless BaseGL window is created and the physical mode is switched to the same height and width.
- elias
[quote]BaseGL is a window
[/quote]
Ooops… oh yeah.
Ok… so still… like you say for a fullscreen window some interaction with Display makes sense. Why not pass a DisplayMode when you want to make a fullscreen window.
Display is not exactly irrelevant. You are always creating a Window on a Display, right?
Anyway… for the bizillionth time… for a fullscreen window we need to know the refresh rate… something needs to change somewhere, if BaseGL is going to be capable of creating a fullscreen window without ever using the methods in Display to initialize the screen.
Or in other words… what is expected if BaseGL is used to create a fullscreen window without having first called Display.setDisplayMode()? Note that the window dimensions can be passed such that they do not match those of the current screen, or ANY available DisplayMode for that matter. What happens when BaseGL is asked to create a fullscreen window with dimensions that don’t match the screen?
Ah, I finally understand the problem - BaseGL isn’t supposed to call Display - the user is. That’s why the parameters to Display.setDIsplayMode and BaseGL.create doesn’t match. The only thing BaseGL has to do is create a window of the specified size in two different modes. Borderless in fullscreen mode and with borders in windowed mode. So to fix the examples, you’d have to insert a Display.setDisplayMode(modes[i]) and use the fullscreen constructor of BaseGL.java. See the FullScreenWindowedTest in org/lwjgl/test. It can switch between fullscreen and windowed mode so it contains the correct code.
- elias