Messages

226

Java / How to build JSFML

« on: January 30, 2012, 10:54:09 pm »

Nice you're going for it!

Am I supposed to do something specific with PROPERTY_JSFML_BIN ?

That property I believe can safely be ignored. I realized that I will not want people to tamper with it. I should probably remove it to avoid this type of confusion.

SFMLNative checks the classpath for the "bin" folder, from which it will load the libraries specified after OS and architecture detection. Note that load order is very important here, but this doesn't seem to be your problem. From there, it will extract the binaries to the user .jsfml directory. This way I can contain all binaries for all systems in a single file and people don't have to bother.

for windows and linux you add "linux_x64/libjsfml.so" to nativeLibs. What is this library ? I can't find it.

JSFML also has C++ sources which do the actual delegation to SFML, and those are compiled and linked into jsfml.dll / libjsfml.so using the "win32", "win64", "linux32" and "linux64" targets in the ant buildfile. You will need to compile those sources into a dylib as well.

Code: [Select]

Exception in thread "main" java.lang.UnsatisfiedLinkError: org.jsfml.SFMLNative.nativeInit()V
   at org.jsfml.SFMLNative.nativeInit(Native Method)
   at org.jsfml.SFMLNative.loadNativeLibraries(Unknown Source)
   at org.jsfml.SFMLNativeObject.<clinit>(Unknown Source)
   at ShortExample.main(Unknown Source)
This is the missing libjsfml.dylib you need to create from the C++ sources.

Just to be sure, nativeInit is defined as Java_org_jsfml_SFMLNative_nativeInit in C++, right ?

Yes.

"One of the two will be used. Which one is undefined." warning happens because libsfml-window.dylib was loaded twice.

