SOLVED Moving from Mono to Windows

[josh123]

EDIT 2: I have localized the error to an System.AccessViolationException only occuring on windows and not on mono with the SFML.Net source distribution. I am dumbfounded as to why it only happens on one platform. If anyone could test the SFML.Net source to see if it works on their machine, that would be great.

EDIT: I removed the second exception I was encountering because it may be due simply to dll including. The main problem persists.

I'm developing a simulator that uses SFML.Net (the person I'm working for mandated C#). It runs fine on Mono and now I'm trying to get it to run on a machine running windows. I downloaded the SFML.Net source and built it on windows without errors (for reference I had to get the csfml-system library from csfml directly). When I try to run my application with all of the needed libraries in the same directory, I get the error

Unhandled exception: System.AcccessViolationException: Attempted to read or write protected memory.
This is often an indication that other memory is corrupt.
    at SFML.Window.Window.sfWindow_createUnicode(VideoMode Mode, IntPtr Title, Styles Style, ContextSettings& Params)

This implies that the issue has to do with bitness according to this topic http://en.sfml-dev.org/forums/index.php?topic=15873.0 However windows complains that it cannot find the sfmlnet-system library if I use 64-bit libraries instead of 32-bit.

Any help is appreciated.

[zsbzsb]

I can't say for certain what your issue is, but let me pick at your post and also give some pointers on avoiding issues.

I downloaded the SFML.Net source and built it on windows without errors (for reference I had to get the csfml-system library from csfml directly).

If you are using the latest SFML.NET source from github you must also use the latest CSFML source from github that includes the blending mode changes. Yes, blending mode changes broke interaction between SFML.NET and CSFML. If you can't be bothered to build SFML and CSFML yourself to get the blending mode changes (and csfml-system module) feel free to grab the nightly builds from here.

However windows complains that it cannot find the sfmlnet-system library.

If you have built SFML.NET from the source on github you must also reference the sfmlnet-system module in your project. And once you reference it (assuming you are using VS) it should automatically be copied to the directory containing your executable.

if I use 64-bit libraries instead of 32-bit.

When using SFML.NET it is a very good idea to target either x86 or x64 with your own project and also make sure SFML.NET and CSFML dlls were built with the same target.

[josh123]

Thanks for the quick response.

you must also use the latest CSFML source from github

I'll try using the nightly build of csfml to see if it helps any (I don't always have access to a windows machine, but I'll try as soon as I do).

you must also reference the sfmlnet-system module in your project

Yes I reference sfmlnet-system in my project (I'm using MonoDevelop). I compiled the application with Mono on Debian and put the executable on a flash drive. Then I built SFML.Net on windows because the application was failing to run with the SFML.Net binaries I built on Debian. On windows I built SFML.Net for 32 bit, but perhaps I have to rebuild the application on windows as well (maybe Mono binaries can't run on windows).

it is a very good idea to target either x86 or x64

I built SFML.Net for x86 and according to MonoDevelop my application is built for x86.
The output of

file BinaryName.exe

is:

PE32 executable (console) Intel 80386 Mono/.Net assembly, for MS Windows

[josh123]

Using the nightly build of CSFML does not remedy the issue. I get the same error.
EDIT: Upon futher expection, a System.AccessViolationException is thrown for any SFML.Net app once it attempts to access SFML.Net libraries
EDIT 2: I'm getting

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

When trying to run a simple program that only sets up a SFML window. The exception is thrown by the following line of code

Window window = new Window(new VideoMode(800, 600), "title", Styles.Default);

EDIT 3:
After trying a variety of configurations, it seems to boil down to this:
x86 binary + x86 libraries  = System.AccessViolationException
x64 binary + x64 libraries = System.AccessViolationException
x86 binary + x64 libraries = System.BadImageFormatException
x64 binary + x86 libraries  = System.BadImageFormatException

This same application runs on mono with both an x86 binary + x64 lib and x64 binary + x64 lib. I still can't get anything that uses SFML.Net to run on windows.

[josh123]

I was able to get the "sound" and "sound_capture" examples working, but anything that attempts to create an SFML window still crashes with the original error message. This means that binary format is not the problem as I recently expected.

Any guess as to why only the examples that depend on sfml-system and sfml-window crash?

The reason I'm building the latest SFML source is because the binary distribution does not include the sfml-window library. Perhaps I am mistaken to think I need the latest source?

EDIT: Upon debugging the opengl sample I get an AccessViolationException on this line in RenderWindow.cs:

CPointer = sfRenderWindow_createUnicode(mode, (IntPtr)titlePtr, style, ref settings);

All I can guess is that this is a bug.

The reason the other code crashes at sfWindow_setunicodeTitle is that it is the first time CPointer is used. It seems to crash when attempting to set CPointer.

[josh123]

I've switched to the stable release of SFML.Net, now I get a blank console window and windows prompts me to force close the application. I also tried a simple application which only launches a window, but it crashes with the usual AccessViolationException.

EDIT: I got access to other computers running windows and the program ran and opened a window  but text I draw by loading a char map texture does not render properly. This is relevant because I use SFML to load the texture. On one system no text appeared. On another (I called someone by phone to test it, so I did not actually have the computer) the user reported Arabic looking text. Very strange, but at least it does not crash completely.

[josh123]

SOLVED.

I know no one probably cares, but in case someone has a similar problem:

It turns out that the mono seems to allow taking the size of a class while windows doesn't, this caused my vertex buffer to have the incorrect coordinates on windows, but not on Mono.

There are a few lessons to be learned here:

• Only use the stable release.
• Be careful when using Marshal.SizeOf  across platforms (especially with classes).
• Don't assume sfmlnet-system-2.dll is missing in the stable release, but not the latest source.