I've decided to:

• Write a rendering system in OpenGL and Direct X


• Create an interface for the user to do his own rendering


• Create a visual editor that works in % to eliminate the problem of different resolutions and aspect ratio's


• The user must provide input

Thanks to everyone for their help

If you want any chance of producing something useful and practical, you'll need to step on the shoulders of giants that have tackled the task before.

For class design, look into existing libraries. Windows API and its recent wrappers in .Net, Java's AWT/Swing, Eclipse SWT, QT, perhaps various Linux layout and window managers.

For layout, look into CSS. It's well understood by developers, and is designed in a device/resolution agnostic manner.

Regardless of which you look at, all have their downsides, and all are incredibly complex, with many quirks and problems.

UI is not a trivial matter. To provide something designers are comfortable with, and can do practical things that directly convey their thoughts, you'll need to cover what CSS/Latex/Postscript do. In other words, really lotsa stuff.

To just design something trivial, you'll limit your potential userbase to a small number of *coders* who just need something to display their boxes and buttons with. You won't however appeal to designers.


Your general design will be based around 1 single entity - Entity.

These entities are then laid out in some way or another. Experience has shown that tree-like layout is very limiting, especially when it comes to non-trivial designs.

This implies that you'll need to handle some form of hierarchical containment, as well as arbitrary positioning.

Next problem will be relative positioning. In general, any absolute units, in either percent, pixels or centimeters are useless. Entities are laid out relative to something. At basic level relative to borders of parent, later relative to each other.

Next problem will be enforcing min/max constraints. Here, there is no perfect solution. Ultimately some component will be simply too large, and will start breaking out of its desired bounds. How to properly handle this remains the $6 million question. Even browsers today have trouble with this.

Last, and most trivial problem, is implementing the entity. Likely, this will look trivial, something like:

 virtual void render(Canvas c)

Canvas is your particular API implementation, DX, OGL, .... You then provide basic primitives, such as renderTexture, drawText, drawLine, ...).

Each different type of Entity is nothing more but a readily provided implementation. Here, you can re-use, base class for all ListBoxes, then specializations for different behaviours. And so on.

You'll also need to abstract the event pump. There's several choices. In general, a single UI thread, either applications main thread, or separate, guarded thread for UI dispatching.

But as said, designing a useful UI toolkit is far from trivial, and is a huge task.

Thanks for the idea of using css. I'm definitely going to look into it.

Quote:
Your general design will be based around 1 single entity - Entity.

These entities are then laid out in some way or another. Experience has shown that tree-like layout is very limiting, especially when it comes to non-trivial designs.

Exactly what do you mean by this? Please could you give an example of how not to limit my design

Thanks

Quote:Original post by JasonBaldwin
Thanks for the idea of using css. I'm definitely going to look into it.

Quote:
Your general design will be based around 1 single entity - Entity.

These entities are then laid out in some way or another. Experience has shown that tree-like layout is very limiting, especially when it comes to non-trivial designs.

Exactly what do you mean by this? Please could you give an example of how not to limit my design

Thanks

What *is* a component?

All entities/components share one thing - layout outline. Button, checkbox, List... as far as layout is concerned, they are all rectangles. They might have some elaborate border inside, but from layout perspective, they are rectangles.

Each of these components will act as event producer, and possibly consumer. When user clicks something, a message is sent to all registered listeners. Who sent it or who received it is not important at this level.

Quote:I think the *best* solution is actually to use triangles and whatnot to build your GUI

Implementation detail. The UI talked about here is definitely vector-based, not raster. I don't think anyone was proposing the use of raster.

When it comes to units, there's nothing wrong with using some absolute units. Saying x pixels doesn't in any way limit flexibility. Sometimes, you *want* to have a window 32x32 pixels.

Raster is far from undesirable. If you look in windows, you have a choice of different DPI for desktop. By specifying raster images in absolute pixels, you can scale them effectively through DPI modification. DPI exists for this very reason, since it provides a natural mapping between raster and vector space.

One does not exclude the other. It's unrelated to the problem of layout though, it's just an implementation detail.

And triangles are awful for any practical design. You get incredible number of redundant information, need to look at mundane details such as winding, need to worry about overlap and intersection....

The only practically acceptable option is to keep this device specific. By saying renderTtexture(), the renderer will choose what it likes best. Either 2 triangles, or a single rectangle, or rasterized scanline conversion.

Quote:Original post by Zipster

Quote:Original post by Kylotan
Don't bother with the visual editor. When you think about how a system is going to generalise to different resolutions and aspect ratios, and you quickly lose most of the benefits that a visual editor gives you. Instead, think about how to make your components flow like a web page does. You can still provide a visual editor if you feel the need, but generally I don't see the point.

The point is that UI artists can easily design and modify the interfaces without having to edit raw text files and then load the game just to see their changes. That's nowhere near user-friendly (to an artist no less) and increases iteration time immensely. If you want to support different resolutions and aspect ratios, build it into the tool.

I think a visual editor can be useful, but unfortunately it's common for people to use the existence of an editor to build entirely the wrong approach simply because it doesn't take any longer to do it when the tool does the hard work for you. Building different resolutions and aspect ratios into the tool is one example of what I think is completely the wrong approach - these problems should be addressed by the underlying formatting scheme. Of course, if you have a tool that lets you preview a GUI and quickly generate the output for it, that's fine. But that should not be what is foremost when you set out to "write a UI library to be used in games", as the original poster has said. Get the underlying representation right first and then write tools for that if necessary.

Quote:I don't see how anyone could suggest that a visual editor isn't necessary for GUI design in general. Even if you had to use the Windows Forms designer and parse resource files, it's better than nothing.

It's quite easy to knock up HTML pages or XUL dialogs without any real need for real-time visibility of how it looks, though it does help a small amount. I think the perceived need for a visual editor comes from the dark days of struggling with 'Visual' C++ or Visual Basic which have virtually no real control over layout except X,Y positioning. Still, also bear in mind I am approaching this from the perspective of someone coding a UI library, and such a person shouldn't look to tools to paper over the cracks in the implementation. Layout is one of those things that should make sense when you look at the specification, because merely testing that it looks ok in your own preview mode doesn't mean it'll be ok on everybody else's system.

Quote:Original post by Ademan555
I skipped the better half of the thread, but I was very disturbed by what I read from a few people "displaying images and text"... I think the *best* solution is actually to use triangles and whatnot to build your GUI, basically don't rely on anything resolution dependent, you'll have alot more flexibility with, say, svg+cairo, though I can't speak for the speed (I know cairo surfaces can be rendered by opengl though)

Yet most of your ingame assets are likely to be raster images. That's just how a lot of stuff will work, with textures, etc. I expect many GUI artists will be able to generate vector graphics, but even they will be implemented in terms of bitmaps.

Quote:I may be a bit biased because of what I've seen, I'm SURE that if done right raster based GUI systems can work fine and look great, but what i've seen, especially from CEGUI, is ugly images that don't work correctly together [...]

What about the thousands of professional games? I expect 99% of them just use raster images, not vectors.

Quote:I didn't sleep last night so I may not be the clearest but my point is simply take a vector based approach not a raster based one.

Vectors are better in theory, but I'm not sure they're very compatible with the way most games are going to be rendered, or the way the assets are going to be generated.

Either way, my point was to have the GUI work with 'images and text', and that how you actually render those things shouldn't be an issue. The idea would be that someone could switch from a raster/bitmap system to vectors at any point and the GUI library wouldn't need to change at all.