Well, some of you know that 0.9alpha is being released at Easter with any luck, which is a very short time away in terms of free evenings and such!
If 0.9alpha works we'll go to beta status which means we're officially going to freeze the API except for bugfixes. Hurrah! This means you can rely on us not to totally rewrite everything again! (It's happened about 4 times now!)
What this means for you is: if you have a desperate urge for any API that needs to be in there, please tell us! Or it might not make it into the 1.0 release. (At 1.0 I think we shall all take a rest from developing it for a while and get on with using it, yes?)
The feature I feel is most useful to the community at large is an AWT bridge of some sort so we can render to an AWT canvas; this will be part of the new "context management" interface I'm working on.
Cas :)
It was mentioned in another thread, but I think a FSAA API would be nice.
- elias
I have not a lot to ask for...what I really needed I implemented on my own :D
My unique point is: how much of the platform-dependant extensions (WGL, GLX) do you plan to expose?
For example the experimental OpenGL plugin by the Eclipse team let you use each and every extension such as you were working in C/C++.
I don't know wether this is the case (there are pros and cons for each choice) but I would like to know your opinion...so I will know what we'll get in LWJGL 1.0 :D
I don't think we plan to support any WGL, GLX and AGL extensions, unless there's a really good reason for doing so. In fact, I recently removed all previous supported WGL extensions from CVS.
- elias
What about OpenGL 1.5? Are we going to get that in for 0.9?
Cas :)
I'd like to see OpenGL 1.5 in LWJGL 0.9... :roll:
So would I. Any volunteers :P ? I'm busy putting all the security & bounds checks stuff in.
Cas :)
1.5 in next release - at the cost of postponing 0.9 - IMO
I'm all for postponing 1.5 to later and have a proper 0.9 alpha out for review. After all, OpenGL 1.5 is a simple API addition and is not even supported in any drivers yet (nv and ati that is).
- elias
ehh? GLSLang is supported in ATI, albeit in beta
I thought GLSLang support in LWJGL is almost ready... :roll:
http://puppygames.net/forums/viewtopic.php?t=420
Nono, GLSlang and friends are *not* opengl 1.5, although it's an extension defined alongside the 1.5 spec. We have GLSlang already. When I say 1.5 I mean those few extensions that are promoted to core for that particular version. That's also the reason it can wait - all 1.5 functionality exist already as ARB extensions, as far as I know.
- elias
But this 1.5 discussion might be obsolete very soon anyway - spasi, the extension expert, is likely to implement support for it soon anyway. Am I not right, spasi?
- elias
OK, the following are the 1.5 core promotions:
ARB_vertex_buffer_object
ARB_occlusion_query
EXT_shadow_funcs
and a few tokens were renamed. LWJGL already has these as extensions, including the GLSL ones (which are not in the 1.5 core) and the renamed tokens as well. What you are saying is (correct me if I'm wrong) to create a GL15 class (like the 11-14 ones), that contains the above extensions. And remove the separate ones. It's no big deal actually (no delay worries). Just a few cuts&pastes. Is that it? Tell me and consider it done.
Just a personal note... I'm not sure I like this merging. Especially for such important extensions. I mean, it kind of ruins the clean-up we're doing with all the extension splitting. And unless we keep them separate as well, the fact that VBO (for example) will be inside GL15 is confusing, since it's supported in much older cards too (with not even 1.4 support). Any thoughts?
Nono, you don't do any merging. Even though the extensions are "promoted" to gl 1.5 they're still different from the actual extensions. So you create a GL15 class and don't touch the extensions. Take ARB_texture_compression: we have it as a separate extension, but it's also inlcuded in GL13.
That way, users can decide to use a specific GL version (say 1.4) and assume all functionality without checking if all the extensions they need are there (because they're in 1.4). Or they can settle on a lower version (say 1.2) and use specific extenions.
- elias
Any reason you don't expose the GLU tesselation routines? They're awfully handy to me and are exposed cleanly in jogl thru a callback class. Am I just missing them in LWJGL or are they not here?
I'd like to see tesselating exposed in 0.9; otherwise, would you please explain why you've left it out?
They were initially left out because of the ugly hacks needed to callback java from C. However, erikd has implemented most of GLU in pure java for 0.9 instead.
- elias
GL.glSupport15(true);
GL.glFinish();
:wink:
:-)
GL_ARB_multisample support is also in for linux and win32.
- elias
Buffer checks 95% complete too. There are just a few that I don't know what to do with at the moment.
Cas :)
A while back there was some push towards removing unnecessary extensions to methods. Is that still the intention, or are the type qualifiers now deemed a necessary evil?
There are still a load of these extensions littered over the place - just scanning through CoreGL11 there is glLoadMatrixf, glLightModeli, glLighti, glPixelStoref, glPixelTransferf, glNormal3b, glScalef, glRotatef...
Well, we're deliberately not removing the ones that don't have a Buffer to match its type with. Those seem to cover all your mentioned functions except glLoadMatrixf which seems to be all right even so:
public static void glLoadMatrix(FloatBuffer m) {
BufferChecks.checkBuffer(m);
nglLoadMatrixf(m, m.position());
}
private static native void nglLoadMatrixf(FloatBuffer m, int m_offset);
(the f version is private)
- elias
Just out of interest, why do you remove the suffixes from methods that are distinguished by Buffer type, but not from methods that are distinguished by primitive type? Is it just policy, or are you trying to limit the number of automatic widening conversions?
Re: glLoadMatrix, I guess that's already been fixed since last release! I dunno, fixing things before you're asked... What kind of Open Source project is this? :D
:-D
Just wait for 0.9, it will definitely please most of you.
Yes, we try to avoid widening conversions by keeping those postfixes.
- elias
Additional methods in Window to allow setting the size and location of already-created windows would be useful. I know you generally don't like windowed mode, but as people are using it it might be worth adding these methods.
Also useful for Xith3D's CanvasPeer:
http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1077533097;start=0#0
Yes, we'll add methods to reshape windows in windowed mode, with a clear explanation of why they might have no effect ;)
Cas :)
I just finished render-to-texture. It works fine (I tested it in Marathon - gave me a 20-30% speed increase :wink: ), but I don't like the way I did it, api-wise. render-to-texture is win32 only, render to depth texture and render to rectangle texture are NV only, so trying to make it system-independent was quite difficult.
I'd like to hear any opinions on the implementation (if anyone has time to check it out) :roll:
Well, I don't like the WGL* references obviously. However, because render-to-texture is only supported in win32 (no extension exist for linux and probably not for mac either), we could keep it like it is now, _but_ make it clear that the API will change (and functionality might be cut out) when the GLX/AGL versions are out, even after LWJGL 1.0.
- elias
Another argument for splitting LWJGL functionality up by core and extensions. We should keep the cross-platform cross-vendor stuff in the core and then move out nvidia specific code into lwjgl-nvidia and so on.
Can render-to-texture's public API be made to look implementation agnostic? <edit> Actually it seems like the public API is already implementation agnostic. We need to be able to query for RenderTexture caps in GLContext though in a platform independent manner.
Cas :)
Quote from: "princec"Actually it seems like the public API is already implementation agnostic.
Yes, it is. Anything that has to do with WGL is hidden. You just query the pbuffer capabilities and pass a RenderTexture if supported. I just had to create some tokens to hide the WGL ones (one of the stuff I don't like the way it is now).
Quote from: "princec"We need to be able to query for RenderTexture caps in GLContext though in a platform independent manner.
I think we should keep the query in pbuffer, as they are so closely related. It'll have to clean-up somehow though, maybe later as elias said.
Request: org.lwjgl.LWJGLException, a subclass of java.lang.Exception; to be thrown by both Java and native code wherever a vanilla Exception is currently being thrown.
One line that exists in every single LWJGL application that should have no reason to exist anywhere in nature is "throws Exception". Please remove the need for it!
Question: Why is a colour depth passed to Window.create()?
I expect there's a really simple reason for it that I just haven't realised. It looks a little odd passing in a colour depth to change display mode, then passing it in again to create the window. What happens if I pass in different values each time? When would I want to do just that?
I know different windows can use different palettes, but surely it's not possible to create for example a 32-bit window on a 16-bit desktop, under any operating system anywhere?
Request: As the new "samples" behaviour is slightly off-the-wall, can we have another couple of Window.create() methods that don't require it to be passed please?
It's perfectly acceptable for LWJGL to assume 0 samples if nothing is specified, but it's not acceptable for people to have to make a decision as to how many "samples" they want just to create a window. Allow people who care to specify it, but don't scare off or confuse those who don't know what it means.
Actually your argument about the samples parameter can be applied to most of the other arguments also. Should we create a dumbed down overloaded create that only took a width, height (+x,y and title if windowed?) and that used some default values (min 16 bit color, 16 bit depth, 0 bit stencil and 0 samples)? I've seen a few times where a user couldn't understand that the depth buffer didn't work until pointed at the min. depth argument of Window.create.
- elias
Quote from: "elias"Actually your argument about the samples parameter can be applied to most of the other arguments also.
Agreed! I don't know how many people actually
want an alpha component in their on-screen windows, but I expect it's very few. Stencil buffers are used a lot more, but I'm sure they're still not used by the majority.
As LWJGL is intended to be used by graphics developers, I don't think it's unreasonable to request a colour depth and depth buffer precision - maybe have two variants: (width, height, bpp, depth) to allow people to get up and running without any hassle, and (width, height, bpp, depth, alpha, stencil, samples, etc) for those who want/need more control.
Quote from: "elias"[...] that only took a width, height (+x,y and title if windowed?)
Just an observation on this line - currently you need to pass in a window title even for a full-screen window. On one hand I think this is probably a good thing - if the system just can't go full-screen it's reasonable for LWJGL to guess at positioning the window at (0,0), but there's no sensible default for a window title. However, on the other hand, what percentage of computers won't be able to go full-screen? It seems a rather unlikely state of affairs, at the moment.
However, I guess the real reason for it is that it makes for a useful task-bar representation if focus moves away from the full-screen window. :?
Mouse.destroy():
/**
* "Destroy" the mouse. Remember to reset the native cursor if
* setNativeCursor() has been called with anything else than null.
*/
public static void destroy() {
assert currentCursor == null;
if (!created)
return;
created = false;
buttons = null;
currentCursor = null;
nDestroy();
}
Remember to reset the native cursor. Why force the user to do this? This is just basic cleanup work. If you're going to take the time to trash the VM with a failed assert, why not just do the cleanup instead?
setNativeCursor(null);
Mouse.create():
public static void create() throws Exception {
assert Window.isCreated() : "Window must be created prior to creating mouse";
if (!initialized) {
initialize();
}
if (created) {
return;
}
nCreate();
hasWheel = nHasWheel();
created = true;
currentCursor = null;
// set mouse buttons
buttonCount = nGetButtonCount();
buttons = new byte[buttonCount];
}
Inconsistent. If the window hasn't been created yet you throw an assert in debug mode and continue otherwise, but if you've already created a mouse you silently ignore any extra calls to create.
I would have thought that creating a mouse without a valid window should have the same result irregardless of whether or not asserts are enabled, while creating a mouse multiple times should be a recognised error on the part of the programmer. Thoughts?
You are absolutely correct, we are replacing all asserts with runtime exceptions.
I am also wondering: why don't we automatically create and destroy all the devices we can get our hands on when the window is created? They cost bugger all memory or startup time and are essential to 99% of all LWJGL apps. So we might just hide create and destroy and just leave isCreated() public. What do you think of that?
I'm really in favour of simplifying the API as much as possible.
I'd also like a Window.create() that took no args at all and just created a fullscreen window at the current colour depth, 16 bit depth, 8 bits stencil if possible. I want people to be able to totally initialise LWJGL with just that call.
I don't yet see any value in a LWJGLException class. Either the call worked, or it didn't. The whole checked exception argument in Java is supposed to make more robust code but it simply makes programming more annoying and difficult without actually increasing robustness.
Cas :)
Quote from: "princec"You are absolutely correct, we are replacing all asserts with runtime exceptions.
Lovely! Having played with asserts for a while now, I've decided that they have
one purpose - internal sanity checks. They should never be used for anything else, as such use
always causes problems and confusion down the line.
However your RuntimeExceptions work, please make them consistent! ;)
QuoteSo we might just hide create and destroy and just leave isCreated() public. What do you think of that?
Sounds good! That will also get rid of the old
which object do I destroy first? problem. If it's possible for LWJGL to handle all this, don't make the user do it.
QuoteI don't yet see any value in a LWJGLException class. Either the call worked, or it didn't. The whole checked exception argument in Java is supposed to make more robust code but it simply makes programming more annoying and difficult without actually increasing robustness.
This isn't a checked or unchecked argument - it's just removing references to "Exception". Specific libraries should throw specific and known exceptions - even if that exception is just a single "whoops".
Being able to catch all LWJGL exceptions but leave others to propagate is very useful. Declaring that a method "throws Exception" is just plain ugly. Just by throwing an LWJGLException instead of an Exception, you make the example code much easier to read and understand. And it'll only cost you a ~500 byte class.
Ok, bunch of stuff commited:
- Now there's a really easy way to start a LWJGL application:
Window.create("My 733t New Game");
- And here's a typical main loop:
while (!Window.isCloseRequested()) {
if (Window.isMinimized()) {
// When minimized, we don't need to do anything except sleep
try {
Thread.sleep(100);
} catch (InterruptedException inte) {
}
} else {
// Do "game" logic, and render
logic();
render();
}
// Do everything related to window processing
Window.update();
}
- And here's the cleanup code:
Window.destroy();
Display.resetDisplayMode();
Regular watchers will observe the complete removal of the Window.paint() method, which I have determined is completely unnecessary, and all the controller creation, polling, buffer reading, and cleanup is done automatically for you.
The Window now even puts itself straight into 1:1 pixel aspect ratio orthographic projection mode for you when it's created.
Samples parameter is now optional.
Cas :)
That is one *sexy* main loop :lol:.
However, am I right in thinking that that is also the most advanced tutorial currently available for LWJGL development? :roll:
You are sort of right :)
but I suggest you d/l the preview 0.89 available from sourceforge (www.lwjgl.org too!) and check the source code for the test programs
the openal PositionalTest.java one is pretty fun (left-center-right-left-center-right-left... and so on and so on) :D
you might also want to check Java Cool Dude's examples available in this (http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1078868758) thread. It's fun stuff :)
Request: As there's been a major change to the initialisation and destruction code, and also to the main loop, could we have an "unofficial" 0.891 release please?
Re: LWJGLException.
Thanks guys, fantastic! :D :D :D
The real 0.9 is due in a week or two anyway, so that shouldn't be nescessary. 0.9 is meant to be an API review anyway.
I checked in a few of your changes too:
1. LWJGLException is used where Exceptions is used today. You can argue that we need a more finegrained exception hierarchy, but I didn't bother.
2. All asserts have been converted to appropriate runtime exceptions.
3. I added a version check to guard against jar<->dll mismatch.
4. The buffering input events now preserve the events that are not read by the application, up until the buffer is filled, instead of starting from scratch at each .read(). That fixes the problem of calling Window.update() (which calls .read()) more than once before actually reading events from the input devices.
- elias
... and the native cursor (if any) is reset at Mouse.destroy() too as you requested. Must be your birthday or something, eh dobbie?
- elias
:mrgreen:
It is a good day to be an LWJGL user indeed!
OK, we'd like some opinions on a problem that occured.
1.5's static import can't be used with inherited static fields and methods. This affects some of the LWJGL classes (e.g. ARBVertexProgram & ARBFragmentProgram that extend the private ARBProgram). We wouldn't like to duplicate code to solve this. So, any suggestions?
I'd prefer making the base class public, although it may complicate the documentation and confuse people.
I don't see a problem with making it public. So long as it's abstract it won't confuse anyone I don't think.
Cas :)
Well, ARBProgram involves quite a lot of code - it's not at all sensible to duplicate all that (unless you use a preprocessor to insert it into the appropiate files - yuk). Given the choice between duplicating it or making it public, I'd vote for making it public - although not knowing anything about using these classes I really don't know how confusing it's going to be. From the API it looks like you may end up pretty much alternating calls if you use ARBVertexProgram... which would suck. Are there any other solutions?
I think more's the question why can't static import be used in this way? Is it a bug or is there a good reason for this? Seems a bit fishy to me.
- Lose the postfix on GL11.glLightfv(int, int, FloatBuffer), GL11.glLightiv(int, int, IntBuffer) and GL11.glMultMatrixf(FloatBuffer).
- GL15.glGetQueryObjecti(int, int, IntBuffer) and glGetQueryObjectui(int, int, IntBuffer) - you could remove the i postfix, just leaving the u on the unsigned method, if you wish.
- Wrong CRLF format in ARBFragmentProgram.java, NVFragmentProgram.java and NVProgram.java.
Quote from: "cfmdobbie"Given the choice between duplicating it or making it public, I'd vote for making it public - although not knowing anything about using these classes I really don't know how confusing it's going to be. From the API it looks like you may end up pretty much alternating calls if you use ARBVertexProgram... which would suck. Are there any other solutions?
Well, I've used them a lot and and it seems like 3 things already, not 2. There's the program handling and then there's VPs and FPs. They've done the same thing themselves with GLSL. There are shader objects and then there's vertex and pixel shaders. It makes sense to make it public, but an "ARB_program" extension doesn't exist, so we should document this well for newbies.
Quote from: "cfmdobbie"I think more's the question why can't static import be used in this way? Is it a bug or is there a good reason for this? Seems a bit fishy to me.
That was my first thought too. Even IDEA doesn't complain when I try it. I read the spec and couldn't find anything that forbids it. Anything visible should be imported.
Anyway, this will also affect NV_VP+NV_FP and VBO+PBO(coming soon).
cfmdobbie: Thnx, it should be fixed now.
I think you'll find that the class itself is not visible, and that's the problem - you simply can't reference it as it's not in scope.
Cas :)
New in CVS:
ARBProgram and NVProgram are now public and final. The corresponding common vertex_program and fragment_program functionality can be found there. The same applies for ARBBufferObject. It contains the common functionality of ARB_vertex_buffer_object and the new EXT_pixel_buffer_object.
New extensions:
EXT_Cg_shader
EXT_depth_bounds_test
EXT_pixel_buffer_object
GL_NV_fragment_program_option
GL_NV_vertex_program2_option
BufferChecks.java:67
static void checkBuffer(Buffer buf, int size) {
if (buf.remaining() < size) {
throw new BufferOverflowException();
}
}
Request: Include buf.remaining() and size in the exception message. I had to dig through the LWJGL source to find out that it wanted a 16 element buffer.
Spasi: what is the reasoning behind not letting classes extend each other anymore? E.g. not letting NVFragmentProgram extend NVProgram?
- elias
Quote from: "elias"Spasi: what is the reasoning behind not letting classes extend each other anymore? E.g. not letting NVFragmentProgram extend NVProgram?
Hmm. Even if the heirarchy isn't accessible via static import, it's probably handy to keep it in place so the normal ARBFragmentProgram.GL_CURRENT_MATRIX_ARB method of access still works for those that don't use static import.
The static import problem still sounds like a bug to me... :-/
Quote from: "elias"Spasi: what is the reasoning behind not letting classes extend each other anymore? E.g. not letting NVFragmentProgram extend NVProgram?
Because I got too excited with static import! Now most of our GL statements are actually ONE line! :wink:
Well, seriously, for two reasons:
A) Using static import is THE way to use LWJGL. We don't want new people to watch ugly code, right :wink:? This way, we kinda force users to do it.
B) Normally, one would create wrapper classes for things like programs and buffer objects. Allowing access to the management code from both (e.g.) VertexProgram and FragmentProgram, one may assume there are two managements, thus duplicating code in their wrappers. Again, we're forcing them to read the (not really clear) specs better and thus, understand what they're doing better.
If anyone has a big problem with that, I don't mind doing the hierarchy again. It just felt more natural this way for me.
Will LWJGL 0.9 require a 1.5 JVM, then?
Question: Should org.lwjgl.opengl.glu.Quadric be made abstract? Looking through the code I can't see any reason for a user to directly create a new Quadric object, only a subclasses of it.
No LWJGL should not require a 1.5 JVM. So yeah, I think I like the hierarchy back. I think it is important to call all the (say) VertexBufferObject functions from the same class, not caring whether some functionality is shared with PBO.
- elias
Of course it'll not require 1.5. You can still say ARBProgram.glBindProgram(ARBVertexProgram.GL_VERTEX_PROGRAM, x); if you want to. No problem there. Anyway, I'll put the hierarchy back, when I return home.
Yeahh! Only one week till easter!
WiESi
Is it possible to add a function that resizes a fullscreen window, without destroying the gl context? What I want is to change resolution from inside the game without loosing the textures and the gl state.
I know this is a bit late for the 0.9 release, but maybe for the 1.0?
Any comments?
The GLSL update changes are added in cvs.
Could someone send me fresh win32 & linux builds?
I'll send you a Win32 build; Elias can most likely send you a Linux build.
tomb - we're about to change the whole Display / Window API so that Window will no longer be used. It's all going in Display, and it's going to be quite bean-like in that you should simply be able to tweak properties all day long and it Just Works.
Cas :)
http://odense.kollegienet.dk/~naur/lwjgl-linux-20040627.zip
(although you haven't comitted any native changes lately, but that might be deliberate)
- elias
Thank you guys.
No native changes from me, but many by others. I just didn't have any latest binaries (especially for linux). :wink:
Just a quick thought to throw at you:
While you're making the context-handling functions more user-friendly, is it possible to do the same w.r.t. extensions that make it into the core unaltered? i.e. can you clean up code like the following:
if(GLContext.OpenGL13)
GL13.method();
else if(GLContext.TheExtension)
TheExtension.methodEXT();
else
throw new Exception("Doh");
Are there many situations in which the library can guarantee the code would have worked the same, if only the developer had added a load of version-checking boilerplate instead of calling the core method directly?
Apart from the implementation burden on us, there is the subtle problem that the original extension spec often is slightly different from the core spec of the extension. And as such, we can't guarantee the same behaviour just by re-routing the method call.
- elias
Righto, so the answer is "not enough to make it worthwhile"! :D
I can live with that, it was just an idle thought.
I wouldn't say it isn't worthwhile. The spec differences are mostly clarifications, so it isn't entirely impractical, we just need to document the fact properly (maybe with an explicit runtime flag).
I guess that for a particular extension, if the core version is available, the original extension is also available.
- elias
Small suggestion - do a check of the 'size' arg to glVertexPointer (which according to my docs should always be 2, 3 or 4). Going by Eclipse's intellisense/function tooltips it suggests that the 'size' param is the size of the buffer you're binding, rather than the size of the coords it contains (and hence me typing in a whacking great number :oops: ).
Probably only want it enabled in debug mode though.
Would changing that argument from "size" to "vertexSize" fix things for you? Eclipse should generate its popups directly from the source and javadoc, so that might help to make it less confusing.
That'd be another good idea. :D
IIRC, this was proposed long time ago:
We should have a way to define an icon for the LWJGL window. Even in fullscreen mode, it looks ugly when minimized.
Was this considered & rejected, or simply forgotten?
Somewhere between the forgetting, and actually writing the code that supports it - cross platform!
How would it be implemented? Display.setIcon, Display.create(..., icon) ?
I'd prefer a setIcon, if it's just a matter of code style. :wink:
I vote for setIcon, and I'd like it to take a ByteBuffer containing a 32 bit RGBA image. Of some known size...?
Cas :)
I vote for setIcon(...) too :)
Chman
yeah, well - I vote for setIcon too - but who's going to implement it ??? :p
anyhow - won't we need different sized icons, 16*16, 32*32, 128*128 for different platforms and so forth ?
Could you perhaps set a range of icons of different resolutions, and have LWJGL pick the one of the correct size? Possibly resizing an differently sized icon if none of the correct size was provided?
GLU tesselation methods would be very very helpful...
Why are there still the methods Keyboard.create() and Mouse.create()? I determined that it isn't necessary in newer versions to call this methods so it irritates me...
WiESi
Quote from: "WiESi"Why are there still the methods Keyboard.create() and Mouse.create()? I determined that it isn't necessary in newer versions to call this methods so it irritates me...
WiESi
They need to be public in order to be called from Display since they're in a different package.
- elias
Dunno if this has been mentioned...
In org.lwjgl.input.Mouse, the "absolute position" returned from getY() isn't consistent with the upper left origin, instead it returns it relative to the lower left. I have to put in (WindowHeight - Mouse.getY()) to get a proper position.
I don't know if it's possible for you guys to do it without also subtracting window height, which would equal no performance benefit. Still, I think it would be better for consistency's sake to match it up with the origin. I think two additional functions in Mouse would work, like getOriginX() (and Y), or maybe getRelativeX() (and Y).
err - isn't the OpenGL origin lower left ?
How come the GLU methods don't use Buffers like the GL* ones?
It's a bit of a fiddle using gluUnProject, since it requires float[][] for matrices that GL* return as FloatBuffers.
(With LWJGL at 0.98 and people with much more interesting things to do with their time, I'm not really asking for an API change ;))
Sorry to gripe :D
P.S. I am liking LWJGL very much, thanks.
QuoteHow come the GLU methods don't use Buffers like the GL* ones?
I think GLU uses float[] because it is written in pure Java code while the GL ones are native c++ and thus require JNI buffers.
Quote from: "Matzon"err - isn't the OpenGL origin lower left ?
Depends what you pass into glOrtho surely? You can easily flip the origin from top left to any other position you want with correctly calculated values.
Could you consider changing the way the native libs are loaded so they can be set dynamically in code to something such as;
- Create a new property such as lwjgl.library.path which defaults to the java.library.path + anything else set.
- Look for lwjgl.library.path/LIBRARY_NAME resources on each of the given paths.
- Use System.load(LIBRARY_PATH) for each resource found.
Would be nice when creating a whole bunch of engine demo's not to have to explicitly specify the lwjgl path for each one.
Thanks,
Simon
Can't this be solved by a custom classloader? We made a special classloader for TT to get it to load libraries from a svn working directory.
- elias
I have a suggestion regarding the AWTGLCanvas.
Could the initialization of the context be done before paint() is called or just exlude it to an extra function. Because when working with the AWTGLCanvas within Desktop Apps it is handy to have the context itself been initialized on object creation. OGL init and data loading stuff can be done later and not within the paintGL() like at the moment. Thats really frustrating to have a big block of code within paintGL that is only once executed. Additional it make it harder to change the object that provide the render data for the canvas.
In my current implementation i went the way and liked to see the context available before the paintGL is called. For me is paintGL just for painting usage. Not for init or anything else.
Maybe this could be solved via a AWTGLCanvas2 class ;) or similar stuff. If requested i will post my current usage of the AWTGLCanvas which is allready very flexible.
Evil
Actually I second this! I am not sure how it could be done, but it is annoying to have the initialization code in the paintGL method. It's not a performace hit as it only runs the first time through, but it's ugly!
I would still fine with by calling a create method by myself. That might be the ultimate solution for it ;)
We can't create the context before paint(), since that's where the component is realized and available for binding a context to it. I added a initGL() method to AWTGLCanvas which is called only once immediately after context creation.
- elias
I would like to see some proper swapinterval access.
Right now we only have setVSyncEnabled(boolean sync) over in Display, which sets it to either 1 or 0.
While that swapinterval stuff is some extension there is no way to use it, because:
"We don't expose any WGL extensions as they are completely platform specific."
And its GLX_SGI_swap_control or WGL_EXT_swap_control.
What I want now is some method like setSwapInterval(int interval). setVSyncEnabled can be of course kept with true as parameter it would call setSwapInterval(1) and with false it would call setSwapInterval(0).
If you wonder for what its needed... well say you have some 60hz tickbased game and want to add an 120hz option. With swapinterval 2 it would simply show each buffer twice, which is *very* smooth.
edit: ati treats 2 (or 3 or whatever) like 1. So, it seems to be pretty useless in reality :(
Regardless of the driver support, it was an easy addition since all three platforms support the concept of swap intervals. So I've added setSwapInterval to Display and AWTGLCanvas (and made setVSyncEnabled to call setSwapInterval(enabled ? 1 : 0)).
- elias
Hi!
If I have a:
private Vector2f position;
And I do this:
this.position = Vector2f.add(this.position, this.position.normalise(null).scale(amountOfAcceleration), null);
The compiler tells me that the Vector2f.add is not applicable for the arguments (Vector2f, Vector, null)
This is because the Vector2f.scale(float amount) returns a Vector instead of Vector2f. Could these methods be fixed so that they return Vector2f instead? Since the call to scale returns the object itself (a Vector2f), there shouldn't be any problems fixing the signature.
Of course I could cast the return value to Vector2f since the method javadoc says the method is returning itself, but this makes my code look ugly. I also have to always check from the javadoc that the method actually returns itself and not something else.. =)
I realize that there are propably bigger things to do also, but this helps in using the code. =)
I also thought that I could perhaps do the changes myself? I just haven't yet participated in any open source development so it is all new to me. =) I guess I'd have to start by creating myself a sourceforge account..
I recognized that sometimes exceptions in FMOD aren't thrown in Java but native. This occurs for instance when trying to access a stream that has already quit its playback.
I would appreciate it to fix this issue in a future release of LWJGL.
WiESi
as with any bugreport - a test case goes along way to getting it fixed faster ;)
Quote from: "Matzon"as with any bugreport - a test case goes along way to getting it fixed faster ;)
I took a look at my code and it seems that I have made a mistake with synchronisation. One Thread gets an FSoundStream from another Thread and calls GetTime. The exception is thrown out when the variable changes at exactly this time so this error doesn't occur always and is hard to reproduce. I cant't post my code because it's much too long but I think you should understand the problem.