Jump to content

- - - - -

User Interface Frameworks

4: Adsense

Lately I have found myself looking for an easy (or easier) way to get some native D3D11 code to play nicely with a user interface framework. Way back when I first started out writing Hieroglyph, I had the basic idea that I could just make my own user interface in the engine. I think many people start out with this mindset, but it is rarely the best way to go. You have to build so many pieces to make it work well, and there is almost always one more thing that you have to add to take the next step in a project... It is so much better to have an existing framework that you can simply adopt and put your rendering code into, and you will be significantly more productive if don't have to reinvent the wheel.

Native Frameworks
Unfortunately, there aren't tons of options available for native code. I don't count Win32 as a UI framework, but rather more as a way to make some windows to render into. Technically you can create some basic UI elements, but it doesn't really count. MFC is an option, but it is a relatively old codebase and it can feel pretty clunky until you really have some experience with it. There is also the downside that MFC isn't available with the Express versions of Visual Studio, which limits the audience that can use your code.

wxWidgets is another option that is open source and cross platform. This solves the issue of being available on the Express SKU, but it has a design that is very reminiscent of MFC... There has to be something more modern available. Qt is another open source and cross platform solution, but it is a really, really big framework. In the context of Hieroglyph 3, it would require all of its users to download and manage a whole other library in addition to Hieroglyph 3 itself, which is less than ideal (although it is a viable option).

Managed Frameworks
So if we decided not to use a native framework, but rather a managed one, then some of the issues from above go away too. Basically there are a couple frameworks to choose from: Winforms and WPF. Both of these frameworks are available on Express SKUs, so there is no issue there. Since they are included "in the box", the users don't have manually download any additional libraries on their own. So these seem like a viable option as well. The obvious downside here is that we have to create a native-to-managed interface, which requires careful and deliberate planning on how the UI framework has to interact with the native code. This is non-trivial work, especially if you haven't done it before...

Native and Managed Frameworks
There is one additional possibility that combines both of these worlds. On Windows 8, it is possible to build WinRT apps with native C++ and XAML. This allows for a built in framework, available on Express SKUs, and access from a native codebase - no managed code required. This is really attractive to me, since I have never been much of a managed developer. But there is always a catch... it is only available for WinRT applications. This significantly limits the people that have access to it (at least at the moment) but it still remains as an interesting option.

So What To Do?
Well, currently Hieroglyph3 supports MFC, at least at a basic level. One of the users of the library has shown a sample of using wxWidgets with it in a similar way, so I may try to see if he will contribute that back to the community (@Ramon: Please consider it!). In addition to these options, I also want to explore Winforms and WPF. And in the long run, I want to use C++ and XAML as well. So I choose all of the above, except for Qt at the moment.

My plan is to build some library support for each of these frameworks in a optional additional library manner, similar to how the current MFC solution is separate from the core projects. As I go through each framework, I'll be discussing my impressions of them, as well as discussing the process. Strangely it seems that there isn't too much centrally located information on this very important topic, and I hope to consolidate some of it here in this journal. I'll probably start out by describing the existing MFC solution, so stay tuned for that one next time.

Mar 13 2014 03:49 PM

From experience, MFC / Win32 / WinForms tend to be harder to make it not look like, well, windows UI.  XAML is much easier to make pretty, but also a bit more complex to create and use.  And the win8/C++ XAML codebehind is amazingly ugly to look at =)


Last time I used WPF for a game, I ran into airspace issues with directX integration though, but admittedly that was years ago and it may have gotten better.


Of course, since you're more of a toolset than a game, WinForms/MFC might be perfectly acceptable as a look, and winforms is nice and easy to use, I was always able to whip out a decent winforms UI quite fast back when I did it for a living.

Mar 13 2014 07:37 PM

Thanks or the comments ferrous.  I totally agree that the MFC / Win32 / WinForms look like business apps, but I'm actually ok with that.  I'm looking at this like a learning experience, so I suppose we'll see how it turns out in the end.


