Milestone 1

[RonHiler]

I'm close to done with the only really new code in Milestone 1, which is the AVI player. That's steps 9 and 10 (out of a total of 17), and I've already finished 1-8 and 13-14. The ones I haven't yet done (11-12 and 15-17) are just rehashes of already existing classes from Sov and Enzyme, so they will be quick.

I haven't actually yet gotten the AVI to play on the screen. I consider this a very minor setback :D I'm really pretty close though, the hard junk is over, which is reading and interpreting the dang file in the first place. I should now have the first frame sitting on a texture all ready to go to the display. Then it's just a matter of working on the frame timing (to make it play and synch with the sound stream).

At the end of M1, the program will have played all the AVI files, loaded any game files needed (which will be very little but will increase with subsequent milestones) and take you to the selection screen. The only active option from this screen will be to exit, so it won't be real interesting, heh. I'm going to need a background graphic. I never was real happy with the one we had (which I put together). I'll have to figure out something for it.

[RonHiler]

Well, it took a lot more effort than I would have thought, but the movie portion of the AVI player is now working, which is a giant step forward for Milestone 1.

Let me tell you guys, I HATE working with the GDI in general and bitmap files in particular. They are aggravating in the extreme. The functions that open and initialize the AVI files are pretty straightforward. Once you calculate the frame you need and pull it out of the file, it dumps it as a BITMAP field in a memory buffer. You then have to figure out a way to get that bitmap onto a D3D surface. This is where the trouble begins. If the functions you needed to call made any logical sense, this would be possible. However they are completely random and mysterious. In order to do this, you have to:

1) AVITexture->Graphic->GetSurfaceLevel(0, &Surface);
That gets the surface of the texture. It's a D3D call, so it makes perfect sense to me.
2) Surface->GetDC(&SurfaceDC);
That gets something called a Device Context for the D3D surface. No one is really sure what a DC is for, but apparently it is required for access to the GDI functions on a D3D surface.
3) BitmapDC = CreateCompatibleDC(SurfaceDC);
This is the bitmap. Or actually, where the bitmap will go. Or, actually, the DC for where the bitmap will go. Again, no one knows what a DC is, but now we have one, and apparently it is compatable with our D3D DC.
4) HandleBitmap = CreateDIBSection(BitmapDC, lpbi, DIB_RGB_COLORS, (LPVOID*)&BitmapColorInfo, NULL, 0);
NOW we have a place to put our bitmap. There is nothing there yet, mind you, but we have a place for it.
5) memcpy(BitmapColorInfo, ImageData, lpbi->bmiHeader.biSizeImage);
And this copies the data that was dumped to the buffer from the AVI file over to a brand new buffer that we just created. What's the difference? Why could we not simply have used the original buffer in the first place?The new buffer has our D3D compatable DC (which again, no one really knows what that is), and we also have a handle to this buffer which we didn't have before. Why do we need a handle? Who knows! I certainly don't. But goddammit, we have one! (to paraphrase my favorite comedian Lewis Black)
6) OldObject = SelectObject(BitmapDC, HandleBitmap);
It's not enough that we have a mysterious handle and DC to our recently moved buffer, now we need to select it. Select it for what? The bowling team? Beats the hell out of me.
7) BitBlt(SurfaceDC, 0, 0, lpbi->bmiHeader.biWidth, lpbi->bmiHeader.biHeight, BitmapDC, 0, 0, SRCCOPY);
This is the part that does the actual copying from our recently moved buffer onto our D3D surface. The reason I used this function is because the bitmap and the D3D surface may not be compatable in terms of how they hold the color data. BitBlt does those conversions for us, which is a big relief (because, for one thing, I don't even know what the format of the D3D surface is, it depends on the particular video card in the user's machine. For another, the bitmap format is also variable, depending on how the AVI is set up, so writing a lot of conversion routines would be a nightmare).

Then there is a lot of cleanup crap that no one cares about involving deselecting the object we just got finished selecting and releasing all those DCs and surfaces and stuff.

And after all that, the texture is FINALLY ready to be displayed.

I didn't mean to turn this into a rant. I just really HATE bitmaps and dealing with the GDI in any form. Anyway, it's pretty cool to see the movie play when you run the program. Now I just have to get the sound working. The logo avi doesn't have sound, so I picked up a short avi that does just for testing purposes so I can at least get the sound ready for when the logo movie actually does have a sound track (or any of the other movies we might add later on).

