Well, I'm still working on the sheet editor (actually, I'm working on learning C# and building an app that will be similar to the sheet editor.)
Anyway, we're probably going to have to move some sprites around at some point, right? So, the frames are stored in a listview, I figured it would let me drag one here or drag one there, but no. So, I set out to do it manually, get some code off of code project, and hack it all together and then I find out that it doesn't work with LargeIcons (actually, I couldn't get it to work in any mode.) So I started over. And again. Now, here I am, with working code that sorts the damn thing, but its hacked.
What it does is, when I add a frame, it puts a number in front of the frames filename(the current list size; in the format #) - framefilename.png). Then, when I move an item, I have to remove that number, and put the new index number on it. I thought that would be the end of it, but I didn't think about the rest of items. They're all off now, so I have to go through the list (from insertion point to end), removing the number and adding the correct number.
So, yea, I'm pretty sure Raymond isn't going to be down with that, so I'm off to find another way. Any of you C# gurus know how to do this?
DragonFire Games Updates
I wanted to program each module so that it could be used separately, but it would not only make coding it harder, it would also slow it down exponentially. If everything works together, then I know what classes are being used, how the data is being used, etc (so I know how to exploit the system.) But if I allow the user to supply his own Renderer class, he may not keep track of the texture that are set in the stages, or he may not track renderstate changes. My system does and knowing that, I can exploit it.
I worked on the GUI module's design document earlier while Raymond was busy. I decided that instead of having messages, my system is going to be similiar to C# forms (having an OnXXX function that the user can override.) I like this approach much better, but I'm not quite sure if it'll have speed/memory issues. So far the list of events that a widget can handle are:
o OnCreateo OnDestroyo OnResizeo OnMoveo OnRendero OnKeyDowno OnKeyUpo OnKeyPresso OnMouseMoveo OnLeftClicko OnLeftReleaseo OnMiddleClicko OnMiddleReleaseo OnRightClicko OnRightReleaseo OnMouseWheelI'm sure a few more will come to mind.
Each widget will be split into 9 sections
-----------------|0|| 1 ||2|-----------------| || || ||3|| 4 ||5|| || || |-----------------[6|| 7 ||8|-----------------The four corners(0, 2, 6, 8) will be identical in size.
The width of the left and right (3, 5) will be identical.
The height of the top and bottom (1, 7) will be identical.
The width of the center (4) will be identical to the top/bottom.
The height of the center (4) will be indentical to the left/right.
Widget list so far (* denotes maybe, ^ denotes extras (meaning done after everything else))
- dftGui Widget List
- Label
- Button
- Check Box
- Radio Button
- Text Box (single or multiline)
- Image
- Group Box
- List Box (regular or drop down)
- List View
- Array
- Tabs
- Timer
- Scrollbar (vertical or horizontal)
- Slider
- Counter
- Progress Bar
- Dialog
- File dialog (load/save files)
- Color dialog
- Tool tip
- Console
- Menu context(text, *special, and *radial), ^window menu
- ^Status bar
- ^CD player dialog
- ^Toolbar
Some notes:
The array is just like a listview widget, except that it has arrows (no scrollbar) and scrolls by item or page. Unlike the listview (which can hold only an image and optional text), the array holds an image, optional text, and a void* pointer for user data.
Special context menus are menus that are brought up by a right click. They have an image background and buttons (buttons only.)
Status bars are going to be similar to Windows status bar, only in the fact that they can store a string (and only a string.) They're going to be more like labels, but they can be docked or undocked (at creation time.)
Every widget can have a tooltip.
The counter is the little box with a number in it that has an up/down arrow which, when pushed, increases/decreases the value.
Label is just a static text object (I like label better than static or static text.)
To add images to the game's screen (health bar, etc) an empty dialog will have to be created.
The timer widget will display a text timer on screen at the specified location.
The progress bar might be renamed to something lame like amount bar, since it will be used as health bars and such (status bar would probably be the best, but thats taken >_<.)
Scrollbars will just be a class containing a modified counter and a modified slide
Each widget will contain a vector pointer (this is its "bound" vector) and an offset vector. This will allow the user to bind text to the top of a characters head and such.
Each widget will have a timed display ability. This will allow the user to display said text above a characters head for say 4 seconds.
I'm thinking of adding an instant messenger widget, but I'm not sure how to do that (it would have to allow you to IM anybody in at least Yahoo, MSN, and AIM. If anybody knows anything about this, please say so because I'd really like to add this.
The console will take the longest because I want to set it up so that the user can specify global variables and then be able to modify them in game (not quite sure how to do this at the moment.)
The console will be scrollable and will retain a number of strings (the user sets the number.)
Most text input widgets will support the scripting that is inside of the font engine (smiley codes, ^#,^^, \n, \t, \b.) Although, each widget handles the input(OnColorScript, OnNewLine(), OnTab(), and OnBackSpace().)
In the above, ^# is used for coloring the text and ^^ is used to turn something into all caps. The second may be removed, because I can just see people (read: assholes) abusing it.
Since I plan on using this in a online games, I am adding support for smilies. Don't worry though, this will either be in a separate class, or in between #define/#endif.
Variable width fonts will be used, even though they add extra overhead. I will provide a function so that the user can get the width of a string.
If you see an item that you think is stupid/dislike/etc don't worry about it :P There are only a few widgets that REQUIRE another. Scrollbars (counter and slider), Counter (text box and 2 buttons), etc.)
ListView will support sorting (default or custom) and dragging items to sort them(who'd ever need that feature though? [wink].) Note however, that if sorting is one, dragging the item won't work (since the listview will just resort it.)
I have a few things that I'm not going to add, just so I have something to suprise people with.
Using the CD player dialog will allow you can control 4 volumes - game music volume, sound effect volumes, voices volumes, and cd music volumes. It will have playlists (normal play and random play) and allow for searching.
I plan to stick to this list as much as possible, but some things will probably have to be removed/simplified. I am planning on this taking at least the same amount of time that EDI Project2 does, if not more. Actually, I'm positive it will take more time, since I have to design and code the entire graphics module first.
Enough about the GUI though, since I won't get to actually code it for quite some time [sad]. Anybody have any questions, comments, or suggestions?
You'll notice that I didn't make very many of the items extras. That would be because I have a planned use for the ones that aren't marked as maybes/extras.
Before anybody says anything, I know that a 90% of the people that actually use the module, probably won't use most of these widgets. But, I have free time, I enjoy GUI development, and it won't slow your app down by being part of the module, so why the hell do you care? Plus, better to have the tool available than not.
Until the graphics module is done, all of my updates will be on that and EDI stuff.
Wow, A nice 120 some line update, almost 1500 words. Hope you had fun reading it [grin].
