Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - pdinklag

Pages: [1] 2
Java / Sorry, I'm out
« on: January 19, 2016, 10:34:24 am »
I guess I should finally make this official: I won't continue developing JSFML.

This is difficult for me on one hand, but on the other hand it will make my life easier and make things clear for people wondering what is going on here.

To answer the latter - nothing is going on with JSFML from my side. I am packed with work - producing music, running a small music label, studying and working at the university - and last but certainly not least, there's life itself. I have not been using Java in almost a year now, because my job changed and I grew to hate Oracle's BS. There is no development environment for JSFML that I maintained. Building the native stuff for multiple environments has been a major pain, because I have no frequent Linux system nor a Mac. To make things worse, apparently, SFML cannot be built on Windows 10 / VS 2015 without additional efforts - so my Windows environment is nixed for SFML as well.

Each time I try to motivate myself to get JSFML updated, I hit on issues like this and it plagues me. I have no use for it myself anymore and thus, I decided to just drop the burden now. Everything is on Github, so whoever wants to pick up on it: please go ahead! I'll be available to answer questions about how it works.

I apologize to those who rely on JSFML and were hoping for timely updates. Thank you for your interest in the project!

Edit by eXpl0it3r: Archived website

Java / JSFML for SFML 2.2
« on: December 18, 2014, 06:53:11 am »
This is just a little sign of life. ;)
Life is keeping me very busy these days, I hope that I can find some time to update JSFML for the new SFML release sooner than later.

From what I've seen, there are not many API changes, so it should all go relatively quick once I find some time.

The problem will be - as always in the past - building and packaging the native (C++) part. I don't have any Linux development systems I use regularly, so the ones I used last are heavily outdated. I also don't own a Mac to build the OS X version. If anybody could help out here, I'd highly appreciate it.

Java / Test Release #5
« on: December 02, 2013, 08:02:19 pm »
I just uploaded another test release of JSFML which addresses the vertex array limit (it is lifted) and fixes some serious bugs concerning floating point conversion between Java and native code.

It's available here: http://jsfml.org/?page=download

At the moment, there is no way for me to provide a Mac OS X version.  :-\

Java / Test release #4
« on: July 31, 2013, 06:40:44 pm »
I have just uploaded test release #4 to the download page. This release is based on SFML 2.1 and should contain all its fixes. Apart from that, Hiura was kind enough to provide me with a Mac OS X build, so this release should work with Mac OS X once again!

Due to problems with Virtual Box, I could not really test this release on Linux systems, however, support for Fedora 32-bit has already been confirmed, so I suppose it will be fine.

There has been one problem reported of JSFML (supposedly) generating unsupported GLX commands on Linux, but no driver or hardware details (other than "ancient") have been provided. If anybody gets these kinds of errors, please try to give some detailled info and, if possible, check whether an equivalent SFML application (C++) behaves in the same way.

Java / Test for test release #4
« on: July 28, 2013, 11:41:56 am »
Yep, you read that right.

I have just updated JSFML to SFML 2.1, but I have run into real trouble with Oracle's Virtual Box. The guest additions of the latest versions do not seem to work well for Debian 7 at all, the result is that OpenGL does not quite work and I am currently not able to test JSFML on Linux systems. Until that is resolved, I will release test versions for the test releases right here...

I'd highly appreciate if any Linux user (32-bit and/or 64-bit) could give this version a shot:

I have also contacted Hiura so he can hopefully find some time to build a Mac OS X version. If that works and I can use the summer hole at work to finish some tutorials and review Sonkun's changes to the build process, we might be closing in on a release candidate very soon. It IS about time...

Graphics / Use of sf::Font's copy constructor?
« on: March 16, 2013, 09:39:49 am »
I know Laurent asks for common use cases when asked to introduce new features, now I must ask this for an existing one. :D I just stumbled across sf::Font's copy costructor and can't think of any use case for it.

While copying textures and sounds can make sense, since they are "editable" using update / loadFromSamples, I can't happen to find any use for copying a font. You can't "edit" fonts or glyphs, so there's no use case like "copy that font but change that property". Any copy created would be nothing but wasted memory.

The only uses I found on the forum were a workaround to make something ugly even more ugly (talking about this post) and awkward resource management (= wasted memory, see this post).

So, where is the benefit of this constructor? In essence, why was it implemented?

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?

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;

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:

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
$ 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?

Java / RenderCanvas on X11 and Cocoa
« on: October 11, 2012, 11:07:23 am »
A short while ago, I started the "render-canvas" branch in which I'm adding the "RenderCanvas" - a Java control that makes it possible to have an SFML RenderWindow inside a Java AWT UI.

On Windows, it seems to work perfectly fine now. There was a conflict between AWT and SFML in that both registered their own window function. The solution I came up with was to create my own window function that passes all events to both AWT and SFML.

Now, I am trying to get things running under Linux / X11, where I'm facing a similar problem: AWT seems to "eat" all the input events and SFML doesn't get any. The problem is that I know barely anything about X11 programming and how applications register themselves as "input listeners".