[Pix]

Well, it took a lot more effort than I would have thought, but the movie portion of the AVI player is now working, which is a giant step forward for Milestone 1.

Let me tell you guys, I HATE working with the GDI in general and bitmap files in particular. They are aggravating in the extreme. The functions that open and initialize the AVI files are pretty straightforward. Once you calculate the frame you need and pull it out of the file, it dumps it as a BITMAP field in a memory buffer. You then have to figure out a way to get that bitmap onto a D3D surface. This is where the trouble begins. If the functions you needed to call made any logical sense, this would be possible. However they are completely random and mysterious. In order to do this, you have to:

1) AVITexture->Graphic->GetSurfaceLevel(0, &Surface);
That gets the surface of the texture. It's a D3D call, so it makes perfect sense to me.
2) Surface->GetDC(&SurfaceDC);
That gets something called a Device Context for the D3D surface. No one is really sure what a DC is for, but apparently it is required for access to the GDI functions on a D3D surface.
3) BitmapDC = CreateCompatibleDC(SurfaceDC);
This is the bitmap. Or actually, where the bitmap will go. Or, actually, the DC for where the bitmap will go. Again, no one knows what a DC is, but now we have one, and apparently it is compatable with our D3D DC.
4) HandleBitmap = CreateDIBSection(BitmapDC, lpbi, DIB_RGB_COLORS, (LPVOID*)&BitmapColorInfo, NULL, 0);
NOW we have a place to put our bitmap. There is nothing there yet, mind you, but we have a place for it.
5) memcpy(BitmapColorInfo, ImageData, lpbi->bmiHeader.biSizeImage);
And this copies the data that was dumped to the buffer from the AVI file over to a brand new buffer that we just created. What's the difference? Why could we not simply have used the original buffer in the first place?The new buffer has our D3D compatable DC (which again, no one really knows what that is), and we also have a handle to this buffer which we didn't have before. Why do we need a handle? Who knows! I certainly don't. But goddammit, we have one! (to paraphrase my favorite comedian Lewis Black)
6) OldObject = SelectObject(BitmapDC, HandleBitmap);
It's not enough that we have a mysterious handle and DC to our recently moved buffer, now we need to select it. Select it for what? The bowling team? Beats the hell out of me.
7) BitBlt(SurfaceDC, 0, 0, lpbi->bmiHeader.biWidth, lpbi->bmiHeader.biHeight, BitmapDC, 0, 0, SRCCOPY);
This is the part that does the actual copying from our recently moved buffer onto our D3D surface. The reason I used this function is because the bitmap and the D3D surface may not be compatable in terms of how they hold the color data. BitBlt does those conversions for us, which is a big relief (because, for one thing, I don't even know what the format of the D3D surface is, it depends on the particular video card in the user's machine. For another, the bitmap format is also variable, depending on how the AVI is set up, so writing a lot of conversion routines would be a nightmare).

Then there is a lot of cleanup crap that no one cares about involving deselecting the object we just got finished selecting and releasing all those DCs and surfaces and stuff.

And after all that, the texture is FINALLY ready to be displayed.

I didn't mean to turn this into a rant. I just really HATE bitmaps and dealing with the GDI in any form. Anyway, it's pretty cool to see the movie play when you run the program. Now I just have to get the sound working. The logo avi doesn't have sound, so I picked up a short avi that does just for testing purposes so I can at least get the sound ready for when the logo movie actually does have a sound track (or any of the other movies we might add later on).

Lol--you're dealing with plain old GDI stuff, of course you deal with DCs. What do you mean nobody knows what they are? They're the thing you get from Windows to use pens, brushes, bitmaps, fonts, etc. It's weird, but it goes right back to at least Windows 3 (that I'm aware of.) You want a less weird method of drawing, use Java or .Net. :)

[RonHiler]

Lol--you're dealing with plain old GDI stuff, of course you deal with DCs. What do you mean nobody knows what they are? They're the thing you get from Windows to use pens, brushes, bitmaps, fonts, etc. It's weird, but it goes right back to at least Windows 3 (that I'm aware of.) You want a less weird method of drawing, use Java or .Net. :)

Nah, I use D3D. Much more logical :)

The only reason I used the GDI here was because I had no choice. The AVI functions give you a Bitmap in memory, which means using GDI.

