search

Secretchronicles / TSC

An open source two-dimensional platform game.
https://secretchronicles.org/
GNU General Public License v3.0
205 stars 49 forks source link

Support CEGUI 0.8.x #10

Closed Quintus closed 8 years ago

Quintus commented 11 years ago

Currently, SMC only officially supports CEGUI 0.7.x. It’s time to move on!

Luiji commented 10 years ago

I'm actively working on this. Status update: the hardest thing so far is getting CMake to handle it correctly. I'm new to CMake. ;) I got it able to detect CEGUI 0.8.0 but it adds /usr/include/cegui-0/CEGUI to the include path instead of /usr/include/cegui-0. :(

Quintus commented 10 years ago

If you want, I’ll do this later today for you (in a separate branch), then you have a definite starting point. CEGUI is a bit tricky to detect, because CMake doesn’t have a built-in find-module for it, so I turned one up from the Internet and modified it.

Sorry for not having worked on SMC the last few days, but the Heartbleed bug got me quite busy. All the new TLS keys and certificates took my week up.

Vale, Quintus

Quintus commented 10 years ago

@Luiji, I’ve created a cegui-0.8 branch for you. There are already two commits in there you probably want to have a look at:

Thereby I noticed CEGUI 0.8.3’s pkg-config file is broken; it says the CEGUI headers are in /usr/include/cegui-0/cegui, but in reality they are in /usr/include/cegui-0/CEGUI. This is an upstream bug that short be reported to them; I can do this in the next days.

Oh, and why do they have appended zeroes to all their stuff?? This looks weird.

The Falagard WR stuff seems to have vanished in CEGUI 0.8.x, so I commented the respective line in the CMake module out. If there’s an equivalent that needs to be detected, you can replace it accordingly or remove the TODO comment.

Vale, Quintus

Luiji commented 10 years ago

Thank you for the help! I'll look more into getting the code updated tonight or tomorrow. I'm not sure why they chose to add the cegui-0 suffix, though.

As for the incorrect case in the include path, that explains why I couldn't get my versions of the CEGUI CMake scripts working. Weird.

Quintus commented 10 years ago

As for the incorrect case in the include path, that explains why I couldn't get my versions of the CEGUI CMake scripts working. Weird.

I’ve reported the problem upstream to CEGUI devs: http://cegui.org.uk/forum/viewtopic.php?uid=12544&f=3&t=6751&start=0

The CEGUI people use a weird combination of bugtracker + forum for bugtracking. The bugs forum is not linked from the website, but the bugtracker -- but the bugtracker doesn’t let you register. Unless you manually look into the forums, you won’t be able to even find the bugs forum. And registering with that forum requires you to surf CEGUI’s wiki and fill out one of these awful captchas. I really expected that my first post on the forum additionally is subject to moderation or so. They don’t want bugreports I guess. Bah.

Vale, Quintus

Quintus commented 10 years ago

Upstream CEGUI has fixed the pkg-config issue with this commit on their development branch, i.e. it’s not in a stable release yet. Complete discussion is in the CEGUI forums.

Vale, Quintus

Quintus commented 10 years ago

@Luiji, it seems they have moved Falagard into an own library: http://static.cegui.org.uk/docs/current/fal_man.html

Vale, Quintus

EDIT: Forget that. I’ve misunderstood their documentation layout.

AMDmi3 commented 10 years ago

You might want to check out this commit regarding CEGUI detection. https://github.com/AMDmi3/SMC/commit/83c989707b7d4cdf80586a327910ac0aedfd13f6

PS. SMC CMakeLists says that pkg-config is better way of dependency detection - I'll disagree with that.

CMake's building modules and custom ones (which are very simple to write, only FIND_PATH + FIND_LIBRARY are needed basically) work quite well and produce [full path to library] and [include path] which are easy to manage and may just be passed to TARGET_LINK_LIBRARIES/INCLUDE_DIRECTORIES.

pkg-config, though, produce mix of different entities (like -l foo -L /path/to/foo) which, being meaningless without each other, should be separated and passed to different commands. Additionally, these are later combined back with possible ill side-effects, like picking up wrong version of a library from -L path provided by pkgconfig output of unrelated library.

Needless to say, this issue is also a result of using pkgconfig.

Quintus commented 10 years ago

PS. SMC CMakeLists says that pkg-config is better way of dependency detection - I'll disagree with that.

The comment is outdated, relying only on pkg-config indeed is (currently) not ideal. Which is why I have written a module for finding CEGUI; it uses pkg-config as a base, but also uses find_path and find_library. The problem here was an error in CEGUI’s pkg-config file, i.e. something you cannot point to as being pkg-config’s fault. pkg-config’s goal is the unification of library and header detection so that it is not necessary to know where a project chose to place its headers as long as it provides a proper pkg-config file. Currently, this is far from being ideal, but I do think pkg-config’s efforts should be supported.

Your commit looks fine to me. As it refers to the cegui-0.8 branch, I think @Luiji should merge it.

Vale, Quintus

Quintus commented 10 years ago

@Luiji, you said you got segfaults when trying to use CEGUI 0.8. Did you get these segfaults in SDL’s IMG_Load() function in conjunction with libPNG and weren’t able to properly resolve that problem? Today I ran into this, and it turned out to be an incompatibility of the SDL_image and FreeImage libraries that require different versions of libPNG. As a consequence, I dropped the FreeImage dependency and instruct CEGUI to use the DevIL library instead. Could you check if merging commit 8a3a36b167a99fec273f9b3b9503119487db2d4f fixes the segfaulting problem for you?

Vale, Quintus

Luiji commented 10 years ago

I merged everything up, but it's still got a segmentation fault. For reference, here's the current GDB traceback. It seems to be a related problem, but related to libJPEG.

[nnn@nnn-optiplex-745 build]$ ./manage test
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from testinstall/bin/smc...done.
(gdb) run
Starting program: /home/nnn/Documents/smc/cegui-0.8/smc/build/testinstall/bin/smc 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Initializing resource manager and core classes
Game data directory: /home/nnn/Documents/smc/cegui-0.8/smc/build/testinstall/share/smc
User data directory: /home/nnn/.local/share/smc
User cache directory: /home/nnn/.cache/smc
User config directory: /home/nnn/.config/smc
Warning: Preferences file '/home/nnn/.config/smc/config.xml' does not exist. Using default values.
Configuration file is '/home/nnn/.config/smc/config.xml'.
Translation locale is en_US.UTF-8
Translation support with gettext set to:
    Directory /home/nnn/Documents/smc/cegui-0.8/smc/build/testinstall/share/smc/translations
    Codeset: UTF-8
    Text domain: Secret Maryo Chronicles
[New Thread 0x7fffe6cbe700 (LWP 19630)]
[Thread 0x7fffe6cbe700 (LWP 19630) exited]
CEGUI log file is at '/home/nnn/.cache/smc/cegui.log'.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff1d8f0bc in jpeg_CreateDecompress () from /usr/lib/libfreeimage.so.3
(gdb) backtrace
#0  0x00007ffff1d8f0bc in jpeg_CreateDecompress ()
   from /usr/lib/libfreeimage.so.3
#1  0x00007fffe813a12c in SILLY::JPGImageContext::JPGImageContext() ()
   from /usr/lib/libSILLY.so.1
#2  0x00007fffe8139bd8 in SILLY::JPGImageLoader::loadHeader(SILLY::PixelFormat&, SILLY::DataSource*) () from /usr/lib/libSILLY.so.1
#3  0x00007fffe8138d38 in SILLY::Image::loadImageHeader() ()
   from /usr/lib/libSILLY.so.1
#4  0x00007fffe83401f5 in CEGUI::SILLYImageCodec::load(CEGUI::RawDataContainer const&, CEGUI::Texture*) () from /usr/lib/cegui-0.8/libCEGUISILLYImageCodec.so
#5  0x00007ffff7bcd69f in CEGUI::OpenGLTexture::loadFromFile(CEGUI::String const&, CEGUI::String const&) () from /usr/lib/libCEGUIOpenGLRenderer-0.so.2
#6  0x00007ffff7bcf512 in CEGUI::OpenGLTexture::OpenGLTexture(CEGUI::OpenGLRendererBase&, CEGUI::String const&, CEGUI::String const&, CEGUI::String const&) ()
   from /usr/lib/libCEGUIOpenGLRenderer-0.so.2
#7  0x00007ffff7bc0eec in CEGUI::OpenGLRendererBase::createTexture(CEGUI::String const&, CEGUI::String const&, CEGUI::String const&) ()
   from /usr/lib/libCEGUIOpenGLRenderer-0.so.2
#8  0x00007ffff77300df in CEGUI::ImageManager::elementImagesetStart(CEGUI::XMLAttributes const&) () from /usr/lib/libCEGUIBase-0.so.2
#9  0x00007ffff7732a8b in CEGUI::ImageManager::elementStartLocal(CEGUI::String const&, CEGUI::XMLAttributes const&) () from /usr/lib/libCEGUIBase-0.so.2
#10 0x00007fffe8546891 in CEGUI::ExpatParser::startElement(void*, char const*, c---Type <return> to continue, or q <return> to quit---
har const**) () from /usr/lib/cegui-0.8/libCEGUIExpatParser.so
#11 0x00007fffe9cffd1f in ?? () from /usr/lib/libexpat.so.1
#12 0x00007fffe9d00a1e in ?? () from /usr/lib/libexpat.so.1
#13 0x00007fffe9cfedb1 in ?? () from /usr/lib/libexpat.so.1
#14 0x00007fffe9cff53d in ?? () from /usr/lib/libexpat.so.1
#15 0x00007fffe9d029af in XML_ParseBuffer () from /usr/lib/libexpat.so.1
#16 0x00007fffe854566e in CEGUI::ExpatParser::parseXML(CEGUI::XMLHandler&, CEGUI::RawDataContainer const&, CEGUI::String const&) ()
   from /usr/lib/cegui-0.8/libCEGUIExpatParser.so
