SkyLock tech demo (GUI - DX combo box)

I decided to take some time and restructure/rethink my scroller/plotter (I love hex, but man it can be pain! :D ). With that in mind I started working on my games GUI features which I had pretty much designed and while I'm coding them, go back to the notepad/pen to rework my hex specific code.

Anyhow, I started working on my combo box class and command button class this morning. There's still some work to be done but they are pretty much fully functional now. The thing I'm most proud of is that the combo box list can dynamically grow/shrink.
To test this alter the "test.txt" file that's included. The first line is the number of items to populate the list. The following lines are the data for the specific rows of the combo box.
ie: Right now the list has 4 rows of data. To add a new row just change the 4 at the top of the file to a 5 and add another line of data.

It all uses DirectX 7. Input through DirectInput7 and drawing through DirectDraw7.

This is some of the code that I'm thinking about sharing as open source (probably in a tutorial on my site) so let me know if anyone is interested. If enough people are interested then I'll try to get the tutorial written this week and have the full source posted with it.

Controls: uses the system mouse.
*Click on the "exit" button to quit.
*Click on the drop down arrow on the combo box to open the list of items. Then click on an item in the list to set combo box'es value to that item's name.

Jason

That's pretty good. The mouse pointer is very creative. But of course I'm going to offer a couple of suggestions:

The mouse pointer shouldn't move quite as fast. Maybe just a tad bit slower.

And when you point your mouse over a selection it would be cool if that selection were highlighted.

Although, I'm sure that this is only a test version of it.:)

Man, Tech! I thought I was my harshest critic! This is after only a few hours of work, cut me some slack... :D

j/k, I appreciate the suggestions.

As far as the mouse movement speed, right now it's set to 2x, because that's what I prefer, but in the game you will be able to adjust mouse speed in the options menu from 1x (normal) to 3x (fastest).

And I'm going to implement object highlighting when the mouse is over them. It's just a matter of adding another version of the bitmap extended to it and swapping when the mouse is over the object (with a PtInRect test). That's one of the features I plan to work on today.

that looks really nice i could never dream of making this kind of stuff lol.
just a bit of advice,
- it would be nice if you could press on the name of the item and the scroll down appears instead of having to press the arrow (i think in windows it is like that)
- also a border would around the scroll down box would look good

great job i still can't wait till you finish at least part of your game so i can play it :D

Quote:

---

Originally posted by red_baron
- it would be nice if you could press on the name of the item and the scroll down appears instead of having to press the arrow (i think in windows it is like that)
- also a border would around the scroll down box would look good

---

1-I already fixed that part. You can check out an updated example at http://www.geocities.com/jd_eadg/code.html

2-Thanks for the idea. I'll implement that later this week. I just need to add 2 more bitmaps to represent the top/bottom of the list and a check so that it puts the top border on the topmost item, the bottom border on the bottommost item and a reguler (side-only) border on all the ones in between.

Thanks for the suggestion!

As far as a playable demo:

The parts of the GUI that I'm working on now are mostly for the development tools (map editor, soldier editor, etc.) and they shouldn't take too much more work to be usable.

I just fixed my scrolling code tonight! :D Man that was a major hurdle!

Every object now has a OnScreen bool variable. At the beginning of a call to that object's Blt member function it checks to see if it's RECT intersects with the viewable screen RECT. If it doesn't then OnScreen is set to false and no blitting is done. If it does then OnScreen is set to true and my custom clipping code gets the viewable area and resets it's source RECT accordingly, blits it to the screen and resets OnScreen to false.

That eliminates any unneccessary blitting and helps keep the fps up (sorry 'bout that, Tech! 3 fps, OUCH!).

Anyhoo, the headache with the scrolling/wasted blits was my biggest hurdle yet. Now that it's been conquered I'm going to start working on my map editor. Once the map editor is done the first playable demo will be ready. I'm hoping for September 1st or so. Which will put me in a pretty good spot (8 months into a 2 year project, so I'll have plenty of time to polish it up and work on content).