Easy GUI for 3D engine

Started by
14 comments, last by GameDev.net 10 years, 9 months ago

I search easy GUI library for DirectX (vs2010). I looking for wxwidgets and qt but they seem complexity. Do you known some other ?

Advertisement

There is CEGUI (lots of features but also more on the complex side and a bit dependency heavy) and libRocket (rather lightweight and simple but the project seems to have stalled for a long time now - what is there seems to be working though).

If by "GUI library" you mean basic window management and context creation though, I would suggest SFML or GLFW.

Edit: nevermind, missed the DirectX part.

wxWidgets generally supports OpenGL rendering much better than DirectX and the library is simple but unfortunately it is messy as hell with years of cruft. It was also based on the design of MFC in the early days (when two stage construction was "a good idea") making it a bit horrid.

Since Qt requires an external parser to compile (it isnt 100% standard C++), people don't realize this yet but in ~10 years it is going to be as hard as Borland VCF C++ projects to compile.

So my suggestions...

There is a version of GLUT for DirectX called DXUT (in the DirectX SDK Samples). If you are confident enough to load your own textures / sounds / shaders etc... without SDL or other frameworks, then I highly recommend it. Since DXUT (and GLUT) is extremely small, it also keeps your software portable to other platforms at a later date (such as that crippled Windows 8 Metro stuff). If you don't want to write your own texture loading stuff then you can still use standalone libraries (FreeImage, DevIL/OpenIL, even SDL just for images).

Since you are using DirectX (with a GUI toolkit), you are probably only interested in the Windows platform. Since C++/CLI or C++/CX are "Microsoft standards" then perhaps you might want to try using Winforms to create the DX rendering context using those compilers? The rest of your code can remain 100% standard C++. If you don't mind constantly asking Microsoft (every 30 days) for a developer license, then you might want to use the Windows 8 Metro framework as a GUI / rendering context too.

http://tinyurl.com/shewonyay - Thanks so much for those who voted on my GF's Competition Cosplay Entry for Cosplayzine. She won! I owe you all beers :)

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.


If by "GUI library" you mean basic window management and context creation though, I would suggest SFML or GLFW.

Edit: nevermind, missed the DirectX part.

I agree with GLFW (OpenGL only), but why not SFML? Like SDL, it's capable of managing a window with attached DirectX device/context. Basically every framework will do, as long, as you can acquire a valid handle pointer - that's all what is required to properly initialize a direct3d device.

I have no experience in using SFML in combination with DirectX. I felt it safer to just redact that piece of uncertain information than offer pure speculation. However, while we are doing speculation: at least GLFW 3 seems to be able to return the native window handle. If it's possible to prevent the GL context creation (with the appropriate window hints), using GLFW for DirectX should be doable too with little extra work.

Since Qt requires an external parser to compile (it isnt 100% standard C++), people don't realize this yet but in ~10 years it is going to be as hard as Borland VCF C++ projects to compile.

That's an awfully large leap of opinion. I'm personally a fan of Qt and if I could see any reason that this comment were true, I would look at other libraries, but the comparison to Borland VCF is highly inappropriate and misleading. Qt continues to update the library to incorporate the new C++ features such that signals/slots can be used with C++11 lambda/functional if desired, Qt is not diverging further from standards which is quite a large difference. As to the moc pass, it is effectively nothing more than extraction of reflection information (plus a couple other items) which is not tied to any specific version of C++, special extensions or other things which is again highly different than a library written against a custom closed source compiler/RAD tool. All said and done, Qt and C++ are merging closer together, not diverging away from each other so your worries are likely unfounded. (No absolutes, anything "could" happen; we could all be writing games in Basic in 10 years seems about as likely.)

As to the other libraries (non-DX based though), you can see an example of integration of multiple libraries in the sources for my articles: https://code.google.com/p/a8u-tutorial-sources/

Incorporated into that right now:

C++11 libraries, lamda, ranged for in use. (Would probably have problems with VC2010 unfortunately but could be corrected.)

SFML for window handling.

libRocket for the gui.

Lua for scripting. (Integrated with libRocket and some preliminary bits of the game.)

Physfs for archive packs. (librocket and everything else is integrated into this already.)

Qt5 for the editor wrapper. (Just started, not integrated with the game itself yet.)

It would not take much to replace the minimal OpenGL use with DX, I've not done any real rendering except the integration with libRocket for the moment.

I recant.

Qt is non-standard garbage and going the way of the dinosaur fast. Best bet is to use a Microsoft approved offering, like DXUT.


Considering a whole OpenSource community lives around Qt (KDE), I find such a flamebaity post without any evidence to back it up ... extremely difficult to believe.

libRocket for the gui.


I checked out libRocket in the past but it always looked inactive to me. The last news on their web page is from 2011 and the forum is not exactly active but not completely dead either. Do you have any more experience with that project? Are they still actively developing?

Qt is non-standard garbage and going the way of the dinosaur fast. Best bet is to use a Microsoft approved offering, like DXUT.


Considering a whole OpenSource community lives around Qt (KDE), I find such a flamebaity post without any evidence to back it up ... extremely difficult to believe.

It's not really flamebaity, Qt is very difficult to compile/build for Windows platform, has many non-standard tools and code, looks like crap compared to officially approved GUI technologies for Windows and seems to have compatibility issues with Windows 7 and above. For Linux Qt is the one-eyed man in the land of the blind. Everywhere else its just a one-eyed man smile.png

I meant also that mouse-based GUIs are going the way of the dinosaur fast.

http://www.kde.org/community/history/qtissue.php

This topic is closed to new replies.

Advertisement