Well, it looks like I haven't posted a dev journal entry since April 15th. Sorry about that, guys! As you probably know, the next phase of the GC2 beta will focus on the user interface. That means that we have to get a lot of the screens in, which is now pretty easy thanks to DesktopX. However, the sheer number of them means that it's time consuming. Anyway, here's what I've been working on since the last time I posted a dev journal.
At first, I was waiting for the artists to get some graphics done for the screens, so I worked on fixing some bugs. I fixed one that was causing bad thumbnails to be created in the ship design screen, and made a function to allow us to update a thumbnail once a ship was upgraded. I also found and fixed a crash bug that was happening because of loading code that was not thread-safe, and another crash that happened when a wonder was completed.
I also added some functionality to the GCConfig program. I made a launch button so that you can start GC2 directly from the program, and it now will initialize with the data that you currently have set in your prefs.ini file. There's also a reset button to restore the default GC2 video settings. If you will recall from my last dev journal entry, I had started this work but was having problems with crashing. Once I got my installation of GC2 from SDC fixed, the crashing stopped, so I'm not sure if I started out with a corrupt installation, or if one of my interim changes corrupted the build and caused the rest of the problems. At any rate, it's all sorted out and working properly now.
By the time I was done with my changes to the GCConfig program, Scott (aka Boogiebac) had finished the Domestic Stats window so I started working on that. Stat windows are pretty easy to do because they don't have very complicated controls on them, but they can be tedious. I was mostly done with it when I discovered that Scott hadn't made a dxpack for the listbox entires on that screen. However, I knew what fields were going to go into those listboxes, so I wrote the code for them anyway. That's one of the great things about our interface code; you can get most of the code written without actually having the graphics, as long as you know what is going in that particular screen. It took me awhile to get stats for the different categories in, but I had coded the screen so that it will be easy to add/change what stats are displayed. We should also be able to use the same graphics and most of the same code to do the foreign stats window.
The next screen that we needed to work on was the Custom Race Screen. This is a pretty complicated screen because you have to be able to set a lot of different things, and you can't just cram it all in a 1024x768 screen. So we had to make it tabbed. We took some time to mock up the screen, including each tab and a color picker window, on the white boards in the lab. Since we'd nailed down all the details of what was going to be on the screen and how we were going to display it, Joe and I started coding the screens while the artists were still working on the graphics. Then, when we got the graphics, we just plugged them in and were able to test them to make sure that they worked the way that we wanted them to work. It was like working on about 7 different screens, including all the tabs, the color picker, and the dialog to save a custom race configuration.
I also had to add information to the civilization class and the raceconfig.xml, data that was previously either hardcoded or kept in english.str. This has the side benefit that it will be easier for you modders to create a whole game mod, like a Star Trek version. Working on the custom race screen also exposed some bugs in the EntryField class, which I fixed, and the picture listbox. I also tweaked the function that checks to see if a string is an invalid filename.
While Joe was polishing up the Custom Race screen, I started working on the Domestic Government screen, and then the Domestic Trade Window. Those were both pretty easy, but they both need some tweaking to fix some graphical errors. The Domestic Trade window also needs some more work, but I had to fix a cheat key to be able to test it efficiently.
One of the classes that we have in our code library is a key mapper, which we didn't use much in GalCiv 1 because we didn't fully understand how useful it could be Essentially, it allows you to assign an ID to a key, specifying if the control and/or shift key should be pressed, which you can then use in a function called a callback. This allows you to separate the code from the interface code, which is useful if you want the keys to do the same thing on multiple screens. I didn't know how to make it recognize that the shift key was down, so none of my cheat keys that used the shift key were working. However, the answer came to me this morning while I was brushing my hair in one of those moments of clarity that only comes when you're not thinking about anything related to your problem.
The highlight and selected states for listboxes were sometimes drawing in the wrong places, so I started looking into that today. I'm not 100% sure what was causing the bug, but I figured out enough of it to mostly fix it. Now they draw in the right places, but if you highlight or select the topmost image in the listbox I was using to test my new code, it looks like it clips it. So I'll still have to figure that out on Monday.
Oh, one more thing. I was working with a user who was having trouble running GC2 and it turns out that his problem was that he had Direct3D acceleration disabled. So I added a check when it checks the DirectX version to pop up a message and warn the user that they will probably have to turn it on in order to play Gal Civ 2.
Mormegil finished the new graphics for the Event window and the Trade screen, so I'm also going to have to work on those next week once I've got the Domestic Trade window finished.