Fortran Binding to GLFW

Is anyone aware of a GLFW Fortran binding or a similar library?

1 Like

There are:

  • F03GL: Fortran 2003 interface bindings to OpenGL, GLU, and GLUT.
  • fortran-sdl2: Fortran 2008 interface bindings to SDL 2.0 (includes OpenGL bindings).
  • DirectX bindings for Windows.

Hi @general_rishkin, and welcome to the Fortraners club.

I have written Fortran bindings for GLFW some time ago, but it’s not complete, in the sense not all of GLFW has been ported. My bindings were not intended to be a stand-alone project but rather, part of my next version of Fortran Multimedia Library. As such, only the functions needed for my library are ported. I actually add new GLFW functions to the bindings as needed by my library. I didn’t need to add much lately, because what’s included already fits my needs. In fact, the bindings are more than enough for most tasks. I was planning to publish my bindings together with my library but if you really need them right away, I can release them separately.

Other than that, if you want a complete port, F03GL is a great choice. F03GL is a Fortran interface to GLU, GLUT, and OpenGL. It is a mature project and it works very well (fun fact: I found out this project exists long after I wrote my own bindings for FreeGLUT and OpenGL).

Now, I should add a few notes about FreeGLUT (used by F03GL) that may or may not be important to you. FreeGLUT does things in its own way, which is not necessarily the user’s way. For example, it includes raster and vector built-in fonts, some (limited) parallel functionality, and a small GUI. It also takes over the main loop of your OpenGL program by default (there is however a way to avoid this). Don’t get me wrong, FreeGLUT is an excellent project, used by many, and it is still updated. However, FreeGLUT (and therefore F03GL) is more of an “all in one” library, thus not directly comparable to GLFW. If you don’t care about the FreeGLUT details I tried to describe above, F03GL is an excellent choice and I can easily recommend it. In fact, the current version of my Fortran Multimedia Library uses FreeGLUT bindings in the background (but will be replaced by GLFW and other libraries in the next version). In this video you can actually see Fortran bindings for FreeGLUT in action (this is not F03GL because as I said I wrote my own bindings before I realized F03GL existed; however, you can have the exact same results by using F03GL, except the sound and image rendering). In the video, the window itself, the fonts and fade in/fade out are all driven by FreeGLUT bindings.


Thanks @interkosmos and @Pap. I will have a look at F03GL.

@Pap : When do you plan on releasing your Fortran Multimedia Library?

@general_rishkin : Good question… When I show my library in action to a friend, two years ago, he said “then what are you waiting for?”. Well the answer is not that simple. I will try to explain but I’m afraid it will be a long text, so feel free to skip it, but here it is:

The reason my library is not released is mainly the fact at some point I decided to replace some of the underlying libraries, specifically, GLFW instead of FreeGLUT, and perhaps FreeImage instead of SOIL. The former is mostly done, and it was much more work than it seems to be at first glance. The reason is what I tried to explain in a previous post: FreeGLUT is more than just an OpenGL framework; you can’t just replace it with GLFW, you have to use other underlying libraries too, which in turn need their Fortran bindings to be implemented. Also, in my library the user doesn’t have to use any of the underlying libraries; he/she can use a “higher level” API which is 100% object-oriented. This means all classes and methods of that API had to be heavily modified. As if all that wasn’t enough, I am also experimenting with a built-in GUI.

My library just works as it is, I use it everyday. That doesn’t mean it is ready for a public release. Many details do need some attention, especially if you are like me and you want everything “perfect” (and good luck achieving perfection; there ain’t such a thing). Furthermore, there is no documentation, really. Well there is, but it is based on doxygen, which supports Fortran but proved to be inadequate (object-oriented features of Fortran 2003 and above are very poorly supported).
All the above are not hard things to do, they are rather trivial - but very time consuming, and I usually avoid it, using my free time to explore new things such as MGRX (a C library I am also developing Fortran bindings and examples - for the fun of it), plasma effects using my library, fire effects, particle generators, and many other “Sirens” that can devour my free time very easily.
In other words, I do not have a date to tel you. The short answer is “whenever I finally find the energy and time needed to deal with the trivial work remaining” - which becomes more and more imperative lately, as a few people asked about my library.

In the meantime, if you just want the GLFW Fortran bindings, I can release them (like I said it’s not a 100% Fortran port of GLFW; I just ported the functionality I needed - which should be more than enough even for large projects). GLFW has excellent documentation and a very well-thought schedule for further development. In my opinion, it is the best OpenGL framework you can find today. But it’s just that, an OpenGL framework on steroids. The developers made it clear that they intentionally avoid any add-ons to make it an “all-in-one” solution. So you will not find background procedures, image rendering, sound support, or even font and text rendering. If you need those, you will have to use other libraries together with GLFW. In my humble opinion, that’s better than a library that “does it all” - and that’s exactly what my library tries to do: make several underlying libraries (each one dedicated to a specific task) work together.
That being said, there is nothing wrong with “all-in-one” libraries. It all depends on your needs and programming style. So if you want a somewhat more “complete” solution, F03GL is the way to go. If you want a “totally all-in-one” solution, SDL is a mature, already established library for that purpose, so fortran-sdl2 (as recommended by @interkosmos) is a great choice.

I could have a better answer (and much shorter, I promise) if I knew what exactly you want that Fortran library you are looking for should do.

1 Like

It would be great if you can release them !

1 Like