Why does that happen? I'm not sure how Mac OS X's Java ticks concerning libraries, but my guess is that if you load libsfml-graphics.dylib, it automatically loads the dependencies before that (it doesn't do that on Windows and Linux). Try removing the "libsfml-window.dylib" from the nativeLibs list and see what happens.

I guess you used some kind of "make install" when building SFML? It's not good if it suddenly uses a dylib from elsewhere, this might cause bad incompatibilities. Not sure what we can do about this.

227

General / SetFramerateLimit does not seem to work correctly

« on: January 30, 2012, 06:22:30 pm »

This does not seem to happen on Ubuntu 10.04, 32 bit (tested inside a VM, but it runs very smoothly and I can increase the FPS at will and it works fine).

228

General / SetFramerateLimit does not seem to work correctly

« on: January 30, 2012, 06:13:27 pm »

Likely related to https://github.com/SFML/SFML/issues/162 (saw this after I wrote this post, sorry)

I noticed oddities while working on JSFML. I set my window's framerate limit to 60, but in fact my test application runs at about 120 FPS. In fact, it varies. Sometimes, the application also runs at 100, I had times where it would only run at 30 for a while, then all of a sudden go up to 120.

I'm not sure what exactly might be the problem, but here is how I can reproduce it:

Code: [Select]

#include <SFML/Graphics.hpp>

int main(int argc, char **argv) {
sf::RenderWindow window(sf::VideoMode(640, 480), "FPS Test");
window.SetFramerateLimit(60);

int numFrames = 0;
int msLeft = 1000;

sf::Event e;
sf::Clock clock;

while(window.IsOpen()) {
while(window.PollEvent(e)) {
if(e.Type == sf::Event::Closed)
window.Close();
break;
}

sf::Time delta = clock.Restart();

numFrames++;
msLeft -= delta.AsMilliseconds();

if(msLeft <= 0) {
printf("Frames last second: %d\n", numFrames);

numFrames = 0;
msLeft += 1000;
}

window.Clear();
window.Display();
}

return 0;
}


This is counting the actual frames within 1000 milliseconds. Unless I'm totally out of my mind this should be a working way to test the FPS. I'm aware this is not perfectly accurate, but it should not be counting 120 frames anyway.

My output of that program a few minutes ago looked as follows (Windows 7 32 bit, Release, latest SFML from github):

Code: [Select]

Frames last second: 115
Frames last second: 124
Frames last second: 114
Frames last second: 115
Frames last second: 121
Frames last second: 117
Frames last second: 115
Frames last second: 120
Frames last second: 119

229

Java / Java integration features

« on: January 29, 2012, 08:16:23 pm »

I just did a little experimenting with synthesizing mouse events and passing them to a root component. It works perfectly! Even focus traversal seems to work correctly (that is, focus within the Swing focus manager, I am not yet sure what happens to the actual OS focus). I believe keyboard events (in the end it only comes down to mouse and keyboard events) will not be any more problematic.

Translating SFML input events to AWT events should be easy and not performance expensive. So I think this feature might become reality. All I need to do is find a quick way to convert AWT images to SFML textures.

230

Java / How to build JSFML

« on: January 29, 2012, 04:59:07 pm »

I finished the build targets for Linux, concluding my mission to setup a complete building toolchain. Mac OS X is not on the list of targeted systems yet.

231

Java / Java integration features

« on: January 29, 2012, 11:35:18 am »

How will focus/keyboard/mouse things work?

I guess the only way to accomplish that is to eat SFML input events and somehow emulate AWT events and give them to the components. This will need a good amount of experimentation, I'm not sure how well this will work. But I can't really imagine that it isn't doable.

232

Java / Java integration features

« on: January 29, 2012, 09:38:50 am »

SFML, in C++ and other languages, provide a Window/RenderWindow constructor which can take a handle to an external canvas. This is usually enough. Why do you need to provide a dedicated class in Java? Does it require more complicated code?
A potential problem that I can see, is that you will have to provide two versions: a canvas that is a Window, for OpenGL only, and one that is a RenderWindow, for using the graphics module.

On a Java level, there is no way to get a window's handle. Also, not every Swing window or panel has a window handle. It's what I had worked on before, if you remember. The problem was getting the actual handle, and then there were a good amount of issues concerning event handling (because both SFML and AWT override GWLP_USERDATA, I was able to fix this and it already worked fine on Windows).

Good luck
It is usually not allowed to draw on top of an OpenGL area with non-OpenGL functions.

The only idea I have so far is to let Swing render its controls and then convert the result to a SFML texture. Rendering them to an image is perfectly doable, so there should be nothing speaking against this idea other than possible performance issues. I will definitely give this a try.

233

SFML projects / JSFML - A Java binding for SFML

« on: January 29, 2012, 09:02:53 am »

I changed the build system now to use MSVC++ on Windows, this way 64-bit is possible and works fine. I got rid of the cpptasks Ant plugin, it's just of no proper use if you want to compile with MSVC++.

More details: http://www.sfml-dev.org/forum/viewtopic.php?t=6906
Working on Linux right now.

234

Java / How to build JSFML

« on: January 29, 2012, 06:46:23 am »

The guide to build JSFML has been moved to the Github Wiki: https://github.com/pdinklag/JSFML/wiki/Building-JSFML

Discussion should still happen here.

235

Graphics / Flipped RenderTexture

« on: January 29, 2012, 04:51:15 am »

You need to call Display() before actually using it, I had the same problem before.

236

Java / Java integration features

« on: January 29, 2012, 04:34:29 am »

While the first release of JSFML will be more like a direct binding to SFML standing by itself, in later versions I would like to build up a range of features to integrate JSFML into Java environments.

Generally, to be able to tell apart between pure SFML bindings and Java integration features, new classes for this task will get a different root package. I am still split about whether to call it org.sfml.java or simply org.jsfml, but I'm leaning towards the latter.

What follows below is a list of goals I want to achieve, a todo list so to speak, which I would like to discuss and possibly extend using this discussion thread.

• RenderCanvas
  This feature will be a major milestone. It is a Java canvas that can be used as an SFML render window, thus making it possible to have OpenGL contexts in any Java AWT / Swing user interface, including browser applets.
  
  
• Type conversions
  I will introduce several conversion methods between common SFML and Java AWT types. This includes:
  • org.sfml.graphics.Color ↔ java.awt.Color
    
  • org.sfml.graphics.FloatRect ↔ java.awt.Rectangle
    
  • org.sfml.graphics.Image ↔ java.awt.image.BufferedImage
    
  • org.sfml.graphics.IntRect ↔ java.awt.Rectangle
    
  • org.sfml.system.Vector2i ↔ java.awt.Point
    
  • org.sfml.system.Vector2f ↔ java.awt.Point
    
  The conversion methods will come as special copy constructors and toXYZ() methods in the SFML classes.
  
  
• Implementable Drawable class
  This will be an abstract subclass of org.sfml.gaphics.Drawable, allowing custom drawables to be implemented in Java. This can be used to create simple extensions of existing drawables such as compounds, but also to create a possible link between JSFML and LWJGL, which would also allow 3D rendering via JSFML.
  
  A note on that: JSFML is not to be seen as some sort of competitor to LWJGL. LWJGL focuses on providing direct access to OpenGL, OpenAL and OpenCL functions for Java, while JSFML focuses on providing a binding to the straightforward SFML library. There are some aspects that are covered by both libraries (especially concerning input), but in such cases, the user has to decide what to do.
  
  
• Implementable SoundStream class
  This will be an abstract subclass of org.sfml.audio.SoundStream, allowing custom sound streams to be implemented in Java. This will make it possible to write MP3 decoders in Java, for example, and makes JSFML less dependent of C++ source code. A subgoal of this should be to attempt and connect JSFML to Java's sound API (which I do not know too much about yet). That way, any already existing sound decoder library available for Java could also be used for JSFML.
  
  
• AWT / Swing component rendering
  This is still more of a brainstorming, I am not entirely sure how well this will be possible. The idea is to make it possible to render and possibly even manage AWT / Swing components within an SFML render window. This would be the perfect way to create complex GUIs within JSFML applications, using a toolset every Java developer should be perfectly used to. Since it would also support Java LookAndFeels, there would be practically no limits concerning styles either.
  

237

SFML projects / JSFML - A Java binding for SFML

« on: January 28, 2012, 07:12:20 pm »

I will change the build process to use Microsoft's Visual C++ compiler for Windows again, because I can't figure out how to build the SFML dependencies using mingw-w64.

The Windows SDK with C++ compilers should suffice to build JSFML then, the Visual Studio should not be required. However, it will probably be required to build SFML itself... anyway, more details will follow.

238

SFML projects / JSFML - A Java binding for SFML

« on: January 24, 2012, 09:36:59 pm »

So you build SFML using Microsoft Visual C++ and JSFML using MinGW? Mixing those is probably not a good idea at all.

Still, it should be compilable. I'll look into setting everything up for 64-bit building, but I won't be able to test it until somebody builds the SFML dependencies for MinGW as 64-bit.

239

General discussions / SFML 2.0 vector of drawable

« on: January 24, 2012, 02:44:19 am »

Hm, true, since transformations are also part of render states, there is no problem really. You'd just have to manage your own structure keeping both the Drawable and the render states.

Got to arrive at SFML 2.0 property.

240

General discussions / SFML 2.0 vector of drawable

« on: January 23, 2012, 08:42:40 pm »

I have thought about this exact connection between Transformable AND Drawable myself, and in the same context (polymorphism).

The question I couldn't find an answer to is what to call it... TransformableDrawable? Anyway, I would like if SFML could provide this additional abstraction layer. Not necessarily because it'd be better design or anything, but because of its practical use.