Jump to content
  • Advertisement
Sign in to follow this  
markjco

OpenGL GLFW vs. FLTK vs. SFML

This topic is 2952 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I've been reading some threads about what toolkits to use with OpenGL development. In summary, I've noticed that the community would advice to determine the nature of the application, what it has to do, in order to decide on what the best approach is.

Okay, I am developing a Virtual Environment where I can:

1. navigate smoothly with an external hardware control such as an exosceleton. (but keyboard keys will do for now)
2. manipulate and interact with the object rendered (grab it, etc.) in the environment with again hardware interface (but will use a mouse interaction for now)
3. render an arbitrary object (but that's for later research)

Those are the three major considerations in deciding what toolkit to use.:)

So, do I use GLFW which was made for OpenGL, had a new release this 2010, but some do not recommend it for complex applications.

OR FLTK or SFML (I don't know the difference between the two honestly), which are modern alternatives to SDL.

For me, any would do because they are all good choices but I would just like to have some comments for weighing them out. What would be best for what I would want to do... I've been researching for some time and since I'm a newbie, can't really pinpoint strengths and weaknesses. If you could suggest other toolkits I did not mention or don't know, please advise:D

Thank you very much.

Share this post


Link to post
Share on other sites
Advertisement
So these are all windowing toolkits. They provide a platform independent API for abstracting getting keyboard/mouse input and creating/managing an openGL window. Your three criteria, although interesting, really don't have anything to do with these libraries.

I like GLFW because of it's simplicity and only tries to do one thing (window creation/input handling). It is C based and pretty easy to use and I can use any number of other systems to handle audio, threading, image loading, rendering, etc. It's nativly a C API, but provides bindings for several languages.

SFML does all that and also provides an API for audio, fonts, and networking. It's nativity a C++ API but provides bindings for several languages.

FLTK is a GUI library like Qt or Gtk. I haven't used it ever, but I hear it can generate an openGL context and provide input handling. I believe it is used mostly as a widget library.

Your criteria all exist at a pretty high level, these libraries are fairly low level in most architectures. You probably can't go wrong with either GLFW or SFML. Depends on your requirements as to which is best for you.

cheers,

Bob

Share this post


Link to post
Share on other sites
I'm using GLFW in my game and am happy with it. Far better than GLUT, which I originally used..

I didn't know a new version came out this year though?

Share this post


Link to post
Share on other sites
Quote:
Original post by Scourage

Your three criteria, although interesting, really don't have anything to do with these libraries.



Hi,

Really? I assumed that it had to do with the libraries because I would be getting inputs and rendering them on the screen:) Do you mean that I don't have to use these libraries in my implementation?

Quote:
Original post by Scourage

Your criteria all exist at a pretty high level, these libraries are fairly low level in most architectures.



What do you mean high level? Doesn't my criteria operate on the low level OpenGL itself? :)

Share this post


Link to post
Share on other sites
Quote:
Really? I assumed that it had to do with the libraries because I would be getting inputs and rendering them on the screen:) Do you mean that I don't have to use these libraries in my implementation?
Libraries such as GLFW, SDL, and SFML should all do an adequate job of handling user input, so there's nothing of particular interest there. The only consideration would be if you have unusual input requirements. I'm not sure what the hardware interface you refer to is, but you'll probably want to make sure that whatever library you choose will be able to accommodate it.

Regarding graphics, no, the choice of windowing API doesn't really matter. Each of the APIs mentioned can create an OpenGL context, and that's all you need; the rest is up to you.

As for having to use one of these libraries, you certainly don't *have* to, but it will most likely make things easier if you do.

Of course, if you'd like to be able to work with the graphics at a higher level (that is, without having to write a lot of low-level OpenGL code), you could use a higher-level game or graphics engine (e.g. Ogre, C4, Unity, etc.).
Quote:
What do you mean high level? Doesn't my criteria operate on the low level OpenGL itself? :)
None of your criteria has anything in particular to do with OpenGL itself. The first two criteria are hardware/programming issues, and the third (rendering an arbitrary object) is a general requirement that can be met by any API that facilitates 3-d rendering (that is, there's nothing about the requirement that requires any special consideration with respect to OpenGL).

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk


As for having to use one of these libraries, you certainly don't *have* to, but it will most likely make things easier if you do.

Of course, if you'd like to be able to work with the graphics at a higher level (that is, without having to write a lot of low-level OpenGL code), you could use a higher-level game or graphics engine (e.g. Ogre, C4, Unity, etc.).



By "you don't have to" you mean I could display the OpenGL scene without these toolkits? I read that OpenGL doesn't have those functionalities natively.


Quote:
The first two criteria are hardware/programming issues, and the third (rendering an arbitrary object) is a general requirement that can be met by any API that facilitates 3-d rendering (that is, there's nothing about the requirement that requires any special consideration with respect to OpenGL)


I understand this a bit, that OpenGL concerns itslef with the rendering not, the ones I mentioned, that's why I was wondering, with the criteria I mentioned, would it be better if I use GLUT, SMFL, or FLTK?:)

Share this post


Link to post
Share on other sites
Quote:
By "you don't have to" you mean I could display the OpenGL scene without these toolkits? I read that OpenGL doesn't have those functionalities natively.
Sure, you could display the OpenGL scene without one of these toolkits, by (e.g.):

1. Using a graphics or game/interactive engine such as Ogre, Unity, etc.

2. Writing whatever native code is required to get an OpenGL context up and running.

Going with option 1 might save you some development time in the long run (depending on what you're doing exactly). As for the second option, if you need to target multiple platforms (e.g. Windows and OS X), using a cross-platform toolkit will almost certainly save you a lot of time. If you're only targeting one platform, it'll still save you time, but likely not as much (if you're targeting only Windows, for example, you could just write native WinAPI code, which is well documented and for which there are many tutorials floating around online).

My own recommendation would be to use the highest-level tool you can that will meet your requirements (where 'requirements' could refer to feature set, budget, target platforms, and so on).
Quote:
I understand this a bit, that OpenGL concerns itslef with the rendering not, the ones I mentioned, that's why I was wondering, with the criteria I mentioned, would it be better if I use GLUT, SMFL, or FLTK?:)
I would choose SFML over GLUT; FLTK I'm not familiar with.

That said, any decent windowing/events API (e.g. SDL, SFML, GLFW, etc.) will do the trick. The only real 'gotcha' I can think of is the hardware interface you mentioned; if it's something unusual, you'll want to make sure that whatever input API you choose can accommodate it.

Does that clarify things at all?

Share this post


Link to post
Share on other sites
Hi,

Thank you very much, yes it did clarify things for me. I'll do more readings on ogre and if it has the capability to handle the inputs that my project requires then I'll go with that:)

I made a mistake though, instead of putting GLUT I meant to put GLFW, so do you still choose SFML over GLFW?:)

Share this post


Link to post
Share on other sites
Quote:
I made a mistake though, instead of putting GLUT I meant to put GLFW, so do you still choose SFML over GLFW?:)
I only have limited experience with each, so I really couldn't say.

Really though, I would just pick an engine or library that meets your requirements and move forward. Also, it seems the input issue you mentioned is a pretty clear requirement, so I would start by eliminating APIs that don't meet that requirement. You should then have a shorter list, which should make it easier to choose.

Share this post


Link to post
Share on other sites
I would recommend GLFW.

It's simple to use and integrate, and you can always easily replace it with something else if desired (it doesn't tie into your code too deeply). Or you can modify its source code if you need to change something.

It also has a very clean API/interface imo.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!