Messages

106

Java / Re: Maven repository ?

« on: January 10, 2013, 06:02:36 pm »

Hey, thanks for your feedback!

To be honest, I have no idea about using Maven.
What exactly do you mean by "mavenizing" JSFML and what would I have to do to achieve that? Is it enough to place a pom.xml into the root directory? What should that contain?

I am not really planning to build JSFML itself using Maven, but if there's any way I can make JSFML work with Maven, I'll be happy to cooperate.

107

Java / Re: RenderCanvas on X11 and Cocoa

« on: January 03, 2013, 08:46:46 pm »

There are some issues that remain before the RenderCanvas can be merged into the master branch.

In the render-canvas branch, the JSFML binary depends on the Java AWT binaries. However, those might not be available everywhere. For instance, you can install a headless JRE on a Linux machine and end up without the AWT binaries.

I am not quite sure how to proceed here. SFML is a multimedia library, and a headless environment practically does not need that. However, you might want to use some of the SFML classes for server code, e.g. Vector2f for synchronized entity positions, to name an example.

A very easy fix would be a separate lightweight JSFML package called "jsfml-headless" for those environments. It would only contain data classes like Vector2f, Time, etc.  Those are all implemented in pure Java anyway, so that package would not even require any of the complicated binary loading and take a few kilobytes at max. It would be similar to SFML's "system" binary, JSFML is not as strictly modularized.

Other than that, there has been zero progress for Mac OS X yet and I did not do any testing yet concerning browser applets. I'd love to include this feature in the first release, but these have to be resolved first. The binding is finally shaping up now and I will spend more time on this branch in the near future.

108

Graphics / Re: How to best handle Textures

« on: January 03, 2013, 05:09:48 am »

If I draw 50 sf::Sprite in immediate succession (i.e. nothing drawn in between them) would the drawing be faster if all 50 were set from the same texture (but potentially different texture rectangles), than if all 50 had individual textures?

I'm aware in pure OpenGL the above would be faster due to not having to re-bind textures for drawing, but I'm not 100% familiar with all the code in SFML (especially 2.0 RC), so I'd thought I'd ask directly.
Thanks.

Yes.
SFML binding a texture should not be alot different from what you'd do in raw OpenGL code.

109

Java / Re: Writing Tutorials

« on: January 02, 2013, 05:04:09 pm »

Sorry, I deleted the page a few days ago in WinSCP. 
It's back on now. The tutorials are in the github wiki anyway: https://github.com/pdinklag/JSFML/wiki

And thanks for the hint - I thought I killed all the remainings of the old domain.

110

Java / Re: Writing Tutorials

« on: January 02, 2013, 01:39:28 pm »

Thanks for the feedback.

If they are that good, maybe they can help out Laurent progress with the SFML 2.0 tutorials. The code changes required would be minimal for C++, but I guess that style is the most complicated question for that matter.

Chapters 13 through 15 are done now. 14 (Drawables and RenderStates) might require some feedback, since I wasn't able to test it yet and there is a lot of explanation in there. The Shader tutorial isn't really long, because I can't possibly explain GLSL in there. Instead, I gave a short example on a post effect.

111

System / Re: Access violation in sf::String destructor (empty string) on Debian Squeeze

« on: January 02, 2013, 07:47:03 am »

Good thing that there's a hint now!

Though, I do compile both SFML and JSFML on the same system. I would not know why the libc version should change between the two build processes.

The only thing I could imagine is that the Java Virtual Machine itself was built with a different libc. In that case, I am probably mightless, unless I downgrade to that version (if I can even find out which it has been compiled with).

EDIT:
Then again, if the destructor is inlined, the JVM's libc version should not really matter, since the function executed is still in my module.

112

System / Re: Access violation in sf::String destructor (empty string) on Debian Squeeze

« on: December 31, 2012, 09:16:27 am »

Just fyi, I "fixed" this by using std::string("") instead of sf::String("").

I still have no idea what caused it, and I agree that it's unlikely to be a bug in sf::String after having looked at the code. It might be an issue with basic_string in a particular glibc version, but I have not compared the versions yet.

If nobody else has this issue, I guess it's all fine.

113

Audio / Re: Slow music loading

« on: December 18, 2012, 02:01:50 am »

Thanks!
I hope a suitable solution can be found for that floating point format at some point as well.

114

Audio / Re: Slow music loading

« on: December 17, 2012, 07:47:28 pm »

Was the change ever reverted? It doesn't seem so to me.

