SFML community forums
General => General discussions => Topic started by: Nexus on July 13, 2013, 05:08:34 pm
-
Hello
I just saw that GLFW 3 (http://www.glfw.org/docs/3.0/index.html) was released a few weeks ago, it is quite different from earlier versions. Have you ever considered using it or parts of it for SFML? It provides a lot of features you currently use or you might add in the future:
- OpenGL and OpenGL ES context creation
- Very sophisticated window management
- Input handling: Keyboard, mouse, joystick (might solve the keyboard issue)
- Support for multiple monitors
- Clipboard text support
- High-resolution timer
It would mean another dependency, but you could drastically reduce your code and wouldn't need to reinvent the wheel. Also, GLFW is a pretty lightweight C library.
On the other hand, I might imagine that over the years, you have found specific workarounds and code to handle functionality uniformly across operating systems. There might also be crucial features it does not provide. Anyway, just wanted to bring this into discussion, no need to decide soon :)
-
Another cool feature:
The window title is a regular C string using the UTF-8 encoding. This means for example that, as long as your source file is encoded as UTF-8, you can use any Unicode characters.
glfwSetWindowTitle(window, "さよなら絶望先生");
-
You can set sf::Window title to sf::String and you can get sf::String from utf8 encoded const char * or std::string easily.
-
Hmm looks definitely interesting. Maybe if I ever get around to OpenGL, I'll give it a try. :P
-
Using it in SFML? No, I think both libraries are at the same level, they are more in competition than complementary ;)
But it's very interesting, now I have a new reference library to add to my list (after SDL and Allegro) ;)
-
Really? :(
What about clipboard and open-file-with-default-app? :'(
Or at least the clipboard.
-
imo the coolest way would be if glfw is an optional depence from sfml,
if glfw exist it uses its features, if not use the allready existing native features
imo it would short the code if sfml uses glfw
-
It would be even shorter if SFML used SDL... Seriously, that's really not what SFML is (a thin interface on top of big libraries). SFML uses the lowest possible level of implementation to provide the same stuff that SDL, Allegro, GLFW, etc. provide.
I don't understand why suddenly everyone wants me to use GLFW. It's just another library like SDL and Allegro. And like SFML.
-
What about getting clipboard and default app open in SFML?
-
What about getting clipboard and default app open in SFML?
What about creating proper feature requests for them? :P
-
I don't understand why suddenly everyone wants me to use GLFW. It's just another library like SDL and Allegro. And like SFML.
Because they don't understand what the aim of GLFW/SDL/SFML/Allegro is. They just see these libraries as a set of features, and for a beginner it seems like to include a feature you need to make use of the library itself instead of just reimplementing it yourself. Either you just silently ignore them, or explain to them in a calm manner for the 59273087th time what you just said :). Or you could confuse them even further by asking them what would happen if all libraries just depended on each other to provide functionality :P.
-
Or you could confuse them even further by asking them what would happen if all libraries just depended on each other to provide functionality
;D
-
But it's very interesting, now I have a new reference library to add to my list (after SDL and Allegro) ;)
Okay, good to hear my idea is not useless ;)
Note that I mentioned "the library or parts of it", meaning that for very specific features, you could use their code inline (if the license allows it) or use it as inspiration for your own implementation.
imo the coolest way would be if glfw is an optional depence from sfml,
if glfw exist it uses its features, if not use the allready existing native features
imo it would short the code if sfml uses glfw
Shorten the code? No, because of "if not, use the existing native features". Doing it this way would combine the disadvantages of both approaches and lead to more code, a case differentiation and two incompatible versions of the library.
-
Or you could confuse them even further by asking them what would happen if all libraries just depended on each other to provide functionality
;D
You awaken Cthulhu from his slumber. Good going there!