I’m having a weird problem with Piston using a Glutin window. I’m packing up a little program in a dll and calling it from C#. It works like magic on my development machine, but on my target machine the screen freezes on the last frame. The Glutin window closes and the process stops running and you can even see the mouse cursor changing when you mouse over the WPF controls that should be visible, but the screen just stays stuck on the last frame. If I push Esc, which quits my WPF program, the screen clears and everything is good.
It works fine on the target if I run it directly as an executable, not from C#. It only does this when I call it from C#. It also works fine if I run it from C# in windowed mode.
If I run it from C# at a lower resolution in fullscreen mode, it doesn’t freeze but it also doesn’t change the resolution back when it’s done. If I close the C# program, everything goes back to normal.
If I run it in a borderless window at the monitor’s native resolution, it has the same issue as fullscreen. If I alt-tab nothing happens, but if I ctrl-alt-delete it clears the frozen screen and makes my WPF stuff visible again.
It seems like the window isn’t fully cleaning up after itself on the target machine when I run it from C#. Since the window closes when it’s supposed to, I feel like it might be OpenGL that’s not being cleaned up properly. Aside from not closing the Window, everything else works perfectly.
I’ve tried using SDL2 instead of Glutin but that comes with its own problems. I’ll be playing with other ways to get a window and draw what I need all day, but I’d prefer to use Piston based on some of the stuff we’ll be doing in the future.
Anyone have any ideas about what’s happening or sneaky ways I can work around it?