RenderWindow stops drawing

[Epiplon]

A have a List<Sprite> that it's used to draw on the main RenderWindow object. Currently, this list holds 2 sprite and I call a window.Draw(sprite) for each one. Also, they are big as the RenderWindow object in width and height.


^{public void Draw(RenderWindow window)
{
  foreach (Sprite sprite in currentArea.AreaSprites)
  {
     window.Draw(sprite);   
   }
}}

So far so good, until this happens after a couple of seconds, for no apparent reason:


Since the guy continues running, I though that the sprites are having some problems.
The only clue that I have was an AccessViolationException, something that I couldn't reproduce later and that was thrown right after the problem above occurred. The stack trace had something about a thread being started, in root, and I don't know if it have something to do.

I'm curious if all SFML calls are thread safe, since it seems to be locking the resource memory from me.
And also, how many times is it safe to call the Draw() method?

Sorry for being asking, I didn't found anything related on the forum.

[eXpl0it3r]

Nothing in SFML is thread-safe. If you use threads it's you're job to sync them and prevent race conditions etc.

It's odd, but hard to tell what's going on. You should write a minimal example from scratch, so we can directly test your code.
Also make sure your graphics driver is up to date.

[Epiplon]

http://pastebin.com/yJi8i0eJ

SharpTMX loads a Tiled map and renders sprites for each layer and isn't the library's fault also.
So odd. I cut everything that was unrelated and now, it draws correctly. Nothing different besides RenderWindow not being passed on methods calls.
Gonna take a depper look.

Edit:
Can't find the reason. Should I upload the whole project and the executable together?

[zsbzsb]

Edit:
Can't find the reason. Should I upload the whole project and the executable together?

You should write a complete and minimal example that shows the problem. That way you will be able to pinpoint what exactly causes the issue.

Also

using System.Threading.Tasks;

If you are using anything from this namespace (you aren't using it in the example) it means you are using threads and as eXpl0it3r said, SFML is not thread safe.

On a side note, I don't know what kind of time measuring that is, but if you want SFML style Time and Clock classes you can take a look at NetEXT (see my signature) 

[Epiplon]

You should write a complete and minimal example that shows the problem.

https://www.dropbox.com/s/6nifvwb5gr727k5/TestingGame.zip
Now, the problem shows up! It usually happens after a minute or so and I found the following:
In code/World.cs, there is a private void SpriteDebug(Sprite sprite) method. As you can see, it does nothing but print console message from the Sprites. With it, the screen goes blank. If you remove it, nothing happens.
Also, there's the compiled project on Debug folder, all SFML-related .dll was removed (of course ).
My guess is that problem is not particularly the Console, but rather the memory access of the Sprites.

using System.Threading.Tasks;

If you are using anything from this namespace (you aren't using it in the example) it means you are using threads and as eXpl0it3r said, SFML is not thread safe.

Well, don't worry about that.
It's referenced but not being used anywhere on this example or the original project (I'm glad that I asked this upfront).

On a side note, I don't know what kind of time measuring that is, but if you want SFML style Time and Clock classes you can take a look at NetEXT (see my signature) 

Sure! I can even help you on documenting it.

Thanks eXpl0it3r and zsbzsb for your help. 

[zsbzsb]

I tried your program, it crashes after about 15 seconds. However after I remove the call to SpriteDebug() the program runs without any issues. The only thing I can think of is that since SFML doesn't provide its own GetHashCode() the CLR is doing something weird when it is providing a default GetHashCode().

[Epiplon]

The only thing I can think of is that since SFML doesn't provide its own GetHashCode() the CLR is doing something weird when it is providing a default GetHashCode().

Is there something I can do about it, maybe a temporary fix? 

[zsbzsb]

Maybe avoid calling it? If I recall Laurent is planning an update to SFML.NET before SFML 2.2 is released so after that is finished I will take a closer look into the issue.