"Qbasic: The Magazine? I thought this was QBnews." Relaunching under the new moniker of Qbasic: The Magazine, here is issue 2 of the best Qbasic magazine in the world! You may have seen Issue 1, our mini-issue launched the last day of July. This issue is bigger, better, and only a sign of things to come. This month, Aaron Severn returns with part II of his ADVANCED article on using SVGA in Qbasic. Next issue, however, we'll have a program that does all the hard stuff for you, as well as part III of Aaron's article. SVGA, whether through custom lib's or through the next incarnation of DirectQB or Dash, are the future of Qbasic.

   As we were about to launch this Issue 2, incredibly sad news
   was picked up by Qbasic: The Magazine.  Based on a post on 
   many Qboards by LiteSabr, it was learnt that famed QB coder
   Milo, is in a coma and is expected to live only 2 days. In his
   post, LiteSabr asked that, whether you believe in God or not,
   please pray for a safe recovery of Milo.  We will try to get
   more information as it is available, and as LiteSabr said, 
   please pray for Milo's recovery.

   According to recent sources, a large number of qb coders are
   jumping from Blast! to DirectQB. Why the change to the new
   and untested DirectQB? In program EMS support! And a cool
   assembly-language keyboard handler. However, with the EMS 
   support in DirectQB and the SVGA version of Dash looming on 
   the horizon, the future of Blast! looks bleak at best.

   On 09.16.98, an attack of pornography postings on the Neozones
   webboard persisted for hours and virtually shut down the board
   from relevant posts from noon to the late afternoon (pacific
   time). The poster, who used the handle "Ananymoas", apologized
   the day after with a post saying the porn attack was done "in
   a childish rage" and was made up for by "voting for your site
   5 times in the Qbt50."  Heh.  Noone has successfully figured 
   out who the poster was (based on his IP address) but it is 
   figured that it was not one of the webboard regulars.

This section is in right now to introduce you to the more comprehensive version that will be in this very spot next month. Here we will post your rants, complaints, compliments, questions, cool little programs, etc. Also, there will be the Site of The Issue starting next issue which will provide a little writeup on some of the best Qbasic sites that noone should miss.

Look any commands that you don't know up in the QB help file. Qbasic has long been viewed as an inferior or downright bad language. One reason for this is because it can be unstructured. An unstructured program is one where you have all the programming code in one program or file. Although the program will still work, the problem is that you have to keep on using GOTO, or GOSUB commands, to skip between parts of your program. This is bad for several reasons. Firstly, it makes your programs incredibly messy. Because of this, they are very difficult to debug and check for errors. Because of this, they contain more bugs, and are therefore overall worse programs. Also, if you are using GOTO, you usually have to waste quite a bit of time and space reprogramming sections or adding code to allow jumping to different sections. Then, on the other hand, there is structured programming. This makes use of what are called SUBs.

SUB is short for SubProcedure. This is basically like a smaller program, inside your main program. What this allows you to do is make lots of small sections, and test them seperately, so you can find errors and bugs faster. Also, if you have a sub, and you want to have whatever is in the sub happen more than once, all you have to do is call the sub again, which saves space, and just makes everything easier. This tutorial is designed for both those who have never heard of SUBs before, and those who just want to increase their knowledge.