Regarding the airspace issues with WPF, if you use a D3DImage as the ImageSource, then it has full compositing capabilities.  I experimented a little today with this, and it seems to be pretty easy to use.  I'll be posting about how to get it running shortly.

Mar 14 2014 08:56 AM

I've written a few applications in the last couple of years that render Direct3D inside Qt widgets. I agree the framework is absolutely enormous and probably overkill but the actual interop between the two was pretty straightforward really.

Mar 14 2014 12:44 PM

Yeah, I have not used Qt, but old coworkers were big fans of it.


I look forward to seeing your follow up post on WPF and D3DImage.

Mar 15 2014 01:01 PM

@Aardvajk: Is there any of your projects available to check out online somewhere?  I'd like to take a look at a few examples before I decide on how to design the interface to Qt.

Mar 16 2014 02:47 AM

@Aardvajk: Is there any of your projects available to check out online somewhere?  I'd like to take a look at a few examples before I decide on how to design the interface to Qt.


Nope, not online, but if you want to give me an email address on PM, I'll happily mail over a zip of the source for my half-finished 3D model editor if you want.


It hosts multiple D3D windows on the main form and so on. D3D 9.0c though by the way.

Mar 18 2014 12:54 PM

I would steer you clear of using WinForms for this sort of thing. A long time ago I had an idea for a C# dll that allowed one to customize the look of the basic Windows interface with graphics and animation. I actually sold it commercially for a while (well, I had one customer.) . I had to give up on it because GDI+ was changing under the hood over time and causing problems with apps I was developing later. GDI+ was a black box that reported all errors as 'unknown'. It may have improved since then but I was in way over my head.


My demo for this old product actually still works though. You can download it from my resume page here under the crazyforms.dll section. I don't know if I have the source code anymore but I can try to dig it up if you're interested in seeing... what failure looks like I guess.

Mar 18 2014 09:18 PM

@Aardvajk: Thanks for the offer - I'll take you up on it :)


@cephalo: If you can find the code, I would be happy to check it out.  I am making good progress on my WPF based integration, and having a comparison with WinForms would be really nice to contrast with.


Thanks to both for the offers!

Mar 19 2014 09:31 AM

Unfortunately, I suspect my source code is on a loose hard drive (I have drawer full of those) that isn't connected to any computer, however, in thinking about this project again, I remember an issue that you will probably have to deal with in making a UI framework for DX. If you don't consider it in advance, it might create some headaches.


There is this weird paradigm where fonts are considered software to be installed separately from the software that uses them. Sprite fonts, while sometimes necessary, are a big pain in the rear and not versatile in their use. Games and really any serious graphic design often need fonts that no other software would need, and installing such fonts on the target machine just creates clutter and complication. What if the user uninstalls the font? Nobody wants to see 20 pt. Ariel where their specialized font was supposed to be.


For example, that 'Celtic' themed font in my CrazyForms demo would be perfect for some game about the dark ages, but if you wrote a college paper with it you might face expulsion! This was a font handmade by me to create a very specific atmosphere, and has no other foreseeable role anywhere else.


.NET did have some support for private fonts, (In the PrivateFontCollection class I think.) but it was difficult to get all that sorted out. In the end I made it so that you could use private fonts or installed fonts. I believe Direct2D has some new easy access for text drawing and can now interface with Direct3D in DX 11.1 but I have only dabbled with it.


Text drawing has been a gaping hole in Direct X for some time, and if you have connections with Microsoft through your MVP status, you might see where they are going with it because they might have plans to make font drawing a lot easier in DX. GDI+ is dead I think. :)

Mar 19 2014 07:54 PM

Direct2D and DirectWrite are the appropriate ways to handle text rendering if you have to put text into your D3D11 scene.  However, what I am investigating now is the ability to put a rendered frame into a UI framework application.  So the text rendering for the interface portion of the system will be rendered by the UI framework rather than my application.  So there shouldn't be any worries there.


Like you mentioned, in my engine I use a sprite based font renderer at the moment, which is sufficient for my limited purposes at the moment.  The font textures are generated at runtime with GDI+, but in the long run I think I'll be switching over to DirectWrite.

Note: GameDev.net moderates comments.