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.

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.

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.

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?

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.

1. 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 width*height*refresh 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 started2. 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).3. 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.

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.

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?

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?

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)

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.

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

So the only difference between fullscreen and windowed mode in terms of BaseGL.nCreate is the presence of a border on the window? E.g. decorated/undecorated?

Windows are always created on the the "current" display in whatever 'mode' the display happens to be in? If you you haven't set the DisplayMode before creating your window, then it is expected to be created on/over the desktop window?

I'll leave it to Greg to figure out how that fits the Mac way of doing things... He told me earlier that windowed mode would not be supported on the Mac. If I recall correctly he felt that it just didn't fit with how LWJGL was doing things. Maybe it can fit after all, I don't know.

So the only difference between fullscreen and windowed mode in terms of BaseGL.nCreate is the presence of a border on the window? E.g. decorated/undecorated?

Windows are always created on the the "current" display in whatever 'mode' the display happens to be in? If you you haven't set the DisplayMode before creating your window, then it is expected to be created on/over the desktop window?

Absolutely correct, with a few minor details. E.g. in windowed mode, the window is expected to cooperate with the OS. That is, being able to be moved (but not resized), correct focus, etc. Moreso, detecting that the window is minimized or being closed by the user would be nice to implement (isMinimized and isClosed).

I'll leave it to Greg to figure out how that fits the Mac way of doing things... He told me earlier that windowed mode would not be supported on the Mac. If I recall correctly he felt that it just didn't fit with how LWJGL was doing things. Maybe it can fit after all, I don't know.

That section of code isn't likely to change as Windowing mode won't be supported under CGL and I'm not going to rewrite it to work with AGL (which is what it would require). So on OSX the refresh rate will be locked to 60Hz.

Enlighten me - what's the difference between CGL and AGL? I'd guess AGL is the mac equivalent of WGL and GLX, and that CGL is some kind of "smarter" interface. But what exactly is better, and why doesn't CGL support anything else than fullscreen?

Looking through the docs it I see that AGL is the way to go to attach an OpenGL context to a window, CGL is good enough for fullscreen. AGL is primarily implement trhough CGL it seems... but I didn't see any documentation for how you would create a GL context for a window with straight CGL.. I think it is fairly complicated, as AGL supports dragging a window such that it lies across two different displays that could have different graphics controllers. That's something that I wouldn't want to emulate with only CGL, and I don't know if you can force a window on to only one display... so that is probably why you are forced to deal with AGL to let it map things to the windowing system.

Since the current Mac port is all based on CGL it would take some time to switch to AGL. I might be able to assist in that transition once everything is working with CGL... but at this stage I'm not sure how much changing to AGL will affect the current architecture.

"AGL also transparently manages renderers across multiple monitors. For example, a user can drag a window from one monitor to another despite the fact that their display capabilities may be entirely different and that they may be driven by dissimilar graphics cards with dissimilar resolutions and color depths."

Cocoa is the name of the object oriented APIs written in Objective-C.. from what I hear the Cocoa framework is quite cool, but I haven't forced myself to get used to Objective-C, so I can't say much about them.

The Java 1.4.1 JRE on Mac uses Cocoa, the 1.3.1 used 'Carbon', changing over from one APi to the other was part of what took so long to get 1.4.1 out on the Mac... but the even model in Cocoa worked much better with the Java event model etc.. and as I understand it Cocoa is the way to go to get the best OS support.

Carbon is a straight C API, not object oriented.. think of Win32. Cocoa is like MFC that doesn't suck.

One of these days I will know enough Mac stuff to determine the level of difficulty in moving from CGL to AGL in LWJGL... but maybe if we are lucky, Sun will have official OpenGL bindings and Apple will port them by then.

Cocoa is the name of the object oriented APIs written in Objective-C.. from what I hear the Cocoa framework is quite cool, but I haven't forced myself to get used to Objective-C, so I can't say much about them.

Cocoa is a higher level API for writing applications for OSX. Its Objective-C based and while its easier to build graphical GUI applications, it is completely foreign for any developer on any platform other than native OSX developers. Since others are going to be taking the leading OSX role shortly, I didn't want to force people to learn Objective-C in order to keep the OSX port up to speed.

Quote

The Java 1.4.1 JRE on Mac uses Cocoa, the 1.3.1 used 'Carbon', changing over from one APi to the other was part of what took so long to get 1.4.1 out on the Mac... but the even model in Cocoa worked much better with the Java event model etc.. and as I understand it Cocoa is the way to go to get the best OS support.

That's not correct. In order to better handle Swing and native OS graphics bindings it was desired to move over to Cocoa.

Quote

Carbon is a straight C API, not object oriented.. think of Win32. Cocoa is like MFC that doesn't suck.

Carbon is a straight C API like Win32. Cocoa is like writing applications for OSX in another language altogether. One must learn a new language and syntax to do Objective-C.

Quote

One of these days I will know enough Mac stuff to determine the level of difficulty in moving from CGL to AGL in LWJGL... but maybe if we are lucky, Sun will have official OpenGL bindings and Apple will port them by then.

The level of difficulty is moderate. You'll have to rewrite the input code and the graphics code (including using QuickDraw or something else to switch resolutions in fullscreen).

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