Jeff Molofee - NeHe's OpenGL Tutorials

AVISTREAMINFO psi; // Pointer To A Structure Containing Stream Info

PAVISTREAM pavi; // Handle To An Open Stream

PGETFRAME pgf; // Pointer To A GetFrame Object

BITMAPINFOHEADER bmih; // Header Information For DrawDibDraw Decoding

long lastframe; // Last Frame Of The Stream

int width; // Video Width

int height; // Video Height

char *pdata; // Pointer To Texture Data

int mpf; // Will Hold Rough Milliseconds Per Frame

In this tutorial we will create 2 different quadratic shapes (a sphere and a cylinder) using the GLU library. quadratic is a pointer to our quadric object.

hdd is a handle to a DrawDib device context. hdc is handle to a device context.

hBitmap is a handle to a device dependant bitmap (used in the bitmap conversion process later).

data is a pointer that will eventually point to our converted bitmap image data. Will make sense later in the code. Keep reading :)

GLUquadricObj *quadratic; // Storage For Our Quadratic Objects

HDRAWDIB hdd; // Handle For Our Dib

HBITMAP hBitmap; // Handle To A Device Dependant Bitmap

HDC hdc = CreateCompatibleDC(0); // Creates A Compatible Device Context

unsigned char* data = 0; // Pointer To Our Resized Image

Now for some assembly language. For those of you that have never used assembly before, don't be intimidated. It might look cryptic, but it's actually pretty simple!

While writing this tutorial I discovered something very odd. The first video I actually got working with this code was playing fine but the colors were messed up. Everything that was supposed to be red was blue and everything that was supposed to be blue was red. I went absolutely NUTS! I was convinced that I made a mistake somewhere in the code. After looking at all the code, I was unable to find the bug! So I started reading through the MSDN again. Why would the red and blue bytes be swapped!?! It says right in the MSDN that 24 bit bitmaps are RGB!!! After some more reading I discovered the problem. In WINDOWS (figures), RGB data is actually store backwards (BGR). In OpenGL, RGB is exactly that… RGB!

After a few complaints from fans of Microsoft :) I decided to add a quick note! I am not trashing Microsoft because their RGB data is stored backwards. I just find it very frustrating that it's called RGB when it's actually BGR in the file!

Blue Adds: It's more to do with "little endian" and "big endian". Intel and Intel compatibles use little endian where the least significant byte (LSB) is stored first. OpenGL came from Silicon Graphics machines, which are probably big endian, and thus the OpenGL standard required the bitmap format to be in big endian format. I think this is how it works.

Wonderful! So here I am with a player, that looks like absolute crap! My first solution was to swap the bytes manually with a for next loop. It worked, but it was very slow. Completely fed up, I modified the texture generation code to use GL_BGR_EXT instead of GL_RGB. A huge speed increase, and the colors looked great! So my problem was solved… or so I thought! It turns out, some OpenGL drivers have problems with GL_BGR_EXT…. Back to the drawing board :(

After talking with my good friend Maxwell Sayles, he recommended that I swap the bytes using asm code. A minute later, he had icq'd me the code below! It may not be optimized, but it's fast and it does the job!

Each frame of animation is stored in a buffer. The image will always be 256 pixels wide, 256 pixels tall and 1 byte per color (3 bytes per pixel). The the code below will go through the buffer and swap the Red and Blue bytes. Red is stored at ebx+0 and blue is stored at ebx+2. We move through the buffer 3 bytes at a time (because one pixel is made up of 3 bytes). We loop through the data until all of the byte have been swapped.

A few of you were unhappy with the use of ASM code, so I figured I would explain why it's used in this tutorial. Originally I had planned to use GL_BGR_EXT as I stated, it works. But not on all cards! I then decided to use the swap method from the last tut (very tidy XOR swap code). The swap code works on all machines, but it's not extremely fast. In the last tut, yeah, it works GREAT. In this tutorial we are dealing with REAL-TIME video. You want the fastest swap you can get. Weighing the options, ASM in my opinion is the best choice! If you have a better way to do the job, please … USE IT! I'm not telling you how you HAVE to do things. I'm showing you how I did it. I also explain in detail what the code does. That way if you want to replace the code with something better, you know exactly what this code is doing, making it easier to find an alternate solution if you want to write your own code!

void flipIt(void* buffer) // Flips The Red And Blue Bytes (256x256) {

void* b = buffer; // Pointer To The Buffer

__asm // Assembler Code To Follow

{

mov ecx, 256*256 // Set Up A Counter (Dimensions Of Memory Block)

mov ebx, b // Points ebx To Our Data (b)

label: // Label Used For Looping

mov al,[ebx+0] // Loads Value At ebx Into al

mov ah,[ebx+2] // Loads Value At ebx+2 Into ah

mov [ebx+2],al // Stores Value In al At ebx+2

mov [ebx+0],ah // Stores Value In ah At ebx

add ebx,3 // Moves Through The Data By 3 Bytes

dec ecx // Decreases Our Loop Counter

jnz label // If Not Zero Jump Back To Label

}

}

The code below opens the AVI file in read mode. szFile is the name of the file we want to open. title[100] will be used to modify the title of the window (to show information about the AVI file).

The first thing we need to do is call AVIFileInit(). This initializes the AVI file library (gets things ready for us).

There are many ways to open an AVI file. I decided to use AVIStreamOpenFromFile(…). This opens a single stream from an AVI file (AVI files can contain multiple streams).

The parameters are as follows: pavi is a pointer to a buffer that receives the new stream handle. szFile is of course, the name of the file we wish to open (complete with path). The third parameter is the type of stream we wish to open. In this project, we are only interested in the VIDEO stream (streamtypeVIDEO). The fourth parameter is 0. This means we want the first occurance of streamtypeVIDEO (there can be multiple video streams in a single AVI file… we want the first stream). OF_READ means that we want to open the file for reading ONLY. The last parameter is a pointer to a class identifier of the handler you want to use. To be honest, I have no idea what it does. I let windows select it for me by passing NULL as the last parameter!

If there are any errors while opening the file, a message box pops up letting you know that the stream could not be opened. I don't pass a PASS or FAIL back to the calling section of code, so if this fails, the program will try to keep running. Adding some type of error checking shouldn't take alot of effort, I was too lazy :)

void OpenAVI(LPCSTR szFile) // Opens An AVI File (szFile)

{

TCHAR title[100]; // Will Hold The Modified Window Title

AVIFileInit(); // Opens The AVIFile Library

// Opens The AVI Stream

if (AVIStreamOpenFromFile(&pavi, szFile, streamtypeVIDEO, 0, OF_READ, NULL) !=0) {

// An Error Occurred Opening The Stream

MessageBox (HWND_DESKTOP, "Failed To Open The AVI Stream", "Error", MB_OK | MB_ICONEXCLAMATION);