SFML community forums
General => General discussions => Topic started by: ravenheart on May 21, 2009, 01:25:09 pm
-
One question :
Is there a real probability that someone writes a java-wrapper for sfml??
i really like sfml but much of my code is java and i dont like java2d
-
I won't do it myself, and so far I've never seen someone interested to write such a binding. Why don't you do it? :)
-
I won't do it myself, and so far I've never seen someone interested to write such a binding. Why don't you do it? :)
Hi. I am interested in writing such a binding. In fact I started it few days ago. For this I am using JNI. I am right now under heavy deadline at work, so development moves slow. Implemented things so far:
sf::Clock
sf::Randomizer
sf::Vector2
sf::Style
sf::VideoMode
sf::Window (90%)
sf::WindowSettings
Right now I am focused on implementing and wrapping Event and Window GetEvent method and all events in overall. I will release code when i will consider it working enough and have ported few examples of SFML applications. Window creation looks like that:
Window window = new Window(new VideoMode(800, 600, 32), "jSFML", Style.Close|Style.Titlebar, new WindowSettings() );
Constructor takes these arguments:
public Window(VideoMode, String, int, WindowSettings)
I will try to provide posts with weekly updates and changes in jSFML binding. Anyone even interested in using such a binding :?: Except me and ravenheart :].
-
Maybe you should wait for SFML2 (or already start working on it from SVN), a lot of things have/will change.
-
Maybe you should wait for SFML2 (or already start working on it from SVN), a lot of things have/will change.
Ok. Thats good idea. SFML2 code is available at http://sfml.svn.sourceforge.net/viewvc/sfml/ ? I cannot checkout this repository, I'm getting message "Error: Repository moved temporarily to '/viewvc/sfml/'; please relocate". I don't get it what I'm doing wrong? I'm using windows TortoiseSVN.
-
Maybe you should wait for SFML2 (or already start working on it from SVN), a lot of things have/will change.
Ok. Thats good idea. SFML2 code is available at http://sfml.svn.sourceforge.net/viewvc/sfml/ ? I cannot checkout this repository, I'm getting message "Error: Repository moved temporarily to '/viewvc/sfml/'; please relocate". I don't get it what I'm doing wrong? I'm using windows TortoiseSVN.
https://sfml.svn.sf.net/svnroot/sfml
and SFML2 branch:
https://sfml.svn.sf.net/svnroot/sfml/branches/sfml2/
-
https://sfml.svn.sf.net/svnroot/sfml
and SFML2 branch:
https://sfml.svn.sf.net/svnroot/sfml/branches/sfml2/
Thanks. I didnt got it that url on download page was for browser and not for svn client.
-
Weekly changes report:
- sf::Window is fully implemented (all events implemented)
- sf::Drawable implemented
- sf::Shape implemented
- sf::RenderWindow in progress (40%)
In next few days I will finish work on sf::RenderWindow and I will start working on sf::Image and sf::Sprite classes.
Sample code:
import SFML.System.*;
import SFML.Window.*;
import SFML.Graphics.*;
public class jSFML
{
static
{
System.loadLibrary("jSFML");
}
public static void main(String[] args)
{
RenderWindow wnd = new RenderWindow(new VideoMode(800, 600), "jSFML", Style.Close|Style.Resize|Style.Titlebar, new ContextSettings());
Shape shape = Shape.CreateCircle(new Vector2f(400, 300), 250, new Color(255,0,0), 8, new Color(0, 255, 0));
Color background = new Color(0, 0, 0);
while(wnd.isOpened())
{
Event event = new Event();
while(wnd.getEvent(event))
{
if( (event.type == EventType.KeyPressed && event.key.code == KeyCode.Escape) || (event.type == EventType.Closed) )
wnd.close();
else if (event.type == EventType.KeyPressed && event.key.code == KeyCode.Space)
System.out.println("fps: " + 1/wnd.getFrameTime());
}
if( wnd.getInput().isKeyDown(KeyCode.Return) )
{
background.r = Randomizer.randomI(0, 255);
background.g = Randomizer.randomI(0, 255);
background.b = Randomizer.randomI(0, 255);
}
wnd.clear(background);
wnd.draw(shape);
wnd.display();
}
}
}
-
Awesome :)
I have two small questions:
1. Why did you renamed Shape::Circle to Shape.CreateCircle? If it's not for a technical reason, I think you should keep the C++ API's names in order not to confuse people (don't forget that the only documentation available is the C++ one).
2. I don't know how events are usually handled in Java, but if there's a "standard" way of doing it, do not hesitate to use it. For example, this is how SFML.Net handles events:
window.Closed += new EventHandler(OnClosed);
window.KeyPressed += new EventHandler<KeyEventArgs>(OnKeyPressed);
window.Resized += new EventHandler<SizeEventArgs>(OnResized);
Same for anything else that might have a more standard syntax than in the C++ API.
By the way, did you have any issue with the GC? In SFML.Net, the graphics objects are destroyed in the GC thread, after the main thread has ended; I had to write a workaround to make it work properly.
-
1. Why did you renamed Shape::Circle to Shape.CreateCircle? If it's not for a technical reason, I think you should keep the C++ API's names in order not to confuse people (don't forget that the only documentation available is the C++ one).
I think that "Create" prefix is handy. If you type "Shape.C" and press ctrl+space you will see list of all predefined shapes and I am thinking of adding few additional shapes like pentagon, hexagon and octagon.
2. I don't know how events are usually handled in Java, but if there's a "standard" way of doing it, do not hesitate to use it. For example, this is how SFML.Net handles events:
window.Closed += new EventHandler(OnClosed);
window.KeyPressed += new EventHandler<KeyEventArgs>(OnKeyPressed);
window.Resized += new EventHandler<SizeEventArgs>(OnResized);
Same for anything else that might have a more standard syntax than in the C++ API.
I do not know C# and have no idea what this code supposed to do and where it supposed to be used. My goal is to have syntax as much similar to C++ as it can be. Only method names (except static ones) and variable names will have small first letter.
By the way, did you have any issue with the GC? In SFML.Net, the graphics objects are destroyed in the GC thread, after the main thread has ended; I had to write a workaround to make it work properly.
I don't have any issue with GC at this moment. Why this GC thread is issue? Does this really matter when those objects are destroyed? If it does please tell me why.
// edit
About documentation. I have in plans to write Javadoc for jSFML so everything will be documented.
-
I think that "Create" prefix is handy. If you type "Shape.C" and press ctrl+space you will see list of all predefined shapes and I am thinking of adding few additional shapes like pentagon, hexagon and octagon.
My advice would be to stick to the original API regarding functions names. But you're the boss ;)
I do not know C# and have no idea what this code supposed to do and where it supposed to be used. My goal is to have syntax as much similar to C++ as it can be. Only method names (except static ones) and variable names will have small first letter.
This code binds functions to events, so that they are automatically called whenever a SFML event is triggered. This is the standard way of handling events in C# (the concept of events is well defined in the language, and there's native support for it). Maybe there's no native or standard way of handling events in Java, I don't know; it was just a general comment to tell you that if a language has native or standard support for a concept, it's better to use it rather than sticking with the C++ API.
I don't have any issue with GC at this moment. Why this GC thread is issue? Does this really matter when those objects are destroyed? If it does please tell me why.
OpenGL is very picky about how and when things are done when multiple threads are invovlved. In particular, you must always have a valid context activated on a thread if you're calling an OpenGL function, and a context can be active only in one thread at a time. Thus, when things happen in the GC thread, there's no OpenGL context available and OpenGL functions can't be called. But if there's nothing wrong with your binding when you exit a graphics application, then it's fine, don't worry about that.
About documentation. I have in plans to write Javadoc for jSFML so everything will be documented.
Great :)
-
1. Why did you renamed Shape::Circle to Shape.CreateCircle? If it's not for a technical reason, I think you should keep the C++ API's names in order not to confuse people (don't forget that the only documentation available is the C++ one).
I also think that names should remain consistent where possible in order to reduce confusion.
But there comes up the question why the factory method Circle() in C++ isn't called CreateCircle()? Here were some people being confused because they didn't know that Circle() is a static function; in my opinion, "Create" would clarify the construction of a new, independent object. ;)
-
I don't know, it sounds more intuitive to me. It looks more like a constructor than a regular function.
-
Here were some people being confused because they didn't know that Circle() is a static function
As you have to write :: …
I don't know, it sounds more intuitive to me. It looks more like a constructor than a regular function.
I agree with you.
-
I don't know, it sounds more intuitive to me. It looks more like a constructor than a regular function.
Okay, I can reconstruct this. Probably a matter of taste... :)
As you have to write :: …
You don't have to. You may invoke static methods with the syntax a of non-static member function call.
-
Here were some people being confused because they didn't know that Circle() is a static function
As you have to write :: …
It still looks like constructor of some other type in sf::Shape namespace. It is not really an issue but i thought that "Create" prefix won't hurt.
I don't know, it sounds more intuitive to me. It looks more like a constructor than a regular function.
I agree with you.
And because this looks like constructor it makes confusion. When I first saw this I wasn't sure whats happening. I thought that Circle is some class inheriting from Shape in sf::Shape namespace and its constructor is called. But I'm not used to C++ syntax and maybe that caused this feeling.
-
Weekly changes report:
- sf::RenderWindow implemented 92%
- sf::Image implemented
- sf::Sprite implemented
-
Java binding code:
Image img = new Image();
img.loadFromFile("bgr.png");
Sprite spr = new Sprite(img);
img = null;
System.gc();
In case above Java Sprite holds pointer to native Sprite which holds native pointer to non existing native Image and result of Java call (for example) window.draw(spr) is undefined. Java Sprite doesnt hold Java Image object instance, so in code above "img" after GC call will be deleted and coresponding native object also. Calling window.draw(spr) can draw just white rectangle instead of image or even crush. I dont like idea of Sprite holding Image instance in Java, but in many cases my approach to objects handling can couse troubles. How similar code would work in C# binding? I have tried to read cs files in C# binding folder, but i have never seen before any C# code and it is hard for me to understand it.
-
I dont like idea of Sprite holding Image instance in Java
But that's the only solution in order to ensure that:
- the sprite can return its Java image
- the Java image is not collected by the GC, because the sprite keeps a link to it
That's how things work in SFML.Net.
-
C++ Sprite.GetImage() returns const pointer to Image. How in SFML.Net is resolved returning "const" objects? Image object returned from Sprite.getImage() in C# can be modified? I dont know how to resolve this in jSFML. In case small objects like sf::Color or sf::Vector are returned new objects with same field values as returned native const object but what to do with big ones like sf::Image or huge sound objects?
-
const-correctness is not a concept that exists in C#, so there's no way of reproducing the C++ behaviour. If it's the same for Java, then you can't help much.
I saw a workaround for C#, but I'm not sure if it's worth it. After all, why should we emulate something that doesn't exist in the language itself?
-
const-correctness is not a concept that exists in C#, so there's no way of reproducing the C++ behaviour. If it's the same for Java, then you can't help much.
I saw a workaround for C#, but I'm not sure if it's worth it. After all, why should we emulate something that doesn't exist in the language itself?
Maybe you are right. I thought that it will be better to recreate C++ functionality than adapt functionality to Java. For the same reason i didnt liked Sprite having Image instance in Java. So what about other getters? If I'm right in SFML.Net Vectors and Colors (because they cannot be const) are copied and copy is returned. Am i right?
Other thing. C++ sf::Image have GetTexCoords() method which returns non const object and C# implementation does not have this method. Why is that?
-
I thought that it will be better to recreate C++ functionality than adapt functionality to Java
I think it is better to stick to the language. People who will use jSFML will be java users, not C++ users. It must look like a native library, not a binding.
So what about other getters? If I'm right in SFML.Net Vectors and Colors (because they cannot be const) are copied and copy is returned. Am i right?
You're right.
Other thing. C++ sf::Image have GetTexCoords() method which returns non const object and C# implementation does not have this method. Why is that?
Some functions are in the public interface of the C++ class, but are for internal use; thus I don't implement them in the bindings. GetTexCoords is one of them.
-
Some functions are in the public interface of the C++ class, but are for internal use; thus I don't implement them in the bindings. GetTexCoords is one of them.
There is no annotation about that. It would be nice to have this annotation in documentation because i dont know which of public methods are for internal use and I implement all public functions. Can you tell me which public functions in all classes are for internal use?
-
Don't worry about that, there are only 3 or 4 functions like this and the others are annotated ;)
-
Static method sf::Image::GetValidTextureSize is unimplemented in SFML.Net. Why? There is no Glyph class implemented in SFML.Net. Why?
View view = new RenderWindow(new VideoMode(240, 320), "calling move will cause crash :(").getDefaultView();
System.gc();
view.move(20, 20);
Consider above code. Will this work in SFML.Net? When destroying render window its view is destroyed also and Java/.Net object is invalid, because it holds pointer to non existing object. When RenderWindow is destroyed in .Net CSFML sfRenderWindow_Destroy is called and this function destroys default view. Am i right? In case above solution is to set default view field holding native pointer to 0 and checking this value in every call. What do you think about it?
-
Static method sf::Image::GetValidTextureSize is unimplemented in SFML.Net. Why?
Because this one is mainly for internal use.
There is no Glyph class implemented in SFML.Net. Why?
Same. But I think that this one should get defined (I think I did it in CSFML).
Consider above code. Will this work in SFML.Net?
I don't know. There's specific code to ensure that this kind of situation works, but I think you're right about the internal pointer being destroyed.
But using a window's view after the window has been destroyed is clearly an error, I'm not sure if we should find a solution for this.
-
Weekly changes report:
- sf::Font implemented
- sf::String2D implemented
- sf::Shader implemented
- sf::RenderWindow fully implemented
- fixed few bugs
-
You should update your working copy, sf::String2D is now sf::Text ;)
-
You should update your working copy, sf::String2D is now sf::Text ;)
I'm working on revision 1283. When I will finish implementing all functionality I will update everything to head revision. But thanks for pointing that :).
-
This would be quite nice. Any updates on it?
-
This would be quite nice. Any updates on it?
Last week i was sick and now are xmas so i think that next update will be in january.
-
I'm so lazy after loong absence in work around xmas... There is some progress in Audio but nothing works for now. I will try to motivate myself and finish working on 1283 revision to start working on head revision in February.
-
Same answer as in the iPhone thread: I need to port the GL context creation, the GL rendering code, all the windowing part, and adapt the public API which is focused on desktop PCs so far (multiple windows, one mouse / one keyboard, etc.).
-
The GL stuff should be straight-forward to port (I have a good abstraction layer in SFML), the hardest part will probably be to adapt the public API of sfml-window :)
-
Any progress? I'm writing a couple of apps in Java and jSFML would come in handy.
-
Any progress? I'm writing a couple of apps in Java and jSFML would come in handy.
I will try to release jSFML for Linux on Saturday. I dont have plans for Windows and MacOSX yet.
-
First release of jSFML is here! Yay! To use SFML in Java download these files:
:arrow: jSFML.so (http://dl.dropbox.com/u/4613360/jsfml/libjSFML.so) native library (Linux)
:arrow: jSFML.jar (http://dl.dropbox.com/u/4613360/jsfml/jSFML.jar) Java jar library
Then you need to:
:arrow: have SFML 2 libraries in "/usr/lib"
:arrow: add jSFML.jar to classpath in your Java project
:arrow: include following line in your code
System.loadLibrary("jSFML");
:arrow: run your Java program with special parameter for java describing where is jSFML.so file located
-Djava.library.path=/some/example/path
Sample code here (http://ideone.com/cKOAATjG).
Happy testing! I'm waiting for JVM crash reports! :)
PS. About prevoius post. I was thinking about sunday. I have no idea why i wrote saturday ;).
-
Windows version available for download from:
:arrow: here - jSFML.dll (http://dl.dropbox.com/u/4613360/jsfml/jSFML.dll)
If you will get some mysterious external dependency error while running Java app make sure that you have libsndfile-1.dll in one of these directories:
:arrow: Window
:arrow: Window\System32
:arrow: app home directory
And dont forget about:
-Djava.library.path=/some/example/path
or this line if you have jSFML.dll in Java app home directory
-Djava.library.path=./
Happy testing :)
-
Great work. Why don't you release the source code so that everybody can build their own Java library?
-
Great work. Why don't you release the source code so that everybody can build their own Java library?
I don't think that jSFML is ready for release yet. There are no makefiles so there is no easy way to build it under Linux, there is no good solution for building on Windows and there is nothing for MacOSX. Code needs cleanup. There are no javadoc entries in Java code. Still few functions are not implemented. I want to prepare it to be easy to modify and maintain and then release it. And of course doing all this i want to learn a whole bunch of new thing :). For few weeks you will have to depend on libraries provided by me. Or few days ;).