Firstly, you need to have either Qbasic 1.1 or Quickbasic 4.0/4.5 running. The main screen you see now is called the Main Module. This is where the main program will be, branching off to all the SUBs. Now go to the EDIT menu, and choose New SUB. Type a name for the SUB. Now you should see the words SUB (name you gave), and underneath, END SUB. This is just showing where the start and end of the SUB is. Now go to the VIEW menu, and choose SUBs. A window should now open. There should be a list of names in the window. Right now, your list should have only two names. The name of your program, and the name of your SUB. Click on the name of your program (which might be Untitled if you haven't given it a name). Now click on Edit in Active. You should see the main program again. Now you should know how to create and switch between SUBs and the Main Module. Another way to do this is to go to the View menu, and choose Next SUB, which will show the next SUB on the list. Now, its time to actually use these SUBs.

Go to your main module. Now type PRINT "HELLO". On the next line type the name of your SUB. Now go back to the SUB, and in between the start and end markers, type PRINT "There". Now run the program. The words "Hello There" Should appear on the screen. What you did was run the main module, then switch to the SUB and run that too. The problem is that now you can't get back to your main module. to fix this, use EXIT SUB. Go to your main module, and, underneath the place where you called your SUB, type PRINT "Everyone". Go back to your SUB, and right underneath the PRINT "There", type EXIT SUB. Now run the program. You should now see the words Hello There Everyone appear. What you have done is printed Hello, called your SUB, printed There, gone back to the main module right below where the SUB was called, and printed "Everyone". Although this is a simple example, it shows how to use SUBs in your programs. For example, if you were making an RPG, and you wanted to have monsters move around. Instead of placing this all in your main program, you can put the monster moving area in a SUB. That way, whenever monsters need to move, you can just type the name of the SUB, and it will be executed. These are the basics of using SUBs.

This section is for people more advanced than the absolute beginner. In order to use SUBs properly, you need to make sure that all your programs' variables are working properly. Normally, if you say that variable var1 = 10, then var1 will be created, and it will equal to ten. If you say DIM hello%(100), then hello will be created as an array with 100 slots. However, with SUBs, whenever you enter a SUB, variables are not carried over. Because of this, if you have a certain variable telling a command inside a SUB to do something, it will be erased as soon as the SUB is called, and your program will not work. In order to stop this happening, you can do one of two things. First, you can define what variables are to be used in what SUBs. To do this, go to your main module. At the top you should have DECLARE SUB name(). This is telling the program that this SUB exists. Now, in between the two ( ), type the name of a variable. This variable will now be carried over to the SUB, and will not be erased. The problem with this method, however, is that if you have lots of SUBs, you end up wasting time and space typing names of variables over and over again. The second way is to use DIM SHARED. Now, as you know, DIM is used to give dimensions to variables or arrays. If you type DIM SHARED, however, any variable after DIM SHARED will be carried over to all existing SUBs. So if you want to have 5 variables carried over, you type:

DIM SHARED life, mana, dex, strength, wisdom

This makes sure that these 5 variables will not be erased. This works the same for arrays. Also, you can't use DIM SHARED inside a SUB, only in the main module. This is probably because when you use DIM SHARED, you are defining the variable to be used in all SUBs, including the one it is in. Therefore, DIM SHARED would go into some kind of loop, since it would be redefining the SUB that it was in and was running. Another note is that you can use CALL in front of the SUB name, as another way to run the SUB. This is just wasted space though, since it does the same thing as just typing the sub name. Also, since SUBs are structured, you can't use any of the commands like GOTO and GOSUB in a SUB. Although you can't use DIM SHARED inside a SUB, you can use STATIC, followed by the name(s) of any variables. These variables overwrite any variables of the same name that were defined by DIM SHARED. So basically, STATIC is like DIM SHARED, except it can only be used inside a SUB, and it overwrites variables in the main code.

nethersoft@hotmail.com

www.fortunecity.com/skyscraper/terabyte/277

Don't you just hate it, you start a new programming project with high hopes and great ideas, but it seems that everything you want to have in the program, is difficult to program from scratch. You wanted SB sound, and midi and to be able to scale your images and move them around easily like you've in other programs.

But how, can you program all that stuff, and still live long enough to program the actual project you set out to do in the first place. You use a library. A library seems to have a few definitions around the Net, it could be a group of subs and functions that do certain tasks for you, like Blast!, or it could be an actual QuickLibrary like Dash, or even a external EXE you have to run with it, or alone, like SBMIDI and PLAY.

So you group these things together to make your great program, and there are a few results from this:

a) All the work collecting and merging all the stuff bogs you down and you quit.
b) You can't seem to get any of it to work together.
c) You have a really bad program, with great sound.
d) You achieve your goal.
e) Many other problems.

I personally hang between B and D, and I'll tell you why. When you use these outside programs like Blast and QMIDI and DMAplay, you start down a road of conflict, that is, between the programs. I had endless problems with Qmidi and DMAplay together. Blast! and Dash have crashed my computer on several occasions and sometimes it's enough to make you want to quit.

