Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (511)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (577)
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  
  JOGL API Feedback  (Read 6457 times)
0 Members and 1 Guest are viewing this topic.
Offline gregorypierce

Senior Duke




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


« Posted 2003-06-27 02:26:26 »

First order of business - the methodology for handling resolutions sucks. That's really the best way I can describe it - sorry.

Two things that must absolutely make their way into GLCanvas or similar:

.setFullScreen( )
.setFullScreen( DisplayMode )


.enumerateAvailableDisplayModes()
- should be tied to either DisplayMode instances that come back from the standard JDK1.4 fullscreen API (then we can check and see if those modes are hardware accelerated).

The, yet other, binding to GL that I have uses the Fullscreen Mode API and lets the application choose a display mode, set to that mode, and them passes that drawing surface to the native rendering code.

These are a MUST for doing fullscreen games (or something equivalent).

Talk to me Goose!

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 Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2003-06-27 02:59:00 »

For a long time I've been unsuccessfully trying to understand how full screen support works on e.g. Windows, where some drivers apparently enable triple buffering (faster than monitor refresh rates without disabling the sync to vertical blanking) for full-screen games.  I've searched the net fairly extensively and tried to find the appropriate code in the Quake sources, but the SciTech MGL was so opaque I couldn't figure out where it bottomed out into real Windows API calls.

The JDK's built-in full screen support on Windows actually has two implementations, depending on whether -Dsun.java2d.noddraw=true is specified. Theoretically, it is a must to pass this command line flag to any Java application using OpenGL on Windows because of driver-level incompatibilities between DirectDraw and OpenGL, and the Java2D implementation uses DirectDraw for some operations by default.

The -Dsun.java2d.noddraw implementation of full-screen support uses the WinGDI API ChangeDisplaySettings and related calls, without getting DirectDraw involved. The existing component's size is changed (to the best of my recollection) and it is positioned to take up the full screen.

A few months ago I looked at LWJGL's full-screen support and saw that it seemed to pass several different flags to the window creation process than the AWT does. I'd like to do a prototype with JOGL that does similar operations and creates a window without using the AWT. The new APIs I've been thinking of would be along the lines of

GLDrawableFactory:
 DisplayMode[] getDisplayModes();
 GLDrawable createFullscreenDrawable(DisplayMode, GLCapabilities, GLCapabilitiesChooser);

The reason to avoid using the AWT's GraphicsDevice class is that you can't get enough platform-specific information from it (I've tried in the past, probably while working on GL4Java).

I don't think GLDrawable would have to change though we might want to add a sub-interface called GLFullscreenDrawable or similar which would add some methods for switching back from full-screen mode without terminating the application. (GLPbuffer does the same thing without exposing a concrete class in the public API.)

Let me know what you think about this.
Offline gregorypierce

Senior Duke




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


« Reply #2 - Posted 2003-06-27 03:36:57 »

Actually this would be great and address some of the issues expressed by some of the Linux folks who have somewhat hacky screen resolution change capabilities with AWT. You would want to solicit some assistance from the LWJGL folks from an API perspective. Even with JOGL it isn't necessary to have AWT in the mix unless you want it there (though we'd have to do some Class.forName() stuff to make the linking work). If you do something similar to a createNativeGLWindow the native implementation simply spawns a window and uses that window for rendering. That's doable but will require a little munging of the API implementation to make it work to the extent that LWJGL works since the native code compilers will barf if they run across AWT code floating around.

If I understand your question you're trying to figure out how OpenGL on Windows handles double and triple buffering? On OSX (and I believe its still the same in windows) the buffer count is simply passed into the PIXELFORMATDESC that is used to create OpenGL, thereby transparently shielding you mostly from the implementation.

The call to swapBuffers() then just moves to the next buffer in the chain. But I'm not sure I totally understand your question.

But as to your other topic... it looks like I'll have to expose my machine to the 10.3 Developer Preview sooner than I planned Smiley I better go ahead and make sure everything is in CVS...

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!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gregorypierce

Senior Duke




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


« Reply #3 - Posted 2003-06-27 13:36:52 »

GL.GL_XXXXX

This is an annoyance and the more that I type it, the more annoying it becomes Smiley Is there no way we can get rid of this unnecessary GL.GL or gl.gl semantic?

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 Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #4 - Posted 2003-06-27 14:11:45 »

Quote
GL.GL_XXXXX
This is an annoyance and the more that I type it, the more annoying it becomes Smiley Is there no way we can get rid of this unnecessary GL.GL or gl.gl semantic?


Agreed, its an annoying redundancy. Someone in the Jogl crew mentioned that it wouldn't be too tricky to get the generation of the GL etc. classes to output gl.enable() style as basic wrappers for gl.glEnable style, so theres hope yet Smiley Personally I think gl.glXXX() should be a wrapper around gl.XXX().

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline gregorypierce

