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 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.