JSFML - A Java binding for SFML

[pdinklag]

After a good while of hidden progress, I can finally give a first sneak peek at JSFML, a Java binding for SFML.



The goal of this project is to allow Java developers like myself to make use of SFML, which I find to be the most straightforward multimedia library out there. A project like this happened to exist already, but has seemingly died ( http://www.sfml-dev.org/forum/viewtopic.php?t=1256 ). Therefore I am also allowing myself to use the same name, even though my version has nothing to do with that cancelled attempt.

The idea behind JSFML is not to implement all the SFML features in Java from scratch, but instead to define wrapper classes that delegate their functionality to the actual SFML. This is done using native code and has been working very well, however I have not been able to test the native part on any OS other than Win32 so far.

JSFML is based on the latest SFML2 snapshots. Since SFML2 is still in development, I will not yet release JSFML, however, I might release some builds in the near future for people to try.

So sorry, this is no release thread, but an announcement only.

The following is an overview of JSFML's features and status concerning the SFML modules.

SFML modules

Graphics
Most of the SFML Graphics module will be available for JSFML. Almost all classes mentioned in the SFML2 documenation are already supported. One exception is the Glyph class which I don't see any use for in JSFML (if you know any reason why I should make it available, let me know).



A more notable exception is the Renderer class. Using JSFML, you can not yet create custom Drawables, that's also why the Renderer class has not yet been bound. This feature will require quite some work and therefore is planned for a future release, set for when the basic stuff is proven to work.

Audio
Most of SFML's Audio module is already available. You can load and play sounds and musics SFML style.

What's not really done yet is the ability to implement custom sound streams (e.g. for MP3 support). The basic foundation for that is already done, but I have not been able to test this yet. Much like custom Drawables, this is set for a future release.

Network
The Network module of SFML will not be available in JSFML, frankly because there's absolutely no need for it. The Java runtime library provides everything you need for networking.

System
Much like the Network module, SFML's System module is mostly unneeded for JSFML. Java provides multithreading, timing and unicode supprt.

However, the Vector2f and Vector3f classes will be defined as minimal data holders to simplify communication between JSFML and SFML. I do not think vector mathematics should be part of a multimedia library, instead people can extend these minimal vector classes and stuff in as much functionality as they like.

Window
The Window module port will fully include Event and Input handling and also provide the ContextSettings and VideoMode classes. The Window class itself will not be available, you will be forced to use the (fully supported) RenderWindow class of the Graphics module in the first releases.

In future releases, I plan to make it possible to have a Java Swing control wrapper around a RenderWindow so you can perfectly integrate a render targetinto your Swing GUI. So far I have only done some research on this, and this will be tough...



I am currently writing a Javadoc for this which I will upload as quickly as possible. In late June, you can expect a sneak peek release (most likely Win32 only).

In the meantime, feel free to share your comments, ideas and ask questions.

[Nexus]

Looks very interesting!

Do you re-implement everything on your own? Maybe you could reuse some code of the older jSFML project, I don't know how evolved it is however.

[Laurent]

Wow, what a good suprise

The idea behind JSFML is not to implement all the SFML features in Java from scratch, but instead to define wrapper classes that delegate their functionality to the actual SFML

Are you using CSFML or SFML directly? Do you use JNI?

One exception is the Glyph class which I don't see any use for in JSFML (if you know any reason why I should make it available, let me know).

It's not used a lot, but since Font and Text are available there's no reason not to implement Glyph as well. It may be useful for custom calculations on text, for example.

A more notable exception is the Renderer class. Using JSFML, you can not yet create custom Drawables, that's also why the Renderer class has not yet been bound. This feature will require quite some work and therefore is planned for a future release, set for when the basic stuff is proven to work.

Don't bother with that, the Renderer class won't exist anymore in a few weeks. So as the Drawable base class.

The Network module of SFML will not be available in JSFML, frankly because there's absolutely no need for it. The Java runtime library provides everything you need for networking.

Good thing. Most of the languages have a decent standard framework, and the network and system modules usually don't need to be ported.

The Window module port will fully include Event and Input handling and also provide the ContextSettings and VideoMode classes. The Window class itself will not be available, you will be forced to use the (fully supported) RenderWindow class of the Graphics module in the first releases.

Why can't you provide the Window class? It's very useful for people who just want an OpenGL context.

In future releases, I plan to make it possible to have a Java Swing control wrapper around a RenderWindow so you can perfectly integrate a render targetinto your Swing GUI.

If you can manage to retrieve the system handle of a SWIG control, you can directly use the Window constructor that takes a native window handle. I don't know if it's possible with Java, but for example it works with .Net.

And I love the logo

[pdinklag]

Do you re-implement everything on your own? Maybe you could reuse some code of the older jSFML project, I don't know how evolved it is however.

Yep, did it from scratch. I have no idea how that older jSFML project worked and didn't look into it. I would believe our approaches are different, but I don't know and frankly I don't really care too much.

Are you using CSFML or SFML directly? Do you use JNI?

I'm using SFML2 (not CSFML) and the binding is done using the JNI, yes. Right now JSFML consists of a jar (the Java library) and a dll (for Windows), the dll was supposed to simply contain delegation functions but now I also statically linked SFML into it (because of that sf::Text problem I had, you'll remember my "bug" report a few days ago).

