Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  To LWGL or not to LWGL? That's the question  (Read 5797 times)
0 Members and 1 Guest are viewing this topic.
Offline Java Cool Dude

Senior Member




Java forever


« Posted 2003-10-25 07:01:04 »

^
What's the pros of LWGL?
Is it any faster than JoGL?
Is there reason for a JoGL coder such as myself to switch to LWGL?
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-10-25 20:25:38 »

LWJGL pros:

  • It's small. Really really small. You can ship 3 platforms' worth of code in well under a meg.
  • We use Buffers in a particularly intuitive way in keeping with the whole Buffer API. They're secure and fast.
  • Our methods are static. That's because they are static methods. We switched from the JOGL style instance methods because it's wrong. When static import arrives in 1.5, you'll want our babies.
  • It's proven! It really works! Flawlessly! We've got a "flagship" app Alien Flux wot works on Linux, Windows, and now MacOS X (albeit in alpha), and it's released! And Tribal Trouble's going to take it that bit further.
  • It's been in development for a good long time, constantly, and we're determined to keep it in very focused development to solve real world game problems.
  • We cut out a lot of cruft that's inefficient, outdated, or just Wrong In Java, saving you from the trouble of discovering this for yourself.
  • We're generally less bug-prone being small and focused, and when we find a bug, we fix it - fast.
  • It's still dead easy to port from JOGL to LWJGL and vice-versa. By no means is it a one-way ticket.


LWJGL cons:
  • If Elias gets run over by a bus tomorrow the Linux and Mac ports will stall for a few days whilst we find another Dane to take it over  Grin
  • Danish bacon is bad for pigs! The poor things are farmed in horrible batteries before being cured and sliced up and exported to the rest of the world to undercut local pork farms. Support your local farmers! Down with the Danes!
  • No-one really knows where Denmark is. Go on - ask an American where Denmark is, without looking at a map.

    Cas Smiley

Offline Mojomonkey

Senior Member




ooh ooh eee eeee


« Reply #2 - Posted 2003-10-25 20:35:16 »

Quote
No-one really knows where Denmark is. Go on - ask an American where Denmark is, without looking at a map.


It's that Island where good porn comes from isn't it? North somewhere, where everyone is blonde... damn, you're right.

Don't send a man to do a monkey's work.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #3 - Posted 2003-10-26 07:49:56 »

From my point of view:

Other pros:
  • The API is much smaller than JoGL, making it easier to comprehend as a whole.
  • For the newbies: no AWT experience required, and less Java knowledge required in general.
  • Setup/initialisation code is so much less than with JoGL.
  • Static classes are a lot nicer than passing GL references into every single function, or storing them on every single class.  LWJGL 0.6 used to work that way, thank God things changed.
  • Core dev team are very quick at providing fixes: most posts saying "XXX is broken" are replied to within a day with "XXX now fixed", instead of opening issues, assigning people to work on them etc.  (Note: this isn't necessary a bad thing about JoGL, but it is a good thing with LWJGL)

Other cons:
  • No AWT integration.  You can't mix your Java2D with LWJGL.
  • Smaller community, so fewer image/model loaders etc.  Not as much example code as JoGL provides.
  • Documentation is a little stale.

As a whole, I'm very happy with it right now.  YMMV, of course!

Hellomynameis Charlie Dobbie.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


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

Haha, the docs are awful, and it's probably my fault because I've been promising to do them for so long!

I'd just like to clarify a subtlety about the AWT:

The LWJGL is independent of the AWT. They can both coexist happily. You can use the AWT to do things and then render them using LWJGL if you like - font building and glyph layout spring to mind; I'm doing just that for a realtime TV graphics system right now using LWJGL and AWT together. Just remember that there is no automatic interaction between the two - you can't paint AWT stuff with into LWJGL window, and you can't paint LWJGL stuff into AWT windows. But there's no harm in shuffling BufferedImages between the two.

Cas Smiley

Offline Middy

Junior Member




Java games rock!


« Reply #5 - Posted 2003-10-26 13:16:07 »

danes rule

DTS is being coded in it and will ofcourse beat everquest Smiley

When do I get my makeMyGameAsILike() extension?
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2003-10-27 08:21:46 »

DTS?

Cas Smiley

Offline Middy

Junior Member




Java games rock!


« Reply #7 - Posted 2003-10-27 08:34:14 »

actually that was our working title (dont ask)

Its called
Extorris -Dead Man Walking

Extorris is latin for exiled, we realy wanted "xiled" but its a widly used name and there is no .com  domain avaliable.

The game is a MMOG. Currently we have a running server a 3d engine and alot of game objects. I am struggling learning  opengl enough to extend the engine as our needs becomes more clear.

Anyhow you probably dont care., about that. LWJGL is easy to use even though badly documented(lucky we have all the C++ examples).

I still need to bash a few heads in though, because when we upgraded from 0.4 to 0.7 we got almost a 1000 errors. :-(




When do I get my makeMyGameAsILike() extension?
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2003-10-27 10:48:46 »

Hah, yes, we made a major change in our API at 0.7 which put our cards on the table.

Cas Smiley

Offline whome

Junior Member




Carte Noir Java


« Reply #9 - Posted 2003-10-27 18:12:33 »

Is LWJGL implented a proper windowed mode? If I can remember right it was more fullscreen api but had some windowed mode plans in horizon.

ps: shame I still cannot run AlienFlux in my G400 suxor card. Ive tried most of the JOGL nehe ports and only few of them refuse to work.

All Blitz3d/DarkBasic/3DState demos work ok but probably due to a DirectX support.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2003-10-27 18:29:10 »

The latest AF works on the G400. However, as I say to any customers who can't get their old sucky card working - if you go out and buy a GeForce or Radeon, all you have to do is tell me what you bought in the end, and I'll treat you to a free copy of Alien Flux.

Windowed mode is still officially debug mode. It behaves nicely on Windows, allowing you to minimize and drag and close the window. Linux works too but has a couple of issues with keyboard focus. Mac can't yet do windowed mode.

Cas Smiley

Offline vrm

Junior Member




where I should sign ?


« Reply #11 - Posted 2003-10-29 10:38:41 »

other pro :

try to switch video-mode and make fullscreen with AWT/Jogl in Linux (it's doesn't work).
LWJGL provide you a simple & working fullscreen window without the awt/swing bloat  Grin
Offline Mac_Systems

Junior Member




I love my Java


« Reply #12 - Posted 2003-10-29 11:04:30 »

well,

the Mac port is allready in alpha state i know. How good the performance on Mac will be (apx.) ? Also im interested in some do and don'ts on Mac ...

- jens


The Network is the Music
http://www.mac-systems.de
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2003-10-29 12:12:00 »

The Mac performs as well as the PC and Linux versions I believe. In part this is helped by the fact that most Macs capable of running it in the first place already have processors and RAM at twice the minimum specs.

If I actually get Mac customers I'm going to ringfence the money and buy a development Mac with it.

Cas Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #14 - Posted 2003-10-29 16:07:09 »

Cas, you should get the latest Mac port bundled up and post a message to mac-games-dev@lists.apple.com  (you will need to sign up first).   The guys on that list frequently post requests to beta test new games and it might help spread the word in the Mac community.  When you have something easy for user to install (see the link I provided in the Mac Alien fluc thread - it is easy to set up a app bundle that is simple drag and drop to install) try to get Apple to host a link to it at: http://www.apple.com/games/
or
http://www.apple.com/downloads/macosx/

I've seen other shareware titles there, it's not just stuff from EA and the likes.

My gut feeling is that every Mac user that downloads the demo you will get more buyers from Mac users vs. PC.  Mac users had to pay a premium to get a Mac.. so I conclude that they are less cheap ;-)

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2003-10-29 16:19:21 »

We're working on sorting out all the strange glitches in the Mac port of LWJGL. They've really gone out of their way to make Java fiddly on OSX!

Cas Smiley

Offline swpalmer

JGO Coder




Where's the Kaboom?


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

Well with regards to interacting with the window system.. it is much different from other platforms, probably due to the fancy OpenGL based UI that OS X uses.  (Which is really sweet for impressing your wintel friends Smiley)
Maybe in Longhorn (next generation of Windows) where I hear the desktop is DirectDraw/Direct3D based we will have some of the same headaches?

The keyboard issues are odd.. I was under the impression that 10.3 was supposed to fix a lot of that.  The HID code seems a tad unpolished from what I've heard.

Using standard Swing UIs I have found that my Java apps work fine on OS X, Windows and Linux...  The mess is always with the native side.

Offline whome

Junior Member




Carte Noir Java


« Reply #17 - Posted 2003-10-30 16:48:27 »

Quote
The latest AF works on the G400

Yieppee, and it did indeed so. Just tried a new eval version and for the first time it run on my Cel500Mhz  G400-16MB machine. And what best, it run playable speed.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2003-10-31 08:20:32 »

Hurrah! My, you're really scraping the bottom of the barrel there!

Cas Smiley

Offline Guoshima

Junior Member




Java games rock! Do they .. ?


« Reply #19 - Posted 2003-11-14 08:23:03 »

Well I have also been working quite a lot in JOGL lately but perhaps I was also thinking of switching to LWJGL to see if it really is better for games, and if you say that the porting isn't hard at all, then I might try it .. any tips on porting from JOGL to LWJGL ?
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2003-11-14 09:05:38 »

1. You no longer have to worry about getting references to some "gl" instance everywhere. Simply replace all your gl.gl* calls with GL.gl, because it's static.

2. Everything is done in the main thread. You can safely search for any code with the word "synchronized" or "Thread" in it and most likely rewrite it, single-threaded, unless it's something to do with networking.
easier to get to grips with.

3. Be prepared to understand Buffers completely, and forget all about passing arrays into GL methods.

4. Always always always check GLCaps for GL capabilities before attempting to call functions!

5. Running with -ea on the commandline causes the lwjgl_d.dll to be loaded which has lots of extra debugging and checking in it. In particular all GL commands automatically call glGetError() to check for errors and throw runtime OpenGLExceptions.

Cas Smiley

Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #21 - Posted 2003-11-22 15:24:01 »

I mean no malice. I figued that I should present the opposing view to Cas' statements so that we understand the implications of the "pros" (i.e. a "pro" can actually be a "con").

1.  Using statics (which I'm not against in the GL layer BTW) allows any class to insert GL calls onto the stack at any point.  You cannot prevent an arbitrary class from calling into GL.  This throws "defensive coding" out the window.
 Boo hoo! to all of those that can't pass a simple reference around!  That "annoyance" provides you with the knowledge of exactly what classes can access GL.  This simplifies debugging and maintenance.
 Think of it like the American HIPPA standing (it's a medical privacy law).  HIPPA doesn't care about "who accessed the data", it cares about "who had the ability to access the data".  The difference is subtle but very important.

2.  Threads are not bad.  We all need to get out of this mindset.  Just because most people seriously fubar threads does not mean that we should eradicate them.  Since I don't want to waste space I will refer you to:

http://www.realityinteractive.com/software/sc/background/benefits.html

where you can get a taste of why you want threads.  (No, this isn't a product plug.)

3.  Removing the ability for a developer to make a simple (read: less error prone) call to set or retrieve a GL value via an array is just bad mojo.  See the example below:

With arrays:
1  
2  
3  
4  
        
        final int[] textureIdentifier = new int[1];
        gl.glGenTextures(1, textureIdentifier);
        gl.glBindTexture(GL.GL_TEXTURE_2D, textureIdentifier[0]);


Without arrays:
1  
2  
3  
4  
5  
6  
        final ByteBuffer buffer = ByteBuffer.allocateDirect(4 /*sizeof(int)*/);
        buffer.order(ByteOrder.nativeOrder()); // pedantic
       final IntBuffer textureIdentifier = buffer.asIntBuffer();
        GL.glGenTextures(textureIdentifier);
        final int textureId = textureIdentifier.get();
        GL.glBindTexture(GL.GL_TEXTURE_2D, textureId);


Don't forget to call rewind() between retrievals of the value from textureIdentifier.  Oh!  And be prepared for cryptic VM crashes and core dumps.  

I should point out that glGenTextures is even worse than I'm making it out to be:  there's no number parameter.  After scouring the code (as this function has no javadoc) I determined that:
1  
nglGenTextures(textures.remaining(), textures, textures.position())

This means that if I wish to use a shared buffer of size n when I only want m textures, I need to explicitly set the position and limit of the buffer before I can make the call, so add two more calls to the already bloated code.

The bottom line is that more lines of code = larger possibility for bugs.  The second bottom line is that you're making the trade-reability-for-performance decision for me.  The developer should be provided with the ability to make that decision.

4.  "GLCaps"?  "GLCapabilities" too long to type?   Smiley  Seriously now folks, why doesn't the library protect me from making a call to an unavailable extension?  More code = more bugs.

5.  The debugging is done in a separate dll?  Oye!  The developer does not have the ability to choose at runtime nor selectively choose which set of GL functions they want debugged.  Why isn't this done in the Java layer where more control can be handed to the developer?



Now with all of this said, I stand behind the LWJGL effort 100% and I recommend it to everyone that I talk to. Those guys are doing a great job. They're handing bug reports very quickly. There are no production bugs that I have ever run into that have ever stopped me from coding.

If you're going to write a standalone game, use LWJGL.
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #22 - Posted 2003-11-22 16:39:24 »

Those are very good points, and mostly reflect a difference of opinion in the performance trade-offs the two libraries decided to make.  In the interests of disagreeing, though, I have to be picky about this comment:

Quote
Without arrays:
1  
2  
3  
4  
5  
6  
        final ByteBuffer buffer = ByteBuffer.allocateDirect(4 /*sizeof(int)*/);
        buffer.order(ByteOrder.nativeOrder()); // pedantic
       final IntBuffer textureIdentifier = buffer.asIntBuffer();
        GL.glGenTextures(textureIdentifier);
        final int textureId = textureIdentifier.get();
        GL.glBindTexture(GL.GL_TEXTURE_2D, textureId);

That's hardly fair!  With the addition of one utility class I write something like:
1  
2  
3  
FloatBuffer textureIdentifier = BufferUtil.makeFloatBuffer(1);
GL.glGenTextures(textureIdentifier);
GL.glBindTexture(GL.GL_TEXTURE_2D, textureIdentifier.get(0));

Which is basically the same as your array version, except with different words used.  There's some familiarity advantage to using arrays, but buffers really aren't hard to get used to - really.  Come to think of it, in my code I would actually write:
1  
Texture t = new Texture(myImage);

Grin

Hellomynameis Charlie Dobbie.
Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #23 - Posted 2003-11-22 17:06:14 »

Of course you can wrap the code that I presented but the point is that the code has to be written, debugged and maintained.  Instead of debugging and maintaining three lines of code, I'm dealing with six which are intrinsicly more complex.

And the way that I do it is found under Simulation Common at:



and essentially goes:

1  
2  
3  
final Texture2DFactory texture2DFactory = new Texture2DFactoryImpl();
...
final Texture2D someTexture = texture2DFactory.createTexture(<some URL>);


So  Grin to you too!   Smiley
Offline elias

Senior Member





« Reply #24 - Posted 2003-11-22 18:28:18 »

I'd like to respond to your 4. point:

Quote
Seriously now folks, why doesn't the library protect me from making a call to an unavailable extension?  More code = more bugs.


The library _does_ check for nonexistent function pointers, so the GLCaps check is not strictly nescessary, as your application will bomb out with an exception if the function pointer is NULL. However, _not_ checking your (required) extensions before using them is not good OpenGL practice anyway, so I can't see why the extra GLCaps checks (they only need to be done once per extension at startup mind you) can be avoided in a wellbehaving application.

- elias

Offline elias

Senior Member





« Reply #25 - Posted 2003-11-22 18:40:59 »

And regarding your second point about threads:

You're right in that threads can be useful, my griefs are just that they're highly overrated, really. Many programmers (including myself once upon a time) will happily use threads for anything that smells like "multiple tasks at once", ignoring the fact that most of the time the complexity of using threads correctly outweighs the little extra performance they may give. I deliberately say 'little' here because it is well known that you can achieve thread-like execution without threads in common tasks related to games. Take OpenGL for example. Calling OpenGL from multiple threads will likely hurt performance, but using APIs like ARB_VBO cleverly ensures that both the CPU and the GPU is working at all times. Even Cas' example of networking can be solved with non-blocking NIO (most of the time).

- elias

Offline elias

Senior Member





« Reply #26 - Posted 2003-11-22 18:54:48 »

...But I completely agree with your statement about the debug version of the libraries. It does remove some debug flexibility, but more importantly, lwjgl is about simplicity and the separate debug version simply does not fit into that goal.

So we're slowly working on a solution that removes the need for the debug version while maintaining the same level of error checks, but without introducing too much overhead per GL call. Stay tuned.

- elias

Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #27 - Posted 2003-11-22 19:29:15 »

Quote
The library _does_ check for nonexistent function pointers, so the GLCaps check is not strictly nescessary, as your application will bomb out with an exception if the function pointer is NULL


This is exactly what I'm referring to. Why force the developer to make the call to GLCaps? Shouldn't the library be the one that's concerned about not throwing NPE's like they're going out of style? Having the library log some sane message is better than an NPE any day of the week!

Quote
However, _not_ checking your (required) extensions before using them is not good OpenGL practice anyway, so I can't see why the extra GLCaps checks (they only need to be done once per extension at startup mind you) can be avoided in a wellbehaving application.


Developer correct / sane / defensive coding procedures weren't in question and of course the developer should check the available extensions before using them.  The root of what is in question is the need for the call.  So let's look at this the other way, if the library didn't throw on an unavailable extension and instead logged the error what would the developer lose?



In response to your threads topic, I most certainly agree that calling GL from multiple threads is a recipe for disaster.  Just to be clear, Cas was implying that you dump all threads (with some networking footnote) and that's what I'm calling into question.  Threads can be a "good thing" if used appropriately and the link I provided shows how this may be possible.  I just want to get the word out that threads aren't as bad as everyone thinks they are.  Add to that the fact that multi-core processors will be quite common in the near future.  Unless we start to get over our "threads are evil" hangups now, we're going to have a lot of idle processor time out there Smiley
Offline elias

Senior Member





« Reply #28 - Posted 2003-11-22 19:49:55 »

In fact, LWJGL will not throw NPE's, but OpenGLExceptions, but this is not the point. You're saying that LWJGL should log a message, probably something along the lines of "Application tried to call nonexistent function glBlah", right?

If that's what you're saying, then no, that's simply not better than an exception, ever. I'm certainly not calling OpenGL functions because I like to see my nvidia card sweat, but because I want something drawn or a state changed. If the GL library does not support the call there's no other choice than to halt the running program, hence the nescessity of checking with GLCaps. I like bugs to scream in my face, not hide in a log file somewhere.

- elias

Offline Rob Grzywinski

Junior Member




Reality Interactive


« Reply #29 - Posted 2003-11-22 20:58:54 »

I don't want to side-track more interesting points with this so I'll simply say that unchecked exceptions (be it NPE's or OpenGLException's) are a developers worst nightmare and anything that you can do to eliminate them should be persued.  Unchecked exceptions serve only to bite developers in the ass when their code goes into production.
Pages: [1] 2
  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.

BurntPizza (11 views)
2014-09-19 03:14:18

Dwinin (29 views)
2014-09-12 09:08:26

Norakomi (57 views)
2014-09-10 13:57:51

TehJavaDev (79 views)
2014-09-10 06:39:09

Tekkerue (40 views)
2014-09-09 02:24:56

mitcheeb (62 views)
2014-09-08 06:06:29

BurntPizza (45 views)
2014-09-07 01:13:42

Longarmx (30 views)
2014-09-07 01:12:14

Longarmx (36 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!