When you go get another program to do the work for you, you don't learn what you need to know to use it effectively. If you want to compile a bunch of demo's then fine, but if you try to make a program, and some of the third party programs conflict, you probably won't know how to fix it. I, personally, don't know what WriteDSP does, or how the StopMidi ASM works, and if I have a problem with them, then I'm up the creek without a paddle.

But of course, you can also see the other side of the coin. People who always say "Oh, I don't know what's wrong with it, I don't use those things, I just write my own." That's great for people with the knowledge and the time, but in fact, most of those people never actually finish what they start. I believe most of them write a program to allow their game to play music, and then never finish the game, so they release the music playing library for people to use, going against everything they defended. You can sometimes spot these programs, where the programmer tried to make a quick Blast!, and it runs really slow.

But the third side of the coin (?) is that they, at least, could fit it all together. They created it, so they know exactly how it will behave, and they fit it into their programs, and that's where it was ment to be.

What does this all boil down to?

Well, this is how I see it:

1) If you are wanting a sub to draw lines for you or something like that, write it yourself, you can customize it all you want.

2) If you are using utilities like Qmidi, find out how they work, as much of it as you can understand, you will have fewer problems in the future.

Some really great games have been created out of Utilities like DMAplay and Qmidi, WetSpot2 by Enhanced Creations, Space-a-Roo by SonicBlue and, hopefully once I get it finished, MazeRPG by 19day Productions.

So going back to the title of this article, The Price of Utilities, well, it's pretty much the understanding and the customization of them that you have to throw away, to an extent.

Remember, those utilities are out there for you to use, and remember to give credit to those how made them, but also remember to give credit to yourself, because without you, those utilities would just be unused, stagnant code.

members.xoom.com/19day

The web has been the greatest thing for Qbasic Programming since the very first release of QB went into development. Without the web, we would be seeing a quality level in QuickBasic games that is far, far, lower than today. In fact, I can say that, without a doubt, the number of QB programmers would be much much lower than it is today, and, in fact, QBasic would all but be dead except for a few newbies coding with draw-type or, (god forbid) ASCII graphics.

There are a few major reasons that the Web has kept Qbasic strong and will continue to keep

it strong far into the future. First, the games out there currently. As soon as a newbie coder first hears the screech of a modem and types "Qbasic" into the search engine, the quality of his games will go up. As soon as one sees efforts like Wetspot 2 or Groov Buggies, or even the now-dated Legend of Lith, they realize their draw-type Screen 12 game about a crocodile represented by 2 squares isn't the limit of their potential, they will begin searching out ways to make their game sound, look, and play as good as those currently on the Internet. Also, the newbie coder will most likely play these games and (hopefully) get a better sense of game design.

This article is very advanced. I recommend using it only if you know a LOT about Qbasic- editor. Continued from Issue 1

2.3 Setting a screen mode

-------------------------

Once you have confirmed the presence of VESA support, the next step is to set a mode. For a list of VESA defined screen modes see appendix B. The set SVGA mode function is function &H02. You will also need to run function &H01 to return info on the mode. Like function &H00 it will fill a variable with info, this time on the screen mode. The following is the type definition for the info returned by function &H01.

    TYPE ModeInfoBlock
        ModeAttributes AS INTEGER
        WinAAttributes AS STRING * 1
        WinBAttributes AS STRING * 1
        WinGranularity AS INTEGER
        WinSize AS INTEGER
        WinASegment AS INTEGER
        WinBSegment AS INTEGER
        WinFuncPtr AS LONG
        BytesPerScanLine AS INTEGER
        XResolution AS INTEGER
        YResolution AS INTEGER
        XCharSize AS STRING * 1
        YCharSize AS STRING * 1
        NumberOfPlanes AS STRING * 1
        BitsPerPixel AS STRING * 1
        NumberOfBanks AS STRING * 1
        MemoryModel AS STRING * 1
        BankSize AS STRING * 1
        NumberOfImagePages AS STRING * 1
        Rsvd AS STRING * 1
        RedMaskSize AS STRING * 1
        RedFieldPosition AS STRING * 1
        GreenMaskSize AS STRING * 1
        GreenFieldPosition AS STRING * 1
        BlueMaskSize AS STRING * 1
        BlueFieldPosition AS STRING * 1
        RsvdMaskSize AS STRING * 1
        DirectColorModeInfo AS STRING * 1
        Reserved AS STRING * 216
    END TYPE