the Renderer class won't exist anymore in a few weeks. So as the Drawable base class.

OK, gonna be interesting to see what the new class layout looks like then.

Why can't you provide the Window class? It's very useful for people who just want an OpenGL context.

I think I could provide it, but I laid focus on the Graphics and Audio modules really because that's where Java lacks possibilities greatly.

If you simply need an OpenGL context, you could use LWJGL, which is a raw Java binding to OpenGL, OpenAL, OpenCL and some other libraries. Works well, but if you were to create a game engine or similar you'd still have to do all the work from ground up, which I became sick of and thus looked for something that features the most common things out of the box while being flexible at the same time.

Anyway, another reason I didn't include it yet is because Java doesn't support multiple class inheritance (one of the greatest drawbacks really). It'd be a pain to get Window and RenderTarget connected into one class. I'm sure there is a Java way to approach this, but like many things done the Java way it'd probably be very ugly...

If you can manage to retrieve the system handle of a SWIG control, you can directly use the Window constructor that takes a native window handle. I don't know if it's possible with Java, but for example it works with .Net.

Yep, that's exactly where I'm heading. I've been getting crashes trying to retrieve an AWT Canvas' window handle though, so I moved this into the future for now.

And I love the logo

Thanks :lol:

[Laurent]

Another question: do you plan to maintain this binding in the long term? I'm asking because if it's serious enough, I can make it the "official" Java binding -- with packages on the download page of the website, and a forum here. Tell me what you think about it.

And did you already setup a public repository for the project?

[Groogy]

Anyway, another reason I didn't include it yet is because Java doesn't support multiple class inheritance (one of the greatest drawbacks really). It'd be a pain to get Window and RenderTarget connected into one class. I'm sure there is a Java way to approach this, but like many things done the Java way it'd probably be very ugly...

I had the same problem.
 
I did get it to work in Ruby actually using Mixin modules. I think it's called interfaces in Java? I think I made RenderTarget just simply an mixin module( Interface in Java) an included it into my RenderWindow and in RenderImage.

Not an expert in Java so there might be a huge difference between the two

[Laurent]

Actually, I think I'm doing the same thing in SFML.Net (using pure interfaces to allow multiple inheritance).

[pdinklag]

Another question: do you plan to maintain this binding in the long term? I'm asking because if it's serious enough, I can make it the "official" Java binding -- with packages on the download page of the website, and a forum here. Tell me what you think about it.
And did you already setup a public repository for the project?

As for the time being, I'm all up for it!
Before we go there I'd suggest that I make a usable version first.

So far I'm using a private SVN repository, I think it'd be no trouble to move it onto a github on this page.

It all might need some integration work, as I fully rely on Apache Ant to automate building right now. Not sure what standard you'd like to see if any. Also no idea yet how it's gonna look on Linux or Mac. The C++ code should work for any OS, it's mainly the includes and some very special code parts (retrieving a Java canvas' handle) that are platform dependant.

I say we should care about all that when I got something that works, especially considering you're updating the whole Drawable tree soon.

Actually, I think I'm doing the same thing in SFML.Net (using pure interfaces to allow multiple inheritance).

Yep, Java classes can implement multiple interfaces. This will mean some duplicate code but it's better than not having it at all. I'll look into this in the near future.