#17 0x00007ffff76cc184 in CEGUI::XMLParser::parseXMLFile(CEGUI::XMLHandler&, CEGUI::String const&, CEGUI::String const&, CEGUI::String const&) ()
   from /usr/lib/libCEGUIBase-0.so.2
#18 0x00007ffff77216af in CEGUI::Scheme::loadXMLImagesets() ()
   from /usr/lib/libCEGUIBase-0.so.2
#19 0x00007ffff77281bb in CEGUI::Scheme::loadResources() ()
   from /usr/lib/libCEGUIBase-0.so.2
#20 0x000000000069f674 in CEGUI::NamedXMLResourceManager<CEGUI::Scheme, CEGUI::Scheme_xmlHandler>::doExistingObjectAction (this=0x1132760, object_name=..., 
    object=0xd15590, action=CEGUI::XREA_RETURN)
    at /usr/include/cegui-0/CEGUI/NamedXMLResourceManager.h:425
#21 0x000000000069ece7 in CEGUI::NamedXMLResourceManager<CEGUI::Scheme, CEGUI::Scheme_xmlHandler>::createFromFile (this=0x1132760, xml_filename=..., 
    resource_group=..., action=CEGUI::XREA_RETURN)
---Type <return> to continue, or q <return> to quit---
    at /usr/include/cegui-0/CEGUI/NamedXMLResourceManager.h:287