GLFW bindings alone won’t do much. GLFW is an OpenGL framework. It gives you the means to create a window with an OpenGL context, receive user input, and manage device events. That’s pretty much all it does in a nutshell (and it does it very-very well). GLFW itself does not include any OpenGL functionality, so with GLFW alone all you can do is, e,g, open a window and wait for a keystroke to close it; you won’t be able to draw anything on that window (not even set a background color). For that, you should use OpenGL (or Vulkan, but that’s an another story). So releasing GLFW bindings alone won’t be very useful, unless you already have OpenGL bindings. Conversely, OpenGL bindings alone are essentially useless, because they need an OpenGL context, such as the one GLFW provides.

What I can do to make this useful is to release both my GLFW and OpenGL Fortran bindings, together in one package. Those two can (and definitely should) be independent bindings, just released together. Normally, you will use both in a program, but you will have other choices as well. You could also use only the OpenGL part with another OpenGL framework, or only the GLFW part with other OpenGL bindings for a different OpenGL version.

Unfortunately though, this won’t be the end of the story… far from it. Essentially, such a package would include “low level” functionality, in the sense you could do pretty much everything OpenGL lets you do - but there is a catch, and it has nothing to do with Fortran. OpenGL was not designed to be used “as is”; you can do that, but you don’t want to. For small applications, It is perfectly ok to use “raw OpenGL”. However, it becomes very tedious for larger ones. In fact, even implementing simple examples will reveal this is not enough. You will soon realize the need of a “higher level” API that will simplify things greatly. This is why many C/C++ libraries based on OpenGL are available, and this is why I started my own Fortran library.
Moreover, even if you can stand programming in raw OpenGL, do not expect anything remotely close to what you see in “OpenGL applications”. This is because OpenGL itself is “barebones” by design. Things many people take as given by any graphics library are completely missing (most notably rendering text or images). OpenGL leaves such things for other APIs (and, if you ask me, this was a wise decision). This is why “all-in-one” solutions such as SDL2 are so attractive and popular; they save the user from finding and “sewing” together specialized libraries for each specific task needed.

I wrote all the above to make sure people realize what they should and should not expect from GLFW and OpenGL Fortran bindings. If that is enough, I will need some time to “extract” the corresponding bindings from my library and release them as a separate package (implementing examples will take most of the time, because the examples I have are all using the high-level API my library provides, so they need to be heavily modified). On the other hand, if you want more functionality, fortran-sdl2 is probably what you need. Or wait until my Fortran Multimedia Library is “releasable” (I explained why it is not elsewhere).

1 Like

Release early, release often. What can you loose? You probably get feedback or even contributions. Just be transparent about the current state of your code by labeling it as an alpha or beta version. Typical open source license also state clearly that there is no warranty.

I generally dislike the “release early, release often” scheme because it creates more problems than the ones it solves. Yes, it has the clear advantage of useful feedback early. But releasing early may give a wrong idea of what the software is, especially when a major modification is planned. Furthermore, it may cause older applications based on an earlier version of the library not working anymore (you cannot completely avoid this, but at least you can avoid it from happening all the time - which is usually the case if you release early and often.

At any rate, I am working on FOpenGLFW, a library that provides both OpenGL and GLFW Fortran bindings, including examples. You can watch a simple example using FOpenGLFW in action here. The library will be released when it’s ready, and that shouldn’t be too far away, as it is basically done - I am just working on some nice examples right now.

The example above can serve as a way to explain the questions and issues that I had to find an answer (feel free to skip the rest of this post if you are not interested on the details).
Did you notice the FPS (Frames Per Second) counter? That one uses another library for rendering text in OpenGL contexts (and, consequently, provides font loading as well). Neither OpenGL or GLFW support those, so this must be removed from the releasing version, where FPS will be just printed in a terminal window. I had to “draw the line” somewhere, otherwise I would end up releasing my whole Fortran Multimedia Library early. The line is set to strictly OpenGL and GLFW “as is”. This means no text rendering, no image rendering, no sound.
Another question that needed an answer: GLFW uses a GLFWWindow struct as an opaque pointer; this is why the code still needs c_ptr and c_associated at exactly one point. In my Fortran Multimedia Library a “high-level” Fortran GLFWWindow class provides all functionality to make the code for this example shorter, and eliminates any need for using iso_c_binding. Should I include such a class in FOpenGLFW? No, because in that case I should include documentation for that class (which is a “big fat can of worms” by itself - can and will delay the release). And even if I do that why not including high-level classes for other GLFW features? Why not including high-level classes for OpenGL itself as well? And then why not image and text rendering? See how quickly this escalates to early releasing the whole multimedia library? This is why I had to draw a line. FOpenGLFW will provide a “Fortran way” to use OpenGL and GLFW. Both have excellent documentation elsewhere and their Fortran counterpart is pretty much the same, so there is very little to add myself for documentation, other than a few basic facilities included.

thanks for the demo, it looks very nice.

I don’t agree that early or often releases create problems. Unclear expectation management causes problems. One standardized way of communicating changes in a library is semantic versioning. Potential users can decide themselves whether the advantages of using a work-in-progress version outweighs the problems of breaking changes.

Look at @general_rishkin: He seems to need the bindings. In the current situation, the only option for him is to develop them himself. Releasing an early version of your code would at least put him into the position to read your code and then either use it (and add missing features or fix/report bugs) if that seems reasonable. If he is afraid of alpha-quality, he can still decide to develop the bindings himself.