Re: [sdljava-users] Upcoming Features

[Ivan Z. G. <iva...@ya...>]

Robert Schuster wrote.

> Ivan Z. Ganza wrote:
>
>>
>> This should allow one to use these modules more naturally from java.  
>> I've already got it working for loadWAV using SDL_RWops on the C side 
>> and it works perfectly.  Thanks to Robert Schuster for the suggestion.
>
>
> This is pretty cool!
> Does your implementation rely on direct byte buffers (ie. it will fail 
> when on some ByteBuffer b b.isDirect() returns false)?
>
> And does it rely upon full JNI compliance? In a JNI library of my own 
> using direct buffers I am doing this check first:
>
> JNIEXPORT jboolean JNICALL 
> Java_de_bitecode_input_linux_impl_core_LinuxEventDevice  (JNIEnv *env, 
> jobject object, jobject buffer) {
>        return (jboolean) ((*env)->GetDirectBufferAddress(env, buffer) 
> != NULL);
> }
>
> This is because JNI specification allows to return NULL on each call. 
> That means that the VM has no direct buffer capabality.
> AFAIK Free Java VMs lack this kind of functionality yet. It would be a 
> good idea if you mention that somewhere in the docs.
> In the meantime I try to find out which Free VMs support it.


Yes I'm using direct buffers!  And it WILL fail if isDirect() returns 
false.  Thanks to your suggestion I wasn't even aware of them.  Now I 
see they are the greatest thing for java-->native integration.  I didn't 
think about the case where the VM might not support them.  I'll mention 
this in the docs.

>
>> I'm also planning to implement SDLSurface.updateRects(...) in a much 
>> faster way using Direct buffers.  Finally there will be a few new 
>> methods added called queueBlit(...) and queueUpdateRect(...).  What 
>> they will do is basically allow one to "queue" blits or updates, then 
>> later call either flushBlits() or flushUpdates() to send them to the 
>> native layer and have ALL the blits or updates processed at one time 
>> in C.  So for example if you did 100 blits normally that would be 100 
>> separate JNI calls.  In this case it will mean one JNI to do all 100 
>> updates.  I believe this should produce performance near to that 
>> which can now be achieved in C code.
>
>
> That is definitely a good idea!
>
>> Oh and I've been able to get a full OpenGL binding working via the 
>> import of the opengl from the Lightweight Java Game Library -- 
>> http://www.lwjgl.org/.
>
>
> Cool LWJGL goes SDL! Does this mean that the LWJGL Window's key and 
> mouse events are routed to SDL's input system?


No actually I don't initialize any part of LWJGL except for the OpenGL 
subsystem.  Everything else is still handled by SDL.

>
>> Actually needed to slightly hack the jar file to make a few methods 
>> public, however, I am able to use their opengl binding so far without 
>> any troubles.  I'm not sure that I want to stick with this forever 
>> due to certain aspects of its design, but, for now we would have the 
>> capability to fully utilize opengl from sdljava.  I'm not sure that 
>> this will make it into next release but if anyone really needs to use 
>> opengl in this way please let me know.
>>
> I wonder whether it would make sense to ask the LWJGL team about 
> making a specific API to make the LWJGL-sdljava integration a stable 
> feature. Anyway SDL is ported to far more platforms than LWJGL and 
> they could save a lot of development time by relying on SDL or at 
> least please the developers who want the later.


I've been seriously thinking about this!  It really would make much 
sense to offload all the things from LWJGL that SDL already has.  Its 
ported to many more platforms and its very stable.  They could offload 
all that work and concentrate on more important things.  I'm not sure 
how receptive they would be to this.  I will have to post in their forum 
and see what comes of it.

There is a problem with LWJGL OpenGL implementation though.  This is the 
fact that you access the OpenGL subsystem in a static way, eg:  
GL11.glBegin()

This really needs to be behind an interface that you get in some way.  
For instance I would like to have a method on SDLSurface such as:
    public GL getOpenGLContext()

Where you call this on a framebuffer (or window/visible type surface) 
and you get back the GL interface which has all the appropriate OpenGL 
methods on it.  We CAN do this will LWJGL but it imposes one extra 
method call each time as the GL would delegate out to the static GL11 
class.  Another really important reason to have the GL interface is that 
you can support the idea of "composable" which was implemented by the 
old Magician binding and currently by jogl.  Using this you can wrap the 
GL interface with a DebugGL which checks for error on each of your 
OpenGL calls.  If it finds one it throws an exception with the error and 
you can see in the stack trace the precise line where your OpenGL error 
occured.

One another note I found a neat project called GLee 
(http://elf-stone.com/glee.php).  This is also a possibility for 
supporting open gl.

So many ways to evaluate, so little time....In any case when it is added 
to sdljava it will be behind an interface so we could substitue other 
implementations later if need be.

If anyone might have a pointer who I can contact at LWJGL please let me 
know.

Cheers,
-Ivan/

>
>
>
> cu
> Robert
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> sdljava-users mailing list
> sdl...@li...
> https://lists.sourceforge.net/lists/listinfo/sdljava-users