#22 0x0000000000697015 in SMC::cVideo::Init_CEGUI_Data (this=0xa46790)
    at /home/nnn/Documents/smc/cegui-0.8/smc/src/video/video.cpp:151
#23 0x00000000005347ca in SMC::Init_Game ()
    at /home/nnn/Documents/smc/cegui-0.8/smc/src/core/main.cpp:261
#24 0x0000000000533f54 in main (argc=1, argv=0x7fffffffe318)
    at /home/nnn/Documents/smc/cegui-0.8/smc/src/core/main.cpp:173
(gdb) quit
A debugging session is active.

    Inferior 1 [process 19626] will be killed.

Quit anyway? (y or n) y
[nnn@nnn-optiplex-745 build]$

(For reference, ./manage is a script I wrote that contains some shortcuts to longer commands I execute frequently.)

Quintus commented 10 years ago

There’s still FreeImage somehow involved. Try deleting the entire build directory and compiling SMC from scratch; FreeImage is not needed anymore, and it may be the problem.

Vale, Quintus

Luiji commented 10 years ago

@Quintus Figured it out. Didn't merge FindCEGUI.cmake correctly. Got my way up to a `CEGUI::InvalidRequestException. Commiting the modifications...

Quintus commented 10 years ago

@Luiji Your CMake module for CEGUI is still not correct... You have no image codec. Add the DevIL detection, maybe the error vanishes.

Vale, Quintus

Quintus commented 10 years ago

I did so for you in commit f39539deaf98f9a7bba3565d3671fbe4c464917a. This is UNTESTED! I have no CEGUI 0.8 right now here, so please test if the DevIL codec is detected at all.

