Support for lwjgl .92

<first post!>



Reason: Support for LWJGL .92



Classes changed: LWJGLFont, LWJGLRenderer, LWJGLTextureRenderer, LWJGLDisplaySystem,LWJGLPropertiesDialog, LWJGLTimer







Code changes:



Basicly, whenever we did Window.getWidth() a lot, I would create a class variable


  DisplayMode window=Display.getDisplayMode();



and just do

 window.getWidth();




Inside LWJGLTextureRenderer.initPBuffer(), I changed

            pbuffer = new Pbuffer(PBUFFER_WIDTH, PBUFFER_HEIGHT, 32, 0, 8, 0, 0, texture);



to:

            pbuffer = new Pbuffer(PBUFFER_WIDTH, PBUFFER_HEIGHT, new PixelFormat(32, 0, 8, 0, 0), texture);



I changed the following class inside LWJGLPropertiesDialog from:

    private class DisplayModeSorter implements Comparator {
        /**
         * @see java.util.Comparator#compare(java.lang.Object, java.lang.Object)
         */
        public int compare(Object o1, Object o2) {
            DisplayMode a = (DisplayMode)o1;
            DisplayMode b = (DisplayMode)o2;
           
            //Width
            if (a.width != b.width)
                return (a.width > b.width) ?  1 : -1;
            //Height
            if (a.height != b.height)
                return (a.height > b.height) ?  1 : -1;
            //Bit depth
            if (a.bpp != b.bpp)
                return (a.bpp > b.bpp) ?  1 : -1;
            //Refresh rate
            if (a.bpp != b.bpp)
                return (a.bpp > b.bpp) ?  1 : -1;
            //All fields are equal
            return 0;
        }
    }




to:

    private class DisplayModeSorter implements Comparator {
        /**
         * @see java.util.Comparator#compare(java.lang.Object, java.lang.Object)
         */
        public int compare(Object o1, Object o2) {
            DisplayMode a = (DisplayMode)o1;
            DisplayMode b = (DisplayMode)o2;
           
            //Width
            if (a.getWidth() != b.getWidth())
                return (a.getWidth() > b.getWidth()) ?  1 : -1;
            //Height
            if (a.getHeight() != b.getHeight())
                return (a.getHeight() > b.getHeight()) ?  1 : -1;
            //Bit depth
            if (a.getBitsPerPixel()!= b.getBitsPerPixel())
                return (a.getBitsPerPixel() > b.getBitsPerPixel()) ?  1 : -1;
            //Refresh rate
            if (a.getFrequency()!= b.getFrequency())
                return (a.getFrequency()> b.getFrequency()) ?  1 : -1;
            //All fields are equal
            return 0;
        }
    }



Inside LWJGLTimer's constructor, I removed the function call

        Sys.setTime(0);



and removed the function LWJGLTimer.setTime(long)


Inside LWJGLDisplaySystem.initSystem(), there is simply

            Display.setFullscreen(fs);
            Display.setDisplayMode(mode);
            Display.create();



Instead of testing if it's fullscreen, and if not creating an x/y and moving the window to the correct place

