So I was tweeting that this took forever:

dialog1

It’s just a dialog box for gratuitous space battles 2., why did it take more than twenty minutes to put together? Now… I’ve seen unity, I know it has all these plug-ins that do stuff like this, and that it’s all very user-friendly etc blah blah. But I’m old school. I’m rocking my own custom-written engine, including all the GUI. That gives me huge advantages (mostly speed) and also some disadvantages. The best advantage is there isn’t anything I can’t make the code do.

The pain with this dialog box came in three flavours.

Flavour one was those circular clock-like indicators. In theory, this is really easy, you can just generate a tri-strip of a lot of polygons and draw a curve thats smooth and crisp as you like, as long as you can spare the vertexs. I’m not drawing many, so it’s not an issue. The problem is, when you do that, you get a too-blocky, too un-aliased clunky mess that just doesn’t look ‘right’ when surrounded by lovely aliased everything. I’m not drawing 3D models, so my game has a  nice smooth look to it, and it jarred badly. So I have a sprite of that curve, and I draw a subset of it using a tri-strip arc. It’s a bit fiddly, ant took a while to get right.

Flavour two was the outline of the right-hand part of the window. It’s a bit complex, as it goes in and out and then around the close button and then loops around those circles, and it has to be really slick too, and ironically in this case it looks better drawn as a crisp 1 pixel line, so there is actual hand-crafted code in there to work out all those positions and curve ncie arcs and lines around them.

Flavour three was speed. I like everything in my game to render fast, including GUI. No point in having a fast engine where 95% of the frame is spent drawing a dialog box. That means ensuring that ouline on the dialog is a single draw call with no fuss, that all those tiny animated bits of fluff in the dialog corners and outside the edges are drawn efficiently, that the calculations on that arc outline are as fast as possible, and that the dialog in general; doesn’t use many draw calls.

It’s all horribly, laughably slow really. I probably have a ‘spare render target’ knocking about that I could use to blap this whole dialog to (BTW they resize dependent on the ship, which adds to the complexity), and then only update it when it changed, otherwise just blapping it as a single quad. In practice, the windows various elements update quite a bit.. but I’m sure I could speed up the module icon rendering with runtime aliasing onto spare render targets. I love all this stuff.

But even I know when I’m getting obsessed and need to move on!

8 Responses to “Anatomy of rendering a game dialog box in a custom engine (GSB2)”

  1. Metalfusion says:

    This is why I use a HTML & CSS based UI that runs in a completely separate process. Quite inefficient, but at least I can use all of CSS’s graphical features and still have complete control by using JavaScript for interactions and animations etc. Another bonus is that the UI will be fully skinnable and moddable, as all of the JavaScript and CSS code reside in separate files that are loaded at runtime.

  2. Sembiance says:

    You mention speed as the top advantage over Unity… I feel like you need to back that claim up with benchmarks or something. Seems like it would be “plenty fast” in Unity. Perhaps not though :)

  3. Alberto Cairo says:

    It seems you’re suffering from what I call the “Hartman’s disease”…
    It’s a nasty complication of the NIH syndrome.
    In the final stages of the illness, programmers can be heard shouting:
    “This is my _engine_. There are many others like it, but this one is mine…”
    Welcome to the club! ;)

  4. cliffski says:

    You mean I should just use unity like everyone else?
    I manage to get games made faster than most devs, doing everything myself, even coding the engine. I don’t think writing my engine has exactly held me back :D

    • Sembiance says:

      @cliffski: You always poo-poo Unity and other game dev frameworks, but in all my time reading your blog, I don’t believe you’ve ever tried them. I would LOVE for you to try Unity for a full week, then write up a blog post about it. What preconceptions about it you had that were correct and which ones maybe were not correct. I think other developers would love to see that too.

  5. Alberto Cairo says:

    Well, I’m “biased”: the aforementioned disease makes thinking straight very, very difficult. In my restless dreams I see wheels… lots of wheels, all of them begging to get reinvented… :o)
    Anyway, for my current project I’ve taken a less hardcore approach than yours.
    The engine is my own, however I’m using the following libraries:
    – SDL2 instead of Win32, etc.
    – AngelScript instead of rolling my own scripting language.
    – FLTK (only for the editor, though, I’m writing my own in-game gui, too).
    – GLEW for OpenGL extensions.
    All these dependencies make me feel so bad… ;-)
    They save me a lot of time, though.

  6. mrstarware says:

    Have you looked into a project like Xamarin? It’s suppose to port your code to Mac, and smartphones automatically. This could save you time and money. It also gives a good excuse to upgrade to a newer (post-C++) language. Which I’m guessing would be a big advantage for you, such as easier things like LinQ, databases, threading, etc.
    It’s suppose to be compiled to ‘native’ code. What happens when you move to openGL? will all of this ‘fiddling’ port??

  7. ac says:

    While this doesn’t really apply to GSB, talking about dialogs, UI and that kind of jazz, I find a lot of RPG’s that in early 90s often sported custom font/typeface/bitmap fonts etc, I find that where the UI could be taken up a notch in visuals that way, it’s often not.

    In the case of the picture of GSB2 UI, since the image is not in 1:1 scale nor probably a final version I don’t want to come down too hard but I definitely see a lot of room to improve here. I’d perhaps start the by getting an artist to sketch various UIs on paper and then iteratively work them in Flash or such RAD tool.
    Not convinced? The overall quality of what’s seen is perhaps slightly below what was in a Sierra’s Outpost from 1994 for Win 3.x. The Unity games I’ve seen always look distinctly like they were made in Unity – this is bad and suggestive of the tool being a bottleneck. I’m not up to date on what really is the best UI design tool out there, but after playing games like Machinarium and Botanicula made completely in Flash and having not seen anything top them yet, I would suspect Flash is pretty high in the list of tools I’d want to give artists to design UIs with.