Despite what many programmers will tell you, Visual Basic is an excellent programming language for high-end graphic applications - with or without DirectX and OpenGL. Many VB programmers seem to believe that the only way to get fast 2D graphics is with DirectDraw…and they are completely wrong! Using some creativity and efficient coding, you can get the API to do anything that DirectDraw does - and nearly as fast (and in some cases faster!). But this is not to say that only the DirectX-paranoid can benefit from this tutorial, because even the best DX experts could use a good explanation of how Windows handles graphics routines. This series of articles will explain not only how to do fast graphics but how fast graphics work. You have already learned about pure VB routines for graphics processing; that was followed by the basic API routines of GetPixel and SetPixel/V; now comes the more advanced GetBitmapBits and SetBitmapBits and their twice-removed cousins called DIB sections; the last tutorial will cover optimizing your graphics functions for additional speed, shall you need it. By the end of this series of tutorials you will be able to effectively write any graphics application you can dream up using nothing but Visual Basic and the Windows API.

So if you're ready, here's part three of how to become a professional graphics programmer using good ol' VB.

This tutorial will go through two advanced ways of getting and setting pixels in Visual Basic: the API routines of GetBitmapBits/SetBitmapBits and GetDIBits/StretchDIBits. I recommend reading the previous two tutorials, "Visual Basic Pixel Routines" and "Basic API Pixel Routines," as they provide the foundation for the advanced graphics principles discussed in this tutorial.

But on the happy side of things, these are about as fast as graphics get in VB. There are ways to use CopyMemory, assembly language, and other freakish routines to get slightly faster effects, but they are even more perilous than these methods so avoid them if you can.

Onto the graphics!

At this point in your VB career you are probably used to interacting with images one pixel at a time using something like PSet/Point or GetPixel/SetPixel. This makes for some pretty easy programming, but it's very, very slow. The main reason for this is that every time VB calls an API routine the code from that API routine is dynamically stripped out of the DLL file and placed streamline into the in-memory lines of your programming (hence the name "dynamically linked library"). Considering all the work involved in doing this VB actually moves pretty quickly, but there are better ways of doing things.

Enter GetBitmapBits and SetBitmapBits. Instead of getting each pixel individually, we pass each function an array and let it fill the whole thing at once with the picture's pixel data or set the picture's pixel data all at once with the information in the array. Much more efficient, eh? The trade-off, of course, is that this involves a little more programming and significantly more risk. If the array dimensions are off by a mere 1 byte all kinds of things can happen - the picture won't appear at all, your program will shut itself down, or your entire machine could freeze up. But these only happen if you're careless and don't heed my warnings, however, so don't get too scared. :)

The first step is to declare a whole bunch of things:

This might seem a little extreme, so let me go through each of these one at a time.

The 'Bitmap' type is required for the 'GetObject' call - if you'll look at GetObject's declaration, you'll notice that the last parameter is of type 'Any.' This is where we pass in our 'Bitmap' object. As for the individual elements of the 'Bitmap' type, we only care about four out of the seven variables. They are:

SIDE NOTE ABOUT 'GETOBJECT': You may be wondering why we use the GetObject call at all - couldn't we just resize the ImageData array using the picture box's ScaleWidth and ScaleHeight properties? In theory, you could. However, VB does strange things to the ScaleWidth and ScaleHeight properties depending on what is stored there. For example, the same image might report different ScaleWidth and ScaleHeight properties at different execution times. JPEGs are notoriously bad at this - when you load one, VB sometimes thinks that the picture's width is one pixel less than it is in memory. I honestly have no idea as to why VB has this problem. And the strangest thing is that it pops out of nowhere - just one of those strange Microsoft anomalies, I guess. GetObject never suffers from such a problem so you should always use it. The speed difference is trivial in any case.

SIDE NOTE ABOUT DECLARING YOUR ARRAY: You can use any number of dimensions in your array, so long as its total size is accurate. For example, you could also do something like ReDim ImageData(0 to bm.bmWidth * bm.bmHeight * 3) and the function would still work fine. The API call could care less about how the array is declared - all it gets is the address of the first element in the array and the number of bytes that it's allowed to work with. The way the array is dimensioned is only for your convenience. I like the above way because it makes editing the image very easy. This issue will be discussed further in tutorial 4.

WARNING!! This ReDim statement is where you can really screw your computer. If ImageData is too small, GetBitmapBits will attempt to put the picture data in unallocated memory, causing a general protection fault, a page fault, or some other nasty illegal operation. Make sure that ImageData is the right size!! If you use the above method you should never have any problems…but if you do, it's in no way my fault.