I just noticed that opening a music (ogg) from a stream took AGES (it's 15.8 MB in size, takes about 7 seconds to load). I analyzed it, and indeed the whole stream is being iterated over before "openFromStream" is done and the application continues. This practically nullifies the "instant play" advantage that streaming offers.

While cracking .ogg files are something a developer can fix if he informs himself about the supported formats, people who are not affected by that issue now suffer from immense loading times. Besides, you only need to "fix" / convert your .ogg file once to resolve the issue for good, but the way it is now everyone needs to wait every single time the application starts. I think a bit of responsibility can be left to those who opt to use .ogg files. This is definitely not worth the cost.

115

System / Re: Access violation in sf::String destructor (empty string) on Debian Squeeze

« on: November 28, 2012, 07:06:25 am »

Nope, that's highly unlikely here.

I pass an empty Java String to the setString method, which does security checks (e.g. makes sure the string is not null) and delegates the call to that native method I pointed to. To make sure there are no problems converting an empty string, I caught that case and construct an sf::String with an empty ANSI C string (that line #75).

In that case only I get said "invalid pointer" in libc's free() method. It works perfectly well with any non-empty string.

There are no pointers or references that have to be held anywhere (like in the Font class, where I need to keep the font data in memory as long as the font is in use), since iirc, the sf::String::setString method creates a copy of the string passed to it for its own (in Uint32 / unicode). So garbage collection can most probably be ruled out here.

If I didn't link the binaries on a Debian i686 myself, I'd say maybe it's an incompatibility of sorts, but I built the JSFML binaries in a Debian Squeeze VM and the issue doesn't occur there. Which makes this whole problem a real pain to analyze...

116

System / Access violation in sf::String destructor (empty string) on Debian Squeeze

« on: November 27, 2012, 07:03:17 pm »

Testing JSFML on a university machine, I ran into an access violation when setting an empty string on a Text. I added some debug info output and it turned out this way:
http://pastebin.com/fJHQHFdt

The native method that sets the string on the sf::Text object suceeds, however, after doing so it crashes. Apparently, the destructor of the locally allocated sf::String runs into a free() call for something that was never allocated.

The operating system on the machine in question is Debian Squeeze. More exactly:

Code: [Select]

$ cat /etc/lsb-release
DISTRIB_ID=Debian
DISTRIB_RELEASE=6.0
DISTRIB_CODENAME=squeeze
DISTRIB_DESCRIPTION="Debian 6.0.6"
$ uname -a
Linux fiws185 2.6.39-bpo.2-686-pae #1 SMP Fri Feb 3 17:37:38 CET 2012 i686 GNU/Linux
I failed to reproduce this in a VM with Debian Squeeze (slightly older and modded Kernel version) and I have never observed this on Windows (obviously, as it seems to be something in glibc that fails).

The code in question is this: https://github.com/pdinklag/JSFML/blob/master/src/cpp/JNI/org_jsfml_graphics_Text.cpp#L75

In Java, a minimal code sample to reproduce the problem would be:

new Text().setString("");

I assume that a C program as simple as that would result in the same error, but I did not have the time yet to set up an SFML working environment on that system yet (compiling SFML on it won't be possible due to the lack of rights to install dev packages).

Can anybody give me a hint on what may be going wrong or can anybody maybe even confirm this?

117

Graphics / Re: sf::Image -> sf::Texture -> sf::Sprite slow process

« on: November 23, 2012, 05:38:05 pm »

Is there a way to avoid loadFromImage without removing the createMaskFromColor functionality?

Other than storing your tileset in a 32-bit color format that has an alpha channel (e.g. PNG), no.

Concerning the "slowness" - I second FRex' question. What exactly do you mean by slow?

118

Java / Re: Possible to create an extension

« on: November 05, 2012, 06:27:44 am »

You might be able to do it using JSFML / JOGL if you got that running, but if you want to port your C / C++ code, you will have to go the same painful way that I go and link dynamic libs for each system.

Does the term "extension" refer to something special? Are you writing an OpenGL extension? Or are you just planning to add additional classes? In the latter case, just create your own package (preferably following the package naming standards), and create a build target that puts your package into a JAR file. From that point on, you can distribute and use that package in any other project much like JSFML.

119

Java / Re: Final members on vertices and vectors

« on: October 28, 2012, 07:21:35 am »

Efficiency / performance had absolutely nothing to do with this decision or really any design decision.

I made data structure classes like these immutable a while ago because they should be. There is no such thing as "const" in Java, so whenever you pass a vertex anywhere, it could be modified and break stuff. That's bad design, that's why I made this change.

Also, how is

this.vertices = new Vertex[4];
this.vertices[0] = new Vertex(new Vector2f(-0.5f, -0.5f), new Vector2f(0.0f, 0.0f));
this.vertices[1] = new Vertex(new Vector2f( 0.5f, -0.5f), new Vector2f(1.0f, 0.0f));
this.vertices[2] = new Vertex(new Vector2f( 0.5f,  0.5f), new Vector2f(1.0f, 1.0f));
this.vertices[3] = new Vertex(new Vector2f(-0.5f,  0.5f), new Vector2f(0.0f, 1.0f));

any more painful than, say,

this.vertices = new Vertex[4];
this.vertices[0] = new Vertex();
this.vertices[0].setPosition(new Vector2f(-0.5f, -0.5f));
this.vertices[0].setTexCoords(new Vector2f(-0.5f, -0.5f));
this.vertices[1] = new Vertex();
this.vertices[1].setPosition(new Vector2f(-0.5f, -0.5f));
this.vertices[1].setTexCoords(new Vector2f(-0.5f, -0.5f));
this.vertices[2] = new Vertex();
this.vertices[2].setPosition(new Vector2f(-0.5f, -0.5f));
this.vertices[2].setTexCoords(new Vector2f(-0.5f, -0.5f));
this.vertices[3] = new Vertex();
this.vertices[3].setPosition(new Vector2f(-0.5f, -0.5f));
this.vertices[3].setTexCoords(new Vector2f(-0.5f, -0.5f));

? (Nevermind the wrong coordinates, I just wanted to illustrate that you'd end up with 3 times as many lines)

The only point where this really gets painful is when you re-iterate and want to change vertices. Instead of changing single properties, you'll have to create a new instance. That's a little annoying, yes, but safe and predictable code should be preferred over slightly shorter code.

120

Java / Re: Unable to find native library libsndfile-1.dll

« on: October 21, 2012, 07:31:14 pm »

Not insanely huge.
At the moment, I plan on packing up Windows, Debian and Mac OS X libraries. Total size is about 3.5 MB then.

When there's a release, all those binaries will be in it so users won't have to worry about that.