(<- I believe there's a phpBB extension that introduces this horizontal rule tag, very useful thing to make posts more readable )

Meanwhile, good progress getting a RenderWindow onto a Java AWT canvas!

(click to enlarge)

As you see, the basic stuff works, just a few details don't.
[list=1]

• The render area pops a little out of the canvas after a while. Looks to me like the RenderWindow's position gets changed for some reason, I'll try and find out what happens.
• The RenderWindow's resizing behaviour is a little weird, as you can see on the second picture. The area filled by Clear actually got enlarged with the canvas, however the render area is still clipped to the initial size, also the render area seems to be bound to the bottom left corner of the canvas. Any ideas?
[/list:o]

[Laurent]

The RenderWindow's resizing behaviour is a little weird, as you can see on the second picture. The area filled by Clear actually got enlarged with the canvas, however the render area is still clipped to the initial size, also the render area seems to be bound to the bottom left corner of the canvas. Any ideas?

It seems like the RenderWindow is not getting OS events. Are you able to use an SFML event loop in this example, and get all events properly?

[pdinklag]

It seems like the RenderWindow is not getting OS events. Are you able to use an SFML event loop in this example, and get all events properly?

I only get these event types:

• MouseButtonPressed
• MouseButtonReleased
• MouseMoved
• MouseEntered
• MouseLeft

MouseWheel and keyboard events don't get caught, neither does the resize one.

What I actually tried is override the "setBounds" method in the JSFML canvas, which gets called everytime the control's size and position changes. In that function, I use the RenderWindow's "setSize" function, which results in the issue I described above.

[Laurent]

What I actually tried is override the "setBounds" method in the JSFML canvas, which gets called everytime the control's size and position changes. In that function, I use the RenderWindow's "setSize" function, which results in the issue I described above.

You shouldn't have to do that, the render window should catch the resize event and adjust accordingly.

So you must find why it's only getting mouse events :?

[Hiura]

Also no idea yet how it's gonna look on Linux or Mac.

If you want some screenshot, just send me a .jar file.  :wink:

BTW, I think Ant is a great build tool; I used it last year for a school project and it went perfect. So I've no objection, on the contrary.

Good luck with this project!

EDIT : about the resize problem, couldn't you use something like http://download.oracle.com/javase/tutorial/uiswing/events/componentlistener.html ?

[pdinklag]

Good luck with this project!

EDIT : about the resize problem, couldn't you use something like http://download.oracle.com/javase/tutorial/uiswing/events/componentlistener.html ?

Thanks.
Gonna get back to you about Mac / Linux (whatever you can provide).

I don't need to be using a ComponentListener really, because I'm using a java.awt.Canvas subclass called JSFMLCanvas, I can directly react to resizes etc.

Keyboard events are most likely caught by the main window, I might try setting the focus on the JSFML canvas. Gonna try what Input reports as for which keys are pressed etc, to see whether that works fine.

Concerning the resize, those Java Canvases do have a window handle, but they are no ordinary windows, so to speak. So whatever RenderWindow does to detect a resize, I'm not surprised it doesn't work.

My question is, how can I modify the RenderWindow upon a resizing event? Simply setting its size causes this weird behaviour with a clipped area and it being bound to the bottom left.

[Laurent]

Concerning the resize, those Java Canvases do have a window handle, but they are no ordinary windows, so to speak. So whatever RenderWindow does to detect a resize, I'm not surprised it doesn't work

If it has a window handle, it probably generates native resize events. A native window is not necessarily a top-level window, it may be a canvas, a button, a label, or whatever. So if you can get a native window handle from a control, you're not supposed to do anything else, SFML handles it.

What happens sometimes is that there are flags that control the behaviour of the canvas, and you may need to adjust them to get the expected results.

[pdinklag]

If it has a window handle, it probably generates native resize events. A native window is not necessarily a top-level window, it may be a canvas, a button, a label, or whatever. So if you can get a native window handle from a control, you're not supposed to do anything else, SFML handles it.

What happens sometimes is that there are flags that control the behaviour of the canvas, and you may need to adjust them to get the expected results.

I am aware that "window" doesn't mean a window in the Windows sense only.

What are the flags I need to adjust? I suppose I do that using SendMessage in Windows?