Messages

91

Window / Re: Thread-local sf::Context

« on: March 15, 2013, 01:37:14 pm »

I'm not entirely sure how sf::Context is used, obviously. You are right about the first two points, it won't matter if it is "slow" when it's not used often (the term "slow" I used very loosely here, it's just really slow compared to an opeation on a pure Java level, simply because of the overhead generated when calling native methods).

However, the graphics module does not seem to take care of creating a context automatically for me.
One piece of evidence was provided in http://en.sfml-dev.org/forums/index.php?topic=10452.0, where textures could not be loaded in a separate thread unless a Context instance was created, and just recently I realized that I cannot load textures before creating a window or a Context (I would end up with white squares when used as a sprite).

Is there anything I might have done (accidentally) to prevent that from working?

92

Window / Thread-local sf::Context

« on: March 15, 2013, 07:18:27 am »

I am currently trying to optimize the Context class in JSFML.

Right now, to acquire a valid context, the approach is exactly like in SFML: you create a new instance of the class to ensure there is an active context on the current thread and can also use it to explicitly activate or deactivate it. However, that is relatively slow, because creating the "C++" (native level) SFML object causes quite some overhead, which cannot be avoided other than minimizing the amount of communication done (much like in networking).

My idea was to cache any Context instance created thread-locally, so that any subsequent creation on the same thread would simply return the current thread-local context. This turns out to be blazingly fast, however, I believe this means that any context stays active unless somebody explicitly deactivates it using "setActive", because the object will not be garbage collected and destroyed on a native level (at least not on long-running threads like the main thread).

Is that correct and, more importantly, is that a problem?

93

Graphics / Mistake in sf::Image::copy?

« on: March 13, 2013, 04:24:06 pm »

I just noticed the following piece of code in sf::Image::copy (Image.cpp line 176 and 177):

if (srcRect.width  > static_cast<int>(source.m_size.x)) srcRect.width  = source.m_size.x;
if (srcRect.height > static_cast<int>(source.m_size.y)) srcRect.height = source.m_size.y;

The source rectangle may still be larger than the source texture this way (e.g. if srcRect.left > 0 and srcRect.width = width of source image).

I suppose what was meant is this:

if (srcRect.width  > static_cast<int>(source.m_size.x) - srcRect.left) srcRect.width  = source.m_size.x - srcRect.left;
if (srcRect.height > static_cast<int>(source.m_size.y) - srcRect.top ) srcRect.height = source.m_size.y - srcRect.top;

94

Java / Re: Attempt running jsfml-test.jar, UnsatisfiedLinkError

« on: March 13, 2013, 08:30:45 am »

I think I have seen people do that, come to think of it. Would you recommend following suit and including it in there somewhere? Also, what function does it serve in this case?

If you are actually shipping a game, you might as well include it in your release package.

What function it serves is not 100% clear to me, that's why I will look into avoiding the dependency. My best guess is that the dependency is caused by some Visual C++ default setting. Instead of statically linking certain functionality, it is linked dynamically. The result is a smaller dll file which, however, depends on those Visual C++ runtimes.

For Linux, would you recommend also including those other libraries? My main concern here is, I don't want there to be an error that cannot be fixed, say if the application cannot start, it cannot report an error, either, but they don't know why - OR, Linux users are used to it and just add it at download and/or in a readme.

"Those other libraries" are most likely already present on most (updated) Linux clients. I only encountered problems with libGLEW (of which there are many different versions around) and libjpeg (because distributions like Fedora only know libjpeg-turbo) (note that in the current test release, they are not included because of a little mistake I made).

In case the other dependencies are not available, users will have to download them. It's not possible for you to include them I fear, most distributions only allow proper installation of things via their package manager. Your best guess is to include a list of dependencies which users need to make sure they have. The next JSFML test release will include those dependencies in the readme file.

Users do still get an error message, though. It would look similar to yours, and that is reportable. Besides, errors can also be caught on a Java level. If you wish to do that, the first thing you should do before using any JSFML objects in your application is this:

try {
    SFMLNative.loadNativeLibraries();
} catch(JSFMLError err) {
    //report the error into a log file, display a message dialog, whatever
}
 

That method is automatically executed anytime a "native" object is created. If you do it manually, you have the ability to catch any errors that occur.

Read about that, yes. Although... I had thought double clicking jars (on windows, not sure about mac), does not do it - opens it as text. Setting default program, perhaps. Anyway, is there any good cross platform way to detect the java installation ( jre) directory? I would go java -jar somejar.jar, but that only works with java on the path.

Double-clicking on JARs is a windows feature IIRC. On Macs, I have no idea, but most Linux systems will detect the JAR file as a zip and open it with an archive editor by default.

From waht I know, wherever Java is installed, "java" is on the classpath, so doing "java -jar game.jar" should be safe anywhere.

95

Java / Re: Attempt running jsfml-test.jar, UnsatisfiedLinkError

« on: March 12, 2013, 06:19:34 am »

Ah. That did the trick - neat demo, also. The drop from 60-63 to 55 only occurred at about 1000 entities.

I'm currently working on some major performance improvements, so that number might in fact be twice that soon.

Anyway, I had thought that most things branded within VisualC++ were Windows only. You say if you are on windows, though, which seems to imply it is not the case elsewhere. If I were to distribute this, what would I need to include with it?

For Windows, indeed, the Visual C++ redistributable is required. Many clients will already have it installed as many games ship with it. I will look into avoiding the dependency, but I have a feeling that it would increase the size of the DLLs a lot.

Linux users will require nothing but Java 7 - hopefully!
libjpeg and libGLEW are linked statically (= included in JSFML) because they have caused me quite a few headaches with certain distributions. The other dependencies (e.g. libpng, zlib, libgl) should be available on any common Linux client. On some distributions, it's not that easy to acquire Java 7 (by "easy" I mean a standard software update via the distribution's repository).

Linux, in general, is still a large question mark, mainly because there are so many distributions and I'm not the greatest of experts. On the "main" distributions out there, which I consider Ubuntu and Linux Mint, JSFML works out of the box.

Mac users should not require any additional packages either, however, I cannot test the Mac version myself. What I do know is that developers need to provide a starting script for Mac users, because on Macs, the JVM needs to be started with the "-XstartOnFirstThread" option. Apple is to blame here, there is nothing that I know that JSFML can do.

96

Java / Re: Attempt running jsfml-test.jar, UnsatisfiedLinkError

« on: March 11, 2013, 07:13:57 am »

Yes, JSFML unpacks the DLLs itself and putting them in the working directory will not help.
From your post I gather that they have actually been extracted to "C:\Users\Kids\.jsfml\windows_x64\" ? (7 dll files, accompanied by an MD5 file each)

The error message is "Can't find dependent libraries" - I have a feeling that you might have missed one requirement: on Windows, you do require the "Microsoft Visual C++ 2012 Redistributable Package". Since you seem to be running a 64-bit system, here's where you can grab that package:
http://www.microsoft.com/en-us/download/details.aspx?id=14632

I forgot to put this information into the readme, I will add it later today. Currently, it's "hidden" on the Github page. 

I hope this resolves your problem.

97

General discussions / Re: SFML bindings (information for the new website)

« on: March 10, 2013, 12:15:09 pm »

JSFML is for Java 7 and based on SFML 2.0.

The latest test release based on a snapshot from early February should be working on all "major" operating systems (Windows, Mac OS/X and at least Debian-based Linuxes, needs a lot more testing and feedback). It currently lacks updates, but that's because I'm in a exam-heavy phase.

The API is mostly complete and fully functional (as tested) and only lacks SFML's February and March changes. Future changes for a release candidate will face performance and cross-platform compatibility.

The website is http://www.jsfml.org/
The design and logo (see attachment) might be changed once a new SFML logo has been determined. I wanted it to look a bit like Oracle's Red, it hasn't much to do with the original SFML one.

