Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[C#] glfw-net, a GLFW3 .NET Binding


Recommended Posts

**What is GLFW3?**
@GLFW3 Website:

> GLFW is an Open Source, multi-platform library for creating windows with OpenGL contexts and receiving input and events. It is easy to integrate into existing applications and does not lay claim to the main loop.
> GLFW is written in C and has native support for Windows, OS X and many Unix-like systems using the X Window System, such as Linux and FreeBSD.

_Note: This means it's just a windowing system. Creating an OpenGL binding is something I'm also considering doing, but the OpenGL API is far larger and far more difficult to implement a binding for and test to see that every single facet of the binding works._

**What is glfw-net?**
glfw-net is a .NET binding of _only_ GLFW3 (so no earlier versions) that is meant to mimic the GLFW3 API as close as possible – types and casing are almost exactly the same. Obviously since GLFW3 supports multiple operating systems the goal of glfw-net is also to support those same systems. Currently due to the limitations of C#, the C# equivalent of C++ API calls need to be prefixed with "GLFW3.", but if my interpretation serves correct, with Roslyn, C# and Mono will support static imports like Java, allowing you to drop the "GLFW3." entirely. With everything being said, glfw-net is not meant to fit the code style of C#, as it is not meant to be a wrapper. It's designed to maximize copy-pasting between C++ and C# code to facilitate easier porting.

**Current shortfalls?**
Unfortunately at the moment, since the official GLFW3 website does not provide binaries for systems outside of Windows, I have only packaged binaries for x86 and x64 Windows compiled with VC2013 (so potentially will not support older Windows systems). In addition, I've only tested about 20 API calls and ensured that the program did not crash prior to or after the call (for example my original implementations of for example ```
```didn't crash when I called it, but when I tried to close the application after the API call it crashed instead of closing normally).

**So why have I posted this when most of it's untested?**
First off, I know some people around here like tinkering with things, and this is something that may pique their interest. Second of all, I can't test for example, the joystick related API calls, since I don't own or know where I can borrow a joystick. Third of all, at the moment I am unable to test OSX or Linux, so I'm hoping someone will compile some binaries for them as well as test API calls to make sure I don't have any stupid bugs that don't show up on Windows. Lastly, I know a lot of people around here are starting to get into, or have gotten into C# programming, and I'm trying to encourage moving off of, and staying off of, any version of VB, as well as some innovation so people won't just use things like SFML (which has terrible memory management for objects despite having a fairly simple/good API) and will instead think further outside the box.

I haven't tested to see if anything will work right now with glfw-net (haven't had that much time, and I just started on the binding about 24 hours ago, which includes sleep and working time), but somebody might be able to get glfw-net to work with OpenTK, which would provide a means to use OpenGL with GLFW3 from C#, without using something like Pencil.Gaming (which seems to have a. a less than desirable GLFW2/3 binding implementation and b. a bloated implementation). There are OpenGL bindings in C#, just none of them live up to the standard LWJGL3 has set, which from my experience with it and the underlying C/C++ APIs, is really good.

**Repository** – https://github.com/lodico/glfw-net
**License** – MIT (open source, free for commercial use and derivative works so long as the license is packaged with any distributions of the source code, read the license file for more detail)

**.NET 4.5** – if someone wants to see if glfw-net works on an earlier version of .NET and submit an issue to the repository for me to change the version, go ahead, but otherwise it's staying on 4.5
**GLFW3 library files for your system** – obviously if the provided GLFW3 binaries don't work for you (stored in the 'lib' directory tree) you'll need to compile your own (or download the binaries if you're running Windows but can't use the VC2013 binaries that I provided, but I find this unlikely if your version of Windows supports .NET 4.5)
Link to comment
Share on other sites

glfwCreateCursor() – broken, haven't figured out how to fix this one
glfwGetGammaRamp() -- less than desirable implementation, but it works
glfwGetMonitors() -- less than desirable implementation, but it works
glfwSetGammaRamp() -- untested, might just work or have the same problems as glfwCreateCursor()
Link to comment
Share on other sites

  • 2 weeks later...
Confirmed bugs/errors on glfwCreateCursor() and glfwSetGammaRamp()
Added issues for the two enhancements (glfwGetGammaRamp() and glfwGetMonitors()) and the two bugs/errors listed above

Issues: https://github.com/lodico/glfw-net/issues
Link to comment
Share on other sites

  • 1 year later...
glfw-net is now in beta development for glfw-net 3.2\. This update is to bring it up to spec with GLFW 3.2 and is also marking x86 as obsolete, as unless someone else fixes the issues I was having with it (AccessViolationExceptions on cursors and gamma ramp) it will not be supported, and I have actively removed the x86 build configuration from the solution.

GitHub: [glfw-net 3.2 update development branch](https://github.com/lodico/glfw-net/tree/update32)

I will be testing/correcting the Vulkan API externs I added to the source starting sometime this week when I receive my GTX 1070, as my current GTX 560 Ti was not given Vulkan drivers by nVidia (rendering me incapable of testing it).
Link to comment
Share on other sites

Pushed another commit fixing string encoding issues, now UTF-8 is supported like it should have been from the get-go.

Github: [Commit c2ec20c: Fixed string encoding issues, normalized code style](https://github.com/lodico/glfw-net/commit/c2ec20ce4a3e6dac9ea816ee793575ff8b30f1b2)
Link to comment
Share on other sites

  • 1 month later...
This looks pretty impressive actually. Although, this graphics API is not that useful since it does not support mobile devices.

How come you had to write bindings for it? I am just curious. Can't you load the C .DLL inside the project and use them? What I read it seems like the binding allows you to use it in WinForms/WPF. Maybe there's more to it than that.
Link to comment
Share on other sites

tl;dr: To address the points you brought up/questions you asked:
1\. It is a windowing/context management library for GL on the desktop, mobile devices use GLES and don't need this.
2\. I wrote bindings because it's stupidly difficult to do (even with GLFW3 [in C++], C++ and C# experience) and it's a wheel that is a horrendous waste of time to have to reinvent.
3\. To my knowledge this is exclusive from WinForms and cannot be used with it. Pretty sure that also applies to WPF.

More in depth:
It's a desktop windowing system with some OpenGL and Vulkan context management support - things that aren't necessary on a mobile device (which to my knowledge have no Vulkan support yet, and use OpenGL ES which is a subset of the OpenGL API).

The reason behind making the binding is because even writing these bindings have been a chore. GLFW3 is a C++ library and lives in unmanaged space. It's taken a lot of research, time and trial and error to even get the binding as usable as it is (still not 100% since none of the Vulkan stuff is really supported beyond the "isVulkanSupported()" binding. Given that I originally used GLFW 2 and 3 for C++ applications, and know both C++ and C# I'm capable, even without full knowledge of C#'s Marshalling system, to be able to research enough to make the correct guesses needed to make it functional, this isn't something I would expect 99% of the people here to be able to do. It's just leg work that doesn't need to be redone, and I also dislike the other (less complete, and from testing of my own code which I wrote after examining the structure of the other) binding's structure, and think it should be true primarily to the GLFW API, and not to the C# style guidelines because it would make it much harder to use all of the documentation and examples on the internet that are almost exclusively in C or C++ when you need to translate everything to C# "style" code (case differences for example).

This project actually is just a very small part of my original overarching plan, which was to go and rip OpenTK to shreds and make it conform to the actual C/C++ API to allow, like with this, code to be reused without much change from C++ to C#. Unfortunately though, I'm really lazy and don't do much in the line of game programming anymore, but if I were to I would just write everything in C++ because I can and there's no need for me to creating the unbelievably massive binding for the entirety of the OpenGL API. Eventually I might get to that part of the project, but it's extremely low on the list of my priorities, and OpenTK still works, even if it adheres to C# style guidelines rather than the API it binds.

As far as I know, it is completely distinct from WinForms, since WinForms is window management and GLFW is window management. While this is a guess, I'm 99.9% confident this is the case.
Link to comment
Share on other sites

Well yeah, writing a binding is hard. I wasn't saying it wasn't. I can't do it. :P

I see bindings being written for language translation mostly, such as MonoGame bindings for Cocossharp. I just had no clue what the bindings actually were, I suppose it is just a translation layer or something to allow it to be used natively in the language's syntax. It still confuses me. Must be really high up in CS.
Link to comment
Share on other sites

Bindings are used to map methods and whatnot from compiled native binaries into whatever language you're using (typically non-natively compiled languages such as Java or C#). C++, C and assembler to my knowledge can all share native dependencies written in any of the three languages, but that's the extent of my native-compiled language knowledge (everything else I use is run in some sort of VM).

In the case of this it's making calls from managed C# space into unmanaged space owned by the GLFW3 native binaries, though I'm pretty sure you can write managed C++ (Visual C++) code as well, but you'd still need the bindings to make the language-external libraries accessible from the C# space, which in the example of this binding also has to translate types by telling the marshaller what kind of memory the GLFW3 library has so it can handle it properly.

An example of not needing to create bindings is between C# and VB.NET, or Java and Groovy (and I think Scala too) since both groups of languages share VMs. I'm pretty sure you cannot write a .NET binding for a JVM library though.

The difference between a wrapper and a binding is that a wrapper provides additional functionality that a binding would not (such as extra methods). Wrappers and bindings can be mixed though, and that's actually what this library actually is (though it's almost entirely a binding). Another example of a wrapper-binding is SFML.NET, which adds stuff that is not purely mapping external library functions to .NET and facilitating any data translation that might be necessary.

Each component of SFML (the C++ SFML) is also a wrapper of sorts, and it does no binding. The whole of SFML, and probably even some portions of it are also classed as frameworks.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...