Sprite draw crash.

[nihohit]

At certain points during a debug run, the program will stop, and return a nullobjectexception in the Transform.Combine function that is being called during the RenderWindow.Draw(Sprite) function (in the first line of the Sprite.Draw(RenderTarget target, RenderStates states) function). The null object is the transform.

Now, as far as I can see, the Sprite & Texture behind the sprite aren't null, and I don't see any recurring events which lead to this, so I've failed to find the source of the error. Any idea?

[Laurent]

Does it happen with the OpenGL example application?

[nihohit]

No, in my own program, with no OpenGL at all.

[eXpl0it3r]

No, in my own program, with no OpenGL at all.

Laurent meant the example that comes with the library.

A 'wild' guess do you define that sprite as global or before the window gets created?

[nihohit]

Yes, I didn't run the OpenGL example program. I tried once and errors popped ("output path not defined"), and since I wasn't interested in OpenGL didn't bother with it.

There's no global sprite. There's one that is created before the window, but it gets displayed well - it's the background, and the program runs and displays stuff (and the background) before crashing. It happens when drawing new sprites.

[Laurent]

Can you show a complete and minimal example that reproduces the problem please?

[nihohit]

Argh. This is a problem that spans the interaction between several objects and threads. I can try to minimise it, but will it still be worthwhile if the code I'll upload will be quite long?

[Laurent]

Do you really need the same complexity to reproduce it? I mean, if it's a bug in SFML then it can probably be reproduced easily. If not, then the problem is caused by your program, and there's nothing I can do.

[eXpl0it3r]

... several objects and threads...

Do you handle your OpenGL context in the right way? (You need to activate the contex in the thread you're working with graphics)

[nihohit]

Do you really need the same complexity to reproduce it? I mean, if it's a bug in SFML then it can probably be reproduced easily. If not, then the problem is caused by your program, and there's nothing I can do.

Oh, I don't know what I need to reproduce it. Currently it's very complex, and I'll try to focus on the minimal needed to reproduce it.

eXpl0it3r - I don't use OpenGL, but I do set it to Active(false) on the thread it's created.

[nihohit]

I'm still looking at reducing the code, but now I've noticed that the only null part of the Sprite is myInverseTransform, and that under InverseTransform there's a message "'((SFML.Graphics.Transformable)(sprite)).InverseTransform' threw an exception of type 'System.AccessViolationException'   SFML.Graphics.Transform {System.AccessViolationException}".

Is this a hint towards what happened?

EDIT: I now see that every object has it as null. So I don't see what do I get the null exception on - the Sprite's definitely not a null, and I can't seem to reduce this to a minimal case that wtill pops the error.

[nihohit]

So, to explain why I failed to find a minimal working problem - apparently it's not the Texture, or the original images - Sprites made from both are running. There's no discernible cause for this, no condition that I could isolate through prints, etc. Frankly, at the level of information open to me, I can't discern any difference between the Sprites that crash (and they're very few) and those that don't.

The only thing I know is that sometimes, when calling line 165 in Sprite.Draw, states.Transform *= Transform, the "right" variable will be null. Since this.Transform isn't null, but is Matrix(System.Single)[], I don't really understand what is happening.

[Laurent]

After looking at the source code again, I can tell you that the Transform member of the sprite cannot be null. The only way it can be null is if the same sprite object is manipulated from several threads concurrently -- the Sprite class is not thread-safe.