New GUI API project in the works

Started by
16 comments, last by Haiduk67 16 years, 10 months ago
I have been browsing this site for quite some time, but never got around to actually registering an account. Welcome to my first post here. (Yeah I guess that means I'm a noob.) Over the last couple months I have been busy working on what started out as a simple GUI system to use for prototyping game ideas, but has become something a bit more. What I intended at first was a simple class to wrapper the the d3d device to cleanly handle lost/reset device states and a simple object oriented Gui framework. It has become a bit more than that. As it is now, it not only wrappers the d3d device and provides a Gui framework, it also has API functions to save/load dialogs to and from XML format. The system is event based with (or even without) callback functions. The API also includes functions to easily implement a fully functional external c/c++/c# style scripting language that can compile scripts at runtime or load pre-compiled scripts. Makes it easy to make your app fully "modable" by the end user. Although the project is a ways from completion, I finally got around to putting together a preliminary demo and thought I'd share it with you folks here for the potential input. Heres a cropped screen shot: demo screenshot I recently started putting a documentation website together for the project. You can download a demo and/or working libraries from there. D3D GUI Documentation Site [Edited by - Haiduk67 on June 5, 2007 2:26:19 AM]
Advertisement
Nice job, can't wait to see more..

Check out Super Play, the SNES inspired Game Engine: http://www.superplay.info

Just in case anyone is interested in this project, I've got a simple documentation website in the works. You can get the latest demo and the API libraries from there.
How hard do you think it would be to abstract your code from directx into a general interface and then re-derive it for both DX and OpenGL?? I'm working on a generic OpenGL/DX/Whatever rendering system in my free time... just curious is all. I might be really interested when I get something serious to show. (if of course :p)

Either way, It looks all snazzy :)
Stephen Timothy Cooney
I have started on the OpenGL version of the display classes (based around SDL/OpenGL). I don't expect to have that project done for at least another week or two after I get the documentation website more complete. The interface itself should be almost exactly the same, but using SDL for the OpenGL does mean platform independence. Essentially, you define with a single function which display system to use and the API takes care of using it.

Some of the windows specific types will be changed to include the types defined by SDL. Like Uint32 instead of DWORD and Uint8 instead of BYTE etc. Also the image files used for loading the textures are currently in DDS format. It should be a simple matter of converting them to PNG's with alpha channels and use the SDL_IMAGE libraries to load them. But most of this is for another forum.

Sorry for the somewhat long reply, but bottom line is, at this time only Direct3D is supported.
What rendering method do you use, rasterised from texture or vector drawn?

What kind of performance do you have with it?

How does it handle different resolutions?

How do we customise the look of the controls?

How do we extend the library with our own controls?

How did you get the fonts rendered?


Dave
Nice work, although it's too STL/OpenGL/Boost Libraries/Custom IO Streams unfriendly for my taste. But if I were tying myself to D3D and Windows I'd probably love it. Good luck.

I wonder why more libraries don't at least go for STL compliance. Although I'm probably alone on this desire, yet again...
Programming since 1995.
Aye, I feel the same way about STL. Internally, almost all of the functions are using STL. It's just the current interface functions that aren't. I wanted to initially provide a framework that was somewhat similar to the interface used by the Win32 API so it wasn't completely foreign.

In a later version, I will include STL versions of all of the interface functions. Like, for example, using string references instead of char pointers. Nothing is set in stone.
Quote:Original post by Dave
What rendering method do you use, rasterised from texture or vector drawn?

The controls themselves are rendered using DrawPrimitive() and Triangle lists from preloaded textures.
Quote:Original post by Dave
What kind of performance do you have with it?

It depends on whether or not the controls are using a render surface. If they don't use a surface they are rendered each frame. The most complex control so far is the multi-line text edit control (basically a full featured text editor). I get between 300-500 fps rendering this control every frame with about 50,000 text characters in it. With the render target enabled, it is pre-rendered and I get between 1500-2000 frames per second, but at the cost of another texture in video ram. So in other words, there is very little overhead.
Quote:Original post by Dave
How does it handle different resolutions?

Basically the API stores the present parameters for both the windowed and full screen modes. You can toggle between windowed/full screen with a single call. There is also a default display settings dialog that you can display for the end user to select the video mode they want to use. Also there are functions to set the present parameters for both the windowed and full screen modes. I think it's important to note that the GUI fires an event while enumerating the display modes to give the programmer a chance to check the "proposed" display mode against the capability requirements of their application. Any display modes that don't meet the requirements of the application are not available to the end user.
Quote:Original post by Dave
How do we customize the look of the controls?

Simply re-skin the texture files. I plan to make use of an XML format configuration file that describes the dimensions of the individual "tiles" within the textures, Like the height of the caption bar at the top of the window, or the width of the borders, or the size of the button, etc.
Quote:Original post by Dave
How do we extend the library with our own controls?

There is a function that creates a "user" frame control object. It simply passes the border dimensions of the control you wish to make, a handle to the control it is attached to, and how it's attached, then inserts it into the tree of objects. Within the callback function for that user control, you deal with the individual events your custom control fires. Like updating its position, size, contents, mouse clicks/unclicks, drags, keyclicks, etc. Rendering the control during its own render event. I will have some examples of creating and using user controls on my website soon.
Quote:Original post by Dave
How did you get the fonts rendered?

Basically the text functions are based around the ID3DXFont::DrawText. The GUI automatically takes care of handling the fonts during the device lost/reset states.

[Edited by - Haiduk67 on June 5, 2007 7:00:59 PM]
Quote:Original post by Haiduk67
Aye, I feel the same way about STL. Internally, almost all of the functions are using STL. It's just the current interface functions that aren't. I wanted to initially provide a framework that was somewhat similar to the interface used by the Win32 API so it wasn't completely foreign.

In a later version, I will include STL versions of all of the interface functions. Like, for example, using string references instead of char pointers. Nothing is set in stone.

I understand, although I despise the Win32 API. It is far to C like for my stomach.

Regardless, if you do get to an STL friendly version and are willing to use Boost libraries as well, then I'd be glad to offer a hand. I need a GUI too, but I need a very flexible one although it doesn't need to many fancy features (a full multiline text editor is over kill).

Let me know if you go in that direction.
Programming since 1995.

This topic is closed to new replies.

Advertisement