Messages

61

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 13, 2011, 11:21:37 pm »

Okay, I'll bite

Again, this is all based on my very limited knowledge of SFML's internals:

1) Create a sf::GraphicsInitialize object which must be constructed as an automatic object (disable operator new/delete to enforce this) some time after main() has been entered. sf::GraphicsInitialize would be responsible for the creation and destruction of both the shared context and the default font (and whatever else is needed).

2) Remove any context creation/destruction code from GlResource.

3) Allow EnsureContext() to fail if called outside the lifetime of the sf::GraphicsInitialize object.

4) Resources treat 'EnsureContext()' like any other possibly failing function (e.g. assert, throw, return false, whatever), except from destructors, where failure to EnsureContext() implies that nothing need be done (i.e. no context implies no resource to destroy).

What do you think?

62

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 13, 2011, 08:21:19 am »

But we still have the problem of WGL calls before/after main() with ATI drivers.

Noted.

It seems the only solution other than banning global SFML objects (which doesn't sound totally unreasonable), would be to decouple context management from the lifetime of individual resource objects. I'm not sure if I have the patience fully grok the SFML code base, so I shall leave that in your capable hands.

63

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 13, 2011, 07:56:36 am »

Are you sure? I thought that this rule applied only to globals, and that the mix between function static and globals were undefined.

Yup, I'm sure. I can even quote the standard if you like.

Isn't "= 0" the dynamic initialization? Until that moment, the variable may contain random bits, doesn't it?

Nope. It is static initialization because the initializer is a constant expression.

EDIT: And in fact, the variable would have been guaranteed to be initialized with "0" even without the explicit initializer.

64

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 12, 2011, 07:35:45 pm »

What I forgot to say is that I can't trigger the global init at global startup -- that would make the ATI bug come back.

So I really have to call this when the first GlResource is created.

Meaning, you cannot make driver calls before 'main()' has been entered?

And I'm not sure that your solution would solve the "global destruction fiasco" problem: what happens, for example, when a GlResource is allocated as a function-local static variable (such as the default font)? Is there a C++ rule that ensures that it is destroyed before globals that are instanciated in the same code unit?

The constructor for a function local static object is called at the first time execution passes through the block in which the object was defined. Destruction happens in the reverse order of construction (yes, even for function local static objects). So if an object was constructed before the first call to the function in which the font object is defined, it will outlive the font object, and vice-versa if the function was called first.

Same for GlResource::EnsureSharedContext::myInclusionCount: it may be initialized after the sfGlResourceEnsureSharedContextObject globals are constructed. And it will, at least in GlResource.cpp, because the global instance is declared first in this code unit.

No it wont. The initialization of objects with static storage duration is a two phase process. 'myInclusionCount' doesn't require any dynamic initialization (which is the second phase), while the 'sfGlResourceEnsureSharedContextObject' object does (i.e. its constructor must be run), so we're safe.

65

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 12, 2011, 03:55:33 am »

After having a glance through source, I can't immediately see the need for having the global mutex you mentioned. It seems the following construct would be sufficient (note that I've stuffed all this inside GlResource simply because that is where the current code handles the initialization):

In GlResource.hpp:

Code: [Select]


namespace sf
{
    class GlResource
    {
    public:

        class EnsureSharedContext
        {
        public:
            EnsureSharedContext();
            ~EnsureSharedContext();
        private:
            static unsigned myInclusionCount;
        };

        // ...
    };
}   // namespace sf

namespace
{
    ::sf::GlResource::EnsureSharedContext sfGlResourceEnsureSharedContextObject;
}   // unnamed namespace


In GlResource.cpp:

Code: [Select]

#include <SFML/Window/GlResource.hpp>
#include <SFML/Window/GlContext.hpp>
// ...

namespace sf
{
    unsigned GlResource::EnsureSharedContext::myInclusionCount = 0;

    GlResource::EnsureSharedContext::EnsureSharedContext()
    {
        if (myInclusionCount++ == 0)
        {
            ::sf::priv::GlContext::GlobalInit();
        }
    }

    GlResource::EnsureSharedContext::~EnsureSharedContext()
    {
        if (--myInclusionCount == 0)
        {
            ::sf::priv::GlContext::GlobalCleanup();
        }
    }
}   // namespace sf

What do you think?

As an aside: I noticed that you create a function local static 'sf::Mutex' object in 'sf::priv::WglContext::CreateContext'. This isn't thread safe without some external synchronization (and I assume there isn't any, or the mutex would be redundant).

66

SFML projects / SFML powered / crossplatform - SideScroller Construction Kit

« on: October 10, 2011, 05:07:06 am »

The TIGSource forums are likely your best bet.

http://forums.tigsource.com/

67

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 10, 2011, 05:00:30 am »

So the real issue is global access to some shared state? I'm fairly certain that can be achieved without running into the static initialization fiasco (modulo the fact that I don't know all the details here).

68

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 10, 2011, 02:23:00 am »

Can we say something a little more descriptive? I'd like to make sure there really is no way around this.

69

General / Possible Bug in RenderWindow Destructor (SFML 2.0)

« on: October 09, 2011, 11:43:05 pm »

[...] (SFML has globals too, and you can't enforce them to be destroyed after yours).

That is most unfortunate. Why exactly does SFML need static (or do you _really_ mean global) objects?

70

SFML projects / SFML powered / crossplatform - SideScroller Construction Kit

« on: October 09, 2011, 01:01:06 am »

You really need some beautiful screenshots

This. So much this. I was thinking exactly the same thing. With all due respect to the artist, that tileset really does look tacky.

71

SFML projects / Airport

« on: October 08, 2011, 09:56:39 pm »

Hi,

I wasn't able to play. None of the F keys worked (i.e. nothing happened when I pressed them) and the background image wasn't displayed properly:
http://i54.tinypic.com/3eozo.png

OS : Windows XP SP3
Graphics card : NVIDIA GeForce 7600 GT
Screen resolution : 1440x900

72

Graphics / [Solved] SFML 2.0: strange rendering issue.

« on: October 08, 2011, 09:25:09 pm »

Even that wasn't the cause, I still think there is something fishy going on.

It seem likely that you got "lucky" with some code changes which just happen not to trample memory in such an obvious way. If the solution you provided really is what makes the difference between a well defined program and uncalled code randomly executing, then there is something seriously wrong with SFML.

73

General discussions / The new graphics API in SFML 2

« on: October 08, 2011, 08:52:37 pm »

Having an array of vertices represent geometry is all about efficiency, since that is what most closely matches the machine model. I haven't seen anything in this thread which would lead me to believe that higher level abstractions wont be provided, so I think your concern is premature at best.

74

Graphics / [Solved] SFML 2.0: strange rendering issue.

« on: October 08, 2011, 01:46:04 pm »

I suspect your program is exhibiting undefined behaviour, most likely caused by pointer molestation. Seeing a construct such as "delete this" makes me wince slightly.

75

General / Adding Events to the Event queue

« on: October 07, 2011, 04:47:27 pm »

Why don't you use the event (signal/slot) system of GWEN?

Code: [Select]

quitButton->onPress.Add(&window, &RenderWindow::Close);

In that case, RenderWindow would have to derive from Gwen::Event::Handler.

As an aside: I proposed an alternative system some time ago, but Garry didn't seem too interested (he asked for more details, I gave them to him but got no reply):
http://www.facepunch.com/threads/1090922?p=30462180&highlight=#post30462180
http://www.facepunch.com/threads/1090922?p=30519858&highlight=#post30519858