For a complete description of what everything is for see appendix A. The important fields are as follows.

    ModeAttributes     - will let you know if the mode is available or not
    WinGranularity     - either 4 or 64, this defines the size of the banks
                          in the mode, more on this later.
    WinASegment        - the start segment of the graphics buffer, usually
                          &HA000
    XResolution        - speaks for itself
    YResolution        - what do you think?
    BitsPerPixel       - how many bits are required for one pixel, useful in
                          determining how many colours are available
                          colours = 2 ^ BitsPerPixel
    NumberOfImagePages - the number of video memory pages available in the
                          mode, this changes from computer to computer
                          depending on how much video memory is available.
                          This value is actually the number of pages minus 1.

    1. DIM a variable of type ModeInfoBlock.
    2. Set AX to &H4F01, VESA function &H01.
    3. Set CX to the mode number (listed in appendix B).
    4. Set ES to the segment address of the ModeInfoBlock variable.
    5. Set DI to the offset address of the ModeInfoBlock variable.
    6. Generate interrupt &H10, remember to use CALL INTERRUPTX for ES.
    7. Check (ModeAttributes AND 1), this should be 0.
    8. Set AX to &H4F02, VESA function &H02.
    9. Set BX to the mode number.
   10. Generate interrupt &H10.
   11. Check the value returned in AX, it should be &H4F.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

3 Basic Graphics Functions

--------------------------

3.1 Setting pixels

------------------

3.1.1 Bank switching

--------------------

Remember way back in the introduction when I explained that you only had 64k of video memory in the early days of PC graphics. Well, in some ways that hasn't changed. Now you can only have 64k of video memory at a time. Since SVGA modes often require well over a megabyte of video memory, this creates a problem. You can't possibly have access to all the video memory at once. The solution is bank switching.

The SVGA video memory is arranged in banks of either 4k or 64k (determined by the value in WinGranularity). When working with SVGA, you have to choose which bank you want to write to. The VESA supplies a nice little function that will let you do just that. It is VESA function &H05 and works as follows.

    1. Set AX to &H4F05.
    2. BX does have a purpose, but generally you don't need to use it, thus
        set BX to 0.
    3. Set DX to the bank you want to write to.
    4. Generate interrupt &H10.

There is one further detail that should be discussed about bank switching. The window granularity plays a big part in it. Some cards have 4k banks for the purpose of faster bank switching, I won't go into detail on how this can be achieved. Unfortunately, a lot of cards use 64k granularity, so if you write the software specifically for 4k granularity it won't work on many computers. Thus it's a good idea to simulate a 64k bank when you have a 4k bank. To simulate 64k banks in all granularities, divide 64 by WinGranularity and save this value for later use (winGran = 64 / WinGranularity). Then when switching banks, multiply the bank you want by the value you calculated (bank = winGran * bank) and use that value in DX. This will effectively simulate 64k banks even if 4k banks are in use.

3.1.2 256 colour modes

----------------------

Pixels in 256 colour SVGA modes are stored exactly like they are in VGA mode &H13 (SCREEN 13 in QBasic), one byte = one pixel with pixels colours defined in the same palette that mode &H13 uses. The only difference is the bank switching that must be performed as explained above. So here's what you should do.

    1. Make sure that the default segment set by DEF SEG is pointing at the
        graphics buffer (usually &HA000, the value is contained in the field
        WinASegment of the ModeInfoBlock).
    2. Calculate the offset of the pixel the same way that you would in
        SCREEN 13 (offset& = y * xRes + x).  Note that offset& will be a
        long integer, and must be treated as such.
    3. Find out what bank the pixel is on by dividing the offset by &H10000,
        effectively a bit shift of 16 to the left (bank = offset& \ &H10000).
        Note integer division is used (backslash).
    4. Compare the value found for the bank with a variable that holds the
        current bank.  If it is different then perform a bank switch the way
        described above.  Use the method that simulates 64k banks even if
        they are 4k.
    5. Change the offset so that it is within the range of an unsigned
        integer (offset& = offset& AND &HFFFF&).  Note that since QBasic uses
        signed integers, you will still need to hold the offset in a long
        integer variable.
    6. POKE the colour at the desired offset.   

