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.

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.

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")

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]

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]