Messages

16

General / Re: Strangest sf::sleep bug

« on: July 30, 2013, 02:58:27 pm »

Hehe, I was thinking the same, but didn't go looking for the thread. Would be nice if we can find a good solution.

Good to hear! So I am not the only one I created an issue on the tracker: #439

I personally think a "high resolution sleep" is a bad idea, as it's very platform dependent, and on some platforms completely impossible.

I think instead something that yield's the current thread's timeslice back to the system would be much more effective. (i.e. SwitchToThread() on Windows (not Sleep(0), which is different)); this would be most useful for programs that don't want to unnecessarily max out the CPU (like mobile devices, where battery is important).

17

General discussions / Re: More Community-driven Development

« on: June 19, 2013, 05:06:08 pm »

I created a style guide page on the wiki. It would be awesome to have the whole community contribute to it! I'm just reading SFML's source code, finding patterns and documenting them. Right now I'm trying to create a general skeleton of the style guide, and after that it's just a matter of filling in the details.

18

General discussions / Re: More Community-driven Development

« on: June 19, 2013, 12:23:33 am »

Problem is time, as usual.

I'd like to have the time to write a complete style guide for contributors, but I don't. Sometimes I take the time to tell people what to change so that their pull request can be merged, sometimes I don't because I really have no time. I know, it's so sad

Would it help if we (the community) wrote a style guide (which you would correct and revise when you had time), and then once you're satisfied with it then it's done? Once it's all written, it should be pretty easy to integrate it into the website (of course, this wouldn't be done instantly, but I'm trying to find ways to help out).

I certainly understand the issues with time.

19

General discussions / Re: More Community-driven Development

« on: June 18, 2013, 04:54:46 pm »

Do you really think the main motivation of contributing is to appear in the commit lists?

I don't think it's a primary motivation (nor should be), but it's a form of positive feedback. It's encouraging to know you've made a positive impact.

I don't know if it's good to go in that direction, it might lead to people saying "look, I am part of the SFML development"

But aren't they? They may not be a primary/core developer or a maintainer, but they can certainly claim to have helped and contributed.

or competitions between users concerning who contributes most, and a lot of trivial commits of which the merge overhead outweighs the feature -- in other words, people who only contribute for the sake of being visible in the commit list.

I've never had such "dick measuring" (sorry) be an issue in the open source projects I've followed and contributed to. I really don't think that would be an issue.

Also, the repository owner shouldn't be under the pressure of applying a commit, because not doing so or implementing it himself (which would be faster in some cases) would appear as "unfair compared with others".

Oh sure, trivial things are easier to reject, IMO.

Of course, this is a pessimistic view, but eventually there will be a few people acting like this.

I doubt it'll be problematic.

In my opinion the motivation should generally be a different one, namely progress.

In case it wasn't clear, I don't think your name in the commit history should be your real motivation. Progress should absolutely be your primary motivation. But positive recognition can certainly be encouraging and help strengthen your motivation. But even if someone was purely motivated by recognition... well as long as SFML progresses, I don't really care.

And I still find the points in my last post important, but of course it's up to Laurent how this is handled. But you can be sure, even if the SFML conventions are listed again and again, many people will not follow them exactly.

True, but if a clear style/conventions guide was available, all it would take is a one sentence "Make sure you're adhering to this style guide; rejected until fixed." and then you don't have to say any more about the trivial stuff. Either they'll fix it, or it will stay rejected.

In the case of smaller contributions, constantly rejecting commits and hinting to the mistakes takes up much more time than implementing things oneself.

If you've got a clear style guide, again, you can just link to it and say it's rejected until fixed. Make them figure it out. It'll weed out the serious from the not serious.

20

General discussions / Re: More Community-driven Development

« on: June 18, 2013, 03:25:27 pm »

I've been thinking about this a bit, and one thing that I think would really help the community to get involved is to get their names in the commit history of SFML. There are tons of pull requests that seem to get the response "I used your changes as a base but didn't like the way you did things so I rewrote it myself."

