Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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 11469 times)
0 Members and 1 Guest are viewing this topic.
Offline cfmdobbie

Senior Devvie

Medals: 1

Who, me?

« Reply #30 - Posted 2003-11-22 21:11:05 »

I very much agree with Elias' sentiment.  Naturally I like a system to prevent me from writing bad code when possible, but when that's not possible it should tell me in no uncertain terms that I've screwed up.  Trying to use an extension that isn't supported is a developer error, and should be treated as such.

And yes, in the past I've vocally opposed removing checked exceptions from Java, and will continue to do so!

Hellomynameis Charlie Dobbie.
Offline princec

« JGO Spiffy Duke »

Medals: 1033
Projects: 3
Exp: 20 years

Eh? Who? What? ... Me?

« Reply #31 - Posted 2003-11-23 11:01:58 »

This is one of those great debates that only comes along once every 6 months Smiley

In response to everything here I'd like to state our goals with LWJGL:

  • Speed
  • Simplicity
  • Ubiquity
  • Smallness
  • Security
  • Robustness
  • Minimalism

and this will help explain how we got to where we are today and more importantly where we're going and where we're not going.

The whole point of LWJGL was to bring the speed of Java rendering into the 21st century. This is why we have:

  • Thrown out methods designed for efficient C programming that make no sense at all in java, such as glColor3fv.
  • Made the library throw an exception when hardware acceleration is not available on Windows. No point in running at 5fps is there?
  • Provided a separate debug library that checks GL error state after every method call, which is not something you would normally do in deployment but would definitely want to do in development.

Our library is designed to work on devices as small as phones right the way up to multiprocessor rendering servers. Just because there aren't any phones or consoles yet with fast enough JVMs and 3d acceleration is neither here nor there - there will be, one day. We're carefully tailoring the library so that when it happens we'll have OpenGL ES support in there just like that. This means that:

  • We had to have a very small footprint or it'll never catch on in the J2ME space at all. That's why the binary distribution is under half a meg, and that takes care of 3d sound, graphics, and IO.
  • Even under desktop environments having a 1-2mb download just to call a few 3D functions is daft.
  • We've worked to a lowest common denominator principle rather than attempting to design for all possibilities, but we've made sure that 99% of required uses are covered. That's why we've only got one window, and why we don't guarantee that windowed mode is even supported (it's officially a debug mode and hence we don't even supply some very basic windowy abilities that you'd get in AWT) and why we don't allow multiple thread rendering contexts.

LWJGL needed to be simple for it to be used by a wide range of developers. We wanted relative newbies to be able to get on with it, and professionals to be able to use it professionally, maybe typically coming from a C++ background. We had to choose a paradigm that actually fits with OpenGL, and one that fits with our target platforms which ranges from PDA to desktop level. This is why:

  • We aren't catering for single-buffered drawing
  • We don't require that an instance of GL is passed around all over the place but we do not prevent this style of coding. See below for why.
  • We removed a lot of stuff that 99% of games programmers need to know nothing about
  • We have decided that consistency is better than complexity. Rather than allowing multiple ways to call the same methods and bloating the library we've just said, "Right, no arrays. They're slower anyway. Get used to buffers, as this is what buffers are meant to be used for." See below for why this doesn't affect you.

See ubiquity above. We had to be small.

  • Small == simple. The less ways there are to do something, the easier it is to learn the only way that works or is allowed.
  • Small == our code is less buggy. Wouldn't you rather be hunting for bugs in your own code, not ours?
  • Small == downloadable. No version nightmares. LWJGL is small enough to download with every application that uses it.
  • Small == J2ME.

We realised a few months ago that no-one was going to take us seriously if we couldn't guarantee the security of the LWJGL native libraries. This is why we:

  • No longer use pointers but exclusively use buffers instead
  • Are gradually adding further checks to buffer positions and limits to ensure that the values are within allowed ranges to prevent buffer attacks

Similarly to security we have now realised that a reliable system is far more useful than a fast system. When we actually had a proper application to benchmark finally we had some real data. Many of our original design decisions were based on microbenchmarks - well, you have to start somewhere! But with a real application to benchmark we now know we can throw out asserts and replace them with a proper if (...) check and a thrown exception. We know also that we can move all that GL error checking out of native code and into Java code and we will no longer need a separate DLL for debug mode.

As for runtime exceptions, they have their place. There's not a reasonably well defined argument as to when you should use a runtime exception and when you should use a checked exception. When I made OpenGLException a checked exception all it did was end up littering my code with try {} catch {} sections - except that if you've got an OpenGLException there is very little sensible you can do to rectify it because it should never have occurred in the first place. That's why it's a runtime exception. You should simply not write code than can throw it because it is generally not recoverable nicely. However for robustness (and security) we are required to throw an exception if something is amiss. It falls, I believe, into exactly the same category of trouble as NPEs, ArrayIndexOOBs and ClassCastExceptions: should never occur but needs to be trapped somewhere.