Again, sample code is available in appendix D if you need help.

3.1.3 Direct colour modes

-------------------------

Direct colour modes are the SVGA modes that allow up to 16.8 million colours. This section will discuss two types of these modes, the 15-bit modes (32k colours) and the 16-bit modes (64k colours). The name direct colour was chosen for a reason. Unlike 256 colour modes which have a customizable palette that can hold 256 different colours, direct colour modes have no palette but instead accept red, green, and blue components (rgb) directly. In 15-bit modes, each component is 5 bits long, thus it can have any value from 0 to 31, with one bit left unused. 16-bit modes use the extra bit in the green component which is 6 bits long and can have any value from 0 to 63. Both of these mode types require 2 bytes of memory for each pixel, for that reason the simple offset = y * xRes + x formula won't work. Instead you need to use offset = (y * xRes * 2) + (x * 2). The multiplications by 2 adjust for the fact that each pixel fills 2 bytes. Other than that, setting pixels is the same as in 256 colour modes until it comes to writing the actual values to the video memory. You need to combine the red, green, and blue components into two bytes and POKE them both in one after the other. Here's how to combine the components.

  For 15-bit modes:
    highByte = red * 4 + green \ 8
    lowByte = (green AND 7) * 32 + blue

  For 16-bit modes:
    highByte = red * 8 + green \ 8
    lowByte = (green AND 7) * 32 + blue

That's just a series of bit shifts to put the components in their proper places. Then you just POKE them in at the calculated offset like so.

    POKE offset&, lowByte
    POKE offset& + 1, highByte

And that's how to set pixels in 15-bit and 16-bit direct colour modes.

3.2 Page flipping

-----------------

In order to achieve good smooth animation, page flipping is almost a must. Many of us, though, don't know what it is since we've grown up using QBasic's SCREEN 13 for the 256 colours, which doesn't support page flipping. The concept is pretty simple, usually screen modes don't use up the entire video memory, and often they use less than half. Rather than let the rest of the memory go to waste, it can be used a little like a second screen. You display one page while drawing graphics on the other, then you display the page you were drawing on and start drawing on the other one, and just keep on swapping pages. The result is, the user can't see you drawing the graphics so animation looks more smooth. As explained before, the number of pages available in each screen mode depends on how much video memory is available. To get the number of pages available take the value in NumberOfImagePages of the ModeInfoBlock and add 1.

3.2.1 Setting the active page

-----------------------------

This is done with a bit of a trick. There's no function that will choose which page you want to write to. You can write to any page at any time. So here's the trick, when writing to page 0, y = y, when writing to page 1, y = y + yResolution, when writing to page 2, y = y + yResolution * 2, and so on. In general, y = y + yResolution * page. This is really all you need to do.

3.2.2 Setting the visible page

------------------------------

Now this is a little more complicated. There's a VESA function that lets you choose the first vertical scan line that you want to view. In order to view page 0 this value would be 0, for page 1 it would be yResolution, for page 2 it would be yResolution * 2, and so on. Again, in general terms firstLine = page * yResolution. So here's the details.

    1. Set AX to &H4F07, VESA function &H07.
    2. Set BX and CX to 0.  These do have a purpose, but for page flipping
        they should be 0.
    3. Set DX to page * yResolution.
    4. Generate interrupt &H10.

3.3 Getting enough speed

------------------------

The pixel setting graphics functions described above will work just fine, however they will be way too slow for most practical purposes. The only solution is to write other, more useful functions in assembly language. Then you will be able to achieve enough speed. An example of a put routine for 256 colour SVGA modes is available in appendix D as an example of what must be done to make useful SVGA graphics functions. If you really know what you're doing, you should be able to write your own such functions. If not, well I guess you'll have to learn. If you've read all the way down to here you must be committed to learning this, or you should be committed. Either way, I hope this helped. Next issue, we'll provide some assembly code and...an actual program for Qbasic SVGA! Tune in!