Vale, Quintus

Luiji commented 10 years ago

Compiled but had no effect. The log gets spammed with this error:

CEGUI::UnknownObjectException in function 'CEGUI::Image& CEGUI::ImageManager::get(const CEGUI::String&) const' (/build/cegui/src/cegui/cegui/src/ImageManager.cpp:262) : Image not defined:

I think I just made a mistake in my usage of the ImageManager. Interestingly, it doesn't fail after spamming all these, it fails on this:

CEGUI Scheme Exception occurred : Failed to load module 'libCEGUIFalagardWRBase.so': /usr/lib/cegui-0.8/libCEGUIFalagardWRBase.so: cannot open shared object file: No such file or directory

It is completely correct that /usr/lib/cegui-0.8/libCEGUIFalagardWRBase.so does not exist. It isn't provided by the Arch Linux package. I'm not sure what the deal with this is but I haven't yet had time to look into it. I'll get to it soon.

Quintus commented 10 years ago

Hm, very mysterious. Here’s how the Arch Linux package is built: https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/cegui

As far as I can see, everything normal. The package shouldn’t miss anything.

Vale, Quintus

Quintus commented 10 years ago

@Luiji, I figured it out. FalagardWRBase has been renamed to CoreWindowRendererSet. This had to be changed both in the CMake module (to find the correct library) and in the XML schema (to load the correct module). Commit dce86f635ec7a2a5e0117993819fcd940fcba223 does this now.

Note that I fixed a dependency error. We were depending on TinyXML, but as we already depend on libxml2, I figured that to be nonsense. I removed the implicit dependency on TinyXML and instructed CEGUI to use libxml2 instead. Please recompile SMC from scratch to not have any old cmake stuff flying around.

Vale, Quintus

Luiji commented 10 years ago

@Quintus that commit got past that error. Now to deal with the fact that I haven't updated any of the .layout files to the latest format! :P

Luiji commented 10 years ago

@Quintus Still getting all of the error messages relating to images. However, we now abort here:

Setting up level player
Loading levels
Applying preferences
CEGUI::UnknownObjectException in function 'CEGUI::WindowFactory* CEGUI::WindowFactoryManager::getFactory(const CEGUI::String&) const' (/build/cegui/src/cegui/cegui/src/WindowFactoryManager.cpp:185) : A WindowFactory object, an alias, or mapping for 'TaharezLook/StaticText' Window objects is not registered with the system.
CEGUI::InvalidRequestException in function 'void CEGUI::GUILayout_xmlHandler::elementWindowStart(const CEGUI::XMLAttributes&)' (/build/cegui/src/cegui/cegui/src/GUILayout_xmlHandler.cpp:251) : layout loading has been aborted since no WindowFactory is available for 'TaharezLook/StaticText' objects.
terminate called after throwing an instance of 'CEGUI::InvalidRequestException'
  what():  CEGUI::InvalidRequestException in function 'void CEGUI::GUILayout_xmlHandler::elementWindowStart(const CEGUI::XMLAttributes&)' (/build/cegui/src/cegui/cegui/src/GUILayout_xmlHandler.cpp:251) : layout loading has been aborted since no WindowFactory is available for 'TaharezLook/StaticText' objects.

I'll look more into it later but we're definitely making progress!

Quintus commented 10 years ago

Seems we are jumping from on exception to the next one :-P

Vale, Quintus

Quintus commented 10 years ago

@Luiji, as @datahead8888 pointed out to me in https://github.com/Quintus/SMC/issues/100#issuecomment-47750270, we are approaching the feature-freeze date end of this month. Do you think you are able to manage CEGUI 0.8 until that? It would be very nice to have this in 2.0.0 as this is our major blocker that prevents SMC from inclusion into modern Linux distributions.

Vale, Quintus

Luiji commented 10 years ago

@Quintus I'll try what I can but I've been pretty busy so don't hold your breath. Any help would be appreciated. I'll see if I can fit a little more work on it today.

datahead8888 commented 10 years ago

@Luiji, I just thought I'd say that I really respect your diligence with CEGUI, since it does not sound like a fun task but is obviously something that has to be done.

Quintus commented 10 years ago

Being realistic, we will not get CEGUI 0.8.x support in version 2.0.0. This is nothing bad, we will schedule it for later. This will be one of the first things I will go after once the 2.0.0 final is out.