I think it's fine to be nitpicky, but I honestly think it would help encourage and motivate others to contribute to SFML if there names actually showed up in the commit history. If you could tell them specifically what needed to change so they could make the necessary changes in order for the patch to be "good enough," I think it would help people better understand the SFML coding style (so their next patch is more likely to need less changes) and it would act as a good boost of motivation to work on another patch.

Thoughts?

21

Feature requests / Re: Condition Variables

« on: May 29, 2013, 05:03:35 pm »

The answer is that SFML is not a threading library, it only implements what it needs. There are dedicated threading libraries that do this job much better than SFML would (boost, C++11 standard library, ...), so there's no reason for me to reinvent the wheel.

So in the case where it's needed in the Android code, would you (if you were writing it) just use pthreads directly (so you use pthread threads, mutexes, and condition variables, avoid all the sf::Thread stuff), or would you write a condition variable class for SFML and then use sf::Thread, sf::Mutex, sf::ConditionVariable, etc?

22

Feature requests / Re: Condition Variables

« on: May 29, 2013, 04:36:18 pm »

I'm sure it has already been discussed, have you searched before asking?

The one and only thing that seemed close to what I'm requesting is this which was closed without a real reason being stated (perhaps because it wasn't posted in the forums?). I'm unable to find any actual discussion.

23

Feature requests / Re: Condition Variables

« on: May 29, 2013, 04:13:39 am »

Here's an example of what I have in mind (quickly made, if that's not obvious):

Code: [Select]

template <typename T>
struct Cond // should be non copyable
{
    Cond(pthread_mutex_t& mutex) : signaled(false), mutex(mutex)
    {
        pthread_cond_init(&cond, NULL);
    }

    ~Cond()
    {
        pthread_cond_destroy(&cond);
    }

    void set(const T& v)
    {
        val = v;
    }

    const volatile T& get() const
    {
        return val;
    }

    void setAndSignal(const T& v)
    {
        set(v);
        signal();
    }

    void signal()
    {
        pthread_mutex_lock(&mutex);
        signaled = true;
        pthread_cond_signal(&cond);
        pthread_mutex_unlock(&mutex);
    }

    void waitForSignal()
    {
        pthread_mutex_lock(&mutex);
        if (!signaled)
        {
            pthread_cond_wait(&cond, &mutex);
        }
        pthread_mutex_unlock(&mutex);
    }

    volatile T val;
    bool signaled;
    pthread_cond_t cond;
    pthread_mutex_t& mutex;
};

And here's a sample usage:

Code: [Select]

pthread_mutex_t mutex;
Cond<int> cond(mutex);

void* getValueThread(void*)
{
    printf("Please hit space and press enter\n");

    cond.setAndSignal(getchar() == ' ');

    return NULL;
}

void* watchValueThread(void*)
{
    cond.waitForSignal();

    if (cond.get())
        printf("You hit space!\n");
    else
        printf("You did NOT hit space!\n");

    return NULL;
}

I imagine something similar could be done with Win32 condition variables.

We're going to need condition variables for Android (the OS calls into application functions from an external thread, and condition variables are needed to sync things up properly). I'll probably implement something along these lines in Sonkun's Android branch, but I'm hoping we might find support for them in the official SFML repo.

Edit: I have a decent version done now (Unix and Win32, though not compatible with XP); I'm just documenting it.

24

General discussions / Re: Benchmark : SDL vs SFML

« on: May 29, 2013, 02:57:44 am »

The results between SDL and SFML are much closer now.

Would be interesting to hear what your hardware (and results) are.

25

Feature requests / Condition Variables

« on: May 29, 2013, 02:08:30 am »

Condition variables would be incredibly useful with multithreaded programming. Can we please get them? (I know, not now, but at least in the future?)

26

General discussions / Re: SFML Mobile Issues

