Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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 renderer  (Read 2913 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2004-11-22 18:56:49 »

Haha, nearly forgot to x-post: LWJGL now appears to work just fine and dandy on the Mac, and we're not making any more API changes (fingers crossed). Get porting!

Cas Smiley

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #1 - Posted 2004-11-24 10:06:53 »

Well the port is already done and in CVS.

I'm excited that LWJGL now works on a Mac, I would like to keep the port well maintained as a viable option for Xith3D.

However, it appears the port was done on an older version of LWJGL - the "Window" class appears to have since been removed from LWJGL.  Can you please point me in the direction of some information regarding this change and how best to upgrade the code?

Thanks,

Will.

Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2004-11-24 20:23:53 »

The old org.lwjgl.Display and org.lwjgl.opengl.Window classes are now merged into one class, org.lwjgl.opengl.Display.

Initialisation and usage is trivially simple now.

One particular point of interest: if you manufacture your own DisplayModes now using the now-public constructor, you cannot get a fullscreen display. However if you use the DisplayMode.getDisplayModes() method the modes returned are usable for both windowed and fullscreen mode.

Cas Smiley

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

JGO Coder


Projects: 2


Fire at will


« Reply #3 - Posted 2004-11-26 00:08:36 »

I've hit one snag:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
William-Denniss-Computer:~/proj/xith3d williamdenniss$ java -cp classes/:third-party/lwjgl/lwjgl.jar:third-party/vecmath/vecmath.jar com.xith3d.render.lwjgl.test.HelloXh3D
java.lang.IllegalArgumentException: Number of remaining buffer elements is 0, must be at least 16
        at org.lwjgl.BufferChecks.checkBufferSize(BufferChecks.java:154)
        at org.lwjgl.BufferChecks.checkBuffer(BufferChecks.java:174)
        at org.lwjgl.opengl.GL11.glLoadMatrix(GL11.java:1102)
        at com.xith3d.render.lwjgl.CanvasPeerImpl.setGLViewMatrix(CanvasPeerImpl.java:512)
        at com.xith3d.render.lwjgl.CanvasPeerImpl.setView(CanvasPeerImpl.java:487)
        at com.xith3d.render.lwjgl.CanvasPeerImpl.display(CanvasPeerImpl.java:917)
        at com.xith3d.render.lwjgl.CanvasPeerImpl.render(CanvasPeerImpl.java:1055)
        at com.xith3d.scenegraph.View.renderOnce(View.java:591)
        at com.xith3d.scenegraph.View.renderOnce(View.java:524)
        at com.xith3d.render.lwjgl.test.HelloXith3D.<init>(HelloXith3D.java:145)
        at com.xith3d.render.lwjgl.test.HelloXith3D.main(HelloXith3D.java:82)


The code in question is:

1  
2  
3  
        // sets the OpenGL viewm atrix
       floatBuffer4x4.put(viewTrans);
        GL11.glLoadMatrix(floatBuffer4x4);


View trans is:  float[] viewTrans = new float[16];
floatBuffer4x4 is: private FloatBuffer floatBuffer4x4 = BufferUtils.createFloatBuffer(16);

And at the time of the crash, that array holds this data:
1  
 1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 -2.0 1.0


Everything looks normal to me and it used to work.

Any ideas?

Will.

Offline tom
« Reply #4 - Posted 2004-11-26 00:29:28 »

Try rewinding the buffer.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #5 - Posted 2004-11-26 02:49:42 »

Thanks.

I wounder why it worked previously?  Perhaps it didn't  :-/

Am I correct in thinking clear() (or rewind()?) should be called before the "floatBuffer4x4.put(viewTrans); " line?

Will.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #6 - Posted 2004-11-26 04:35:02 »

yep - either one. rewind is fine if you're going to overwrite all values anyway, but a clear is probably safer.
.put continues from the position - there are getters and setters that take a startindex too though.

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #7 - Posted 2004-11-26 09:02:15 »

Apologies - there are a few issues like that in there.  We caught a few of them when JCD used it for a while, but as no one else was interested in it at the time, much of the implementation remains untested. Embarrassed

All I can really say is that the bits I was able to test, that were simple enough for my Savage chipset to render, work fine.  Bit sad, really!

In particular, I'm concerned that many of the different code paths are untouched.  If you want to promote LWJGL-Xith3D as a first-class citizen of the Xith3D project, we'll need people with diverse chipsets trying it.

Hellomynameis Charlie Dobbie.
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #8 - Posted 2004-11-26 09:18:54 »

Quote
Am I correct in thinking clear() (or rewind()?) should be called before the "floatBuffer4x4.put(viewTrans); " line?


If viewTrans contains all the needed data, either would be fine.  If some of the data should be left in the buffer, rewind is what you want.

Crash course in NIO Buffers:

If you're filling a buffer with new data, get to the end of that data input and now wish something to use it, call flip().  That'll go back to the beginning, and automatically set the size of the buffer to the amount of data you just added.

If you've got a buffer containing n elements that you're about to fill with n new elements, call rewind.  This will go back to the beginning but leave the size fixed.

If you're just about to add or you've just added 3 elements of a 4-element vector (the fourth already being present), call rewind.

If you've got a data with old data in it that isn't relevant any more, call clear to start afresh.  Resets any start position or limit.

Call mark when you're at a position that you wish to return to - call reset to return there.

If none of the above make sense in any particular situation, use position(int) and limit(int) instead to directly manipulate these values.


Buffers hold a lot of state, so using them in a multi-threaded context is highly inadvisable! Grin

Hellomynameis Charlie Dobbie.
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2004-11-26 09:20:07 »

Easy enough... get all the tests up and running on a page of JNLP links and we can all go through them one by one.

Cas Smiley

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

JGO Coder


Projects: 2


Fire at will


« Reply #10 - Posted 2004-11-27 04:09:53 »

Quote
Apologies - there are a few issues like that in there.  We caught a few of them when JCD used it for a while, but as no one else was interested in it at the time, much of the implementation remains untested. Embarrassed


The LWJGL port has been a bit neglected.  I am very thankful for your effort (your name has been added to the Credits incidently, better late than never).

I too have been adding features to the LWJGL renderer without testing them (e.g. Background/Foreground).

For me, as there was no OS X port, it wasn't of great interest to me at first.  Now with the full complement of OS's supported by LWJGL, I am very interested.

Quote

All I can really say is that the bits I was able to test, that were simple enough for my Savage chipset to render, work fine.  Bit sad, really!

In particular, I'm concerned that many of the different code paths are untouched.  If you want to promote LWJGL-Xith3D as a first-class citizen of the Xith3D project, we'll need people with diverse chipsets trying it.


I'm about to commit my changes which bring the port up to date with the latest LWJGL version.  It is working - but visually it looks slightly strange on my Mac.  Hopefully we can iron out these bugs.

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #11 - Posted 2004-11-27 04:31:28 »

I've commited in my changes and the lwjgl.jar version I'm using (from the OSX release).

Try running any of the demos and you should see what I mean when I say it just doesn't look right.  I'll get some screenshots up soon.

Thanks for the NIO advise.

Will.

Offline itistoday

Junior Member




There's too much blood in my caffeine system.


« Reply #12 - Posted 2004-11-27 14:37:28 »

Quote
I've commited in my changes and the lwjgl.jar version I'm using (from the OSX release).

Try running any of the demos and you should see what I mean when I say it just doesn't look right.  I'll get some screenshots up soon.

Thanks for the NIO advise.

Will.

I just checked out the latest CVS and I don't see the mac version in the third-party folder  Huh

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #13 - Posted 2004-11-28 00:29:56 »

Quote

I just checked out the latest CVS and I don't see the mac version in the third-party folder  Huh


You will need to download it yourself for now:  http://lwjgl.org/forum/viewtopic.php?t=787

Will.

Offline itistoday

Junior Member




There's too much blood in my caffeine system.


« Reply #14 - Posted 2004-11-28 01:11:49 »

Quote


You will need to download it yourself for now:  http://lwjgl.org/forum/viewtopic.php?t=787

Will.

His site is down Sad  I'll check later i guess.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #15 - Posted 2004-11-28 02:09:56 »

probably just stale DNS:  http://puppygames.net/forums/viewtopic.php?t=821

I have posted the current problem I am having here by the way:  http://lwjgl.org/forum/viewtopic.php?t=817

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #16 - Posted 2004-11-29 10:37:04 »

The previous problem has been solved.

Wow - I am very impressed.  I just switched renderers for my game and it worked perfectly (after I found and fixed a few more buffers which needed rewinding...).  Visually, I could not tell the difference.  Speed wise the JOGL renderer was faster, however my two sample scenes were slightly different (randomly generated levels), and of course the LWJGL renderer has yet to really be optimised.

One line of code changed:
1  
import com.xith3d.render.jogl.*;


to

1  
import com.xith3d.render.lwjgl.*;


And I'm using LWJGL!  Very cool.



OK, I'm not being totally honest, I had to add a "Display.update()" after my renderOnce() - but this can be fixed.  I also had to disable my input system -- time to implement an input abstration layer for me.

My game is a pretty good test of the renderer, I have a lot of polygons, a Foreground HUD, a Background SkyBox and lighting.  I'm going to let my users chose what renderer they use.

In the not too distant future, with an input abstraction layer, the two API's should be fully interchangable.

Thank you David for your clever design, we now have a proof of concept that the abstraction works.  Thanks Charlie for your initial port of the LWJGL renderer, bar a few tweaks and bug fixes, most of the work was already done Smiley

I'll post a screen shot tomorrow.

Cheers,

Will.

Offline aNt

Senior Member




AFK


« Reply #17 - Posted 2004-11-29 11:05:46 »

nice  Grin
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #18 - Posted 2004-11-29 12:30:11 »

great!
This should also make a great benchmark between jogl & lwjgl, so that we may locate any potential bottlenecks in both implementations.

Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #19 - Posted 2004-11-29 12:43:01 »

Nice one Will!

Xith & LWJGL really do make a good match.

Kev

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #20 - Posted 2004-11-29 13:34:48 »

Fantastic news! Cheesy

Hellomynameis Charlie Dobbie.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #21 - Posted 2004-12-01 04:34:21 »

Thanks for the words of encouragement Cheesy

An update:

Display.update() no longer needs to be called manually.

I have finished the keyboard part of my generic (read: not just for xith3d) input abstraction layer and I'm quite happy with it.  Next I will add Mouse support, then javadoc everything and release.  Changing between input API's is as simple as changing a single line of code (and you get your choice of LWJGL polling or buffering).  Stay tuned.

We also need to add a bunch of RenderOptions to tweak the verious LWJGL settings.  I think LWJGL specific ones should have "LWJGL_" prepended to them, likewise with JOGL ones (should we add any).

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #22 - Posted 2004-12-06 23:44:43 »

The input abstraction layer I was talking about has now been released.

I am waiting for community feedback on the proposal to convert Xith3D's demos to use it instead of being tied to AWT.  Hopefully this will go ahead which will mean we can easily test the LWJGL renderer with all the existing demos.

Once this is out of the way, we will need to do some profiling and work out where the bottlenecks are.

Mouse input with LWJGL is vastly superior for games when compared to AWT by the way, especially for exclusive mouse mode.

Will.

Offline cascade

Junior Member




Java games rock!


« Reply #23 - Posted 2004-12-08 09:27:44 »

One question:

Is the lwjgl rendering independent of the jogl stuff ? Because I am still looking for getting multiple views up and running and at the moment I am suspecting jogl to be the source of an HotSpot error making this impossible.

Does using lwjgl in this case make sense ?

Offline tom
« Reply #24 - Posted 2004-12-08 12:49:50 »

Not only is it indepentant of jogl, it is independamt of awt. Lwjgl uses it's own native window, and you can only have one "view".

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #25 - Posted 2004-12-09 09:50:56 »

The LWJGL renderer is working very well for me.  Xith3D is providing graphics abstrcation, HIAL is providing the input abstraction.

In my code I have a simple statement:
1  
2  
3  
4  
5  
6  
            Xith3DFrame xith3d = null;
            if (renderer.equals("LWJGL")) {
                xith3d = new Xith3DFrameLWJGL(config);
            } else if (renderer.equals("JOGL")) {
                xith3d = new Xith3DFrameJOGL(config);
            }


The (abstract) Xith3DFrame is just your basic Xith3d frame which just sets up the canvas and view.  The two implementations of the frame simply add some boilerplate renderer-specific code.

My users can now chose which render to use.

Cool

Will.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #26 - Posted 2004-12-09 17:05:40 »

The thing I *really* like about this is that we can start doing side-by-side comparisons between AWT, JOGL, LWJGL, and JInput without huge amounts of pain and wondering how incredibly lopsided it all is.

Sure, they won't be fair to start off with (pandering to only the things that Xith uses/does), but the ability to render the same scene identically with the different setups with just tiny changes makes tech-comparison articles suddenly a million times more feasible.

Could help a lot with checking graphics driver bugs too...

malloc will be first against the wall when the revolution comes...
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.

ctomni231 (39 views)
2014-07-18 06:55:21

Zero Volt (36 views)
2014-07-17 23:47:54

danieldean (29 views)
2014-07-17 23:41:23

MustardPeter (32 views)
2014-07-16 23:30:00

Cero (47 views)
2014-07-16 00:42:17

Riven (48 views)
2014-07-14 18:02:53

OpenGLShaders (38 views)
2014-07-14 16:23:47

Riven (37 views)
2014-07-14 11:51:35

quew8 (33 views)
2014-07-13 13:57:52

SHC (70 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!