[Shane Christopher]

I would have imagined that the D3D DirectX API would have a relatively simple method of dealing with AVI and other movie files. I tried to get into Direct3D programming a while back. Couldn't get the compiler to work so gave up. Lol I'm crap at actually starting something but when I do I'll give it a fair go at learning it. Like Java.. once I got into it nothing was gonna stop me from making the program do exactly what I wanted. And it did. Simple :)

Kinda want to get into Direct3d and C++ again but I need a free (or potentially free) compiler and something to write it in. For Java I use JCreator Pro which does everything nicely.

[RonHiler]

I would have imagined that the D3D DirectX API would have a relatively simple method of dealing with AVI and other movie files.

Yes and no. They have a module called DirectShow to deal with media. But it is no longer supported since nobody was using it. I looked at using it, but it comes with it's own set of issues.


Kinda want to get into Direct3d and C++ again but I need a free (or potentially free) compiler and something to write it in. For Java I use JCreator Pro which does everything nicely.

There is a freeware one out there, but the name escapes me at the moment (gcc?). Maybe Pix or Strike knows the one I mean. I think Borland even has a free version of a compiler as well.

Any compiler you use that is not MSVC is going to have setup issues, since DX was meant to be run using MS products. Borland needs its own set of dlls and lib files to make it work. It's kind of a pain, but once you get it working it's not such a big deal. I'm willing to bet pretty much any compiler will have a set of DX libraries at this point.

[Strike]

I know of djgpp, and also things like cygwin, for Windows platforms...

I've not had much luck setting a C++ compiler on my machine, but then I've not had much motivation to do so, either.

Finding something that works for you shouldn't be /too/ hard, though getting it to run may be painful -- that's my short answer ;)

[Pix]

For Windows programming, get Visual Studio Express. DJGPP is really only good for command-line programs. It happens to be a port of GCC, and more or less the same restrictions apply. Oh, theoretically I think you could do it with stuff like MINGW, but why go thru the effort when Visual C++ Express is free?

http://msdn2.microsoft.com/en-us/express/aa975050.aspx

You want Visual C++ express, SP1, the Vista update if you use Vista, and then go to http://msdn2.microsoft.com/en-us/express/aa700755.aspx to get instructions on getting the Windows SDK and how to modify the compiler settings so you can produce non-.Net programs and use the SDK headers/libraries. It's not hard to set up. (Also, if you don't feel the need for a GUI, the Visual C++ 2003 Toolkit, which consists of only the command-line version of the compiler and the standard C++ libraries (you'd again need the Windows SDK to write Windows programs), MS removed it from their site a while back but it's still available on the web...or if you can handle a 30MB or so download, I could email it to you.

[Strike]

Hm, if the GUI-less C++ will work on a Win98 machine (like the C# does) then I need to snag a copy.

Still, I don't have any immediate use for it (or for making Windows programs) so I'm not gonna ask for a 30-MB email :)

[Shane Christopher]

Thanks for that Pix. I did download the entire DirectX SDK a while ago and I think I tried out MSVSE at the time with it and ran into some problems. I didn't have the motivation to fix them at the time though. I'll give it another bash now.

[Pix]

