Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
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  
  LWJGL Port help needed  (Read 1776 times)
0 Members and 1 Guest are viewing this topic.
Offline gregorypierce

Senior Devvie




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


« Posted 2003-05-09 19:18:13 »

Okay I'm about mid port in the new functions but I can't find anything documented that specifies what these functions are supposed to do. I need to know what the state of the system is supposed to be after

Java_org_lwjgl_Display_init
Java_org_lwjgl_Display_setDisplayMode


Should the system be ready to render after init? If not, what is the goal of the init method? Would be nice to get something that looked like Blinn's model for trip down the graphic pipeline so I can make sure that when the system starts issuing command to rendering and change display modes and such - that it is actually ready to do so. I've been taking a look at the linux code and it appears that after init, the system still can't render. Its not until setDisplayMode is called that something can actually render to the screen (because otherwise the display doesn't have a particular mode set).

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 gregorypierce

Senior Devvie




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


« Reply #1 - Posted 2003-05-09 19:39:08 »

I also cannot tell from the interface how a Display is ever disposed of.

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 Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2003-05-10 08:14:04 »

Sorry for the tardy reply. From the Javadoc:

Quote

Initialize. This determines, natively, the current display mode and stashes it back in the mode static member.

That's exactly what Display.init() does; it is called on classload and determines the current display settings. On the native side it should construct a DisplayMode and then stash this back in the Display class.

The Display class changed considerably since you last saw it; now it is purely concerned with the physical characteristics of the screen, and has nothing to do with any windows or input any more.

Also from the Javadoc of setDisplayMode() (which provides a reasonably good specification of what the native code should be doing:)

Quote

Set the current display mode. The underlying OS may not use an exact match for the specified display mode. After successfully calling setDisplayMode() you will still need to query the display's characteristics using getDisplayMode().


And that's exactly what Display.setDisplayMode() is supposed to do; it either changes the monitor's display resolution to some other mode (which can subsequently be retrieved by the client with getDisplayMode() - it may not be the same mode as they asked for), or it will throw an Exception to say that it could not change the mode. It's therefore your choice as to whether to throw an Exception or choose a similar but available mode if the the user tries a mode which turns out not to be supported.

Of course, getAvailableDisplayModes() should be doing its level best to only return modes that the computer genuinely can display, but we know from experience that this is sometimes a bit unreliable.

Cas Smiley



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

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2003-05-10 08:15:56 »

...and being static, Display is never disposed of, unless you're feeling really rock'n'roll and throw t'bugger out the window!

resetDisplayMode() should return the display to the mode that it was in on classload.

It's not in the spec but it should be, that LWJGL returns the display to its original mode when the class is unloaded. (It does this on Win32 when java.exe exits but that's a bit loose)

Cas Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2003-05-10 08:18:10 »

Oh, and before you can actually render anything you'll need an instance of GL, which is a combined Window and GL rendering context.

And not only do you need a GL, you need to create() that GL too, and destroy() it to close the window.

Cas Smiley

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #5 - Posted 2003-05-10 08:49:29 »

Quote
...but I can't find anything documented that specifies...
what do you mean by documentation Roll Eyes

AFAIK, Display controls the display, that is the actual monitor. It is not used to draw, but rather control resolution, gamma and such stuff.

Having done some tests:
In order to draw, you just have create the GL instance (which inherits from a window).  Display does NOT have to used at all - at least on win32... Elias will probably drop by with linux results

So the system should be ready to render as soon as the GL instance has been created.

Quote
I also cannot tell from the interface how a Display is ever disposed of.

It isn't. It lives for as long as the application is running. Display is used to alter (amongst other things) the display mode - if you don't alter it, you're just running in the current display mode..

/me needs to go mow the lawn

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #6 - Posted 2003-05-10 08:50:29 »