The GetBitmapBits call itself is very straightforward: it takes the address of ImageData() and fills it up with the pixel data located in PictureBox. Pretty easy, isn't it? Now you can edit the values any way that you want to. For example, the following loop would invert all of the pixels in the image:

(Really, this method is almost as easy as GetPixel if you can get used to the API structure…) SetBitmapBits is almost identical:

Everything is the same as GetBitmapBits, except that we aren't resizing the array (because it's already the right size and resizing it would erase all of its information). The last if/then statement is included because SetBitmapBits won't automatically initialize the AutoRedraw event, so we have to tell it to replace the 'Picture' property (what is shown on the screen) with the 'Image' property (what is stored in memory).

So of course, someone is going to ask "but how can I do fast graphics in 16 or 8 bit color mode?" That is what DIB sections are for, so if you want to know about them then keep reading.

(Personally, I would recommend using DIB sections for all of your graphics programs because you'll never get unexpected errors with them and it’s a great way to add additional functionality to your graphics program. I have only discussed BitmapBits because they make for an excellent introduction to DIB sections.)

DIB section stands for 'Device Independent Bitmap.' The name is pretty self-explanatory: DIBs are simply a way of interacting with bitmaps in any color mode or on any computer and getting consistent results. There are actually two varieties of DIBs - OS/2 encoded and Windows encoded, so I'm not entirely sure of why they're called "device independent'... but that's okay. :)

DIBs share many characteristics with BitmapBits. The calls share certain parameters and the underlying logic is very much the same. However, DIB sections suffer from three unfortunate problems: they're slightly more confusing to use, they require more code, and they return the image data rotated 180 degrees (of course, they also rotate the data 180 degrees when you set it so this usually isn't a problem). The trade-off, of course, is that DIB sections work in any color mode and the StretchDIBits call is much more powerful than SetBitmapBits. Below are the required DIB section declarations:

Quite the mess of declarations, isn't it? You should notice some similarities between these declarations and the BitmapBits ones - that makes our job somewhat easier. Here's the quick explanation of all that stuff:

TOTALLY USELESS SIDE NOTE ON ALPHA CHANNELS: This is just a thought to add to the "useless but cool" programming section of your brain: both DIBs and regular bitmaps can contain transparency information. If you have an expensive monitor and video card and run them at 32-bit color mode, that extra byte contains (mostly useless) transparency data. So technically, 32-bit bitmaps and DIBs could be used like GIFs - displayed transparently and all. There's actually an API call with Win2K/ME/XP called "AlphaBlend" that's similar to BitBlt/StretchBlt except that it utilizes an alpha channel (this method is very similar to DirectX and a transparent key color); you can read all about the "AlphaBlend" call at the MSDN site.

That's a freaking lot of explanation. I need a break, and you should take one too! [Tanner goes outside and plays football for several hours]

 Okay - now that your brain has had some time to digest all of that, let's move onto using the GetDIBits call. Here's a full-blown example of how to get an image's data using the GetDIBits call, minus the declarations above:

Okay, kids, we're almost done with DIB sections - all that's left is StretchDIBits.

The procedure required to set up our variables for StretchDIBits is almost identical to the procedure we used for GetDIBits. In fact, everything up to the actual GetDIBits call is the same - everything except the ReDim ImageData() line, of course (if we ReDimmed the array before setting the data we would erase all of the pixel data!). Here's a full example:

And there you have it - a complete explanation of how to get image data from any picture in any color mode and how to set that same data back into a picture once you're done editing it.

Well students, we've taken quite a journey through ways of getting and setting pixels in Visual Basic. We began with the appalling PSet and Point - the slowest possible way to do graphics. From there we were introduced to the wonders of the Windows API and we used GetPixel and SetPixel/V to speed up our graphics routines a great deal. In this last tutorial we delved into the magic of BitmapBits and DIB sections, and now your graphics programs should be faster than you ever imagined possible in VB! While this tutorial provides a lot of information, to really become knowledgeable about graphics programming you're going to have to do some work on your own.

One of the best ways to learn about graphics programming is just to download other people's programs off of the net and figure them out one line at a time. That's how I learned to program, and it's taught me a great deal about the many different ways that there are to do things within Visual Basic. All of my knowledge about DIB sections comes from reading articles on the internet and experimenting with the API - and I know there are people out there a lot smarter than me! If you're willing to do a little bit of studying, the sky's the limit!