Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (500)
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  
  Why doesn't Create take a Display?  (Read 3040 times)
0 Members and 1 Guest are viewing this topic.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Posted 2003-05-23 15:22:12 »

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.

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #1 - Posted 2003-05-23 17:15:06 »

And we don't have to play games to get the refresh rate Smiley The funniest part of it all is that nCreate takes everything else we need EXCEPT a refresh rate.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2003-05-24 11:26:53 »

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 Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #3 - Posted 2003-05-24 15:38:43 »

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.

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2003-05-24 16:16:37 »

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 Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #5 - Posted 2003-05-24 16:42:51 »

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.

Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2003-05-26 10:38:16 »

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 Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #7 - Posted 2003-05-26 14:17:32 »

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

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
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.

Offline elias

Senior Member





« Reply #8 - Posted 2003-05-26 15:40:36 »

Ok, here's my take on the API:

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 started
2. 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.

- elias

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #9 - Posted 2003-05-26 15:59:58 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 282
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2003-05-26 16:18:54 »

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 Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #11 - Posted 2003-05-26 16:24:12 »

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.

Offline elias

Senior Member





« Reply #12 - Posted 2003-05-26 16:41:41 »

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

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #13 - Posted 2003-05-26 16:49:44 »

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.


Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #14 - Posted 2003-05-26 17:04:48 »

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  
2  
3  
4  
5  
6  
7  
8  
9  
      // 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);

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline elias

Senior Member





« Reply #15 - Posted 2003-05-26 17:59:59 »

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

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #16 - Posted 2003-05-26 18:16:46 »

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.

Offline elias

Senior Member





« Reply #17 - Posted 2003-05-26 18:50:52 »

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

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #18 - Posted 2003-05-26 19:19:05 »

Quote
BaseGL _is_ a window


Ooops.. oh yeah. Smiley

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?

Offline elias

Senior Member





« Reply #19 - Posted 2003-05-26 20:32:15 »

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.

- elias

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #20 - Posted 2003-05-26 21:03:17 »

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.

P.S. Thanks for being patient...

Offline elias

Senior Member





« Reply #21 - Posted 2003-05-26 21:35:21 »

No, I thank _you_ for being patient.

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

- elias

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #22 - Posted 2003-05-27 03:31:16 »

Quote

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.

It can fit, its just not high on my list of things to do.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline elias

Senior Member





« Reply #23 - Posted 2003-05-27 08:02:14 »

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?

- elias

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #24 - Posted 2003-05-27 13:19:52 »

You can get all the gory details here: http://developer.apple.com/techpubs/macosx/Carbon/graphics/OpenGL/opengl.html

CGL stands for Core OpenGL

AGL, The Apple GL library contains the implementation of OpenGL functions and commands specific to the Mac OS windowing system. http://developer.apple.com/techpubs/macosx/Carbon/graphics/OpenGL/AGL_OpenGL/index.html

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.

Offline elias

Senior Member





« Reply #25 - Posted 2003-05-27 16:13:07 »

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

from http://developer.apple.com/techpubs/macosx/Carbon/graphics/OpenGL/AGL_OpenGL/index.html

There's also the "green triangle" example that seems to create a windowed OpenGL app through something called Cocoa, what is that all about?

The example starts at
http://developer.apple.com/techpubs/macosx/Carbon/graphics/OpenGL/OpenGL/chap4/index.html

- elias

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #26 - Posted 2003-05-27 17:16:22 »

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.

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #27 - Posted 2003-05-29 04:24:13 »

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

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
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.

xsi3rr4x (52 views)
2014-04-15 18:08:23

BurntPizza (49 views)
2014-04-15 03:46:01

UprightPath (64 views)
2014-04-14 17:39:50

UprightPath (46 views)
2014-04-14 17:35:47

Porlus (63 views)
2014-04-14 15:48:38

tom_mai78101 (88 views)
2014-04-10 04:04:31

BurntPizza (147 views)
2014-04-08 23:06:04

tom_mai78101 (244 views)
2014-04-05 13:34:39

trollwarrior1 (203 views)
2014-04-04 12:06:45

CJLetsGame (210 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!