Messages

1

DotNet / Re: SFML.Net GTK# Integration Questions

« on: November 17, 2014, 11:59:24 pm »

I tried your suggestions but I still get a NullReferenceException at:

Point extents = new Point(0, sfFont.GetLineSpacing((uint)font.RealSize));

In SFML.cs which is in Gwen.Renderer.SFML. For some reason when sfFont is set to font.RendererData, font.RendererData is null.

However when switching to x86, MonoDevelop simply shows the disassembly. By looking at the stack trace I can tell it is the same issue.

I am not so sure this was designed to work with Mono on GNU/Linux.

2

DotNet / Re: SFML.Net GTK# Integration Questions

« on: November 17, 2014, 03:00:28 am »

Ztormi, were you ever able to get the GWEN.Net samples to work? In the SFML renderer version the sample throws a null reference exception upon allocating a UnitTest. Even when commenting it out, upon closing the application, I get a segmentation fault from SFML. The only sample that worked was the OpenTK renderer, but it rendered everything with a shade of red.

3

DotNet / Re: SFML.Net GTK# Integration Questions

« on: November 16, 2014, 08:29:21 pm »

SFGUI would be my first choice, but the project I am working on has to be in C#.

I saw GWEN.Net before, but I thought the project was dead because the one wiki page was written in 2011. I just checked the latest commit which was done in March 2014. Still probably dead, but better than TGUI.Net if it works. TGUI.Net seems to cause an SFML font warning when instantiating the label class. I'll consider GWEN.Net too, if I can get it to work.

Thanks for the suggestions.

4

DotNet / Re: SFML.Net GTK# Integration Questions

« on: November 16, 2014, 02:01:31 am »

It appears the method of integration in the tutorial I linked just displays a borderless window over a gtk window. This is not good as gtk elements cannot be rendered ontop of the borderless window.

I've tried the window handle method as well. I retrieved the the window handle from the gtk window by using gdk_x11_display_get_xdisplay imported from libgtk-x11-2.0.so (running on GNU/Linux). However this resulted in an X Bad Window error. I also tried gdk_x11_drawable_get_xid and got a similar error. The tutorial by dabbertorres also says that the sf::Event system cannot be used, but I'm not sure why.

Regardless I decided to use another library. Either the currently in development SharpCEGui or the dead TGUI.Net project. They seem to be the only viable SFML/OpenGL based GUI toolkits available as most are dead and do not provide enough functionality.

5

DotNet / Re: SFML.Net GTK# Integration Questions

« on: November 14, 2014, 12:26:20 am »

On another note, since the application is already coded using SFML, I designed it to update every frame. Since GTK takes over the main loop, the application would not be able to update every frame unless something like this is used (from the tutorial I mentioned).

/// <summary>
/// Timer handler. Since GTK controlls the main loop we need this to poll SFML events.
/// </summary>
private void OnTimerElapsed()
{
    Gtk.Application.Invoke(
    delegate
    {
        DispatchEvents();
        Redraw();
        Display();
    });
 }
 

But I do not understand why the author calls the update code from the OnTimerElapsed() method. Maybe it happens every frame?

I have also been looking into a GUI library called TGUI.Net. It might be better in this situation because:
- It doesn't take over the main thread.
- It's widgets embed into a SFML window.
- Event handling can still be done through SFML without calling an update function from OnTimerElasped().

6

SFML projects / Re: SFML GPU-CHTM

« on: November 13, 2014, 10:01:41 pm »

Awesome dude, really nice work. I got interested in Jeff Hawkins's stuff like a month ago. Cool to see it extensions being made.

7

DotNet / Re: SFML.Net GTK# Integration Questions

« on: November 13, 2014, 08:58:29 pm »

I saw that method, but I didn't know it could use X11/Quartz too. That's interesting. However I would rather use a single piece of platform independent code (rather then using all of those compiler directives) to integrate SFML and GTK if possible. Something along the lines of this https://github.com/SFML/SFML/wiki/Source:-GTK-integeration tutorial may allow for that, but I am not sure if event handling would still be possible with SFML API calls rather than GTK API calls.

Regardless I will consider the window handle method, but what I don't like is that it requires me to know all of the platforms the program might run on during coding it. This is reasonable, but coding an application that can run on more than just the programmer's expectations is always preferred.

8

DotNet / SFML.Net GTK# Integration Questions

« on: November 13, 2014, 05:26:40 pm »

In a simulator I am developing, I have used solely OpenGL for GUI, but my needs got a bit more complicated (File Chooser Dialog) and I think it is better that I bring in a GUI library. I am having trouble understanding how GTK integrates with SFML. Do GTK widgets embed themselves into a SFML window? Or does a SFML window embed itself into a GTK window? If so, can event handling still be done with SFML? It seems normally GTK apps take up the main thread with the Application.Run() call, does integrating mean I have to go multi-threaded?

I'm new to GTK so I am not sure if it provides the SFML functionality I am using (OpenGL rendering, Keyboard access), but would anyone suggest that perhaps my use of SFML is superfluous and using just GTK is better? I already have the simulator coded using SFML, so I would rather not switch completely unless I am not putting SFML to good use.

Thanks for any input.

9

DotNet / Re: SOLVED Moving from Mono to Windows

« on: September 28, 2014, 07:29:46 pm »

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.

10

DotNet / Re: Moving from Mono to Windows

« on: September 28, 2014, 12:56:12 am »

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.

11

DotNet / Re: Moving from Mono to Windows

« on: September 27, 2014, 02:12:34 am »

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.

12

DotNet / Re: Moving from Mono to Windows

« on: September 26, 2014, 01:01:57 am »

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.

13

DotNet / Re: Moving from Mono to Windows

« on: September 25, 2014, 05:17:58 am »

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

14

DotNet / SOLVED Moving from Mono to Windows

« on: September 24, 2014, 11:55:03 pm »

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.

15

SFML projects / Re: ERL

« on: July 06, 2014, 03:14:40 pm »

I guess you are interested in our research or similar projects . Ya that would be cool to see your implementation. I'm surprised reading the paper was enough to create an implementation, they are usually somewhat vague. Studying the source is usually better. EDIT: I found it.