(can't move the windows display I believe.


I tried all test. They seem to work from what I can tell, plus the added bonus of being able to finally debug LWJGL programs in Linux.

Sounds fairly straight forward. I don’t notice any gotchas as it’s pretty much 1 to 1 changes to support the new LWJGL.



Now, since you are the first to attempt the new system I’m going to take this time to add my 2 cents on how we do this.



I like the template, and the way you lay things out.



One of the goals for me was to standardize all committed code, this included things such as formatting the code, insuring code standards etc. That’s why I propose submitting it to a single person (or a commity that can check) to check in new code, and double checking existing code that has been modified. Basically, an extra step (filtering step) before committing code to CVS, i.e. rarely will a direct CVS checkin occur (except for very minor changes or bug fixes that require little code change).



So, I propose that as Cep has done here, we discuss what will be done. People throw in what they think needs to be improved upon, changed, etc if anything. Then the work is done, then the code itself is submitted for approval to be checked in.



Another thing, by putting up the poll everyone can vote. Do we want this? I was thinking that only the devs would have a yay/nay vote, but everyone is welcome to comment.

Porting is easy, but… I want us to spend a bit more time looking at the new features available to us with the upgrade. For example, you can change resolutions now without losing your context, is this something we want to add explicit api support for? Also, the whole PixelFormat addition to texture renderer and new abilities to render to an offscreen window without having an onscreen window up. (There are many more additions, probably even some we missed in the .9 lwjgl release)



In other words, we should look at the upgrade at a level deeper than just a port.

To respond to the format of posts on this board:



I like the opening… reason, classes, etc. But not sure about all the little code snippets. For something small, posting the code here is fine, but what about large classes? If I’d had to post ClodMesh or the Particle classes, it would have been pretty ugly. Perhaps we can link to our classes instead or use cvs branching or something?



I guess most posts will not (and should not) be “I already wrote X, here’s the changes.” Especially if it is a major feature add or an architecture change. Rather it should be “I propose this change, here’s the basic idea and (some psuedo code/use case diagram/arcitecture drawing/whatever is needed to convey the idea)” Obviously some cases will not be big enough to require that, but maybe that hints that the change is small enough not to require discussion.



Also, I agree about the poll thing, why bother since we basically just need a responsible person (Mojo I would guess) to post at the end of the thread “This looks good, check it in and I’ll clean it up.” (or send it directly to him, whatever)

Any problems with sending me the code, I’ll put it up on the site, and link it? At least for the short term until a tool is in place or something?

Perhaps you should have a look here:



http://csdl.ics.hawaii.edu/techreports/03-11/03-11.html



The only drawback is, you all have to use eclipse…

I’ld like to get support for LWJGL .92 at least as a port as soon as I can. I can’t debug Linux jME programs without using .92 because of keystroke stealing. I do agree though, the new features should be implimented, but those would be a whole new post. The poll was just for giggles.




Any problems with sending me the code, I'll put it up on the site, and link it? At least for the short term until a tool is in place or something?


It's just that whenever someone has new code to add, it would be nice if the review process could begin ASAP. That doesn't mean it can get put in without going through you, it just means that the code is reviewed for a bit if you're busy with something in RL so that when you come back to check you're looking at polished ideas that can more quickly become part of jME.

I'll email you the full code when I get back home.
I guess most posts will not (and should not) be "I already wrote X, here's the changes." Especially if it is a major feature add or an architecture change. Rather it should be "I propose this change, here's the basic idea and (some psuedo code/use case diagram/arcitecture drawing/whatever is needed to convey the idea)" Obviously some cases will not be big enough to require that, but maybe that hints that the change is small enough not to require discussion.


I had thought the "What about this idea" belongs on the developer forum, and the actual code would be reviewed here.
It's just that whenever someone has new code to add, it would be nice if the review process could begin ASAP. That doesn't mean it can get put in without going through you, it just means that the code is reviewed for a bit if you're busy with something in RL so that when you come back to check you're looking at polished ideas that can more quickly become part of jME.


I'll put things up on the site and announce here as quickly as possible. If after awhile it proves to be too much of a delay we can consider other ways. This also allows me to format things consistently.

You’ll have to pry IntelliJ from my cold, dead hands!



Oh, about .92… I have to tell you I’m a bit disappointed in some of their choices, windowed mode is now almost entirely useless. Which creates a situation where it’s a pain in the ass for people (like me) use run windowed. GASP How stupid am I to want to run something windowed! Now, I understand their reasoning, it’s hard to do native windowing on all platforms… so they rely on SWT. However, I’m not too keen on distributing SWT with jME.

I think we should wait until the 1.0 release because then it would be official. It seems that 0.92, to me, is just to prepare people for the official 1.0 release.



DP

Well, Cep needs the latest version for Linux. So we have a bit of a dilemma. If anyone has any good ideas on how to handle windowed mode (can LWJGL windows be placed in AWT/Swing now?), I’d like to hear them.

My vote is we either update keep updating to the newest version of LWJGL, or we use JOGL. Sticking with an old version of LWJGL is going to really bite us in the butt when a really cool feature is implimented and having to port through 10 different versions causes lots of bugs. By upgrading with them, we can narrow down possible bugs in either LWJGL or jME. Doesn’t renase want the new version of LWJGL for off screen buffers?



One suggestion is to simply make a jME build of the latest LWJGL that centers the screen when it’s created…

Oh, don’t worry, we’ll update with each release of LWJGL, but damn they sure make it hard. We just need to figure out a solution to the windowed problem…



They say they want SWT to handle windowed mode from now on. SWT is not something I want to make jME dependant on, but, if you can put an LWJGL context into an SWT component, can you put it into an AWT component?

I thought we’re moving away from the whole AWT thing to make it possible to compile to GCJ?



Also, Orangy Tang has noticed that GCJ can compile to the GameCube platform. So it would be nice if jME can do GameCube…



DP

I’ve never had GCJ interest…

Talking to one dev on the lwjgl team, it seems enough people have complained about losing window positioning that they are debating readding it. As far as I can see, that would be the only current drawback to an upgrade. I’m all for it because of the new features I metioned earlier…



Also, I’ll have a Swing/AWT implementation ready soon I believe. :slight_smile:

in that case, im all for it, but I can’t vote (im not a developer)



DP

Let’s go ahead and support 0.92 and hope they fix the window issues soon.