Any Last Requests?

Started by princec, February 12, 2004, 09:05:33

Previous topic - Next topic

Orangy Tang

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.

kents1

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

elias

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

Evil-Devil

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

CaseyB

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!

Evil-Devil

I would still fine with by calling a create method by myself. That might be the ultimate solution for it ;)

elias

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

oNyx

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 :(

elias

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

TuurEfe

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..

WiESi

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

Matzon

as with any bugreport - a test case goes along way to getting it fixed faster ;)

WiESi

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.