In the meantime, I hope we can statically compile CEGUI 0.7.x in so we can provide packages for Ubuntu and other distros that don’t break other programs depending on the shipped CEGUI 0.8.x.

Vale, Quintus

akien-mga commented 9 years ago

I just found this, I guess it could be of use: http://lists.freedesktop.org/archives/games/2014-June/000448.html

Quintus commented 9 years ago

I just found this, I guess it could be of use: http://lists.freedesktop.org/archives/games/2014-June/000448.html

Interesting, thank you for the link. Colorized version of the patch for review: http://coderay.rubychan.de/rays/8407

This obviously won’t apply anymore to the current codebase, also there has been work in the cegui-0.8 branch that probably collides with this. Also, @Luiji has been of the opinion that CEGUI should be replaced altogether from the TSC sources, because it is much more complex than our needs require.

Vale, Quintus

Quintus commented 9 years ago

Here’s something I found yesterday that could work as a CEGUI replacement:

http://clutter-project.org

Clutter is part of the GNOME project and thus maintained. libxml++, which we already depend on, depends on Glib, so choosing something in that area as a CEGUI replacement seems natural. I first thought about rendering Gtk+ onto an OpenGL surface; this is possible, but you have to write your own custom Gdk backend for that. Clutter can already render onto an OpenGL surface.

@brianvanderburg2 suggested this:

http://libagar.org/index.html.en

It’s called AGAR, and I’ve not yet investigated as to whether may or may not fit.

Valete, Quintus

Quintus commented 9 years ago

I have spent the last week on CEGUI and graphics libraries. I can now tell the following: CEGUI is a great library with regard to features and API. But until you get to using its API, the setup is insanely hard, because the Linux platform seems to be very underrepresented in the CEGUI team. After a week of trying, I was unable to get even the official CEGUI samples to run correctly. Here’s the post I made to the CEGUI forums: http://cegui.org.uk/forum/viewtopic.php?f=10&t=6995

As it stands, I think I have found a bug in CEGUI that prevents it from being used on Linux with the OpenGLRenderer. @carstene1ns pointed me to other programs using CEGUI on Linux, but all run on Ogre, so I have to assume that CEGUI’s OgreRenderer works on Linux. However, I am not willing to add a dependency on Ogre just for CEGUI. I have coded an example using SFML that reproduces the problem: An upside-down, tiny CEGUI inside the larger SFML window. As pointed out in the CEGUI forums thread, this also happens with SDL2, and GLFW2 (which is what the CEGUI samples use).

Thus, unless someone from the CEGUI team can shade some light on the issue, we will have to abandon CEGUI. I have investigated named AGAR, but it is not developed anymore since years and it’s documentation is bare, so it’s not an option. Clutter is not a GUI library, it is a graphics framework like SFML or SDL2 (that was an error on my side). There is not a single actively developed GUI library apart from CEGUI out there, so this will mean the one thing: We have to code our own, preferably in a separate repository to make it reusable in other projects.

I will now wait for what happens over on the CEGUI forums, and if we can’t resolve the OpenGLRenderer-on-Linux problem in that thread, we shouldn’t lose time and start with a separate GUI library.

Valete, Quintus

Quintus commented 9 years ago

@carstene1ns to the rescue! :-) He suggested imgui, which appears to be actively developed and not bloated on the first glance. I have not yet investigated it, but I’m going to do so.

Vale, Quintus

datahead8888 commented 9 years ago

Thus, unless someone from the CEGUI team can shade some light on the issue, we will have to abandon CEGUI.

How long would it probably take (very roughly) for them to do a minor release that fixes this problem?

Quintus commented 9 years ago

How long would it probably take for them to do a minor release that fixes this problem?

See their list of releases with dates at the bottom of this page:

http://cegui.org.uk/drupal/download

I’ll investigate imgui now.

Vale, Quintus

akien-mga commented 9 years ago

There is not a single actively developed GUI library apart from CEGUI out there, so this will mean the one thing: We have to code our own, preferably in a separate repository to make it reusable in other projects.

What about:

In the project I'm working on (@OpenDungeons) we're using CEGUI, but indeed with its OGRE renderer.

Quintus commented 9 years ago

So finally some suggestions here... I’ll look at each of those one after the other.

akien-mga commented 9 years ago