Senior Duke




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


« Reply #5 - Posted 2003-06-27 17:46:34 »

Now for the moment of truth - now that we see we want to make this change, how do we effect this change. Do we have meetings, talk in a mailing list, vote, etc? Sun folks, please chime in! The weekend is coming and I have a lot that I want to get done Smiley

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 abies

Senior Duke





« Reply #6 - Posted 2003-06-27 18:52:39 »

Please look into "JOGL Exposed" thread - it was covered there.

Quote
The names were left unchanged simply because all of the existing documentation and code refers to those names, and changing them would cause unnecessary confusion.


Artur Biesiadowski
Offline Jeff

JGO Coder




Got any cats?


« Reply #7 - Posted 2003-06-28 06:19:21 »

Well the projects are very much run by the project leads (like most open source).

Until Dan, who I believe is lead ath the moment (is that right, Ken?)  checks in I'd suggest this.  Set up your workspace and dive in.  My experience is its a lot harder to turn down a "gift horse" when its already done Smiley

OR you could spend the wait time working on Mac JInput stuff...   he said, dunning for his own project Wink


JK

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #8 - Posted 2003-06-28 07:27:13 »

There is no formal policy in place but my belief is that there should be consensus among the project owners before making changes like these. I am one of the owners (as well as the first author of JOGL) and would be disappointed if such changes were made without more discussion, in particular over email.

The GL.GL_ redundancy will go away in 1.5 with the introduction of static imports. There are concrete technical reasons for not using static imports to try to eliminate the gl.gl pattern which I will be happy to detail later this weekend if anyone is interested. As I've stated before, I believe that changing the method names from glXXX will only cause confusion.

I also think these are very minor syntactical issues and that there are other more pressing things to work on, including pbuffer support on X11 and Mac OS X, implementing sharing of display lists among contexts, and thinking about full-screen support directly in JOGL.
Offline abies

Senior Duke





« Reply #9 - Posted 2003-06-28 08:14:30 »

Quote

I also think these are very minor syntactical issues and that there are other more pressing things to work on, including pbuffer support on X11 and Mac OS X, implementing sharing of display lists among contexts, and thinking about full-screen support directly in JOGL.


I agree that these things are more important overall - but, contrary to any api-wide naming change, they can be done at any point in the future, independent of each other. On the other hand, possible renaming of all methods would have to be done ASAP.

But I think we got the message - you like them this way and as it is estetic argument, not technical, there is no real point to argue. For me, case is closed Smiley

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

Senior Duke




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


« Reply #10 - Posted 2003-06-28 12:55:01 »

Yeah, that's really the reason I bring it up now. While many of us do own cool refactoring IDEs - it would be best to deal with something so close to the core code now before a lot of people start diving in and having large volumes of code to deal with. On this matter I think JOGL should follow LWJGL.

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: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2003-06-28 14:07:30 »

Hurrah Smiley

FYI there triple buffering is not available at all in OpenGL for Windows, end of story - this is due to the Windows GL/GDI layer just simply not allowing it. I don't expect it to be available on Linux either but I don't know.

Also FYI mixing OpenGL and DirectDraw / Direct3D is exceedingly bad and usually results in big trouble or the BSOD. Currently Webstart is causing LWJGL to barf on the latest ATI GL drivers which is annoying to say the least.

Cas Smiley

Offline djp

Junior Duke





« Reply #12 - Posted 2003-06-28 16:00:20 »

In regards to the conversations going on about how to make an API change.  We are in the process of finishing up some docs on how we want to run the games projects.  In this doc it will describe the process to make changes to an API.  It is _almost_ done,  just need to addess a few more issues.

That being said, Sun has a mandatory shutdown next week (thanks to this great economy of ours) so it won't be finished until the week after.

d

Offline gregorypierce

Senior Duke




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


« Reply #13 - Posted 2003-06-29 16:14:56 »

Well I'm sure most of us are either on vacation or will just be taking a well needed break next week.

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 cfmdobbie

Senior Duke


Medals: 1


Who, me?


« Reply #14 - Posted 2003-06-29 18:33:54 »

Not me.  For some reason the British don't celebrate July 4th... Grin

Hellomynameis Charlie Dobbie.
Offline gregorypierce

Senior Duke




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


« Reply #15 - Posted 2003-06-30 02:40:41 »

We're all friends now Smiley Come over to the states (Atlanta, GA specifically) and I'll buy you a beer.

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.

Longarmx (50 views)
2014-10-17 03:59:02

Norakomi (39 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (36 views)
2014-10-15 16:18:58

TehJavaDev (66 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!