Both SFML and AWT seem to create a so-called "input context" using XOpenIM and XCreateIC. AWT does this before SFML, naturally. I have no idea how this works, but this is the only thing I see at the moment that could cause conflicts.

Both SFML and AWT also perform "XMapWindow" and "XFlush", but since both run in the same environment I think the display remains the same and this doesn't cause any issues.

Finally, both SFML and SWT do something concerning a "WM_DELETE_WINDOW". I assume that's some kind of callback and hope it won't cause any issues.

Well, I could need some help here pointing me in a direction to look.

I also assume that similar problems will occur on Mac OS X / Cocoa. I hope that Hiura can have a look at this at some point as well. Just checkout the "render-canvas" branch, compile it all (C++ sources too) and run "jsfml-test.sh swing". You will probably have to fix the build.xml because the "jawt" library needs to be linked.

Java / Const References
« on: October 07, 2012, 09:40:37 am »
I just pushed a re-designed mapping of SFML "const" references.

Java doesn't know const, which is one of the biggest drawbacks of the language, in my opinion. However, I had to find a way to map SFML's const references properly to assure that a default view of a window, to name one example, will not be modified by the user.

Let's stay with the example of the View class for now.
sf::RenderWindow provides a method to get the window's default view. The returned reference is const. In order to map this behaviour to Java, I introduced the interface called "ConstView", which provides only reading methods of the View class. The View class implements this interface, so the functionality is directly delegated to the original sf::View and no further implementation is needed.

I believe this is the best way to simulate const in Java. It is transparent to the user (unlike what I did until now) and also type-safe.

Now, with the knowledge that a "ConstView" is simply a View, you could trick Java and simply cast it to a View or, even more evil, use reflection. In the documentation, I explicitly stated that this should not be done. For critical cases, such as the default view of a window or the target texture of a render texture, I implemented an (invisible) subclass of the View class that will throw an exception if a write-method is being invoked. This is not a problem, because this can only happen if the user used one of the said tricks.

I'm not sure if this protection is really necessary. I imply that there will be people who intentionally work around the API restrictions using (simple) tricks and try to protect the API from that. Should I do this, or is a warning in the documentation enough?

Window / [Windows] Windows larger than the desktop mode are invisible
« on: September 19, 2012, 08:26:10 pm »
I was supposed to test a little game that a friend wrote, but something was wrong: I did not see a window, but only a taskbar icon (which I could use to close the invisible window).

It turned out that his screen resolution was higher than mine, and that an SFML window will become invisible when it gets created larger than the current screen resolution. I'm not talking about fullscreen windows, but default style windows.

Here is a minimal code example to reproduce this behaviour with SFML 2 RC on Windows 7:
#include <SFML/Window.hpp>

int main(int argc, char **argv) {
        //Get the desktop mode and enlarge it by a pixel in either direction
        sf::VideoMode videoMode = sf::VideoMode::getDesktopMode();
        videoMode.width += 1; //alternatively, increase the height by one

        //Create the window - it'll be invisible
        sf::Window window(videoMode, "Window size test");

        //main loop, irrelevant to reproduce the bug
        sf::Event e;
        while(window.isOpen()) {

                while(window.pollEvent(e)) {
                        if(e.type == sf::Event::Closed)

        return 0;

I am not sure whether this is a bug. Of course, the developer should be aware that there might be people still using low resolutions. However, neither am I sure whether it is good that the window is entirely invisible.

Is this a Windows fault or is there something SFML can do to fix it?

Window / sf::Event::SizeEvent does not use sf::Vector2u
« on: September 14, 2012, 07:56:03 pm »
While window sizes are now stored in a sf::Vector2u struct, the sf::Event::SizeEvent struct still uses a pair of integers for width and height. I believe for the sake of consistency, this should be changed.

General / Dynamically linked SFML on Fedora
« on: August 27, 2012, 12:57:20 pm »
I recently tried to run SFML on Fedora 17, only to get an error that I was missing libjpeg8. The problem here is that the Fedora repositories do not maintain libjpeg but only libjpeg-turbo, hence I had to grab it from an external source as an RPM package.

Now the SFML build I tried is one that I linked on an Ubuntu system, where I linked against libjpeg. The API of libjpeg-turbo is downward-compatible to that of libjpeg, so in theory, it should all just be fine. However, the package name is different, and that's where the problems begin

Is there any way I can link SFML (or modify the shared objects) so that both libjpeg and libjpeg-turbo are supported? Or will I have to link specifically against libjpeg-turbo to make things work for Fedora?
Do the SFML build scripts have any special rules for this, btw?

Graphics / VertexArray::getBounds() can be optimized!
« on: August 24, 2012, 02:54:51 pm »
It's really minor, but I just noticed this:
        float left   = m_vertices[0].position.x;
        float top    = m_vertices[0].position.y;
        float right  = m_vertices[0].position.x;
        float bottom = m_vertices[0].position.y;

        for (std::size_t i = 0; i < m_vertices.size(); ++i)

I suppose i can start counting at 1. :)

Pages: [1] 2