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.


Messages - pdinklag

Pages: 1 ... 4 5 [6] 7 8 ... 22
76
Java / Re: I cannot run a JSFML application (UnsatisfiedLinkError)
« on: May 19, 2013, 03:53:33 pm »
Hm, this is awkward, because libGLEW should be linked statically into JSFML and not even be a dependency. I chose to do it that way so it's no problem if people got a "wrong" version of GLEW like you do. So there's nothing wrong about your setup, it should be working.

May I ask which version you are using? Is it test release #2? Maybe I did a mistake packaging it up.

77
Java / Re: Few questions
« on: May 06, 2013, 06:27:30 am »
Hi!

Yes, JSFML can be used to make games for Windows, Linux and Mac OS X. I would not know of any "troubles" you are risking (what exactly do you mean by that?).

There are still a bunch of things to be done. You may have noticed that JSFML has not been officially released yet, but a test release is out there for people to play with. It should already work on Windows, Linux and Mac OS X.

There is not so much progress at this time, because I am pretty busy with my job and university, but yes, the plan is to get a release candidate out there soon and maintain it during SFML 2's lifetime at least (for the next few years, I guess). The more people who give it a try, the better. If there are any troubles, please go ahead and report them and they will be looked into. :)

Oh, and don't worry about your English, it will improve over the time. :)

78
General discussions / Re: SFML 2 and its new website released
« on: April 30, 2013, 03:32:25 am »
Congrats! :)

79
General discussions / Re: A new logo for SFML
« on: April 30, 2013, 03:31:14 am »
Nice result!

Sorry if I missed it, is a Photoshop project file available for the logo?
It would be good to have to build logos for bindings. I suppose that the font is public domain or open source, too?

By the way, the website could use that pentagon as a favicon. ;)

80
I hope I can find some time to bring JSFML to the released SFML 2.0 soon. These are busy times, though. I'll also update the logo to be more similar to the new SFML logo.

One little note for the bindings page (and the forum likewise): the Java binding is "JSFML", not "jSFML". It's not too big of a deal but I think it should be consistent. One of the reasons I've been using a capital J was to set it off against the abandoned, incomplete Java binding that was not developed by myself. The capital J will fit better in the new logo as well.

81
General discussions / Re: A new logo for SFML
« on: April 19, 2013, 05:10:09 pm »
So far I preferred Haze's logos for whatever idea that was around at the time.

His arrow version also looks the best so far in my opinion, although I'm not quite sure if that "sine" shape would imply anything that SFML isn't. Then again, it makes it look more dynamic than a straight arrow.

82
Feature requests / Re: Basic arithmetic expressions for vector types
« on: March 24, 2013, 03:43:33 am »
Vector2i and Vector2f are aliases for Vector2<int> and Vector2<float>, Vector2 is a template.

83
System / Re: SFML in the future.
« on: March 18, 2013, 10:58:37 am »
You're also using SFML in a "wrong" way then. SFML is not a framework. If I understood Laurent right, the class abstractions are not a design choice that people should rely on, but a simple way of re-using code. Obviously, the boundary calculation for sprites is fundamentally different from the calculation for texts, so there is no re-usable code here, that's why there is no abstraction for it.

If you need abstractions like the one you mentioned, you should design your own framework that uses SFML, not one that builds on it.

84
Graphics / Re: Use of sf::Font's copy constructor?
« on: March 16, 2013, 01:28:08 pm »
The copy costructor does copy the pixel buffer, but the data source (m_streamRec?) as well as the freetype font data is not. A comment in the implementation notes that freetype does not even support such kind of cloning. The copied font simply gets the pointers to the freetype data shoved into them, so I believe any concurrency issues in reading the source data would remain.

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

86
Window / Re: Thread-local sf::Context
« on: March 16, 2013, 09:18:00 am »
From what I read in the sources, the sf::Context constructor will barely do anything if there already is an active context on the current thread. Note that I do it natively (in C++) now, not in Java, so that overhead is ruled out.

Also, I think textures are most likely loaded before entering a rendering loop or something similar, so this should not affect live performance.

87
Window / Re: Thread-local sf::Context
« on: March 16, 2013, 07:54:58 am »
True that, but I haven't touched the loading routines yet in the process of my optimizations. I wanted stuff to just work first. These weeks it's about getting them to work fast. ;D

Anyway, until I happen to find the root cause here, I will force a context to be created by creating an sf::Context instance at the start of any affected native load, update or create method. It might not be the way it's meant to be used, but it works for now and hopefully does not cause any potential other problems.

Funnily enough, only textures seem to be affected. Fonts and texts work fine if created explicitly before any context or window, even though they use a texture internally. Render textures are also fine. If I find any cause for this, I will post it.

EDIT:
This also means that I can create or load textures without any trouble after creating a Font or Render texture.

88
Window / Re: Thread-local sf::Context
« on: March 15, 2013, 03:48:02 pm »
Are you really sure that there's no hidden thread spawned internally?
Everything is done in the main thread. Calling native code does not change threads.

What you can try now, is to call glFlush() (include and link OpenGL) right after calling texture.loadFromFile in your binding.

Tried that now, no change. :(
JNIEXPORT jboolean JNICALL Java_org_jsfml_graphics_Texture_nativeLoadFromMemory
    (JNIEnv *env, jobject obj, jbyteArray arr, jobject area) {

    std::size_t n = (std::size_t)env->GetArrayLength(arr);
    jbyte* mem = env->GetByteArrayElements(arr, 0);

    jboolean result = THIS(sf::Texture)->loadFromMemory(mem, n, JSFML::Intercom::decodeIntRect(env, area));
    glFlush();

    env->ReleaseByteArrayElements(arr, mem, JNI_ABORT);
    return result;
}

I should note that I use loadFromMemory because I handle files on a Java-level, that allows a more detailled exception handling and only needs one "load" implementation that I can use for Java input streams as well. I don't think that should make any difference.

89
Window / Re: Thread-local sf::Context
« on: March 15, 2013, 02:47:38 pm »
I will give that a try.

What I just tried (in Java) is converting the texture to an image (copyToImage) and saving it to a file - and the resulting image is OK! Yet I see a white box when using the texture in a sprite.

90
Window / Re: Thread-local sf::Context
« on: March 15, 2013, 02:27:33 pm »
I'm running on Windows 7.
I tried both 32 and 64 bit now, and in a simple C++ program, it works as you described, textures are fine even if loaded before a window or context is created.
        sf::Texture *texture = new sf::Texture();
        texture->loadFromFile("test.png");

        sf::RenderWindow *window =
                new sf::RenderWindow(sf::VideoMode(640, 480), "Context test");

        sf::Sprite *sprite = new sf::Sprite(*texture);

        while(window->isOpen()) {
                window->clear();
                window->draw(*sprite);
                window->display();

                sf::Event e;
                while(window->pollEvent(e)) {
                        if(e.type == sf::Event::Closed) {
                                window->close();
                        }
                }
        }

        delete sprite;
        delete window;
        delete texture;

(Just in case you wonder why I use pointers - I wanted to resemble as good as possible what happens when using the Java binding.)

The same program using the Java binding results in a white box being painted. The dimensions of the texture are correct (same as the source image), but the content is plain white. As soon as I create a sf::Context instance before creating (loading) the texture, it works just like in the program above.

So this is definitely a problem with my binding, but it is still awkward. The native code executed should be practically the same that I posted above.
I wouldn't know of any thread shenanigans going on in the background in Java, but even if so, according to you, that should not be a problem.

Pages: 1 ... 4 5 [6] 7 8 ... 22