Re: [sdljava-users] Upcoming Features
Status: Beta
Brought to you by:
ivan_ganza
From: Robert S. <the...@gm...> - 2005-01-06 15:11:20
|
Hi. 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. > 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? > 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. cu Robert |