Messages

286

SFML projects / JSFML - A Java binding for SFML

« on: August 06, 2011, 09:11:46 am »

And it is the AudioDevice which prevents the application from exiting??

Yes.
I just created a Destroy() method for myself to make exactly sure of this.
When I manually destroy the AudioDevice from my Java application, the OpenAL thread will be stopped and the application will exit properly.

I don't know why the global exit destructor does not work inside the JVM heap space, but even if I knew I doubt there would be anything I could do about it. So if it doesn't take too much time from other things, I'd appreciate this to be a 2.0 feature already.

287

SFML projects / JSFML - A Java binding for SFML

« on: August 01, 2011, 05:37:48 pm »

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.

288

SFML projects / JSFML - A Java binding for SFML

« on: August 01, 2011, 07:18:43 am »

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?

289

SFML projects / JSFML - A Java binding for SFML

« on: July 31, 2011, 12:41:18 pm »

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?

290

SFML projects / JSFML - A Java binding for SFML

« on: July 20, 2011, 06:42:28 pm »

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.

291

SFML projects / JSFML - A Java binding for SFML

« on: July 19, 2011, 04:04:24 am »

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?

292

Feature requests / ResourceStream class for custom resource loading

« on: July 18, 2011, 06:13:00 pm »

Yay, it will be a fun challenge to implement resource loading from Java InputStreams.

EDIT:
I wonder what exactly the Seek method is needed for?

293

SFML projects / JSFML - A Java binding for SFML

« on: July 18, 2011, 06:07:43 pm »

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?

294

SFML projects / JSFML - A Java binding for SFML

« on: July 14, 2011, 11:49:37 am »

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.

295

SFML projects / JSFML - A Java binding for SFML

« on: July 14, 2011, 11:31:49 am »

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.

296

SFML projects / JSFML - A Java binding for SFML

« on: July 14, 2011, 10:05:48 am »

What do you want to achieve exactly ?.

Are you familiar with Java and the JNI?

To use SFML in Java, I wrote JNI compatible C++ code which is then compiled into a DLL (with SFML linked statically). That DLL can be loaded and used in Java, it serves as a binding between the JVM and SFML. On Linux, this would be a Shared Object (.so file). I have not compiled JSFML for Linux yet, but I have experience with that and it won't be any problem. However, I never used a Mac in my life and got no idea how I would go about it there. I guess what's needed is a dylib, but I'm honestly not sure at all. Anyway, a dynamic library that the JVM can load and use will be required.

The core jsfml C++ source, which contains nothing but JNI compatible delegates and bindings to SFML methods and objects, should be platform independent and even compile on a Mac.

The only thing that definitely needs platform specific code is (currently) the JSFMLCanvas implementation. It's that Java AWT component I blogged about earlier in this thread, it can be used to seamlessly integrate an SFML render window into a Swing GUI. In the best case, all that'll be needed is a Mac-specific method to retrieve a Cocoa handle for the Java canvas.

297

SFML projects / JSFML - A Java binding for SFML

« on: July 14, 2011, 09:28:15 am »

Updated JSFML to the new input system.
Still waiting for the big Graphics update to come.

Hiura, I gather you're currently busy implementing the new input system for MacOSX. If you're free, let me know.

General question about MacOSX: Is it possible to compile C++ on a Mac as well? I saw that the Mac sources of SFML are written in ObjectiveC. I'd hate to maintain the same code in two languages, talking about the native part of JSFML...

298

General discussions / New global inputs in SFML 2

« on: July 13, 2011, 09:33:41 pm »

Nice!
Looks like I need to get the latest build and update JSFML.

299

General discussions / A new logo for SFML

« on: June 18, 2011, 09:39:19 am »

Dunno, those icons look like they were placed on there without any love: Immense color contrast in that Crystal Clear network globe, Joystick seems totally out of place. Not sure what those gears are supposed to do there either.

SFML:

In comparison, David's looks way "cuter" and has a clear comic-style theme, which fits a multimedia library more than that clean font. The only drawback are the aliased edges.

300

SFML projects / JSFML - A Java binding for SFML

« on: June 16, 2011, 03:38:51 pm »

Just in case people are wondering what's going on here.

The next scheduled task was to allow to create custom Drawable classes on a Java level, but since the whole Drawable, Image and Texture system is going to be changed entirely for what I know, I am kindof waiting for that update.

If somebody is interested giving this a shot on Linux or Mac ("giving a shot" means compiling the native Java library, which might need some adjustments in the C++ code), please let me know.