| Q. | Why are you bothering with DOS based graphics programming when there's Windows 95 / 98 / NT and DirectX? |
| A. | Many reasons, but mainly because my system itself is old (purchased in 1994). Running DirectX games on it was mediocre at best. Also I believe that one should be able to walk before they run. Today it seems that we have a whole legion of computer users and even computer specialists that know little to almost nothing about how computers really work. Using Windows without knowing DOS is, in my opinion, a sure fire way to set yourself up to be taken for a ride. That is, by people who ask for $50 to $100 an hour doing simple things, like renaming files and updating boot files. Honestly, does anybody these days know anything at all about DOS? NOPE!!!! |
| Q. | The code you display here looks very familiar. You've read "Teach Yourself Game Programming in 21 Days" by Andre LaMothe, am I right? |
| A. | Yes, I don't try to hide that. In fact, I've read 3 books on game programming: PC Game Programming Explorer by Dave Roberts, Action Arcade Adventure Set by Diana Gruber, and Teach Yourself Game Programming in 21 Days by Andre LaMothe. Of these three books, the last one I've mentioned was the most helpful in understanding the VGA graphics interface. Dave Roberts book was okay, but it was very cryptic, for lack of a better word, when it came to its explanation. The code was not explained very well, nor we're too many of its concepts. But its hardware explanation, especially the one pertaining to the mouse, was very excellent. The book written by Diana Gruber was hardly useful at all. It insisted on teaching you their game editor and their graphics functions and provided NO clue as to how the concepts and the system you were working on works overall. They would say a few things pertaining to the hardware and game programming concepts, then immediately tell you only how to use their programming package to make it work for you. Obviously their ultimate goal was to get you hooked into using their programming libraries and their game editors in order for you to ultimately buy their souped up version of their FastGraph editor for a hefty cost. Not too hefty if you're planning to make a lot of money on video games. Last time I checked, the library is largely defunct (much like this one!). |
| Q. | I just don't understand the whole concept of inline coding. What exactly am I doing here? |
| A. |
Okay, the way we do it in C programming is by using the #define
directive. This directive, like all other preprocessor directives, work
while the program is being compiled and is not present in executable object code.
The reason why we call them macros is because they're not actually functions,
that is they do not expect arguments of a specific type (int, float, etc.) nor are
they expected to return any type of data. They are just simply replaced
with whatever code you associate with them. Take the macro SetPixel
for example, you declare it like so:
#define SetPixel(X, Y, C) videoMem[Y * 320 + X] = C
Whenever the compiler encounters your use of the macro while compiling your source code like so:
void WhitePixel(void)
{
SetPixel(10, 20, 15);
}
It replaces the associated code instead, matching the parameters with the values you provided like so:
void WhitePixel(void)
{
videoMem[20 * 320 + 10] = 15;
}
Before compiling it to object code. As you can see, the values given to the macro replace the parameters in the substituted code. Functions declared with the use of the C++ |
| Q. | I am really having a difficult time understanding libraries and how to make use of them. Can you kind of elaborate on this some more? |
| A. | Libraries are simply a collection of code that programs can use by linking together with them. At its simplest form, a library can be a set of source code files that a compiler can merge together with the primary source code file containing your program. Generally, though, a library is one or more files with the LIB extension that contains one or more compiled source files (OBJ files) that are linked together. Functions contained in library files are already compiled and only need to be linked into your programs to create an executable. However, the compiler must have information about these functions that your program uses in order to compile your program properly. This is where header files (or include files) come in by providing prototype information for these functions. |
| Q. | Does QBasic support libraries? |
| A. | Not really, at least not in the same way that C does. Now, the QuickBASIC compiler does support libraries and include files as well as modular coding. We will discuss this shortly. QBasic users, however, have to cut and paste source code into their programs from other sources to promote code re-use. QuickBASIC, however, does but it's something I never mastered. In the development environment, you use a Quick Library (QLB) file but compile with a Library (LIB) file. |
| Q. | What's the difference between a library file and a dynamic link library (DLL) file? |
| A. | The main difference is the simple fact that library (LIB) files are linked with your program during compiling and linking of your program. That is, code contained within libraries become a part of the executable program itself. Code contained withing a DLL file does not become a part of your executable program, your program instead loads this code into memory as it is needed. Hence why they're called dynamic link libraries. |
| Q. | Can I create DLL files? What tools do I need to create them? |
| A. | Windows based compilers can easily create DLL's. For you BASIC coders, PowerBASIC DLL creater and Visual Basic 4.0 and higher can also create DLL's. DLL files, just like conventional libraries, are primarily a collection of compiled functions written in C and C++ and you must include header files for prototyping these functions. (A little documentation would be nice as well.) DLL's created by Visual Basic 4.0 and up use OLE technology and only work in compilers compatible with OLE. DLL's created by other tools can be used by any compiler that can use DLL's, including versions of Visual Basic earlier than 4.0. |