SFML community forums

Bindings - other languages => DotNet => Topic started by: luiscubal on November 16, 2011, 07:09:58 pm

Title: SFML.NET doesn't expose sf::Context
Post by: luiscubal on November 16, 2011, 07:09:58 pm
Like the title says. I've looked at all 3 DLLs and none of them includes a class named "Context".
I need this class because I'm trying to make a multithreaded loading screen and, even though in my PC everything works fine, some computers seem to be experiencing a crash after the load. My current theory(untested) is that the lack of explicit context setting might be the reason for weird behavior.

So... are there plans to expose it to .NET or am I doing something wrong?
Title: SFML.NET doesn't expose sf::Context
Post by: Laurent on November 16, 2011, 09:51:46 pm
SFML 1.6 or 2?
Title: SFML.NET doesn't expose sf::Context
Post by: luiscubal on November 16, 2011, 10:43:22 pm
SFML 2(a few weeks old version)
Title: SFML.NET doesn't expose sf::Context
Post by: Laurent on November 17, 2011, 07:54:20 am
Then you don't need an explicit sf::Context.

Could you show a simplified (if possible, complete and minimal) version of your code that reproduces the problem?
Title: SFML.NET doesn't expose sf::Context
Post by: luiscubal on November 17, 2011, 05:11:07 pm
This program:
http://dl.dropbox.com/u/6459451/threading.zip

works on my PC, but crashes on some computers(at least a Sandy Bridge Linux 64 bits, maybe more)

To run it:
LD_LIBRARY_PATH=. mono ThreadingTest.exe

Source code:
Code: [Select]

using System;
using System.Threading;
using SFML.Window;
using SFML.Graphics;

namespace ThreadingTest
{
public class Test
{
static Texture myTexture;
static bool threadOver = false;

static void myThreadProc()
{
myTexture = new Texture("texture.png");

threadOver = true;
}

static void Main()
{
using (var win = new RenderWindow(new VideoMode(640, 480, 32), "threading test"))
{
new Thread(myThreadProc).Start();

win.Closed += (sender, e) => win.Close();

while (win.IsOpened()) {
win.DispatchEvents();

win.Clear(Color.Black);

if (threadOver)
{
using (var mySprite = new Sprite(myTexture))
{
win.Draw(mySprite);
}
}

win.Display();
}
}
}
}
}


Since it works on my PC, this bug is particularly bad since it's hard for me to reproduce.
Hopefully, the above source code should be simple enough to make it obvious what the problem is.
Title: SFML.NET doesn't expose sf::Context
Post by: Laurent on November 17, 2011, 05:36:37 pm
I see nothing wrong.

Do you have more information about the crash (where, when, in which module, ...)?
Have you tried it on other 64-bits systems?
Title: SFML.NET doesn't expose sf::Context
Post by: luiscubal on November 17, 2011, 05:56:55 pm
On the computer in which this program crashes, the program simple crashes(returning 1) without printing anything(so no stacktrace is shown)

Quote
Have you tried it on other 64-bits systems?

My computer is 64 bits Intel CPU+NVIDIA GPU and runs that example just fine, so it seems very specific to some computers.
Title: SFML.NET doesn't expose sf::Context
Post by: Groogy on November 17, 2011, 05:58:02 pm
Could be faulty drivers? Have you made sure the drivers on those computers are up to date?
Title: SFML.NET doesn't expose sf::Context
Post by: luiscubal on November 17, 2011, 05:59:55 pm
The person is telling me that he's running with updated drivers.
Title: SFML.NET doesn't expose sf::Context
Post by: Rusky on November 17, 2011, 06:02:52 pm
I believe the problem is that separate threads must use separate GL contexts. Loading the texture needs to be done in a separate context that shares textures with the RenderWindow's, which is why sf::Context would be useful.
Title: SFML.NET doesn't expose sf::Context
Post by: Laurent on November 17, 2011, 06:24:21 pm
Quote
My computer is 64 bits Intel CPU+NVIDIA GPU and runs that example just fine, so it seems very specific to some computers.

So it's probably not  a problem with your code or SFML, but rather a configuration or platform issue.

Quote
I believe the problem is that separate threads must use separate GL contexts. Loading the texture needs to be done in a separate context that shares textures with the RenderWindow's, which is why sf::Context would be useful.

Nop. Please read the thread from the beginning ;)