This is another critical factor in our design decisions. If it doesn't need to be in the library, it's not in the library. Our original aim was to produce a library that provided the bare minimum required to access the hardware that Java couldn't access, and by and large we're sticking to this mantra. The vector math code in the LWJGL is looking mighty scared at the moment because it's probably for the chop - well, at least, from the core library - as it's not an enabling technology at all, and there are numerous more fully featured alternatives. We chucked out GLU because it's mostly irrelevant to game developers except for a few functions that we really need to get redeveloped in pure Java - but basically, GLU is just a library of code built on top of the enablement layer.

Now why doesn't this affect you?
Because we're providing a small, minimal library that very closely mirrors the way the operating system actually works rather than imposing our own ideas about how the object oriented world works upon it, we're letting the next layer up make a decision. In Rob's case, that's him!

If you want to pass a GL instance to all objects so you can track who's calling what, it's easy:

Create a GL interface that contains the method signatures from our GL class.
Create a concrete implementation of that class.
Pass references to the instance of the interface around.
Problem solved.

If you want checked exceptions, create a checked OpenGLException. In your GL implementation class, do:
public void glSomeMethod() throws CheckedOpenGLException {
      try {
      } catch (OpenGLException e) {
            throw new CheckedOpenGLException(e);

where checkError() is just this:
protected void checkError() throws CheckedOpenGLException {
      int error = GL.glGetError();
      if (error != 0) {
            throw new CheckedOpenGLException(GLU.gluErrorString(error));

Save the code in a library, call it lw_bob_gl, and code to that library, not to LWJGL directly. I already do the same in Alien Flux - I automatically direct calls to EXT methods as appropriate instead of later GL 1.4 ARB methods, as appropriate. The important thing is we haven't got in the way of getting the job done, and we haven't sacrificed any of our goals in order to let you achieve what you wanted to achieve.

Sorry for the rambling!

Cas Smiley

Offline Rob Grzywinski

Junior Devvie

Reality Interactive

« Reply #32 - Posted 2003-11-27 15:57:03 »

Three cheers for Cas!  Hip hip Horray! .... (you get the idea  Smiley).

The main reason that this makes me so happy is that we can finally make decisions based on a set of goals rather than pulling them out of our butts.  This ensures that RFE's (request for enhancements) are accepted and rated based on a set of guidelines.

The only other thing that I'm waiting for are performance and size metrics.  That will cut out all of the unbased claims of "we can't do that because it will bloat the library" or "that will hurt performance".

Cas has been modded up a few points! Cheesy
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »

Medals: 1033
Projects: 3
Exp: 20 years

Eh? Who? What? ... Me?

« Reply #33 - Posted 2003-11-27 17:30:50 »

You forgot the "we can't do that because we're too lazy" Wink

Actually this might be a good time to tell you what's coming up in 0.9 (I think Brian, Elias and I are agreed on it):

Preparing for static import
Another major change in the API approaches! But hopefully, the last major change. We will be splitting up the huge GL class into separate classes for each extension, and the underlying C code will be split likewise.

We are doing this in preparation for the new language feature static import. This will make it easier to keep track of which classes use which GL extensions.

The classes will be named directly after the GL extensions string, eg. ARB_multitexture. We've not yet decided yet but all extensions will become classes; those that are merely interfaces full of constants will become classes too. All extensions will be marked final with private contstuctors, reflecting their intended usage.

Existing code will become hideously ugly as static import is not yet implemented in the language. This will go away as JDK1.5 becomes the normal development environment, and also as LWJGL users develop libraries on top of LWJGL to abstract things away.

OpenAL extensions
There's been a lot of work going on in OpenAL lately and we will be catching up on the new stuff.

OpenGL 1.5 and a few more extensions
We'll have OpenGL1.5 support too. Hurrah! There are also a few more extensions going in.

Stable Mac port
We've got a new developer who's getting a Mac especially to work on LWJGL for us. As usual Alien Flux will be the "test" application.

The increasingly-innaccurately described cruft that we claim to be "documentation" will be dealt with Wink

...and we'll get these bloody NeHe tutorials ported and running properly while we're at it.

That's all I can think of off the top of my head. The next version's a big one, oh yes. But the reason for that is that we'll be going into "beta" at 0.9, meaning that we will no longer change the API save for bugfixes, and we need to get it just right this time.

Cas Smiley

Pages: 1 [2]
  ignore  |  Print  

EgonOlsen (74 views)
2018-06-10 19:43:48

EgonOlsen (55 views)
2018-06-10 19:43:44

EgonOlsen (74 views)
2018-06-10 19:43:20

DesertCoockie (254 views)
2018-05-13 18:23:11

nelsongames (154 views)
2018-04-24 18:15:36

nelsongames (154 views)
2018-04-24 18:14:32

ivj94 (895 views)
2018-03-24 14:47:39

ivj94 (156 views)
2018-03-24 14:46:31

ivj94 (808 views)
2018-03-24 14:43:53

Solater (172 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!