« on: May 28, 2013, 04:15:37 pm »

I recently noticed that Android was restarting the whole application when the device was rotated, and that you had to manually save state and restore it after restart, I don't know how users will be able to handle that through SFML

The developer can decide whether or not the activity should be restarted on a screen orientation/size change. In the AndroidManifest.xml file, if you add android:configChanges="orientation|keyboardHidden|screenSize" to the activity node, it tells the OS that you will handle these configuration changes and that the OS should not handle them (which it does by default by restarting your activity). If you state that your activity will handle them, your onConfigurationChanged() function will be called.

There might also be a problem when application is sent to background and restored to foreground, or interrupted by a call, since you will also have to save/restore state, which might involve iOS/Android specific functions. I don't know enough about these mechanisms, but these are potential problems.

That's what I've been thinking about the most. I think lost/gained focus is a good way to handle it, and then when the OS wants to really destroy your application, you signal the window as being closed. The SFML user will have to enter a power-saving state when the focus is lost, waiting for a gained focus event (or close event) while using as little CPU as possible.

27

General discussions / Re: SFML Mobile Issues

« on: May 27, 2013, 11:05:34 pm »

More questions!

This has to do with application and window lifecycles. For iOS and Android, the (simplified) application and window lifecycle is:

• Application created
• Window created and application made "active"/resumed
• Program runs...
• Window destroyed and application paused/backgrounded
• Application destroyed

It's possible for apps to do 1->2->3->4->5 or something like 1->2->3->4->2->3->4->5. The trick here with SFML is that all events are associated with a window. However, here we have some application level (not window level) events (specifically, #1 and #5). These application level events are very useful, though. Specifically, it's nice to be able to pause/background your application, go answer a text, and then resume your application right where you left it (rather than having to reload it from scratch and go through all the menus again).

If we map window open/close events to #2 and #4 (which feels the most natural), we can't get the application level events (#1 and #5) because we don't have a window from which we can poll events.

If we map window open/close events to #1 and #5, and perhaps window gain/lost focus events to #2 and #4, we can get both the application and window level events, but it then changes the semantics of the SFML window class (for example, "window.isOpen()" no longer specifically refers to the window, but to the whole application). Additionally, when a window is destroyed, OpenGL contexts might be destroyed, and "window.isOpen()" might return true despite the window (and the OpenGL contexts) being closed/destroyed, and the user might perform some invalid OpenGL operations (like trying to render). In this case, there's extra responsibility placed on the user to "do the right thing," which will require them to have a deeper understanding of how SFML works on mobile systems.

What are people's thoughts on sensibly handling (and providing access to via the SFML API) application level events and window level events? Specifically, what are the best ways to inform the user of events 1, 2, 4, and 5?

Edit: There's no "window created/opened" event in SFML, so rather than an actual event being fired for such action, I mean "window.isOpen()" would return true. Hopefully that makes sense. Let me know if it doesn't.

28

General discussions / Re: SFML Mobile Issues

« on: May 25, 2013, 10:21:44 pm »

I initially answered twice because I saw your github issue before this post, but now we don't have to continue a duplicated discussion, please don't post everything to both the task tracker and the forum

Heh, sorry

29

General discussions / Re: SFML Mobile Issues

« on: May 25, 2013, 08:43:37 pm »

Quick follow-up question: would you like commits like this to be submitted to the SFML main repo via pull requests, too? There are some changes that are/will be made that could be integrated to SFML, but I don't know if you want these pull requests yet.

30

General discussions / Re: SFML Mobile Issues

« on: May 25, 2013, 08:35:21 pm »

Yes, I will have to get rid of quads since OpenGL ES doesn't support them at all. sf::Text could use triangle strip if glyphs were adjacent, but unfortunately they are not, so we'll have no choice but to use triangles.

Ok, cool. I'm just using a triangle strip for sprites and triangles for sf::Text. Thanks!