argh, hate it when people answer the same stuff...
need to lock a thread when someone is replying  Tongue (yes, kidding, isn't doable)

Offline elias

Senior Devvie





« Reply #7 - Posted 2003-05-10 11:15:03 »

On linux it should be the same - Display only manages resolutions, while the GL object is where the real deal happens (window + gl context).

- elias

Offline gregorypierce

Senior Devvie




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


« Reply #8 - Posted 2003-05-10 14:39:22 »

Okay I see. The CGL Libs are vastly different from what you guys have to do. There is no resetDisplayMode() on OSX. When your application exits, the OS automatically reverts to the resolution it was in - anything you do is transient.

My Display core doesn't do much other than change resolution as with OSX I have to both capture the display:

   CGDisplayCapture( kCGDirectMainDislpay );

and then release the display:

   CGReleaseAllDisplays();

Because of the way this is done, I've done this in the OpenGL code as opposed to the Display code because it would lock a machine on exit since there is no way to release a display and have the opportunity to call CGReleaseAllDisplays().

As such when Display_init is done, its pretty much just a passthrough call as the OS is going to handle the stashed resolution informaiton. I'll have it mimic what you guys are doing with getting the current display mode and storing it for shits and grins but for me its unnecessary.

Display_resetDisplayMode() for me is an empty body function.

The way the API is oriented makes the way you want to deal with switching display modes extremely awkward on OSX using Core Graphic Direct Display. Setting the display mode for me means invoking:

   CFDictionaryRef displayMode;
   displayMode = CGDisplayBestModeForParametersAndRefreshRate( kCGDirectMainDisplay,
                                                               bpp,
                                                               width, height,
                                                               freq,
                                                               NULL );

   CGDisplaySwitchToMode( kCGDirectMainDisplay, displayMode );

I can't do this until I lock the display, which as stated before has to be in the GL code because I won't be able to release the display. Because of this you won't ever be able to swap the display mode properly on OSX under the current architecture because of the ambiguity of the state of the box when setDisplayMode is called. The paradigm of separating the Display stuff into one class and the GL stuff into another class makes it very difficult for me to make things work properly because CGL is so straight forward that you don't split things up that way. The flow for OSX is:

CGDisplayCapture( kCGDirectMainDisplay );
CGDisplayHideCursor( kCGDirectMainDisplay );
CGDisplayMoveCursorToPoint( kCGDirectMainDisplay, CGPointZero );
CGAssociateMouseAndMouseCursorPosition( FALSE );

   CFDictionaryRef displayMode;
   displayMode = CGDisplayBestModeForParametersAndRefreshRate( kCGDirectMainDisplay,
                                                               bpp,
                                                               width, height,
                                                               freq,
                                                               NULL );

   CGDisplaySwitchToMode( kCGDirectMainDisplay, displayMode );

CGLPixelFormatAttribute attribs[2];
CGLPixelFormatObj pixelFormatObj;
long numPixelFormats;

attribs[0] = kCGLPFAFullScreen;
attribs[1] = NULL;

CGLChoosePixelFormat( attribs, &pixelFormatObj, &numPixelFormats );

if ( pixelFormatObj != NULL )
{
   CGLCreateContext( pixelFormatObj, NULL, &contextObj );
   CGLDestroyPixelFormat( pixelFormatObj );

   CGLSetCurrentContext( contextObj );
   CGLSetFullScreen( contextObj );
}


// do LWJGL stuff

if ( contextObj != NULL )
{
   CGLSetCurrentContext( NULL );
   CGLClearDrawable( contextObj );
   CGLDestroyContext( contextObj );
}

CGAssociateMouseAndMouseCursorPosition( TRUE );
CGDisplayShowCursoe( kCGDirectMainDisplay );
CGReleaseAllDisplays();

And that's pretty much it. Help me understand how this fits cleanly in with the architecture now. It would have before, but now things are happening a lot different and that's causing some issues. It may be that the OSX APIs are now 'too' clean that all the extra steps of the other platforms is causing me trouble



Wink

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 Devvie





« Reply #9 - Posted 2003-05-10 15:58:12 »

Can't you release the display in resetDisplayMode()? Every lwjgl app is required to call it if it uses fullscreen mode switching.

- elias

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

Senior Devvie




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


« Reply #10 - Posted 2003-05-10 16:55:05 »

Yes I can. I wasn't sure if that was an optional call or not. I will use that to release the displays. This will allow me to move Display capture back into the Display core.

Thanks elias! Any chance you can kick the OpenAL OSX folks for me so I can get past their busted OpenAL framework?

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 Devvie





« Reply #11 - Posted 2003-05-10 17:15:21 »

The call is missed sometimes because on win32 the display mode is reset when the app exits. Just like the mac, but no display release is nescessary.

On linux on the other hand, the display mode switch is global, so exiting the app without the resetDisplayMode() will leave you in the resolution last set.

What problems do you have with OAL on macosx? Have you tried #openal on irc.freenode.net?

I'm really excited the mac port is finally coming along!

BTW, do you think animated hw color cursors is possible on macosx? I'm currently researching the possibilities, and it seems possible on win32 (of course) and linux from X 4.3.

- elias

Offline gregorypierce

Senior Devvie




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


« Reply #12 - Posted 2003-05-10 19:33:56 »

Unless things have changed - LWJGL was a 'draw your own cursor' environment. I turn off the OS cursor altogether. If you want one, you've got the mouse offsets and can draw any texture, 3d object, or whatever at that x,y position.

Does LWJGL native code handle drawing cursors now?

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 Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #13 - Posted 2003-05-10 20:39:21 »

Quote
Does LWJGL native code handle drawing cursors now?


Nope, but we are investigating HW cursors...

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.

rwatson462 (37 views)
2014-12-15 09:26:44

Mr.CodeIt (31 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (99 views)
2014-12-08 04:46:31

JscottyBieshaar (60 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (38 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

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
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!