JSFML - A Java binding for SFML

[pdinklag]

I took the info on how to do it from the actual Java AWT C++ sources.

Code: [Select]


sf::WindowHandle getHandle(JNIEnv *env, jobject canvas) {
sf::WindowHandle handle = 0;

JAWT awt;
awt.version = JAWT_VERSION_1_4;

if(JAWT_GetAWT(env, &awt)) {
JAWT_DrawingSurface* ds = awt.GetDrawingSurface(env, canvas);

if(ds) {
if(!(ds->Lock(ds) & JAWT_LOCK_ERROR)) {
JAWT_DrawingSurfaceInfo* dsi = ds->GetDrawingSurfaceInfo(ds);
if(dsi) {
#if defined(SFML_SYSTEM_WINDOWS)
JAWT_Win32DrawingSurfaceInfo* dsi_win = (JAWT_Win32DrawingSurfaceInfo*)dsi->platformInfo;
if(dsi_win) handle = dsi_win->hwnd;
#elif defined(SFML_SYSTEM_LINUX)
JAWT_X11DrawingSurfaceInfo* dsi_x11 = (JAWT_X11DrawingSurfaceInfo*)dsi->platformInfo;
if(dsi_x11) handle = dsi_x11->visualID;
#elif defined(SFML_SYSTEM_MACOS)
JAWT_MacOSXDrawingSurfaceInfo* dsi_mac = (JAWT_MacOSXDrawingSurfaceInfo*)dsi->platformInfo;
if(dsi_mac) handle = dsi_mac->cocoaViewRef;
#endif
}
ds->Unlock(ds);
}
awt.FreeDrawingSurface(ds);
}
}

return handle;
}


There's just no way for me to test this.

Mind if I send you a PM with all the stuff in the next days? Already warning ya, you'll need ant and a JDK (1.6 or higher) to build this.

[Laurent]

Code: [Select]

handle = dsi_x11->visualID;

Are you sure that it's not dsi_x11->drawable instead?

[Hiura]

There's just no way for me to test this.

Mind if I send you a PM with all the stuff in the next days? Already warning ya, you'll need ant and a JDK (1.6 or higher) to build this.

Of course you can send me stuff to test. :wink:

[pdinklag]

Are you sure that it's not dsi_x11->drawable instead?

Very well possible, makes more sense indeed.
The Linux and Mac part can be considered pseudo code, I haven't got to try them yet.

[pdinklag]

Just tested music for the first time. It plays fine, but I'm having a problem when the application exits. The music would start to repeatedly hang and the Java application would never really end. It seems to me as if the SoundStream thread never gets ended, but doesn't get fed with new audio data either so it repeatedly plays the current buffer (I would guess).

Upon uninitialization, JSFML successfully invokes the sf::Music destructor and runs through. jsfml.dll (the SFML application) gets unloaded, but a dsound.dll thread keeps running, which kinda confirms my thoughts.

I have a feeling that the Stop method

Code: [Select]

   myIsStreaming = false;
    myThread.Wait();
doesn't quite do what it is supposed to be doing, but honestly I have no clue why. I know Java doesn't like threads created in native code, but that's about all I know and there must be a solution to this.

Any idea how I can investigate this problem further?

[Laurent]

I'm pretty sure it's not a C++ problem.


...I can't help more :lol:

[Groogy]

Hmm really? Now I am a bit worried about rbSFML =/

[pdinklag]

I'll study JNI and threads later on today and see whether I can find a solution.

I will also try and implement the LoadFromStream methods for Image, SoundBuffer etc. later. Since java.io.InputStream (Java's main abstract input stream class) does not support seeking, I might have to go with a custom java.io.FileInputStream wrapper. Gonna see what I can do here.

Now I am a bit worried about rbSFML =/

Are there similar problems in ruby then?

[Groogy]

I haven't used audio yet so I don't know. But rbSFML per say don't have problems with native threads, on the other hand I think they more encourage them than Ruby threads because the latest versions of Ruby has a global lock so only one thread at a time can run ruby code. Which is pretty bad.

Anyway you never know I might have the same behaviour on rbSFML, I got one user I know use the audio library so I asked him to look at it.

[pdinklag]

There is no way to have non-Java threads operate properly in the JVM space. This also explains the crashes I had trying to have custom SoundStream sublcasses interoperating with Java.

I will have to implement the SoundStream class in Java, which shouldn't be too much of a problem. For the Music class I'll have to to a wild mix between Java and C++ code so I can take advantage of sndfile.

[pdinklag]

This audio problem seems to go deeper. Apparently the AL context is never destroyed.

It gets initialized by EnsureALInit, which will invoke the AudioDevice constructor. The destructor, however, is never invoked, I can honestly not tell why, but I doubt there is any way for me to fix it. I have no control over how the JVM manages space allocated by native code, if it can and does at all.

I would need a way to force the destruction of the AudioDevice, which is not possible with the methods currently provided (especially since the AudioDevice is merely a static object inside a method). Any chance some sort of "UnInitAL" could be added to ALCheck?

Or maybe does or did this problem occur in the C# binding? If yes, how did you solve it?

[Laurent]

The audio module will be fixed (in a future minor 2.x release) so that the audio device won't be destroyed at global exit anymore.

[pdinklag]

Hm, that would mean I'd have to carry this (not to be underestimated) problem around until then. Would you mind if I created a solution proposal myself, or is there anything that needs to be done in conjunction with that change?

[Laurent]

I already know how to implement it, don't bother with that.

I don't think it's a major issue if your binding has a memory leak until it's fixed, people may not even notice it.

[pdinklag]

A simple memory leak wouldn't hurt, but the application never exits unless killed manually (via task explorer / kill). It might still not be a major issue, but it is serious.