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.
3 Likes
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.
2 Likes
Update: FOpenGLFW is dead, long live FGL (Fortran Graphics Library).
Not being able to use text in OpenGL was something I couldn’t stomach, even though the initial question in this thread was just for GLFW bindings. So the library I am developing now includes FOpenGL, FGLFW, and the new addition, FFTGL, which is responsible for font loading and text rendering. The name “FOpenGLFW” is no longer representative, so I changed the library name to a more generic one, FGL (Fortran Graphics Library). You can watch a quick demo of FGL in action here, including nice text rendering. The user of this demo can change view to orthographic or perspective, zoom in/out, swich lighting on/off, and rotate around any axis - all using either the keyboard or the mouse, or both.
The rest of this post is details for whomever is interested or willing to do any suggestions.
After quite some time playing around with several C libraries for font loading/text rendering in OpenGL, I ended up using an older one (but still very popular), namely FTGL. This, however, was a tough choice, since the less-known library QuesoGLC is also very good and has a “better” API for my taste. Nevertheless, FTGL “won” for the time being, because it has better performance when you need to change font size often. I tried other libraries as well, but I wasn’t impressed at all, and I won’t even mention them here. Still, if anyone has any suggestions on the topic, I am open for discussion.
Image loading will not be included in the first release of FGL (you will still be able to render images in OpenGL contexts, you just won’t be able to easily load, e.g., a PNG image.) The way I do image loading in my Fortran Multimedia Library is using the SOIL library, which is very nice. The easy solution would be to just port this functionality to FGL. However, SOIL doesn’t seem to be maintained anymore (even the original website is down.) There are various copies of SOIL in gihub and frankly, I don’t trust any of them (why every 'random Joe" loves to just “fork” anything on sight, barely adding anything to it, and then have his/her own easy github entry?) So I am now experimenting with FreeImage, which offers more features than SOIL, has a nice API, and it’s not a project on hiatus. I will probably end up with FreeImage replacing SOIL and then include it in FGL as well. But again, suggestions on the topic are welcome.
As originally planned, FGL is a “modular” library or, to be exact, a bundle of independent libraries which can be used separately or as a whole - it’s up to you. So you can go ahead and use FGL in the beginning of your program, thereby having full access to all components, or you can just use FGLFW, or whatever else suits your needs.
Please note that FGL is still a rather “low level” API, in the sense it provides bindings plus a few goodies for OpenGL, GLFW, and FFTGL; if you need to draw, e.g., a rectangle, you need to write a subroutine that will do that (if you are not familiar with the library components, there are several examples I included in the package that will help you get started.) Higher-level features such as classes for graphics entities, animation, sprites etc, are reserved for my Fortran Multimedia Library, which also includes sound support and other goodies. Still, high-level features also “restrict” the user to my idea on how to implement them, which might not be yours. So if you want to go your own way, starting with “raw” OpenGL, GLFW, and FTGL for Fortran programmers, FGL might be a better choice.
FGL is going to be released soon. By “soon”, I mean when I have time to add some more examples in the package.
4 Likes
@Pap , Just curious have you completed the FGL project. Is there anyway I can try the code for simple displays. I have mostly been using Python ctypes mostly but have recently stumbled due to changes in package policies
@apoorv01 I thought this thread was actually forgotten, and I’m glad it’s not. The short answer to your question is: GLFW is not ready… but I am working on it, whenever I have time. I tend to have several side projects that I am working on, but I am currently concentrating on FGL and FSDL (my SDL port.)
The plan was that I’m almost ready for a first release, just need some more examples of FGL in action. However, I reconsider it, and decided I need a good coverage of every C library involved first. What “good coverage” means is explained below.
Currently, I am working on FImage, the image processing and rendering part of FGL, aiming to hit around 90% coverage of the corresponding C library. The rest is either unimportant, not worth bothering, or just useless in Fortran (because the language offers better ways to do the same thing.) I opted to finish that part first (instead of GLFW) because it is the only part of FGL that it makes perfect sense to be released separately.
I can give an accurate estimation of the development status, because I recently wrote a Fortran utility library that measures coverage without my intervention. So I can tell that image processing/rendering is currently 62.2% covered.
Once FImage is done, next “target” is FGLFW (the GLFW port). This is currently 36.3% covered. The number may look small, but that 36.3% actually includes everything needed even for not-so-simple tasks. Also, GLFW has several features that can be postponed for a second release (like joystick or gamepad control, for example.) I estimate that around 60% coverage would be ok for a first release (that number is not accurate but not made-up either). So FGLFW needs less work than what the numbers say at first glance.
At any rate, FGLFW is still not what I would consider as “complete” or at least “acceptable for a first public release”. I dislike half-baked releases - and I’m not saying this is necessarily a good thing, I’m just saying that’s my thing. Also, even if I released FGLFW as it is now, it is practically useless without FOpenGL at the very least (my Fortran OpenGL port) - or any other similar OpenGL port. That’s because, as you already know, GLFW by itself can’t render anything; it has other things to do and it does them very well.
Admittedly, development progress is slower than what it could be, but that’s for a good reason. No C function is ported before its Fortran version is thoroughly tested. This (and FGL in general) is not a lazy port.
In most cases, adding a single C function to to the corresponding Fortran library needs writing a C and a Fortran program that do the same thing, then testing the results in every possible case (usually including other function combinations as well.) In several cases, the C library contains “pointer hell” features that push the language limits to the extreme; porting those may mean days or weeks of work to be done properly (there is a lot more to be said about that but I’ll spare you further verbosity.)
2 Likes
@Pap Thank you for your detailed reply. Please keep posted about the FGLFW and other exiting work you are doing (read other post on multi-media library) . I will quite interested to try my hand on them. Actually want to slowly shift back fully to fortran. Lately have been using python for UI needs.