So finally some suggestions here... I’ll look at each of those one after the other.

Note that I don't know the libraries, I'm just dropping some names that I've encountered during my years of following open source projects :) ImGui does sound interesting. For MyGUI, the well-established projects that I know which use it are OpenMW and StuntRally. Fifechan is used (and developed) by the FIFE/Unknown Horizons team.

Quintus commented 9 years ago

Thanks, @akien-mga. What led me to my original statement you quoted was the result of more than a dozen Google searches which always yielded several forum posts in several forums that basically said "the only GUI system developed is CEGUI". Just to give you the context why I wrote that. I am very happy to have alternatives to investigate given the problems CEGUI seems to have on Linux.

Btw, you noticed we have a large team discussion scheduled in IRC for the 21st?

Vale, Quintus

Quintus commented 9 years ago

Okay, I took a look at MyGUI. Problems I found:

Hmmm.

Vale, Quintus

Quintus commented 9 years ago

Results on imgui:

Vale, Quintus

Quintus commented 9 years ago

Okay, MyGUI ruled out definitely now. OpenGL on Linux is unsupported: https://github.com/MyGUI/mygui/issues/24

Vale, Quintus

Quintus commented 9 years ago

Findings on Fifechan:

Guys, write introductory docs! This can’t be so damned hard!

Vale, Quintus

Quintus commented 9 years ago

librocket seems to not be developed anymore. All what happens on their repository is that a PR is merged every now and then; the latest news on their website date to 2011. Also, the docs say that they’re in the process of being upgraded, but appearently they do this since 2010.

Vale, Quintus

akien-mga commented 9 years ago

An interesting read about game GUI libraries, though it's two years old: http://www.gamedev.net/blog/1682/entry-2256533-most-gui-libraries-are-terrible/

In the comments of the above blog post, I found out above turbobadger: https://github.com/fruxo/turbobadger

About librocket, it's used at least in Unvanquished: https://www.unvanquished.net/?p=294

Btw, you noticed we have a large team discussion scheduled in IRC for the 21st?

I'll try to drop by :-)

akien-mga commented 9 years ago

Found another interesting resource: http://www.slant.co/topics/748/~what-are-the-best-guis-for-opengl It lists namely Coherent UI, GiGi (this one is used by FreeOrion) and AntTweakBar as GUIs compatible with OpenGL.

Quintus commented 9 years ago

An interesting read about game GUI libraries, though it's two years old: http://www.gamedev.net/blog/1682/entry-2256533-most-gui-libraries-are-terrible/

SFGUI also looks interesting. Much to check out. Hehe, thanks for all your input, it’s appreciated!

Vale, Quintus

Quintus commented 9 years ago

Reading over what I find in those links...

http://www.slant.co/topics/748/~what-are-the-best-guis-for-opengl

It’s obvious we can’t use the commercial libraries that require us to pay them. Apart from them:

http://www.gamedev.net/blog/1682/entry-2256533-most-gui-libraries-are-terrible/

  • CEGUI: We all know that.
  • SFGUI: Interesting, I have to investigate
  • Berkelium: Have a fully-fledged web browser in your application and forcibly use JavaScript. No thanks.
  • GWEN: Dead
  • libRocket: Dead

I’ve not yet checked out the comments.

Vale, Quintus

Quintus commented 9 years ago

Investigation on TurboBadger:

Grrrr. It was so near. If there only would be docs.

Vale, Quintus

Quintus commented 9 years ago

Investigation on SFGUI:

That being said, I like SFML and would be glad if we switched to it. I will now try using it for an example program, and depending on how well I succeed with this, I’d like to use this one unless CEGUI devs reply to my forum posting.

Vale, Quintus

Quintus commented 9 years ago

Bringing @Luiji into the discussion here. How do you think to using SFML + SFGUI if we can’t figure out the CEGUI OpenGLRenderer issue?

Vale, Quintus

datahead8888 commented 9 years ago

I would be interested in how hard it is to add a GLSL shader (ie a lighting system) on top of the existing rendering functionality in SFML and/or SFGUI. If none of us can try it out or verify this (I'm tied up with school for the most part myself), maybe we could ask about it in official forums.

Quintus commented 9 years ago

@datahead8888 SFML is not in your way if you want to do OpenGL stuff yourself: http://www.sfml-dev.org/tutorials/2.2/window-opengl.php

Vale, Quintus