Hm, if the GUI-less C++ will work on a Win98 machine (like the C# does) then I need to snag a copy.


I don't know if VS2005 will install on Win98. You really need to upgrade your OS. :P VS2003, I'm pretty sure, will. You'll have to hunt for it, or ask for that 30MB email, tho. :)

[Pix]

Thanks for that Pix. I did download the entire DirectX SDK a while ago and I think I tried out MSVSE at the time with it and ran into some problems. I didn't have the motivation to fix them at the time though. I'll give it another bash now.

Well, if you have issues, post here or email me; I'll try to help. FWIW, I found the instructions provided by MS pretty easy to follow.

[RonHiler]

After quite a bit of work, I have to admit defeat. I'm going to have to rip out my AVI class and retool it.

Which really sucks, because it ALMOST works. Video plays great. The sound is there. The issue is the frigging sound format. It turns out that sound in an AVI file can be in any one of about three dozen or so formats. DirectSound, on the other hand, only likes one particular format. So if I try to play the sound, you can hear it, but it's all distorted (which is kind of funny to hear, actually).

So I tried to convert it. MS has a set of functions to do this (called acmStreamXXX) which is supposed to do just that. Perfect, I thought. I'll just read the AVI file format and the actual sound, run it through the converter to change the buffer into something DSound can deal with, and we're all set!

Unfortunately, after all that, I get back an error 255, which is the code for "conversion not possible". There's just nothing I can do with that. There is no way to debug that, the driver is just refusing to do it at all.

So, despite being within a hair's breadth away from being done, I'll have to switch over to using DirectShow instead, which is a whole different system. I used DShow to play the music in Sov, and I don't remember it being too difficult to set up. I'm just not really sure how it interacts with D3D and DSound to give a synched video/sound result. Guess I'll find out :)

[Pix]

After quite a bit of work, I have to admit defeat. I'm going to have to rip out my AVI class and retool it.

Which really sucks, because it ALMOST works. Video plays great. The sound is there. The issue is the frigging sound format. It turns out that sound in an AVI file can be in any one of about three dozen or so formats. DirectSound, on the other hand, only likes one particular format. So if I try to play the sound, you can hear it, but it's all distorted (which is kind of funny to hear, actually).

So I tried to convert it. MS has a set of functions to do this (called acmStreamXXX) which is supposed to do just that. Perfect, I thought. I'll just read the AVI file format and the actual sound, run it through the converter to change the buffer into something DSound can deal with, and we're all set!

Unfortunately, after all that, I get back an error 255, which is the code for "conversion not possible". There's just nothing I can do with that. There is no way to debug that, the driver is just refusing to do it at all.

So, despite being within a hair's breadth away from being done, I'll have to switch over to using DirectShow instead, which is a whole different system. I used DShow to play the music in Sov, and I don't remember it being too difficult to set up. I'm just not really sure how it interacts with D3D and DSound to give a synched video/sound result. Guess I'll find out :)

Have you considered using a 3rd-party converter tool to pre-convert existing files into D3D's preferred format, instead of consuming CPU doing it at runtime? :)

Just because I've got a dual-core computer now doesn't mean I want to waste cycles doing unnecessary audio conversions :)

[RonHiler]

Have you considered using a 3rd-party converter tool to pre-convert existing files into D3D's preferred format, instead of consuming CPU doing it at runtime? :)

Just because I've got a dual-core computer now doesn't mean I want to waste cycles doing unnecessary audio conversions :)

Yeah, it's not a bad idea. I'll look into it. I'm still going with DShow though, even if we were to convert the sounds in the AVI files into something DSound can deal with directly. It has much better synching capabilities than I can easily provide. I have it already working (with sound and everything!). The only small hitch is that in windowed mode I get some flickering (in fullscreen mode it works fine), so I'm going to have to use an offscreen surface, but other than that it works great.

On a bad note, DShow has the WORST docs I have ever had to read through. Really just awful. Good thing I'm not doing anything more complicated than playing a simple file.

[RonHiler]

So, news. It's been a bit of time since I've said anything about MD, and I'm sure some of you are wondering just what the heck is going on. Well, not to worry, I have actually been working on MD every day.

I expected to be done with Milestone 1 about 3 weeks ago. Unfortunately, I got stuck on that darned AVI player.

It's been quite frustrating actually. I'm using DirectShow. DShow is quite powerful, and in actual fact, it is REALLY easy to get an AVI to play with synched sound and everything. Which just makes it all the more frustrating when you can't quite get it to do what you want, heh. I've had the movie playing CLOSE to what I need several times now, but always there is some hitch. Fullscreen would work perfectly, but windowed play would flicker. Or windowed would work perfectly but there would be no option for fullscreen in that mode, and so on.

It turns out I can draw the movie frames using Direct3D (which is what I did originally when I was rolling my own solution before going to DShow). To do this, you use a particular type of filter called the VMR-9. Sound is handled by an entirely different filter, the VMR9 is strictly in charge of video. Now in it's default state, the VMR won't do fullscreen, and also you have to update the window through the WM_PAINT message. Since MD is strictly a D3D app, it doesn't use th WM_PAINT message much, so there were some problems.

However, it also turns out that two parts of the VMR9 filter can be replaced with custom parts. One of them (the mixer) we don't care about, it's not applicable to cutscene style movies. But the other, called the Allocator/Presenter is in charge of allocating D3D surfaces for the movie frames and presenting them onto the screen.