Author: Patrick Dinklage (pdinklag at gmail dot com)
Mac OS/X Support by Hiura / mantognini



[attachment deleted by admin]

98

General discussions / Re: A new logo for SFML

« on: February 02, 2013, 01:07:59 pm »

Hihi

just clean and simple!

And a guaranteed lawsuit by Microsoft...

99

Java / Re: Obligatory 'loading resources on a thread' post.

« on: January 30, 2013, 09:15:59 am »

Hard to do if I can't reproduce it, as said, the code olie258 posted works just fine here. I hope I can reproduce it on those Debian machines at university. I will try that tomorrow.

100

Java / Re: Obligatory 'loading resources on a thread' post.

« on: January 30, 2013, 09:00:18 am »

I was using a rather old binding version on that Debian I spoke about, so I didn't really bother investigating.
The test release I did yesterday contains the latest SFML 2 snapshot.

So I guess I will need to provide a way for Java users to call glFlush() for cases like this. IMO it would fit best as a static method in the "Context" class (it can't be a class-less definiton like in C), because I'd rather not create GL classes.

101

Java / Re: Obligatory 'loading resources on a thread' post.

« on: January 30, 2013, 08:45:03 am »

I can also confirm that the code initially posted works fine here without any context activation
(Win7 64-bit, Intel HD Graphics), but I did have a similar problem on Debian a few days ago.

I'm not sure about glFlush, but you can't call it from Java directly unless I provide it. Why would that be needed on some systems and not on others?

102

Java / Re: Obligatory 'loading resources on a thread' post.

« on: January 30, 2013, 07:58:44 am »

Oh, finally somebody giving this a try.

The problem is that the texture is being created "out of context". The OpenGL context created by your RenderWindow is only active in the main thread, so the solution is to activate it in the worker thread before the texture is being loaded.

This should work, but I have actually never tried it so far:

import org.jsfml.window.Context;
[...]

        // On another thread, create a Texture from an image file then cache it
        Thread worker = new Thread(new Runnable() {
            public void run() {
                Context context = new Context();
                Texture texture = new Texture();
                try {
                    texture.loadFromFile(Paths.get("canyonlands_large.jpg"));
                } catch (IOException e) {
                    e.printStackTrace();
                }
                cache.put(KEY, texture);
            }
        });

By creating an instance of the Context class in the worker thread and by keeping it alive (by defining it for the entire run() method), the OpenGL context is activated for that thread and your texture should be created properly.

This should definitely be worth a Wiki article.

103

Java / Re: Maven repository ?

« on: January 21, 2013, 01:57:32 pm »

Same here, got exam phase at university soon and am therefore pushing this back until then.
Thanks for all the information though, they should help me get started.

104

Java / Re: Maven repository ?

« on: January 16, 2013, 08:03:28 am »

Sorry for the late reply.
It looks like I have to learn more about Maven, and at the moment I don't have too much time to do that. I may find some room for that in late february.

So if you don't mind, just use the JAR release for now.
In case you're willing and able to get a Maven setup running, feel free to do a pull request on github. For now, I opened this issue to remind me: https://github.com/pdinklag/JSFML/issues/45

105

Java / Re: Maven repository ?

« on: January 11, 2013, 03:12:42 pm »

There should be no reason to generate the headers. That's only necessary when any of the SFML API changes. The generated headers are checked in and can remain untouched.

The vital build processes are "ant compile" (compile the java sources) and the targets to build the C++ sources, which uses the already generated headers. For that, there should also be no need.

The idea is that users simply grab the release JAR file and put it in their classpath. Building the JAR and binaries yourself doesn't give you any advantage. You'd have to build the binaries for all kinds of operating systems (Windows 32 and 64, Linux 32 and 64, Mac OS X). That's the job I do for users and the result is jsfml.jar.

So I think a simple maven repository that lists the releases and snapshots should be enough?