Sign in to follow this  

New GUI API project in the works

This topic is 3835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
From a level designers perspective. Which of these processes would be more productive?

1) Load up an editor of some sorts
2) Build the level
3) design the scripts
4) save the level
5) load the game
6) load the level
7) test the level
8) find problems with the scripts
9) exit the game
10) load the editor
11) load the level
12) change the scripts
13) save the scripts
14) exit the editor
15) load the game
16) load the level
17) test the changes to the scripts
etc.

or simply
1) load the game
2) enter the "editor mode"
3) build the level using the actual game mechanics
4) find issues
3) make changes to the level while within the game
4) test the changes immediately

The full featured multi-line editor object is a method one could use to provide the ability to make changes to external scripts while within the game itself. Since this API will provide a set of functions that defines a framework to use external scripts and to compile them on the fly, the multi-line editor is essential. Compiled scripts can be attached to the events themselves and fire as the event fires in conjunction with any hard coded stuff.

So in other words the game itself could potentially provide event "hooks" that can have external scripts attached to them. All in attempts to build a system that makes "modding" your application by the end user easy to accomplish.

I agree that perhaps this concept could be construed as "fluff" but for me, it's a critical component. Basically I am developing this project for my own personal use on other projects. I post it here and make it public just to give a bit back to the community. If you can use the system, by all means, please do. If there are some changes that could be made that would make it better, by all means, suggest them.

I appreciate your feedback greatly. Thank you.

Share this post


Link to post
Share on other sites
^ I understand completely, and I wanted the same thing in my game. I don't believe that it is "fluff."

However, I realized that the task of programming is simpler when the editor and the game are separate. There are two reasons for this:
1) A heavy weight level editor does not belong in the final project
2) Editor code tends to be less secure as the purpose is to get it working fast so that the more complex engine can be developed.
3) Adding live editing support to the engine adds complexity to the engine. Although I could imagine a system that lets you reset the engine without exiting the the game, there still needs to be an interface between the engine and the editor.


I guess it is an issue of trade offs, but if I could have it your way I admit that it would greatly ease the debugging and testing process.

Share this post


Link to post
Share on other sites
I dunno. There really isn't a whole lot of difference between the multi-line editor and the single line editbox as far as code goes. As of now the implementation code for the editbox class has about 1385 lines, a good amount are comments. The multiline edit class 1961 lines, but an even larger percentage of it is commented. From the CPU's perspective, they both have about the same overhead, they're written with similar algorithms.

The main difference between the two classes is the multi-line editor uses a buffered undo/redo which can eat up some memory, but the size of the buffer can be limited by the programmer. Both simply use an STL string for the text buffer.

I agree that you might not want the level editor built into the final game, a little forward looking while developing your application could mean simply setting a #define that enables or disables it from the build or using a separate editor altogether. Either way, the same code and resources can be used both for the game as well as the editor(s). Even if they are compiled as two separate executables. I'm in no way saying you have to build your editor into your game, I'm just simply saying you can. I prefer the flexibility.

The simpler the debugging is, the faster you can eliminate bugs and the more time you can spend on development. The API includes a default console window that can also be completely disabled by the programmer. The main purpose of the console is that it receives and displays the text from a printf() type function (yes, even STL strings work too, with .c_str). It provides a method of instant feedback to aid the debugging process. Also it includes an editbox where you can test the functions you set up to be used by external scripts.

Share this post


Link to post
Share on other sites
What they say about "proper documentation" is apparently true. Documentation for a project can take as long, or longer, as writing the actual code for the project itself.

For anyone who has been following this project, I just wanted to let you know that I have been making decent progress on the documentation website. I've got more than half of the functions documented as well some other good information like the coordinate systems used by the GUI and a decent walk through of the features demonstrated by the demo.

(well theres that as well as the shameless "bump")

Share this post


Link to post
Share on other sites
Looks very cool indeed. I must say I'm very happy to see someone put time and effort into making a documentation for a GUI editor. I've seen quite a few good GUI editors with some very ordinary documentation that completely put me off them. Hope you remain motivated and dedicated enough to see this through.

Oh, and you need to give this project a proper name. D3D GUI gives the wrong impression (like perhaps MS is offering it!) as well as being a bit boring. ;)

Keep up the good work!

EDIT:

I find it a bit annoying when I have to register on some site in order to download something. I've now registered on dozens of site because they asked me to and I hardly visit them! If it was some forum or community centric thing I can understand the registration process but why is it required to download something?

Ok, rant over!

Share this post


Link to post
Share on other sites
Hey righton. Some feedback :)

Quote:
Original post by Specchum
... Oh, and you need to give this project a proper name. D3D GUI gives the wrong impression (like perhaps MS is offering it!) as well as being a bit boring. ;)

Somehow I find it mildly amusing that while drinking my morning coffee and looking at my "todo" list I was thinking exactly the same thing.

One of the Ideas I had was simply "Haiduk's GUI" and I even briefly considered "GUI Duk" but only briefly. ROFL.

Quote:
Original post by Specchum
I find it a bit annoying when I have to register on some site in order to download something. I've now registered on dozens of site because they asked me to and I hardly visit them! If it was some forum or community centric thing I can understand the registration process but why is it required to download something?

Ok, rant over!

The main reason it is there now is because that site is still using one of those "free" web hosts that has a pretty hefty bandwidth restrictions. I suppose I could lift the registration download restriction in your honor. Especially if you can help me come up with a decent name. LOL

Edit: It has been done. Guests can now download the demo and library files without being forced to register on the site.

[Edited by - Haiduk67 on June 11, 2007 11:09:42 AM]

Share this post


Link to post
Share on other sites
Cheers to that haiduk! I, however, get linker errors with d3dgui_d.lib. It apparently can't find references to d3dutil or dxutil. Not surprising given that I don't have any such files in my DX April 2005 SDK installation. Is this something I need to download seperately from or is there a workaround this problem?

As for a decent name for a GUI, I wish I could help but unfortunately I have enough trouble coming up with decent names for my own projects. ;) However, with the dark theme of your demo in mind, how about Carbon? Not very original admittedly. :)

Nothing wrong with Haiduk GUI either, mind you! Probably better in fact.

Share this post


Link to post
Share on other sites
Are there linking errors with both libraries or just the debug version?

I am using the April 2005 SDK too, d3dutil and dxutil should both be within the d3dgui_d.lib library itself.

I uploaded the source for d3dutil and dxutil. Try adding the two cpp files to the project.

I wasn't able to reproduce the errors on a test machine with a fresh install of VS2005 and the April DX SDK.

Are you using the d3dgui.lib for the retail build and d3dgui_d.lib for the debug build?

Is anyone else having linking issues?

[Edited by - Haiduk67 on June 12, 2007 5:32:54 PM]

Share this post


Link to post
Share on other sites

This topic is 3835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this