What's great about this is I can override the default a/p and use my own (which essentially just dumps the current movie frame onto a D3D surface), which will go through the D3D engine we already have. We just copy the surface over to a texture and draw it onto a quad on the screen. This works for both windowed mode and fullscreen, because all of that is handled by the engine already.

So anyway, I've written the custom a/p now (which required writing a COM interface) and I think things are about done (what's left is just a bunch of DShow API calls to let the VMR9 renderer know about the custom a/p). Barring any issues, I should finally be able to put this part to rest in the next couple of days and finish up the remaining miscellaneous parts of Milestone 1.

I'll be putting up version 2 of the design document (which I'm basically done with) around the same time I finish M1 and/or start M2. I'll also be releasing the M1 version of MD to whomever wants to test it out. The M1 version won't be terribly exciting, but hey it's a start right? :)

[RonHiler]

Just to let you guys know, the custom a/p did the trick. The movies work perfectly in both windowed mode and fullscreen. So I'm going to work on finishing up M1, which should be fairly quick now.

[Pix]

Just to let you guys know, the custom a/p did the trick. The movies work perfectly in both windowed mode and fullscreen. So I'm going to work on finishing up M1, which should be fairly quick now.

Now you gotta mess around and see if you can put movies on arbitrary surfaces. "I was just walking along, with a movie playing on a window and another on the side of a dumpster."

[RonHiler]

Actually, at this point, that's a peice of cake. Once the movie frames hit the texture surface via the custom a/p, they become no different than any other D3D texture. I can put them anywhere. It just so happens I'm putting them on a quad that covers the entire window (or screen in fullscreen mode), but I could just as easily put them on the side of a mesh. Heck, I could even run them through a pixel shader and get some post-processing effects, heh.

It might be cool, just for the heck of it, to put the AVI movie on the globe mesh once it's back in, just to see what it looks like :)

You could actually do some pretty cool things with this sort of technology. For instance, it would be pretty simple to put a TV in a 3D game world (not MD, but any sort of FPS game), and have it playing. You could even let the player change the channels (you just need one movie track per channel to feed frames to the texture).

It was a pain to code, but I'm definitely going to be keeping this class around for future use.

[Pix]

You could actually do some pretty cool things with this sort of technology. For instance, it would be pretty simple to put a TV in a 3D game world (not MD, but any sort of FPS game), and have it playing. You could even let the player change the channels (you just need one movie track per channel to feed frames to the texture).

Hah, you're like 15 years out of date on that. Syndicate (or maybe Syndicate Wars) had TV playing in-game. Ok, it wasn't 3D in the modern sense, it was actually faked with static top-down isometrics...but there was, in fact, a scene from Ghost in the Shell playing on a billboard. :)

[RonHiler]

Yes, I know it's been done. It's probably even been done this exact same way (using a custom a/p with DirectShow to drop frames onto a texture). I wouldn't be surprised if Bioshock uses it to do their monitor screens in game. But I've never had this tech before. It's a fun new toy to play with :)

[RonHiler]

Well, basically I'm done with Milestone 1 and in my opinion, it looks pretty sharp. There's just one little wrinkle. I thought of a feature it might be nice to add to the selection screen, nothing major, mind you, just a small touch. I figured it would take me an hour or two to put in. Well, as it turns out, there was a complication, and it's not so easy to add.

This is a thing I will have to tackle at some point, but it isn't really necessary for M1. Then again, if I do it now, it's one less thing to do later on. I'm still undecided on whether or not I'll get it in now or later. I guess it really depends on how long it will take. Mod 5 just came out for DDO, and I do need to work on the character planner a little bit to get it up to date, but I don't want to do that before I release the M1 version of MD.

Guess we'll see how it goes...

[Strike]

I recommend getting Milestone 1 finished and out the door, if you're taking votes ;)

IMO, Feature creep + "complications" + other projects == Later.

But I guess we'll just see how long it takes....

[RonHiler]

I recommend getting Milestone 1 finished and out the door, if you're taking votes ;)

IMO, Feature creep + "complications" + other projects == Later.

But I guess we'll just see how long it takes....

Aye. I'm going to go ahead and start the classes needed (in fact, I already have). But if it starts to get out of control in terms of amount of time being taken up, I'll let it go and deal with it in Milestone 2. So far, anyway, it's going pretty smoothy. But again, we'll just see how it goes.

