OpenGL fun

I finished the (short) chapter on pixmaps and bitmaps (OpenGL ones; not to be confused with regular bitmaps... which are pixmaps). Basically, a pixmap is a picture, as we know it: you have the colors stored somewhere else, pixel by pixel, be it in color-index mode (just indices from a palette) or in true color mode (with the color components). The bitmap is _literally_ a bitmap: just a bunch of 0s and 1s, unlike the usual concept, which in OpenGL's terminology would be a pixmap.

There was a bit of a mess with this chapter as the book relies on DirectX and not SDL, and thus, some things don't work as is. Image loading is an example. I refrained from using those quick-and-dirty loading functions the book offered. Besides, it was just BMPs and TGAs, formats I'm not too fond of (I prefer PNG for non-lossy and JPG for lossy pictures).

Bitmaps just specify what pixels are colored with the current color and which aren't. Pretty boring, and I don't see much the use of them. Though working with pixmaps is interesting. Combined with the SDL_image library, you can load just out of the box GIF, JPG, PNG, TGA, BMP and XPM formats. Being careful with the format, you can work directly with the pixel data. But there's a few slight catches:

- Before drawing, you have to set the raster position to where you want your picture. This is modified by the modelview and projection matrices, so either use an orthogonal projection matrix (that way you can use direct on-screen coordinates) or just be careful with your perspective projection matrix.

Good thing about being modified by the modelview matrix: you can do stuff like rotating the starting point of the picture (I can already imagine this being used in Secret of Mana-ish circular menus). No, you can't rotate pictures straight away, but you can zoom/flip them.

Oh yes, and what's more important: with orthogonal matrices, (0,0) is the lower-left corner of the screen. With perspective matrices, (0,0) is the _center_ of the screen.

- Another note: the x86 architecture (which is what Intel, AMD and probably Cyrix use in their chips) is little-endian. What does this mean? Well, it means that, actually, colors aren't stored in the typical Red-Green-Blue-Alpha fashion, but in the Blue-Green-Red-Alpha one. It's exactly the other way around. If you had a Mac, it might be different. Or a machine with a Motorola chip, which are known for being big-endian. AFAIK, RISC chips are as well. Just about everybody except the x86 architecture xDD. Correct me if I'm wrong.

- SDL_DisplayFormat: you have to be careful with the conversion and give the right options to OpenGL. Of course, I've only done a small demo and it'd be overkill, but, you know...

- Pixels are stored in reverse order in SDL's native SDL_Surface structure. Thus, you have to flip the image horizontally and vertically. This is easy thanks to the glPixelZoom function.

When all is conveniently prepared (an orthogonal projection, and the image loaded with IMG_Load) it all boils down to:

glPixelZoom(-1.0f,-1.0f);
glDrawPixels(img2->w,img2->h,GL_BGRA,GL_UNSIGNED_BYTE,img2->pixels);

Oh yes: keep in mind SDL_DisplayFormatAlpha is to be used instead of the normal SDL_DisplayFormat if your picture has an alpha channel (like GIFs or PNGs do). Though PNGs offer pixel-by-pixel alpha values and GIFs just use a transparent color. SDL is bad with pixel-by-pixel alpha right now, though. People usually have to write a replacement and do some hacking around.

Mata jikai! (See you next time!)
~Antonio