The upcoming 0.7 release

[cfmdobbie]

The more I look at the current code in CVS, the more I believe there really are reasons for multiple inheritance... :roll: :lol:

Am I right in assuming that you can access all GL methods via the CoreGL* classes as well as the GL subclass?  So you can avoid any chance of writing to a different spec than you should be using - that's rather cool, nice one!  (Are there any thoughts to moving all the extensions out to individual classes as well?  I'd guess not - too many classes, too much disruption.)

Will there be a document listing the deviations (in method parameters) from spec, and the unimplemented methods?

Request: Please create an LWJGLException class and throw that instead of throwing vanilla Exceptions all the time.  Or something.  I'm assuming that's possible from the JNI code?

Almost time for an official "LWJGL Util" package maybe?  Texture objects, DisplayMode selection, SPGL's MemoryBuffers, Buffer creation, state queries etc all deserve a commonly used set of helper classes.  You can say "people will create their own", but without a commonly agreed upon Texture object for instance, noone can write code to be used by anyone else.  And don't just scowl and point at SPGL - without any available released version it's not something that can be built on!  And SPGL is heavily oriented towards the resource system AF uses.

I have to say the position/limit loops look a lot more readable than I'd have thought!  for(int i = buffers.position() ; i < buffers.limit() ; i++)  I hope there'll be a "guide to flipping" or something, as this area is new to most of us, I'm sure.

I know Java1.5's static imports are going to be recommended for use with LWJGL - but will they be required?  If you're going to go for 1.5, I guess the whole system could be made a whole lot safer with 1.5's Enum, too.


Enough random thoughts for now.  Charlie out.

[Fuseboy2]

Request: Please create an LWJGLException class and throw that instead of throwing vanilla Exceptions all the time. Or something. I'm assuming that's possible from the JNI code?

I'll throw in my vote for this too (if JNI doesn't make it impossible).

Fuseboy

[vrm]

I think it's lazy Matzon who like vanilla Exception

[Matzon]

:shock:

My area is mostly OAL & Input, which throws OpenALException...

however, we could do a single LWJGLException instead of one for OAL and one for OGL (and input too, which doesn't have one).

What exceptions *are* you guys talking about?

the only thing I could find, was these two:

/*
 * Utility function to throw an Exception
 */
void throwException(JNIEnv * env, const char * err)
{
	jclass cls = env->FindClass("java/lang/Exception");
	env->ThrowNew(cls, err);
	env->DeleteLocalRef(cls);
}

/*
 * Utility function to throw a RuntimeException
 */
void throwRuntimeException(JNIEnv * env, const char * err)
{
	jclass cls = env->FindClass("java/lang/RuntimeException");
	env->ThrowNew(cls, err);
	env->DeleteLocalRef(cls);
}

in org_lwjgl_opengl_Window.cpp, which isn't my code  infact - judging by the brace style, I'd say it's Cas' s fault - yeah thats right baby - go blame him  :twisted:  :twisted:  :twisted:

[princec]

Nyah, stick your Exception up your arse
Ok, it'll get changed to a WindowCreationException or somesuch.

Cas

[cfmdobbie]

@Matzon: The Open{GL,AL}Exception classes should really remain unchanged as they're part of the OpenGL/AL experience, if you get what I mean.  They have a clearly defined and useful purpose.

Yep, the quoted code is the culprit.  I believe it was called a lot more in pre-static days, but now only exists in places like Display.setDisplayMode().

I haven't seen a RuntimeException thrown for a long time, if ever.  I must peruse further...

[tvaananen]

Request: Please create an LWJGLException class and throw that instead of throwing vanilla Exceptions all the time.  Or something.  I'm assuming that's possible from the JNI code?

Also, make the LWJGException an unchecked one (derive from RuntimeException). Most  times,  when you get an exception from GL, you really can't do much else but to inform the user and return to some initial state. This would result to much cleaner code since you do not have to declare trows clauses to your methods or wriite try/catch everywhere.