I want to stress this is NOT a feature creep type of thing. This absolutely positively MUST be in the game at some point (it's a sound thing related to wave files, and I don't want to get into a technical discussion about it). It's only a question of whether to do it now or to do it later, it's not an addition :)

I intend to stick to our design doc pretty religiously in order to avoid the whole feature creep thing. While admittedly, parts of the DD are incomplete, it has a full description of all the major interface screens and a full milestone list overview, so that should keep things on track even as the rest of it gets filled out.

[Pix]

If it wasn't scheduled for M1, adding it now, when M1 is otherwise basically done, it's feature creep, of a sort. Add a new milestone, M1.1, consisting solely of this feature, call M1 done, and then add new code.

[RonHiler]

Pfff, that's just nonsense, Pix.

For one thing, this is an unexpected complication. So even if the DD went into that sort of detail on what specific classes would be added when (which it most certainly, and deliberately, does not), these set of classes would be nowhere to be found in ANY of the milestones by virtue of the fact that it is an *unexpected* requirement. It's exactly in these sort of occurances that low level DDs break down. It would have to be added somewhere. Unexpected complications happen, there's no getting around them no matter how carefully you plan. This is why the MD DD is a "high level" DD. It's keeps things on track without shackling us.

For another, these new classes can easily be catagorized under Milestone 1 by virtue of the milestone summary for M1, which goes:

"Basic Windows Initialization, DirectX Initialization (D3D, DInput), AVI player, R&J Cyberware Logo Avi File, Display Logo screens, Show Load Screen, Show Selection Screen, Fonts, Pushbuttons"

(highlight added). The addition that you are speaking of as "feature creep" is trivial. It's to make the buttons make a noise when the cursor moves over them or they are pressed. And yes, that wasn't necessarily in my head when I wrote the M1 list. But again, the list is not there to shackle us, it's to keep things on track. This is an entirely minor addition (literally maybe a dozen lines of code in total) which I feel will add significantly to the pushbutton class. I'm going to just go ahead and reserve the right to make these sort of additions even when they are not in the milestone list if A) they are minor and can be easily done and B) they add a significant improvement.

Now, in the version of the DD that you guys have (version 1.0), sound is not mentioned at all in the detailed M1 list. That was an oversight on my part, and I added it as one of the first things I changed in the second version (and I felt that was okay because it's still consistant with the milestone summary[1]). It was always my intention to have sound working in M1 (if for no other reason than for the AVI files).

Further to that, I had already programmed a DirectSound class before even tackling the AVI player stuff, although it wasn't being used (and still isn't, since DirectShow uses its own internal coding to run the sound through DirectSound).

So I have plenty of evidence on my side that sound was always meant to be in M1. At this point it's optional because the original purpose was to have sound for the movies. But to be sure we'll also need sound in game for other things.

The unexpected complication is for that to work I need to load and play a wave file. It turns out loading a wave file into a directsound buffer is entirely non-trivial, and apparently I've never before done that before (contrary to what I'd thought).

That's why I say eventually we are going to HAVE to have that functionality, to load up wave files into DSound buffers. Either now or later, doesn't really matter. I kind of prefer now, since A) technically I meant to have sound completely working by the end of M1, B) it's one less "base class functionality" sort of thing I'll have to do later on and C) it fits even less well with future milestone summaries than it does with M1. But as I said, if it gets too messy, I'll drop it until later.

Don't get me wrong, I appreciate you trying to keep me to the DD. If you ever think I'm going too far off of it, please do call me on it. But I honestly don't think this is one of those times.

[1] BTW, the milestone summaries are, at this point, pretty much locked. They are central (IMO) along with the interface descriptions to the purpose of the DD, which is to keep progress moving forward without feature creep. While I may change the detailed milestone lists from time to time (like I did with adding direct sound to M1 from DD1.0 to DD2.0), I should NEVER add or delete anything from those lists that is inconsistant with the corresponding milestone summary. If I do, I would (again) encourage you guys to call me on it.

[RonHiler]

Alright guys, the sound classes are essentially done. Works and everything, which is a big relief given the nasty code needed to load Wave files :) We have our first in-game sounds, which are clicky type sounds on the buttons.

I'm going to add a few minor utility functions to the classes that I think would be useful to have around, and clean up some of the graphics on the load screen. I may be able to finish up today and put out a release, but more likely it'll be some time tomorrow.