Horizons Interactive Entertainment

proudly presents

Issue 2 - April 2000


Editor: Matthew R.Knight

QBCM is available at the following websites:



Much thanks to the owners of the above sites for hosting QBCM. If you are hosting QBCM on your site, and it is not listed above then please contact me so that it can be added.

We need QBCM to be available on as many Qbasic related websites as possible. That way ALL Qbasic coders can benefit from it. If you have a website dedicated to Qbasic then please become a host of QBCM too!

All you have to do to become a host is email me telling me the URL of your site, and then I'll send you the new issues every month, and your site will be listed on the QBCM host list!




1. Foreword
2. Your letters
3. Ask QB Cult Magazine
4. News
5. Writing user friendly programs
6. QB Library debate
7. Game tutorial series #1
8. #QBChat survival guide
9. Data encryption
10. Writing your own GET & PUT routines
11. Introduction to Qbasic series #2
12. Interview with Dunric
13. Interview with DarkDread
14. QB tips, hacks and tricks
15. Qbasic museum
16. Reviews
17. Competitions
18. Last words




Welcome to the April, 2000 issue of QB Cult Magazine!!!

If you saw our last issue you may be surprised to see that this mag is in HTML. Well, a lot of people emailed me saying that text format just didn't look good enough - so I descided to learn some HTML, and so QBCM in HTML was born! Much thanks goes to Magnet and Terry Cavanagh for teaching me the basics behind HTML which gave me a good start in the learning process. Thanks again guys ^_^

There is a lot of interesting stuff for ya this issue - and a lot of changes from our first issue too. The TUTORIALS section is now open to any articles, not just tutorials. I think this is better as it will allow a greater variety of information to be presented here. The gfx-demo-of-the-month competition is now gone, but there is a new competition now in Qbasic-website-of-the-month. There is also quite a big change in the mini-game-of-the-month competition in that entries may now be up to 40kb in size ZIPed - this should allow entrants to make games of a much higher quality. One last change, the CLASSIC QBASIC COLLECTION is now known as the QBASIC MUSEUM. I think that title is more fitting.

I would like to thank all the many people who have given me their comments, suggestions, and input to QBCM. Keep it comin! ^_^

A lot of people have asked me when the next issue of QBCM will be coming. I thought his was pretty clear, but let me just clarify this - QBCM is a monthly magazine. New issues are released on the 1st of each month.

Another thing a lot of people emailed me about - in the last issue I mentioned that I can only check me email once every two weeks. Well, that has changed. I am now able to check my email every three days! ^_^

QBCM is YOUR magazine and it needs YOUR input. Please submit all articles, news, tips, and letters to horizonsqb@hotmail.com

Well, I hope you enjoy this issue.

Happy programming in QuickBASIC (is there any other kind?)


Your letters


This is cool (QB Cult), a monthly magazine for QB. But I have a suggestion. A GUI magazine, with iexplore look, images, and links in the magazine would be really cool. YPI already has something like that. Maybe you should look into this. I could help if you want.


Thank you. I'm glad you liked last issue! In addition to that, thanks for your suggestions and offer of helping me, but as you can see I have already converted the magazine to HTML on my own. Hope ya like the new look! ^_^


The first issue of QB Cult was really kewl. The article on modems in QB was really good. Maybe you could do an article on hacking and stuff with QB programs? That would kick aas! Also, it would be nice if the 'zine was made in HTML like Qbasic: The Magazine. That would rule. :-)

-Antonio Coppola

Thanks for the comments. As far as the hacking tutorial is concerned, NOT A CHANCE!!! I am allergic to prison! ^_^


Well, let me just say right at the beginning that I am a BASIC lover. I started coding in BASIC on a Commodore VIC 20 (R.I.P Sob Sob) went up to GWBASIC, and now I'm coding in PB. How's that for faithfulness! I have spent many sleepless nights coding in BASIC, and let me just say that there is no competition. No other language can boast both the power and ease of use that we find in recent variants of BASIC. I have coded in many other languages, including C++, Fortran, Prolog, and Pascal, and yet I still keep coding in BASIC. That tells you something.

It is pleasing for me to see coders such as yourself devoting your time to create quality texts about BASIC like QB Cult. I hope to see QB Cult continue for many years to come.

-Gary Whitta

Thank you...I am always delighted when I hear of other programmers who feel the same way about BASIC as I do. I too keep coming back to Qbasic despite having programmed in other languages...actually, I tend to use a combination of Qbasic and ASM together which I personally feel is the ultimate DOS programming solution.

As for your Commodore VIC 20...I actually still have mine...as well as a number of other old 80's relics such as the Sinclair ZX Spectrum, Apple II, Commodore 64, etc. Collecting these old machines is a hobby of mine...a very weird hobby...but a hobby none the less. My other hobbies include spending many hours of my time creating Qbasic software and publications for which I am paid nothing at all! ^_^


Hail! I checked out QB Cult Magazine, and it does look promising. Keep up the good work.


Why thank ya...it's always nice to get feedback from QB programmers about your work...especially from those who make such cool games! ^_^


Yeah, I like your mag, I quite enjoy reading things like that now and again. How frequent will it be issued?

Anyway, the reason I'm writing is I have a site that I recently, heavily updated. It's only a few days old, and there aren't many items available yet. But we have a game that we wrote last year sometime and it hasn't been reviewed. It's called 'Void' and it's available at http://bounce.to/ribbonsoft

You can get it on the downloads page. Also, I am willing to submit articles/tutorials etc. Please let me know if you're short of anything!

Btw, how can you bear only being able to check your email every 2 weeks??!

-Alan O'Hagen

Much thanks for the comments. QBCM is issued monthly - new issues are made available on the 1st of each month. You wouldn't believe how many people have emailed me asking that exact question!

I'd be happy to review Void for you...Check out the review in the REVIEWS section of this issue!

As for your offer of writing tutorials for QBCM...P L E A S E!!! Any articles/tutorials you can write will be greatly appreciated. ^_^

Hmmmmm...yes, I was only able to check my email once every two weeks until recently. Now I am able to check my email every three days which is, needless to say, much much better!


Ask QB Cult Magazine


Don't you just hate it when you are really stuck on something in Qbasic and no matter how hard you try you just can't figure it out? Doesn't it drive you completely nuts? Yep, I thought so, so that's why I included this section in the mag for ya! If you get stuck on anything in Qbasic, just send an email to me at horizonsqb@hotmail.com and you'll get a reply within 3 days. In addition to that, your problem will be printed here in QBCM, along with my reply, so it can help other coders too! ^_^

We only have three questions this month...I guess y'all must be real QB gurus or something since you don't need any help! Ah well...


A lot of games I have downloaded come up with an error saying "sub program not defined" on a CALL ABSOLUTE statement. Can you please tell me what's wrong and if I can fix it? K?

-Pieter Van Schaik

That's a very common question. Obviously you are using QuickBASIC 4.5...the problem with this version of QB is that it doesn't automatically load in the CALL ABSOLUTE routine...actually, there are some others that it doesn't automatically load in either including ABSOLUTEX, INTERRUPT, etc. It is necessary that these routines be loaded into QB when you start it up in order for those games you downloaded to work...all you have to do is the following:

Usually you type this to start up Qbasic:


You must instead type:


That's it! Problem solved!


I have been stuck on something for a while and nobody has been able to help me. What I need to know is how to convert an integer, or any number, to a string. P-L-E-A-S-E help me!!!!!!!!!!


Okay Cody, I'll help you since you asked so nicely...however, I think the reason that nobody has helped you thus far is that your problem is so simple...if you had read the Qbasic help files you would know the answer to this already...most QB coders out there hate it when people run to a discussion board every 5 minutes or send out multiple emails without even bothering to try and find out the solution to their problem themselves...and I don't blame them. It's nothing personal - it's just that few people really want to be busied with your code when they have their own.

However, you did ask me nicely, and since I do enjoy helping people, I'll gladly help you out. There are two very useful Qbasic functions which perform conversions between strings and numbers - they are STR$ and VAL.

STR$ returns a string representation of a number. Here's some code...

n% = 28
a$ = STR$(n%)

VAL converts a string representation of a number to a number. Here's some more code...

a$ = "28"
n% = VAL(a$)

Well there ya go Cody! Problem solved! ^_^


I want to program a menu into my game. How can I do this, or is there a library out there which I can use?

-Neil Kahan

Tim Gerchmez produced a library several years ago, MenuSys, for QB 4.5 which allows you to produce a menu in the language. Having said that however, you could easily code something yourself. It's a simple program to write (unless you're a beginner.)

I have written a simple menu program for you to serve as an example. It's included with this issue of the mag. It's called MENU.BAS. Hope that helps! ^_^




Magnet Entertainment is recoding the game engine behind Dark Aura, a promising console style RPG, to work with DirectQB. Visit their website at http://www.geocities.com/magnetent

Virtuasoft is working on Dash 2. As the author says, "All the rules of QB libraries will change with this release. There will no longer be any memory limitations with QB because XMS will be seemlessly integrated into it. Calling conventions of the SUBs and FUNCTIONs will be easier to use. Background music and sound effects will be simple to implement. Loading and saving of many graphics file formats will be included. 3D math functions will be integrated so all programmers will be able to break the barriers of the 3rd dimension. The drawing routines will be accelerated even more. Here's your chance to submit ideas for new SUBs and FUNCTIONs, because at this point I'm willing to add just about anything." This sounds pretty freakin cool eh?! Check out the Virtuasoft website at http://www.gnt.net/~gump

Badjas is working on a 3D engine in the form of a library. The finished product will allow QB programmers to make their own 3D games easily. I have seen a very early demo of the engine and even though it wasn't optimised it ran at an acceptable pace. Best of luck on this project Badjas! ^_^

Xybertech, one of the host sites for QBCM, has moved. It is sporting quite a snazzy new look so go check it out! http://www.neozones.com/geoshock

On February 15th another QB magazine hit the scene at the Future Software website. It was called QB Scene. Though very well made it lacked any real tutorials or articles. QB Scene stopped after only one issue to become the new QB Times! QBCM wishes the QB Times crew the best of luck with this publication! The Future Software website is at http://www.qb45.com

Another secret QB project hits the scene! Jorden, Badjas, and Smoky of Future Software have started a secret project. We managed to get a little info out of them! This is what they had to say: Jorden said: "It's a game that hasn't been done in QB before. That's all I want to say." Badjas said: "It's going to use custom specific ASM routines to speed things up. There's a big lack of this kind of game in the QB world." QBCM will keep you posted on this new project!

Merlin, of Master Creating (best known for their awesome RPG Shadow of Power), very kindly provided us will a short press release on his lastest project - Imerion. This is what he had to say: "The story is finished and our concept, which is nearly 50 pages long, is nearly done too. But what will it be? An action-adventure like Shadow of Power? No. Imerion is going to be a turn-based fantasy strategy game like Master of Magic (if you don't know this - like Civilisation with magic and heroes like in Heroes of Might and Magic), but with much better graphics, multiplayer support, five totally different races, and so on. The basic engine, which uses an 800*600 resolution and 24 bit graphics (wow, this sounds awesome! -ed) is nearly finished as well. We already started the soundtrack, which will be MIDI tracks that can be played with wavtable support, but we are still looking for talented composers who want to help us with this job. We don't have a release date planned yet because a lot of graphics still must be created and the battle system, which will be RPG style, still needs to be done too. My personal goal is to finish it by xmas, but it can be completed in July as well. At this point I can't tell you more because the game is still in the early phases of production, and so we'll probably change something." This game sounds godly eh guys?! Check out the Master Creating website at http://www.master-creating.de

We have some more news from Master Creating. They recently released Diamond Fighter IV. I have not seen the game yet, however, having seen the previous works of Master Creating, I assume that this new game must be pretty spectacular! Diamond Fighter IV will be reviewed in the next issue of QBCM.

We have quite a bit of news from the angel of darkness himself, DarkDread, this month. Firstly, DarkDread recently released Myserious Song, a pixel*pixel scrolling console style RPG, to much acclaim. MS is without a doubt his best game yet! Check it out! Secondly, DarkDread added the Vault to his website, which contains 8 of his earliest games - most of which he has never released (until now that is). DD was also kind enough to appear in an interview for this issue of QBCM!!! Check it out! Visit the Darkness Ethereal website at http://www.geocities.com/TimesSquare/Ring/1683

Provgamer, Sane, and QBMaster, well known on #QBChat as experienced and helpfull coders, recently formed a new Qbasic company together called Vgamesoft, which, from what I have heard, seems like a very promising company indeed. Vgamesoft is still looking for more (experienced) programmers and graphics artists. If you are interested in joining them, then contact Provgamer at horstmans@worldnet.att.net

Jorden Chamid and Nekrophidius, a coder fast becoming one of the more prominent figures in the Qmunity, have started coding a new BASIC hybrid - QuickPower. This is what they had to say about the project: "QuickPower is the ultimate BASIC hybrid, finally closing the gap between QB and PB. It is designed for the Windows environment, but the output is still as DOS as ever. Seamless library support, QB dialect expansion, extensive help system, and much more. Through the use of "plugins", QB has more power than ever, and with an optimizing 386 compiler instead of the traditional BC.EXE, you'll soon forget QB had limits!" We wish the QuickPower crew the best of luck on this project. You can see Nekrophidius's site at http://lss.zext.net

ZKman, the founder and editor of the once great Qbasic: The Magazine, has re-appeared in the Qmunity after playing the invisible game for over a month. Nothing is known about why he dissapeared, but we're glad to have him back!

NeoBASIC, one of the more popular QB websites, has descided to stop covering Qbasic material, in preference for Qbasics's predecessor, GWBASIC! This change will take place within the next two weeks. This is quite a shock eh guys?! Then again, this is the April issue...what's so special about April 1st again? :P

Terry Cavanagh, Will Moores, and myself (Matthew R.Knight) recently formed a new QB coding group together (still has to be named). Our first project is an RPG called Apocalypse which will be using a version of my 13h gfx library, Blitz, which has jokingly been called ApocaBlitz. QBCM will keep you informed on the progress of this project in coming months.

Now for some news from Horizons Interactive Entertainment. I (Matthew R.Knight) recently benchmarked my gfx lib that I have been working on, Blitz, against all other currently existing 13h gfx libs. Many of the routines in Blitz actually turned out to be quite a bit faster than GSLib, considered by many to be the fastest 13h lib in existance! There is no release date set for Blitz yet. We'll keep you posted.

That's all the news we have for you this issue. Please send any news or rumours to us at horizonsqb@hotmail.com


Writing user friendly programs


Writer: Matthew River Knight

What makes a program good from the users point of view? Clearly a program that has so few bugs that the user is unlikely to come across one is on its way to becoming a good program. Clearly, how fast and how small a program is are aspects of program efficiency, and users do like programs that get the job done quickly. Just about everything else is a matter of program elegance. Two programs may carry out the same job using roughly the same amount of time and memory, but deliver entirely different degrees of service to the user. One may be easier to use than the other - this is a question of program design and the so-called user interface. One may crash (ie. not complete the job) given only a small amount of user ignorance or perversity, wheras the other may allow the user the liberty of completely ignoring any instructions concerning The 'proper use' of the program. Other important aspects of elegance are not so obvious. Take, for example, maintenance and extendability. A program may do the job in hand but what about tommorow's job? Some programs can be modified easily; others are such a nightmare that it is preferable to start from scratch! These and other aspects of elegance are mainly about using a good programming method and testing the product well, but this is not true of the degree to which a program is crash-proof. A good program is well- written and behaves well in the hands of the user!

In the early days of computing, the demand was for a program that did the job and no more. A user would ask a programmer to produce a program that would solve a specific problem and, if the result was a program that worked when treated with care, then everything was fine. Users had to be content with what they got! These days, however, there is no excuse for producing a scrappy program along with a list of do's and don'ts. Indeed, the average user demands a program that not only works in the sence of getting the right answer and being fairly bug-free; he also wants a program that is pleasing and easy to use, and does not crash no matter what is thrown at it.

The main reason for this is that the number of quality programmers is increasing. This has led to an increased awareness that things do not have to be quite so bad. Consider the scenario; you are demonstarting your program to a group of fellow programmers and descover that you are the only one capable of driving it without error messages springing up like weeds. You will quickly find that this will be considered an unacceptable failure of the program. Notice that in this case, what is the heart of the problem is not really a bug, in the sence of an error in the program. It is simply that the program has no way of dealing with unexpected events.

In order to work around these problems, it is necessary that your program is tested, over and over again, with a view to make it capable of handling whatever is thrown at it. It would not be unwise to allow a number of other users to test the program for you, and then report any errors that occur.

Once you have a fairly bug-free, uncrashable program, the only way that you can improve it is to work on the user interface - that is, improve the way that the program accepts and delivers data to the user. A popular term that is used to describe a program that a user will find easy to use is user-friendly. If your program is uncrashable, then it is well on the way to being user-friendly and it will take very little extra to make it easy to use. Some programmers manage to write user-friendly programs without even thinking about it. Others manage to take the user through the most unnatural sequence of badly-formed questions and deliver responses that are totally uncomprehensible! Apart from a list of hints and tips, there is not very much that can be done to guide the construction of user-friendly programs. The range of different user interfaces is just too great. However, there is one rule that is never to be forgotton - the user is (nearly) always right. If you allow someone to use your program, listen to what they have to say about it and the way they use it. Sometimes users critisise a program because it fails to meet their specific need. In each case it is up to the programmer to decide if the critisism or request for extra facilities is justified. Sometimes the extra facility is desirable but just too difficult to include in a program. One form of user feedback that should never be ignored is the mistakes they make in using your program. For example a program asks:

Largest value is?

and then

Smallest value is?

and the users keep on typing the smallest value first, then change the order of the questions! Mistakes in answering the programs questions are a sign that either the questions are badly phrased or are in the wrong order. Some general points to keep in mind while trying to improve the user-friendliness of a program are:

1. Always ask the user clear unambiguous questions and never use jargon unless it is the users jargon. In fact, employing the users jargon and well- established abbreviations is one way to ensure that a program is user- friendly. For example, it is better to use "VAT" than "value added tax" in an accounting program aimed at accountants.

2. Always allow the user to correct any entries that are made as responses to questions. In other words, avoid the use of INKEY$ to accept single character responses from the keyboard unless you have a very good reason. Everything typed at the keyboard should end with a carriage return to indicate that input is complete.

3. A program should accept as correct any user responses that make sence to the user. So, for example, "YES", "Y", "y", "Yes" or "yes" should all be acceptable in answer to a question.

4. Do not give the user too much information at any one time. The best solution is to give the user control over how fast information appears on the screen but, whatever happens, output should never shoot off the top of the screen before the user has had time to read it. Always use both upper and lowercase. Users can read this faster than upper case only.

5. If you are using color and/or sound, use them sparingly. Use color or inverse video to highlight important messages rather than for every message and pay attention to the way the whole screen looks with the use of high- lighting. Use sound only to draw attention to something on the screen. For example use it when something first appears, when the user is expected to make a response and when the user makes a mistake. Good use of sound in graphics games should make the sound appear to come from whatever it is drawing attention to on the screen. This can be done by synchronising sound and vision.

6. Try to give the user as much control as possible over what happens in the program. There is nothing more frustrating than finding you are in the middle of a program and have just caused it to do something unwanted which not only takes a long time but also allows you no way of stopping it. It should be possible for the user to restart the program from any point without having to reach for the machines reset button.

7. If your program spends a long time working something out, it is comforting to the user if it occasionally prints a message to the effect that it is still awake!

8. When the user makes a mistake, try to correct the mistake by giving an appropriate message. Dont think of such messages as error messages; think of them as correction messages! First tell the user what was wrong, without using jargon, then suggest what might be the trouble. It is always tempting to produce error messages that are either very technical or friendly in the extreme. Messages such as ** INTEGER RANGE ERROR ENCOUNTERED ** and ** You got it wrong didn't you! ** are both to be avoided.

A list of hints and tips of this sort could go on forever by becoming increasingly detailed. The best thing to do is to make your own by observing and learning from some friendly users!


QB Library debate


Writer: Matthew River Knight, and various other QB programmers

Ever since the release of the Blast! library, by Andrew L.Ayers, back in 1997, the Qmunity has been arguing about whether libraries should/should not be used. Some argue that they shouldn't be used since the code is written by someone else, and thus a game written with a library cannot be called 'your own'. Others argue that those who use libraries, and do not understand the principles behind them, will never learn anything about the inner workings of the computer, and will eventually become no more than copy/paste coders. On the other hand, there are many coders who argue that there is nothing wrong with the use of the libraries - after all, we all use Qbasic don't we? And not all of us understand the principles behind Qbasic's routines do we?!

Among the library-using circles, there is also much debate over which is the best gfx library. With the ever increasing number of gfx-libs, this has resulted in what is known in the Qmunity today as the 'library wars'.

In an attempt to bring an end to this age old argument, I decided to hold a debate about it at the QB45.COM discussion forum. I posted the following message:

Matthew R.Knight: (Debate for all QuickBASIC programmers)

A lot of people in the Qmunity argue about whether libraries should/should not be used, which is the best gfx lib available, etc. I want to bring an end to this right now...and I think the best way of doing this is having a big debate about it right here!

Please reply to this message with your views on the following:

1. Do you think libraries should be used? Why?

2. Do you think that someone who made a game using a lib can call that game his own. How much credit do you think the maker of the lib should get?

3. What do you think is the best gfx lib available today? Why?

4. If you would like to say anything else in this regard... here's your chance!

<End of message>

A number of people replied to my post. Here are the best replies I got:

Flexibal: (The only reason I reply is that Glenn did it also...)

1. What do you mean?

2. Do you want to type the same code all over in each program? Everyone should make his own F.Lib?

3. You think so many people know how to make a F.Lib? Well, I don't, so I support libs.

<End of message>

Nekrophidius: (I can't believe I'm answering this...)

1. When it's time to take off the gloves and do a seriously asskicking product, yes, the use of libs is justified. When you're learning programming fundamentals, libraries should be avoided, as they take away the learning aspect (with the exception of learning to call external subroutines, which in itself is a learning experience).

2. As it's been joked about for months now, there is no such thing as SUB DQBbuildMyGamePlease (Author AS STRING). When you write a game, a library can only do so much, such as an enhanced PUT or maybe the tool to a better interface. It does not and never will be able to build a game for you. Anyone who thinks that using a lib does all the work for you is a retarded fool, and you can quote me on that. Now, on to different things. You CAN call the game your own, no matter what the ignorant fools say. Those who argue with me on this are stupid. Of course, it would be retarded in return to not give credit to the original library coder. Though some might argue that "oh, your not giving credit to the makers of QB!", just by knowing its a QB game, we know who made it =)

3. Depends on your definition of "best". Features? Speed? Reusability? If we're talking speed, what modes? For doing 13h work, the fastest out there is kind of a three-way tie between QB13h, EvilLib, and GSlib. QB13h is the fastest all-around, EvilLib is optimized for PIIs, and GSlib shines on a Pentium. Now, for doing 8-bit SVGA, Zephyr's SVGA lib has still yet to be beat in terms of speed. Higher level SVGA belongs to Future Library, nothing out there can touch it. For all around versatility, no library has come even close to the amount of routines as DirectQB, although for 13h only, its got tons of routines, fast primitives and sprite routines, even some dabbling in the 3D field. However, it's also pretty flawed, but chances are, if you need most of the routines in DirectQB, you shouldn't be using it to begin with.

4. Stop this stupid banter. It's ages old.

<End of message>

Matthew R.Knight: (Various...)

Thank you for your very valid points. In reply to question 4 on my list you said "Stop this stupid banter. It's ages old." I couldn't agree with you more. That's the exact reason I decided to do this debate. This stupid argument has been going on for ages and I want it to stop, and I feel that the best way of going about achieving that is by showing these people who think libs are evil or something, that they are wrong! And the way of doing that is holding a debate so they can see everyone's points.

<End of message>

MaxX: (Response)

1. Library should be used because they make the program shorter and faster and they provide good engines.

2. I think someone who has made a game using a library can call the game HIS game but he should give credit to the programmer(s) of the library on the MAIN page of his game.

3. I think the best library available today is the Future.Lib because it's the only one to be updated so fluently. (Don't you mean frequently? -ed)

4. I think a programmer should use only his OWN library so that he knows everything on it and could fix it himself!

<End of message>

Nekrophidius: (I disagree on #1)

I've never seen a lib out there that provides a pre-built engine. And rarely does a library make the EXE smaller, in most cases, it makes it larger. The only exception to this rule is in the case of a dedicated 13h game where the library handles the actual video mode and all routines. A few libs do this, but all the 13h libs allow you to use SCREEN 13. Kinda dumb though. It's like putting on a boot over a shoe to go shopping or something...

<End of message>

NetherGoth: (Response)

1. I think that Libraries should definitely be used. Without them, its impossible to really achieve anything. You can go ahead and make your own functions using inline ASM or whatever, but they simply won't be good. Libraries finally allow QB to start catching up with C++ and other such languages. I personally don't care WHAT language I use. I use whatever programming language is easiest, quickest do develop in, and most fun to program in. That happens to be Qbasic. If there are some ASM libraries to add on, all the better.

2. Yes. A lib is a lib - it is a bunch of functions. A game is much, much more complex than that even if it is not done in ASM. The maker of a game should be able to claim credit for the game. After all, professional game companies never put Microsoft in their credits for making DirectX, do they? I think the lib makers, however, SHOULD get some credit, under a seperate category "Library Programming" or some such thing.

3. The best lib out right now is Zephyr Software's SVGAQB lib. It is just the easiest lib to use by far, has the best documentation by far, and is the fastest. BUT Future library is catching up very quickly, and in the future it will surely become the top library.

<End of message>

Badjas: (Credit with real games)

There is no credit to someone who made a lib that was BOUGHT by the game making company. They buy it!

If you have bought a house, should de one who made the house be written on it? If you got it for free, from the one who made it, then YES OF COURSE dont say its your house. (This is just an example, and you have to see a house as a library... :)

<End of message>

James Robert Osborne: (My reply)

1. Technically yes, because reinventing the wheel is unnecessary, and a complete waste of time, (esp. if it's already done very well by someone else) UNLESS you're writing faster and better routines than something that already exists or give the routines more flexibility for your own needs. If you're trying to make a library using straight QB, you're completely wasting your time. A VERY GOOD example: here's my Absolute value FUNCTION without using QB's ABS FUNCTION:


IF Number% < 0 THEN Number% = Number% * -1


Only problem is, this will take up twice the time to perform. I rest my case.

2. If you're talking about legal-wise, it depends if it's copyrighted, or the author asks for credit. If the library is freeware, yes, I CAN call it my game. As for "how much", it shouldn't work like that, it should be "credit, or "no credit" I mean, come on now, do you see console games crediting people by percentage? I rest my case.

3. If this were SCREEN 13 in particular: The fastest library I've ever encountered with is GSLib, I really don't have to say why, just test it for yourself!

4. Everybody has their own opinion, and philosophy, so of course this stupid arugument will never be put to an end of who's right and who's wrong, but hey, I guess this is brought up to entertain people like me.

<End of message>

Joel: (Reply...)

1. I see no problem using libraries, especially of you don't know how to make the routines yourself. I usually try to avoid libraries because I get joy out of makeing my own routines.

2. Depends on how much of the game is libraries, and how much is the persons own code. And it's only right that the maker of the library(s) is listed in the credits.

3. Don't know. I prefer trying to make my own graphics routines. Sometimes I ask for lots of help, but I try to use my own code as much as possible.

4. Nothing else to say.

<End of message>

Nekrophidius: (I sorta disagree on #2)

Read my answers for the reason =)

<End of message>

Sasha Vukelich: (1, 2, 3, 4...)

1. Yeah, well, cause it's easier to do programming, etc....

2. NO! If you made a program with a freeware library, it CAN NOT be shareware!

3. I only tryed a few, Future.Library seems the best.

4. I wanna play more waves at the same time with Future.Library!

<End of message>

Nekrophidius: (you seem kinda dumb =P)

"Yeah, well, cause it's easier to do programming, etc...." Its easier to do DEVELOPMENT, not coding. Learn the difference.

"NO! If you made a program with a freeware library, it CAN NOT be shareware!" Yes you can. One of the aspects of a freeware library is that its use is out of the hands of the original writers, hence, it can be used for whatever you want to use it for.

"I only tryed a few, Future.Library seems the best." Well duh

"I wanna play more waves at the same time with Future.Library!" Well duh again =P

<End of message>

Glenn: (On 2, you're confusing freeware with public domain...)

Just because, for example, I don't charge you for something that I distributed (i.e. gave) to you, doesn't necessarily mean I'm relinquishing copyrights. And public domain stuff you can't outright sell in and of itself. (No one can sell something they don't first own. :) However, you can usually incorporate it within a bigger product and sell that bigger product.)

<End of message>

Nekrophidius: (I dont think so =P)

I wasnt saying that someone could directly sell the lib itself, but the use of the lib is unrestricted. Which does include selling it, under US law. Ironically, the ones who get it confused are the ones who make the product in the first place. The only difference between freeware and public domain is the copyright. And 9999 times out of 10000, freeware products dont even HAVE a registered copyright, therefore, no proof of creation can be assumed in the first place.

<End of message>

Jan Knutar: (Reply...)

1. Depends on the situation. If I find a routine in a library, and I need that routine for my program, I'll use the library. Libraries are OK, why reinvent the wheel?

2. The maker of the library should be mentioned in the credits section of any game. You should also honor the wishes of the library's creator(s) and follow its license. Of course you can call a game 'your own', but you have to give credit to the guys who made the libraries!

3. Future.Library/Dash. Future.Library is more versatile, SVGA, etc. Dash has very fast functions that can draw to buffers. I use mostly Future these days.

4. These polls are unnececessary and it's difficult to spell unneccessary, in fact, I don't think I spelled it right.

<End of message>

Matthew R.Knight: (Erm...)

Thanks for your very valid comments...

I dont think these polls are unnecessary (I think thats how to spell it!) I did this in the hope that people who have closed their minds on the subject of libs, whatever their opinion on them is, will think more carefully about it and wont just jump to conclusions irrationally.

<End of message>

Jan Knutar: (It's perfectly normal to use libs...)

In fact, all games that are made today use libs.. At least most of 'em use DirectX, which is a lib made by Microsoft!

Standard C(++) really doesn't contain any functions "built-in", you use libs all the time.

I guess it's only in the QB universe that librarires seem to be unnatural.

<End of message>

Badjas: (Here it goes)

1. They should. BASIC is GREAT for developing libraries. They improve the language. Ehm, new opcodes can be used? Why not? (this is the main reason).

2. Making a game IS hard. Credit however, is a MUST. If the game is realy big, put it in the credits section, and show it when finishing the game. If the game is a *normal* one (whats normal?) then the credits should be in the game somewhere in the menu or at a place where the user of the software doesnt have to search for it for hours. If it is a small game, then somewhere in a textfile would be okay. (to me) If it is just a demonstration of a library, then OF COURSE give credit (if it is not your own lib. :). It DOES depend, but not THAT much. Said enough about that I think.

3. Ehm, Future.Library has the best future I think. (not a joke:). havent used Zephyr though. (I WANT HARDWARE SUPPORT!, stupid Windowish way!)

4. Als blikken konden doden hadden ze er geen erwten in gedaan.

<End of message>

FK: (Libraries are needed!)

1. Yes, libraries should be used, else QB would be totally useless!

2. Yes, (s)he can call the game its own, cuz the creativity came from that person, the idea came from that person to make that game. The lib itself is nothing. It's only useful when you made a program using that lib.

3. Most gfx are quite good actually (only I prefer FutLib, dunno why :)

4. ...

<End of message>

Nekrophidius: (Your ignorance is overwhelming)

"totally useless"? GET A CLUE. I have been using QB for years and found it to be nothing short of awesome in all respects. Useless? In what sense? In the sense that using it makes newbies think they're all powerful, only to run into a problem that they can't fix with DirectQB because they don't know the fundmentals of coding, then quit because they can't think for themselves? Get real.

"The lib is nothing"? If you ever said that to my face I'd kick your sorry little ass. As a lib writer myself, I like to know if a person uses my work. Libraries take as much work, if not MORE work, than writing a game itself. It's nothing, eh? From the views you've expressed here, you've shown me that you are nothing but an amatuer who should actually read the QB help files for at least another year before downloading a library to do serious development. Right now I doubt you even know the various methods behind the PRINT and SCREEN commands.

<End of message>

MagnaUnum: (My indisputable argument.)

In my college, before they let you use alot of the routines available from the Standard Template Library in C++, the professors require that you yourself write your own similar routines. When you have passed the test where you write your own routine, on future tests you are allowed to use the library routine.

In essence, you are earning the right to save time and use other people's routines by saying "I can already do it myself, so there is no need to prove it." Get mah drift?

The best gfx lib availible is OpenGL

<End of message>

Badjas: (According to you, you are NOT going to use OpenGL?)

Oh yeah, what about hardware support? You know how to bake your own chips? :)

But the OpenGL lib is quite a beaty actually. You know how to do 3D? (yes I do, I can draw a thing in 3D!, WRONG. put 100 lights in it, and some water, and maybe you are even UNDER water. And what about motion blur? And that lib isnt just fast, because it also filters out the light calculations that are irrelevant...(for example))

No hard feelings, but you are just wrong with your point.

I think one should use a library just as it were part of the language, AS LONG as (s)he is THANKFULL. (at LEAST give credit... (and if you want to do more? send flowers :))

Rome WASN'T build in one day, but the second build SURE was FASTER! :)

<End of message>

Jorden Chamid: (Reply...)

1. If it improves the gameplay, yes sure use a library!

2. Yeah, the programmer still creates the game, so he can call it i's own. However, the creators of the library should be in the credits of the game.

3. Future.Library, because it has better screenmodes than any other gfx lib. Also, easier to use than ZephyrLib.

4. That's all.

<End of message>

Whew! What a debate that was! From these replies, I think it is fairly clear that the majority of the Qmunity has nothing against libs. There were a few posts from people who said something to the effect of "Libraries should not be used." however, none of these people actually managed to come up with a reason for why they felt this way!

Well, I hope you enjoyed this debate, and that it managed to get you thinking about the topic with a broader perspective. I would like to thank everyone who participated in this event. In addition to that, a big thanks is owed to Jorden Chamid, of Future Software, for creating one of the best Qbasic sites in the world, along with its popular discussion forum, which made this debate possible.


Game tutorial series #1 - graphics


Writer: Provgamer

Ok everyone this is my fist tutorial so please excuse any problems! Anyway in this tutorial I'm gonna go over the basics in starting a game. Ok I'm gonna be honsest, all those tutorials that tell you to plan everything FORGET THEM!!! That's right you don't have to spend hours of planning a game, just have a basic idea of your game and then add-on to it as you get more ideas! Well anyway on with the tutorial...

To even start a game you must know some simple graphic commands! Such as:

3. How to use the DATA command

Ok. Now how to use PSET. Try this...

SCREEN 13 : CLS 'this sets the Screen mode to 13 and clears screen
FOR y = 0 TO 100 'this gives a number from 0 to 100
FOR x= 0 TO 100 'gives a number from 0 to 100
PSET (x, y), 4 'draws the graphic (x is the vertical location, y is the horizontal location) 4 is the color number red. NEXT x 'completes the x loop
NEXT y 'completes the y loop

Confused? Maybe we should try something a little more simpler! Try this...

PSET (100,100), 4
PSET (101,101), 5
PSET (102,102), 6

Ok. If you are still confused then think as the screen in qbasic as being a big graph. X is the vertical lines and Y is the horizontal!

So now the commands

PSET (2, 3), 4
PSET (2,4) , 4

would be shown like this:


1. Draw a picture of the letter I.
2. Use the FOR...NEXT in PSET to make squares.
3. Experiment with PSET. Get to know the locations on the screen.

Ok now you should know enough on how to locate spots on the screen by using PSET. I will now attempt to show you the LINE command. First on PSET you pick a spot for a single dot or pixel. Now on the LINE command it's basically the same strategy only you give 2 locations!

LINE (10, 10)-(20, 20), 4

Let's break this command up so we can understand it! The (10, 10) is the location where the LINE will start. (20, 10) is the end of the line. The 4 is the color we chose (which is red)

Now there is another part of the LINE command which is kind of neat. If you wanted to make a square then you'd put in the coordinates of the squre like this:

LINE (10,10)-(20,20), 4, B 'b means block I think

Or it could be

LINE (10,10)- (20,20), 4, BF 'BF means Block Fill I think

I'm not gonna go into anymore depth on the LINE command. The only thing I can tell you is to experiment yourself with this.

Now I'm going to ATTEMPT to explain the DATA command! This is the most precise method of placing pixels. I'm giong to describe how to use it in screen 13:


FOR y=0 TO 4 'Gives us a 5x5 tile
FOR x=0 TO 4

DATA 00,04,04,04,00 'Data for pixels NOTE: #'s = the color #
DATA 04,00,00,00,04
DATA 04,00,10,00,04
DATA 04,00,00,00,04
DATA 00,04,04,04,00

READ Pixles 'Read the data as Pixels
PSET (x,y),Pixels 'Locate x,y and put Pixles there
NEXT x 'Finish x and y loops

Ok now This pretty much self explanatory! So use the example to figure it out! If you cannot make sense of it then check the help file or email me!

Thanks for reading...and GOOD DAY!!!


Next tutorial I will be going over the GET, PUT, BLOAD, BSAVE commands! This tutorial will ONLY be found in QB CULT MAGAZINE! Well see ya then!


#QBChat survival guide


Writer: Matthew River Knight

While the vast majority of people that frequent the #qbchat chatroom are intelligent and interesting qbasic coders, wanting to increase their knowledge of BASIC/ASM programming, and converse with others who have similar interests, I have become increasingly angered by the small minority of idiots who go to #qbchat only to hurl abuse at others for no particular reason.

This minority seem to think that they are being 'cool' by entering the chatroom under a profane nickname, and then proceeding to hurl bad language and insults at others, for no reason other than the sheer perverse pleasure they derive from it. These kinds of morons make me sick. If I had a shell account I would see to it that they be permanently removed from the internet as no good can come from such people being a part of our community. Sadly however, I do not have Unix or a shell account, so the morons stay - it is thus necessary that we find an alternate method to deal with this stupidity.

I recently became the victim of such stupidity...I was busy talking peacefully in the chatroom, as I had done many times before, when suddenly I received an insulting and abusive private message from a certain idiot, for no particular reason. Two (I think) of his moronic friends soon joined in. At first I was shocked. I couldn't understand why I had become the subject of a verbal attack when all I had ever done in the Qmunity is go out of my way to help other coders. I had never said anything bad to/about anyone. I soon, to my later regret, proceeded to yell right back at them. I now realise what a stupid idea that was. Fighting back with idiots who only go to the chatroom to cause trouble makes you no better than them - it makes you just the same as them! I realise this now. The best thing to do would have been to ignore them and continue to chat with my friends. Another alternative would have been to leave and come back later, in the hope that they had left. A couple of other people who entered the chatroom half way through the argument probably thought that I was yelling at them too (it's kind of difficult to direct your conversation at the right people in the main.) I apologise to anyone who thought that I was yelling at them - I was directing it at those three idiots I discussed earlier.

I would advise any intelligent coders going to the chatroom to simply ignore any abusive and obviously dim-witted individuals. Don't bother arguing with them - no good can come of it. If they go too far and start to become a problem, it is advisable to contact Leahcim, who runs the chatroom, who will then take the necessary course of action against them.

Once again, I apologise to anybody who thought I was yelling at them - I wasn't. This is the exact reason why it is advisable not to argue back with stupid and abusive people.

Thank you for reading.


Data encryption


Writer: LordAcidus

Ohhhh...we're all a little closer thanks to the internet. Or so everyone tells me. Personally, I don't want to be any closer to the 50 year old single white male child pornography photographers out there in all the AOL chat rooms, or on IRC. I also am sick of the media saying how about all those dangerous "hackers" out there. OH GOD NOT THE HACKERS! THEY MIGHT DO SOMETHING TO ME! AAHHHH, TECHNOLOGY IS EVIL, FLEE TO THE BADLANDS, THE EVIL HACKERS WILL DESTROY US ALL!!!!!!!!!!

Yes, they tend to blow things out of proportion. However, security is an important thing. But how do you get good encryption software, that is easy to use, and IMPOSSIBLE to break? Simple, make your own.

Now listen up and listen good. I had to self-teach myself all this stuff. I didn't even have books on the subject, so between sleeping in AP economics, and looking at breasts in Latin, I went over the basics of encoding/decoding in my head. First of all, you must have a program. This program can take a file, use some magic wand, and convert the file into a big mess. Then you take the mess, and store it/send it/print it whatever. When you decode it, the program has to use the same magic process and revert the file to its original state.

Granted "magic" isn't a very good definition of what the program does. Encoding a file is a very simple idea. What the program does is to read through the file, and take each character, and change it based on what is called the key. Let's say the character being read is "A" which is ASCII code 65. Ok, the program takes 65 and adds 9 to it (9 being the key). The new value is 74, which is the ASCII code for "J". "J" would then be written to the file.

PRINT NewChar$ 'Displays "J"

Ok, if that's how it works, then I looked at it from the other end. How would I break a coded file. Yes, I have broken files before, and it's pretty easy. It is easy because each character changed by the same value, as in the case of our example, it was 7. I have a program on my Computer that I wrote called "Simple_Break.bas" It just reads through an encoded file, and tries different numbers as keys. It then looks at the file and looks for the words "the" "and" "is" "was" "it" and other common words that I got out of the 1996 World Almanac. Granted this doesn't work on .EXE files, but it is very good a breaking text files. Btw, I call breaking encoded files breaking. "Cracking" is disabling a copyright protection of password on a game, common in WareZ.

So, since you don't want a program that has the same key for each character, what do you do? Well, I soon thought that every key must be different. Like, you type in a password, like "dog", and the computer takes each letter, and matches it with a letter in the key. It takes the ASCII code of the original character, add the ASCII code the letter of the key, and stores the result. If the result is greater than 255, it loops around to 255 - NewCode%. The next letter is moved to, and the next key letter is used, and the process repeats. When the last letter of the key is used, it loops back around to the first letter of the key. This is easier to show then tell. We will encode the sentence "Qbasic will never die!" with the key "dog"

Original: Qbasic will never die
key : dogdogdogdogdogdogdog
After : `ExOE,`DDUOOOY OEOId

First notice that the key "dog" is only 3 letters long. Since this is a lot shorter then "Qbasic will never die", the key is repeated when it gets to the end. Also notice that the space after "Qbasic" is represented by the "," character. Yet the space after "will" is represented by "O". Do you realize how great that. Unless you know the EXACT key letter by letter, there is no way to crack it.

Now notice what happen to the same sentence if we use "Happyness" as the key: ( Yes I know it is Happiness, but we are going to use Happyness)

Original: Qbasic will never die
Key : HappynessHappynessHap
After : (tm)AaY...^s'I__,E+"EO

COMPLETELY DIFFERENT ENCODING! See what I mean, it is incredible. This is IMPOSSIBLE to break except under 1 condition. The breaker knows what the very beginning of the file should look like. By working backward, I could get the key. Only under this one condition could I figure out the key.

Check out ENCODE.BAS (included with this issue of QBCM -ed) for the code of my encoder/decoder, and feel free to use it. Remember, there is really no limit to your key. Make it a line from your favorite song. Make it nonsense, make it anything you want. I use this program a lot when dealing with credit card numbers when I email them to friends. Enjoy!


Writing your own GET & PUT routines


Writer: Matthew River Knight

You will recall that last month, under the Tips, Hacks, and Tricks section of the magazine, we discussed how to do page flipping in screen mode 13h. We wrote a fast PCOPY routine to do this for us, and we briefly discussed how to PSET/POINT to/from these offscreen pages. Unfortunately however, it is not possible to really do much with those short routines.

In any 2D game, the most important routines are probably GET and PUT. Without these two vital routines, it would be very difficult, if not impossible to make a 2D game, running at an acceptable speed. Consequently, I have decided to write a nice long tutorial, explaining step-by-step, exactly how to write your own ASM GET/PUT routines for use with offscreen 13h pages!

The GET/PUT format:

We are going to be using SCREEN 13 for these routines, since it is the most popular screen mode, and also has the nice property of being very easy to use. The whole screen is built up by a 320*200 pixel bitmap with 256 possible colors. Each pixel occupies one byte in the VGA memory, and that memory starts at the address A000:0000h. The first byte contains the index(color) of the pixel at coordinates 0,0, the second bye contains the index of the pixel at 0,1, the 320th byte contains the index of the pixel at 1,0, and so forth.

When you GET a sprite, it is stored in a Qbasic array. The first word in that array holds the width of the sprite multiplied by 8. The second word holds the height of the sprite. Fortunately this value is the actual value, unlike the width, which is multiplied by 8. After all this, the pixel indexes come as bytes stored in the same way as the SCREEN 13 bitmap.

Writing a PUT routine:

We are going to start off by writing a PUT routine. It would be nice if we could write a routine a little better than the standard Qbasic PUT. Obviously it will be much faster than PUT, and it will also be able to PUT in offscreen pages, but let's add another feature. I'll bet that if you have ever made a game in Qbasic, you have been bothered by the fact that whenever you use PUT, a big black box surrounds the sprite, completely obliterating the background. Oh boy, oh boy, yes indeed...well, this PUT routine that we are soon going to write is going to have an invisible color. This means that one of the colors in the sprite will not be drawn on the screen. With this feature, your sprites can have irregular edges and holes in them because a certain color will be skipped when the sprite is drawn on the screen. We'll make color 0 the invisible color.

To start off with, we need to figure out what variables we need to pass to the routine. First of all, we need to pass the x and y coordinates of the screen where we want the sprite to be drawn. The sprite should be stored in an array, and all arrays start with an offset address of 0 in memory, so we just need to pass the segment address. Since this routine must also be capable of PUTing to offscreen pages, it is necessary that we pass the segment and offset address of where we want to PUT the sprite. For example, if we just wanted to PUT the sprite straight onto the screen, then we would pass &HA000 as the segment and 0 as the offset. If we wanted to PUT onto an offscreen page, then we would have to pass the segment and offset address of the array being used as the offscreen page.

The routine will also need to know the dimensions of the sprite, however, that's stored in the sprite data so we can obtain those values inside the assembly routine itself.

So, let's make the CALL to the routine like this:



DSeg% is the segment address of the screen page.
DOff% is the offset address of the screen page.
Sprite% is the array of the sprite to be drawn.
X% is the position on the x-axis where the sprite is to be drawn.
Y% is the position on the y-axis where the sprite is to be drawn.
asmput$ is the string containing the machine PUT code.

Okay, now we can write our PUT routine! I decided to make this routine with Absolute Assembly, by Petter Holmberg, since this is the method of proggin in ASM that is used by most ASM newbies in the Qmunity. If you don't have Absolute Assembly, don't worry, I have included it with this issue of the mag for ya!

PUSH DS ;Allow passing of Qbasic variables.

MOV BX, [BP+0C];Get the segment address of the sprite array.
XOR SI, SI ;Set SI to 0.

MOV BX, [BP+10] ;ES = screen buffer segment.
MOV DX, [BP+0A] ;DX = x coordinate.
MOV AX, [BP+08] ;AX = y coordinate.
MOV BX, AX ;BX = AX = y coordinate.
MOV CL, 8 ;Multiply y with 256.
MOV CL, 6 ;Multiply y with 64.
ADD AX, BX ;Add the results together.
ADD AX, DX ;AX(320*y) = AX + DX(x coordinate).

MOV BX, [BP+0E] ;BX = screen buffer offset.
ADD AX, BX ;AX(320*y +x) = AX + BX.
MOV DI, AX ;Set DI to AX.

LODSW ;Get width from sprite data.
MOV CL, 3 ;Divide the width by 8 to get actual width.
MOV BX, AX ;Store the width in BX.
LODSW ;Store the height in AH.

MOV DX, 140 ;DX = 320 - sprite width.

Yloop: CMP AH, 0 ;Is height zero?
JE EndProg ;Yes --> goto EndProg.
MOV CX, BX ;No --> make CX equal to sprite width.
XLoop: LODSB ;Load a pixel from DS:SI into AL.
CMP AL, 0 ;Is the pixel color 0?
JE SkipPixel ;Yes --> dont draw this pixel.
STOSB ;No --> copy the pixel in AL to ES:DI.
DEC DI ;Compensate for pixel skipping code.
SkipPixel: INC DI ;Skip a pixel.
LOOP XLoop ;Next loop of XLoop.
ADD DI, DX ;Move to the next line of the sprite.
DEC AH ;Decrement height.
JMP YLoop ;Next loop of YLoop.

EndProg: POP BP ;Return to Qbasic.

Now that we've written that code up, we need to run it through Absolute Assembly, so the machine code can be generated. Lucky for you, however, I have already done this for you! And, I have made a working example bit of code to use the routine! Check it out! It's PUT.BAS, included with this issue of QBCM! ^_^

Writing a GET routine:

Now that we have done a PUT routine, you are going to find it very easy to write a GET routine, since it works on very much the same principle, but in the reverse! You probably already have a very good idea how to make this routine yourself, but just in case you don't, we'll guide you through the coding of it right here, step-by-step!

As with the PUT routine, we first must decide what variables we are going to have to pass to the routine. Firstly, we are going to need to pass the segment and offset address of the screen page. We then need to pass the segment address of the sprite array. In Qbasic, when you use GET, you always need to enter the variables/values x1%, y1%, x2%, y2%, and these variables are also going to be passed with our routine!

So, let's make the CALL to the routine like this:

CALL ABSOLUTE(BYVAL dbuffseg%, BYVAL dbuffoff%, BYVAL VARSEG(image%(0)), BYVAL x1%, BYVAL y1%, BYVAL x2%, BYVAL y2%, SADD(asm$))


duffseg% is the segment address of the screen page.
dbuffoff% is the offset address of the screen page.
image% is the sprite array we are going to GET the data into.
x1% is the x coordinate of the top left corner of the sprite.
y1% is the y coordinate of the top left corner of the sprite.
x2% is the x coordinate of the bottom right corner of the sprite.
y2% is the y coordinate of the bottom right corner of the sprite.
asm$ is the string containing the machine GET code.

Okay, now we can write our GET routine! Once again, this routine has been written to use Absolute Assembly.

PUSH DS ;Allow passing of Qbasic variables.

MOV BX, [BP+10];Get the segment address of the sprite array.
XOR DI, DI ;Set DI to 0.

MOV BX, [BP+14] ;DS = screen buffer segment.
MOV DX, [BP+0E] ;DX = x1 coordinate.
MOV AX, [BP+0C] ;AX = y1 coordinate.
MOV BX, AX ;BX = AX = y1 coordinate.
MOV CL, 8 ;Multiply y1 with 256.
MOV CL, 6 ;Multiply y1 with 64.
ADD AX, BX ;Add the results together.
ADD AX, DX ;AX(320*y1) = AX + DX(x1 coordinate)
MOV BX, [BP+12] ;BX = screen buffer offset.
ADD AX, BX ;Add BX(screen buffer offset) to AX(320*y1+x1)
MOV SI, AX ;Set SI to AX.

MOV BX, [BP+0A] ;Get the width of the sprite - (x2-x1)+1
MOV AX, BX ;Copy BX(sprite width) into AX.
MOV CL, 3 ;Multiply width by 8.
STOSW ;Copy (width * 8) to the sprite array.

MOV AX, [BP+08] ;Get the height of the sprite - (y2-y1)+1
STOSW ;Copy height to the sprite array.

MOV DX, 140 ;DX = 320 - width.

yloop: CMP AX, 0 ;Is height zero?
JE Endprog ;Yes --> goto Endprog.
MOV CX, BX ;No --> number of times to do xloop = BX
xloop: MOVSB ;Copy byte at DS:SI to ES:DI.
LOOP xloop ;Next loop of xloop.
ADD SI, DX ;Point at next line of the sprites height.
DEC AX ;Decrement height.
JMP yloop ;Next loop of yloop.

EndProg: POP BP ;Return to Qbasic.

Well there ya go! The code is done! All you have to do now is run the code through Absolute Assembly, and then you can start using this stuff! Well, actually, you won't need to do that because I have already done it for you! Check out GET.BAS, which is included with this issue of the mag!

That's it for this tut. With this new knowledge, in addition to what you learned last issue about writing a PCOPY routine, you can make a pretty cool game, certainly much better than you would have done without this! ^_^


Introduction to Qbasic series #2


Writer: Matthew River Knight

Welcome to part 2 of the Introduction to Qbasic Series, QB newbies! I hope you have been doing some experiments with what you have learnt! Last month we covered only the simplest of Qbasic statements/functions. With that knowledge it would be possible to make some simple programs...pherhaps even a very simple game...but that's not where we're headed with these tuts! We want to make kick @$$ games like Wetspot 2 and Shadow of Power! Yeah! ^_^

There is a lot that we have to cover in this series...I want to go over a few more of the Qbasic text handling routines, after which I'd like to cover the basics behind graphics in Qbasic, and the various methods of controlling program flow. I'll bet even at this stage of the tutorial you're confused... don't worry, soon it will all make sense!

Okay, to get started, let's make a program similar to the type of programs that we were doing last issue - but with a few enhancements!

'Program to test if the product of two numbers is greater than 10.
INPUT "Enter your 1st number:", n
INPUT "Enter your 2nd number:", n2
product = n * n2 'Multiply the two numbers together.
IF product > 10 THEN PRINT "Your 1st number x 2nd number is bigger than 10"

Alright, the above program introduces several new concepts of programming in Qbasic. The first thing you're probably wondering about is the COLOR statement. Let me explain...the COLOR statement is used to select the color of the text that will next be PRINTed or displayed from within an INPUT statement.

The COLOR statement is always followed by a number. In the example program above, it is 1. The number tells the computer which color to use. The number may range from 0 to 15, and each number displays a different color. Try experimenting with different numbers and see what color is shown!

Okay, now that you've mastered that, lets's do something a bit cooler with COLOR. COLOR not only allows you to select the color of the text being PRINTed, it also allows you to select the background color! Let me demonstrate this by means of an example. Try this:

COLOR 2, 5
PRINT "Pretty cool, huh?"

Let's get back to the example code we wrote earlier. The last line of the program uses the IF statement. We have never encountered IF before, but it is likely that you can already see how it works. The line of code translated to english means "If number is greater than 10 then print...". Simple no?

There are other ways that you can use IF. It can also be accompanied by the ELSE statement. Let's demonstate this by example:

INPUT "Enter a number:", n
IF n = 10 THEN PRINT "Number is 10" ELSE PRINT "Number is not 10"

The ELSE statement really has exactly the same meaning in Qbasic as it does in english! Wow! Is Qbasic easy to understand or what?!

The last thing you are probably wondering about is the ' character in the code. That means the same as REM. It is slightly more versatile than REM though, since you can also use it like this:

PRINT "Hello world" 'Say hi to the world

You are advised to use ' instead of REM since it is more versatile and it is obviously much easier to use.

Controlling program flow:

Up until now we have only written programs that when run are executed from the first line, down to the last, one after another. Fortunately we are not limited to this. It is infact possible to make the computer go to another line of code, run it, then jump somewhere else in the code, and run code from there, and so on.

Before I explain this in any further detail, it is necessary that I explain what line labels are. You may not be aware of it but a programmer is capable of giving a certain line of code in his program a name. There are two ways of doing this:

You can either give it a name which is just a number, like this:

10 PRINT "Hello, this is line of code 10"
11 COLOR 2
12 PRINT "Hello world!"

Or, you can give your lines of code more meaningfull names like this:

FirstLineOfCode: PRINT "MyProg.bas - Written by Joe Soap"
PRINT "What is your name"; name$
PRINT "What is your age"; age
WriteName: PRINT name$
WriteAge: PRINT age
EndOfCode: PRINT "Goodbye!"

You can also use a combination of the two if you want.

Okay, now let's see how we can make the computer read lines of code in different ways instead of just top to bottom!!!

PRINT "Hello"
GOTO EndOfCode
PRINT "This line will be skipped"
EndOfCode: PRINT "Bye"

The above program uses a new statement: GOTO. As you probably already guessed, GOTO stands for go to. It is used to GOTO a certain specified line label. Let's try another example just to clarify this further!

count = 0
Start: PRINT "This will be PRINTed 10 times"
count = count + 1
IF count <10 THEN GOTO Start
PRINT "That's it!"

The above program uses GOTO to perform what is known as a loop. This is a really bad way of performing loops. There are better ways of doing this. Here's a demonstration:

FOR n = 1 TO 10
PRINT "This will be PRINTed 10 times"
PRINT "That's it!"

This program uses a FOR...NEXT type of loop structure. Everything in between FOR and NEXT will be done 1, up until 10 times. Try experimenting with this!

What actually happens in the FOR...NEXT loop is that the variable, in this case n, starts at 1, and is then increased by 1 until it reaches 10. When n is equal to 10 then the loop stops! Simple eh?!

But what if we didn't want the variable n to increase by only 1 at a time? Well, it is actually possible to make it increase by any number we want! Let's demonstrate this by means of an example:

FOR n = 1 TO 20 STEP 2
PRINT "Another way of doing a FOR...NEXT loop"

In the above example, n is increased by 2 every loop! You could have made the STEP any number you like. Try it! Experiment! That's the best way to learn about programming!

FOR...NEXT loops are not the only kind of loops in Qbasic. There is another type too! Let's demonstrate it as an example:

number = 0
PRINT "Loop the loop!"
number = number + 1
LOOP UNTIL number = 10

As you can see, the DO...LOOP performs the loop until the variable called number is equal to 10.

What if you wanted to create a loop that would go on forever you ask? Well, it's simple to do with DO...LOOP. Try this:

PRINT "This message will go on forever!"

In the above program the message will continue to be PRINTed for as long as your computer is on, or until you push reset. In order to get out of the program, just press CTRL and BREAK together.

It's up to you whether you want to use the FOR...NEXT or DO...LOOP type of loop structures in your code, though, for certain types of programs you will find the one type of loop more useful than the other.


Until now we have only written programs that display text. However, text is rather boring, and it would be nice to know how to draw graphics eh?!

Okay, in order to use Qbasic's graphics functions we are first going to have to tell the computer which graphics mode to use. You have probably all heard of CGA, EGA, VGA and SVGA. These are all different graphics modes.

CGA is the worst of the graphics modes. It has only a few colors available for its use, and any graphics drawn in this mode will be very blocky.

EGA is a little better than CGA. The graphics will also be blocky, but at least you have 16 colors to play with, which is much better than in CGA!

VGA is the mode used by most Qbasic programmers today. It is also the newest graphics mode supported by Qbasic since it was made quite a long time ago. But don't worry, lots of Qbasic programmers, including myself, are constantly working on new functions for Qbasic, and many of these functions allow you to use graphics modes more up to date than VGA! In VGA you have 256 colors to play with. With this you can do some pretty cool graphics.

SVGA is the latest in graphics modes. It is not supported by Qbasic, although new add-on functions have been made for Qbasic which does allow you to use it. SVGA comes in many flavours. We'll discuss this screen mode at a later stage, when we have improved our programming abilities.

Okay, in order to tell the computer which screen mode to use, we use the SCREEN statement. SCREEN is followed by a number, and this number tells the computer which screen mode to use. To use CGA we type SCREEN 1. To use EGA we type SCREEN 7. To use VGA we type SCREEN 13

There are a number of other numbers that can be put after SCREEN, but the ones that I have listed above are the most commonly used ones.

Now it's time to learn our first graphics drawing function! Let's first type in some code and then we'll explain how it works afterwards...

PSET (160, 100), 14

All that this simple program does is draw a dot (known as a pixel) on the screen in yellow, in SCREEN mode 13(VGA).

It is now necessary that I explain what the term screen resolution means. Your monitor is like a grid. Every square on the grid is a place where a pixel can be drawn. In SCREEN mode 13, there are 320 blocks on the grid going across your screen, and 200 going downwards. SCREEN mode 13 is thus said to have a screen resolution of 320x200 since there are 320x200 blocks on the 'grid' in that screen mode.

In the example code above, we used the PSET statement to draw a dot on the screen. Let's say we wanted to draw a red dot on the screen 'grid' that is 10 pixels across on the grid (measured from the top left hand corner of the screen), and 100 blocks down on the 'grid'. We would use this code:

PSET (10, 100), 4

As you can see, the syntax for PSET is:

PSET (x, y), c


x is the horizontal position on the screen 'grid' measured from the top left hand corner of the screen.

y is the vertical position on the screen 'grid' measured from the top left hand corner of the screen.

c is the color of the pixel you want to draw.

This is all very good, but it would take a very long time to draw a car, for example, using PSET. Can you imagine trying to draw the whole thing one pixel at a time?! That would take all day!

I bet right now you'r thinking "Boy would it be great if there was a Qbasic statement to draw lines!" Well, guess what, there is! And it's called LINE!

LINE is used like this: let's say we wanted to draw a blue line from the PSET position (10,10) to (80,95) then all we would have to do is this:

LINE (10,10)-(80,95)

That's it! Simple eh?!

If you're still confused, take a look at Provgamer's excellent graphics tutorial, which explains these graphics commands in greater depth.

There are a lot of other Qbasic graphics commands, but this entry into the series has got far too big already! We'll cover that another time! Until next issue, experiment with all that you have learned so far! It would not be a bad idea to try make a simple game of some sort - an adventure game, pherhaps. If you make anything, and you would like others to see it, then send it to me via email and I'll include it with the next issue of QBCM!

Happy programming!


Interview with Dunric


Interviewer: Matthew River Knight

Dunric (aka Paul Allen Panks) has managed to achieve in the QB text adventure arena, what DarkDread has achieved with QB console style RPGs. His text-based Qbasic adventure game, Westfront PC, has gained acclaim not only from the QB community, but also from an international publication. Mikrobitti, the largest PC magazine in Finland, recently ran a commentary about the game. This is arguably the most mainstream publicity for a QB game since Dark Ages I - The Continents was included on the PC Gamer CD, surely marking Dunric as one of the great QB game creators of our time. It is thus with great pleasure that I bring, with this issue of QBCM, and interview with Dunric!

MRK: Tell us briefly about yourself...

PAP: I'd be happy to. :) Well, I am originally from Phoenix, Arizona (born and raised) but I now make my home in Flagstaff, a medium sized town about 150 miles to the north. I grew up with one brother, no sisters, and a few cats. Now, I live in an apartment with one cat, Sammy.

My real interest in computers began in 1983 when I saw my cousin's Commodore 64 for the first time. It was a very capable, highly impressive game machine with excellent (for the time) graphics. I must have programmed about 700 sprites on that thing!

MRK: When and where did you get your start in the QB community? What got you interested?

PAP: I didn't know about QBasic until 1994. I had just moved away from the Commodore 64 after programming the first versions of Westfront PC on it. The parser often screwed up and the game was quirky, but the overall gameplay remains the same even to this day.

I fiddled around with a 486 my father bought me for high school graduation. It had 4 MB of RAM and a really small monitor (about 13") but I was new to both IBM machines and Windows. So the adjustment was not instantenous. :)

After I discovered QBasic while checking out DOS, I began writing programs that (I thought) would translate onto this machine. Afterall, when all you've programmed were BASIC programs, it was hard not to think QBasic would be compatible.

As it turned out, I needed to rewrite several of the keywords I commonly used on the Commodore 64 like POKE, PEEK, INPUT, and this new command called LOCATE. Geez, what did this thing do? It wasn't until about 1997 that I had roughly figured out enough of the language to begin translating my works from the Commodore 64.

MRK: What do you think is your best piece of work?

PAP: I'd have to say Westfront PC, because I basically spent 6 years (from 1993 until 1999) perfecting the gameplay. True, text adventures aren't terribly exciting when compared to Duke Nukem, Quake or any of the other graphical games out there, but they provide a sense of imagination to the game player. What was true in TSR Hobbies' Dungeons and Dragons is true in Westfront PC (and other games like it). You slay the dragon and claim treasure (in this case, you complete 25 quests). I am very proud of Westfront PC.

MRK: Where do you get all your good ideas/inspiration from?

PAP: To be honest, I borrowed A LOT of my ideas from fantasy writer J.R.R. Tolkien, David Eddings, TSR Hobbies, and of course Lustymud, an LPMud which I have played since 1994. In Twilight of the Valkyries, I managed to create something a little different from my normal projects, something with a little more flare. The menu idea came from watching Final Fantasy 3 and wondering who they could save space with a more compact menu system. The little icons, I must admit, were not my idea, but the idea of my cousin, Ryan McLaughlin.

MRK: Tell us about Twilight of the Valkyries - What is it? What are your ambissions for this project? When should we expect to see it complete?

PAP: Twilight of the Valkyries is basically a small RPG Demo where you walk around and talk to people in town. You can venture outside of town, but I haven't really put that in yet. The premise is to slay the heads of 5 churches and reunite the souls of Valhalla, the land of the dead in Viking lore. You are Tyr, one of the immortal few chosen to rescue these 'souls' and bring them back to where they belong.

I honestly hope I can finish this game, but I might have to program it in C, due to the limitations of both my programming ability and QBasic. I just don't have the skills to make it what I wanted it to be, so I might start over in the coming fall with a 3-D version, complete with tunnels, traps, magic and dragons.

MRK: What are your ambitions for the future?

PAP: I'd like to be working independently with computers and technology im general. I am really very excited about the growth and use of such things like the Internet and cellular phones. I think they'll eventually merge someday. But at the same time, I am also quite scared. I don't think we have the ability to keep up with such fast moving technology, and of course there are those who may use it against society. We will probably have to set up provisions where everyone online is assigned a local 'tag', much more intense than an ISP address. A tag would track their online activities, to a constitutional acceptable limit, of course. I hope this never occurs.

MRK: What are your views on the use of libraries? Should people use them even if they dont understand the principles behind them?

PAP: I think libraries take away from the fundamentals of 'pure' programming, but if you are skilled enough to write a library, more power to you. I think, as with all things, one should use libraries when only absolutely necessary. When I see what Tsugumo did with TheGame, and I am assuming he did not use a single library, I come away highly impressed.

MRK: Would you ever consider a career in programming? If so, what field would it be in - application or entertainment?

PAP: I still think about it now and again. I'd really like to be sitting on the beaches of Tahiti fishing and eating coconuts, but that's just a pipe dream, really.

I imagine, if I did go into programming, I'd work with robotics, programming them for practical applications. It's funny, in the mid-1980's, a lot of people envisoned robotic maids and babysitters. Now that I look at what's going on around the world, only very elementary progress has been made. I think we will start to see real progress in the area of self sufficient robotic 'helpers' by the quarter mark of the 21st century.

MRK: What upcomming QB productions are you most looking forward to?

PAP: I am very much interested in Darkdread's QB RPG's. I have always been *very* impressed with his work, and the attention to detail in all of his games. Even some of his earliest works, such as Lianne...In the Dark Crown, show me a tremendous amount of ability by Darkdread to mold and craft an excellent world from which players can benefit from and enjoy.

Another RPG I am very high on is Fenix Blade. The wonderous effects used, such as the candles and highlighted SVGA-like graphics, really put an excellent environment towards the player seeking to immerse themselves into the gameplay.

MRK: Smile for the camera. Any final words?

PAP: :) My personal quote: "The only thing you can count on in life are your fingers."

MRK: Thanks for the interview!


Interview with DarkDread


Interviewer: Matthew River Knight

DarkDread has been famous in the Qmunity for almost 5 years now, and has, over the years, developed quite a cult following. He stunned the QB world with one of his first games, Legend of Lith, in 1996, and only a year later started the QB RPG craze with Lianne in the Dark Crown. More recently, DarkDread released Mysterious Song, a fantastic console style RPG, of epic proportion. I am happy to say that this month QBCM proudly brings you an interview with the angel of darkness himself...DarkDread!

MRK: Hail! Tell us briefly about yourself...

DD: Well... To be honest... I'm no good at descriptions... So I'll leave my past and my apperance up to everyone's imagination ;)

MRK: When and where did you get your start in the Qmunity? What got you interested?

DD: Late '95. I was searching for info on My Dying Bride (What else?) and decided to see if anyone else still used Qbasic... I guess you could say that I was just curious to see if there were others who shared my choice of programming language.

MRK: What do you think is your best piece of work?

DD: My latest one :)

MRK: Where do you get all your good ideas and inspiration from?

DD: Hmm... Music, other games... and just generally, whatever I think might make for a good game.

MRK: It is generally accepted that you started the Qbasic RPG craze with your RPG Lianne in the Dark Crown, back in 1997. What are your views on this? Do you think the craze is here to stay?

DD: I'm very flattered. When I created DC, I didn't think it would spark that much interest... It was just a small Qbasic game. I honestly did not think it was that special... Of course, I was happy with it... and thought it was a fun game, so I released it. As for the craze staying... I'm honestly a bit surprised that it's died down... Especially that now, RPGs are more popular than ever in North America... I suppose it just needs a really good kickstart.

MRK: It was a very unexpected surprise when you announced that LITDC is going to be completed. What made you decide to complete the game? What are your ambitions for this project? What will be new? When can we expect to see the game completed?

DD: Well... I'm still happy with some of the original ideas I came up with for the game... That, and I belive that I owe it to everyone to complete Dark Crown. Of course, it's going to be a very much different game... Think more along the lines of the 2D RPGs on the Playstation, and you'll start to get an idea of what to expect ;)

MRK: Distant Promises and Eternal Frost certainly look like they are going to be fantastic games. How are these games coming along? Will they be completed any time soon?

Distant Promises will most likely be scrapped, and re-done... Most of the original graphics, and all of Nekrophidius' music will be kept, but it will be recoded... Trust me, the code is _very_ sloppy.

As for Eternal Frost... I'm seriously considering taking that project up again now that Mysterious Song is done... I have ideas... But I'm not sure of how I wish to present them... All I can say is, that this game will transcend the boundaries of a 'game' and will be more a portal to one possible viewpoint on the frailty of life... Of course, it'll still be a game... and it'll still be fun... But the main point will be the story, and the philosophies, not the gameplay. Hence the term, 'Story RPG'.

MRK: What are your ambitions for the future?

DD: To annhiliate the console gaming world as we now know it... Unless I'm busy that day :)

MRK: A lot of people in the Qmunity still argue about the use of libraries. What are your views on the use of libraries? Should people use them even if they dont understand the principles behind them?

DD: If one is going to use the lib to improve their game, then they should. Face it, why would I write code for certain routines when someone else was kind enough to take the time to do so... and has done it much better than I could?

MRK: Would you ever consider a career in programming? If so, what field would it be in - application or entertainment?

DD: Yeah. If anything though... You'll catch me developing for Linux. I'm really getting fed up with the DOS/Win9x OS... Of course... I'll always write games. It's what I enjoy.

MRK: What upcomming QB productions are you most looking forward to?

DD: To be honest... I don't keep up with the QB Community, and I usually don't take part in what's going on with it. Having said that, I'm looking forward to a finished Kids of Karendow... Get to work Big Nose :)

MRK: Smile for the camera. Any final words?

DD: Camera? Nooooooooo!

Well... For once... I don't really have anything to say... Other than, check out Mysterious Song (http://welcome.to/DarknessEthereal) and let me know what you think... and let DeviusCreed know how you like the renders!



MRK: Thanks for the interview!


QB tips, hacks and tricks


Snooping about in the ROM

Writer: Matthew River Knight

Wouldn't it be cool if you could see the code for your ROM BIOS? Imagine all the cool things you could learn about how the computer works! ^_^ Well, it certainly is possible to do this! All you have to do is PEEK in the right places and you'll be able to retrieve the hex codes, which, by using various programs available on the internet, could then be translated into ASM.

The Technical Reference Manual for the PC/XT/AT has a complete listing of the BIOS code. It is essential for locating things and finding out how they work. But you need a lot of effort and good eyesight to use this listing. The code etched onto the ROM BIOS chip is periodically updated to correct or improve the code. Here's a way to find out when your ROM code was released for production:

'ROM BIOS release date
DEF SEG = &HF000 'Start of ROM code
PRINT "ROM BIOS Release Date: ";
FOR I = &HFFF5 TO &HFFFC 'The last few characters

Now let's try snooping around for something. Here's a fun program that illustrates how to pull information out of the ROM BIOS code:

'IBMs copyright notice in ROM
DEF SEG = &HF000 'Segment of ROM code
PRINT "IBMs copyright notice in ROM: ";
FOR I = &HE000+7 TO &HE000+21 'Copyright offsets

Exploiting the character forms in ROM

Writer: Matthew River Knight

You may have discovered that the character forms you see on the graphics monitor look somewhat different from those on the monochrome monitor. In fact, they are - the characters for the monochrome screen are formed within the monochrome/parallel printer adapter; those for the color/graphics adapter are stored in ROM starting at F000:FA6E. Furthermore, not all the characters are there on the graphics display. The extended ASCII characters (codes 128 to 255) are missing and unavailable to the graphics screen. This is a ghastly state of affairs because you can't screen dump those charcters to an ordinary dot matrix printer - you can only dump them to IBM's version of the Epson (and a few more recent printers).

However, the characters in ROM can be exploited to do fun things above and beyond their use with the color/graphics adapter, as shown in the following application. It is sometimes useful to be able to print large format letters on the printer. You may want to label a printout on its first page to identify it easily, or to print signs and displays of various types. The following program does this by exploiting the letter forms stored in ROM BIOS, which are used in conjunction with the color adapter. I apologise for the sloppy code and all the silly line numbers. I wrote this program several years ago, soon after getting Qbasic. I had not yet broken the nasty habit of coding like I had in GWBASIC.

110 INPUT "Type string: ", PSTRING$
120 GOSUB 10000
130 GOTO 110
10000 'BIGLTRS.BAS -- Subroutine to print strings of large characters on the printer
10010 'Programmed by Matthew Knight, 1995
10020 'PSTRING$ = Input string to print in big letters
10030 DEF SEG = &HF000 'ROM segment with character bytes
10040 STRT = &HFA6E 'Offset of first character
10050 BPC = 8 'Bytes per character
10060 SIZE = 132 'Character width of page
10070 CLIM = SIZE/BPC 'Character per line limit
10100 'Set up printer
10110 LPRINT CHR$(15); CHR$(27); "0" 'Compressed, 8 lines/inch
10120 WIDTH "LPT1:", SIZE
10130 FOR LN = 0 TO BPC - 1
10150 CHAR$ = MID$(PSTRING$, CHRCNT, 1) 'Extract character
10160 CHAR = ASC(CHAR$) 'Form ASCII value
10170 IF CHAR >= 128 THEN CHAR = 32: CHAR$ = " " 'No high-bits allowed
10180 BYTE0 = STRT + CHAR * BPC
10190 LNVAL = PEEK(LN + BYTE0)
10200 FOR PLACE = 0 TO BPC - 1
10210 MASK = INT(2^(7 - PLACE))
10220 IF (LNVAL AND MASK) = 0 THEN LPRINT " ";: GOTO 10240
10260 LPRINT 'Carriage return
10270 NEXT LN
10280 LPRINT CHR$(27); "@" 'Reset printer
10290 RETURN

You enter this subroutine with the printer set to where you want to print and with a line of characters in PSTRING$. Printing is set for 132 characters of compressed printing at 8 lines per inch (lines 10110 and 10120). This setting will accomodate 16 large letters. Change these parameters if you want to print larger letters or if you have wider paper and wish to accomodate a wider sheet.

If you have special settings for the printer, they must be reset after using the above program (see line 10280).

The first few lines of the subroutine give a little program to test the routine.

Auto-centering text

Writer: Fred Buffington

(Last month, in QBCM, we included a tip on centering text which only worked in a few screen modes. Fred Buffington has written a better routine which is far more versatile. Check it out! -ed)

Here is a centering routine that will work in all screen modes. You just need to send it the width to use. offset% is generally 0 for full screen width. But allows centering within a "window box" or a portion of the screen instead of the entire screen. You may for example have the screen logically divided into parts and want to center headings at the top of each part of the screen, not necessarily the center of the entire line. You could also add row% spec, then a locate before the call to this sub would not be necessary. Now this is the entire with wanted not half. For instance to center a line in (normal) text mode, wdth%=80 not 40. (but either way is fine as they are equivilent). That is, 40-20/2 is the same as (80-20)/2 Both=30.

SUB centerit (offset%, wdth%, txt$)

LOCATE ,offset% + (wdth% - LEN(txt$)) / 2 ' ' ' or \2
PRINT txt;


That's all the tips, hacks and tricks we have for ya this issue. If you know any cool QB tips, hacks, or tricks, then please share them with us by emailing them to me at horizonsqb@hotmail.com and they'll be printed in the next issue of QBCM!


Qbasic museum


They said it couldn't be done but they were wrong. Do you ever wonder who these mysterious 'theys' are? They're everywhere, they say everything, and it's usually a load of rubbish too. If there were a few less 'theys' in this world it would be a much nicer place for the rest of us, I reckon. But you know what they say about people who complain...

Contrary to popular belief, 3D graphics programs were being created in BASIC long before QuickBASIC had even been conceived of. Indeed, since the very birth of the home micro-computer in the mid 70's, BASIC programmers have been busily beavering away trying to break the barriers of the 3rd dimension.

The first real 3D game ever written in BASIC to appear in the computer world was Atari's tank battle game - BattleZone. This old Atari game might look awful, but it was stunning in 1980. Its first-person perspective was conveyed through vector graphics, with color courtesy of acetate overlays on the screen. The gameplay was basic, the controls unwieldy, but it was genuine 3D and the crowds lapped it up. Rumour has it (and still no-one's certain on this) that the US Army was so impressed by BattleZone that it contracted Atari to produce a top-secret version for training purposes. No-one's ever seen one of these Army BattleZone machines and neither Atari nor the Army will confirm or deny it, but there's plenty of evidence that this did really happen.

The BBC Micro, an old micro-computer dating back to the early 80's, was great for programming in BASIC but useless for decent games, until Elite turned up. It grabbed everyone's attention with its depiction of planets, spaceships, and space stations, rendered in wireframe 3D, with everything given a dose of reality with a hefty dollop of hidden surface removal. The 3D was fast, the action hot, the game utterly compelling, and for some reason David Braben has yet to do it better, even though the technology has moved on generations.

Pushing the 8-bit Commodore 64's BASIC to its limits, Geoff Crammond's The Sentinel did the unthinkable - it generated filled, color polygon graphics and made a game around them. The Sentinel was a great game, but speed was not its major selling point. Set on a multi-layered chess board, you moved from square to square and the act took a few seconds as the computer redrew your view. Once the view was drawn you could pan it around quickly enough, looking for trees to absorb and trying to make your way to the top of the world, and things did become frantic despite its pace. The Sentinel was a one-off and we're certain that people are still playing it today - it was utterly vast and utterly addictive.

Another 8-bit game to feature filled polygon graphics, Driller was lauded by the cognoscenti because it was an action game set in a solid 3D world. Unfortunately everyone seemed to overlook the fact that Driller was slow - as with The Sentinel, the screen took seconds to redraw, but in the case of Driller it just made the game painfully slow and tortuous to play. It was an attempt to push the limits of 3D gaming, but in the end Driller had bitten off far more than it could chew, and although the programmers managed to eke out tiny speed increases in subsequent games, the pace never got above pedestrian. Now you could play it on a speeded up Spectrum emulator...

For some totally unfathomable reason, when Microsoft launched GWBASIC, programmers suddenly felt that they had no power - it's kind of ironic if you think about it, because GWBASIC running on a 286 is far more powerful than BASIC on a Commodore. Obviously these programmers had forgotton the cool BASIC 3D games on the Commodore 64, and other such 8-bit machines. GWBASIC programmers all seemed to feel that their programming language did not have enough power to produce dynamic 3D graphics. A few rather sloppy 3D programs were uploaded onto BBS's, however, few people took much notice. One of the better 3D graphics programs ever uploaded to a GWBASIC BBS has been included with this issue of QBCM! It's SHUTTLE.BAS. This anciant program was one of the only 3D engines that anybody really took much notice of. With this release, GWBASIC programmers started to realise the potential for creating 3D graphics programs in their language.

A screenshot from the 80's GWBASIC wireframer, SHUTTLE.BAS. This primitive 3D engine was amazing when it first appeared!

Increasing numbers of programmers tried their hand at creating a 3D engine with GWBASIC. The majority of these programs ended up becoming a part of what was then a very active graphics-demo scene. A few more ambitious coders even attempted to make a 3D game. One of the best, and only, 3D games to be completed in the language was XWing by DataTech. It was a truly laughable piece of work, but it was one of the first playable 3D games to be made available. It has been included with this issue of QBCM. It's XWING.BAS.

Yep, that's definitely not one of ours. In fact, I think it's almost certainly an enemy fighter. And it's close, look, the pilot's picking his nose.

Pherhaps the most historic day in Qbasic's history as far as 3D graphics is concerned, was May 22, 1992, which saw the release of Rich Geldreich's 3DEXP1A.BAS - a fast 3D wireframe animation program. The speed of this engine was unprecedented, which resulted in its immediate rise to fame. In fact, this 3D engine has somehow managed to remain famous to this day! The engine was soon inproved, not only by Rich, but also by several other coders. One of these modified versions, 3DEXP1B.BAS, has been included with this issue of QBCM! ^_^

This 3D engine is significant in the light that it provided firm proof that Qbasic was indeed capable of fast dynamic 3D graphics. Had this program not been created, it is unlikely that the Qbasic 3D graphics arena would be where it is today.

Soon after the release of Rich's engine, other programmers managed to learn from the code, and began to produce 3D engines of their own, of ever increasing complexity. However, these engines were still all in wireframe. Having noticed an obvious gap in the arena, Rich Geldreich stunned the QB scene once again with an exceptionally fast 3D filled polygon animation engine. This historic program has been included with this issue of the mag! It's 3DPOLY.BAS.

A shot of the famous 3D filled polygon animation engine by Rich Geldreich. This historic program resulted in an increased awareness that anything is possible in Qbasic if you put your mind to it! ^_^

At last, the Qmunity had realised the awesome potential to create 3D games in Qbasic. High quality 3D engines were immediately churned out from various sources. Two of the most significant of which were probably Matt Bross and M/K Productions. One of Matt's famous 3D engines has been included with this issue - it's 3DPLASMA.BAS.

It is surprising that despite the large number of 3D engines that had entered the scene, few programmers even attempted to make a 3D game. There were a few feeble attempts here and there, however. One such attempt was the 1997 fighter jet simulator, Air Attack, by Solid Rock software. It has been included with this issue of the mag! It's FLIGHT.BAS. It wasn't such a bad game really, I mean, the gameplay was decent enough, and the graphics weren't that bad for the time, but it had terrible flicker, so nobody was able to play it for more than a minute without getting a headache.

It's hard enough shooting down a jet, let alone a bunch of colored pixels.

The 22nd of April, 1997 saw the release of Pasco's Groov Buggies - a fast wireframe car racer. This was probably the first enjoyable, and most complete 3D game that had ever been created in Qbasic. For this it will always be remembered.

Well, what can I say...some people can drive fast and others cannot. It's that simple.

More recently, the 1998/99 release of DirectQB by Angelo Mottola of Enhanced Creations, along with its 3D routines, helped bring about an unprecedented quality in Qbasic 3D engines. The 18th of December, 1998 saw the release of MA SNART(aka Darren Morris)'s Xeno engine. It was a small, extremely fast 3D engine in which you guided a little green frog around a superb textured landscape. I remember how amazed I was when I saw this program...I couldn't believe my eyes!

If you think this screenshot is amazing, you should download the actual program and see the speed at which this thing runs! It is truly remarkable!

Eric Carr, of Spinball fame, was yet another coder to do the impossible in the 3D realm, with the use of the famous 13h graphics library, DirectQB. His 3D engine, WTS-3D, was slightly better than the Xeno one, in the light that it was a little faster, and it used dynamic lighting.

37 FPS on a 225 MHZ computer is not bad at all for a Qbasic 3D engine featuring textures and dynamic lighting! Not bad at all!

Eric Carr soon decided to transcend the boundaries of an engine, and create a high quality 3D game. He optimized his WTS engine yet further, and began work on a 3D space shooter, which has yet to be completed. Check out Eric Carr's website at http://spinball.webjump.com

Here, a newer version of the WTS-3D engine is running at 66 FPS on a 225 MHZ computer. That kind of speed on such a system is amazing regardless of what programming language you've used.

Now that you have seen the past of 3D graphics programming in Qbasic, you are probably curious as to what the future holds in this area. Looking into the future is always a risky business for even the most experienced crystal gazer. Computing is one of the most risky areas - software in particular - simply because of the rate at which things are changing. A prediction made today stands a good chance of being invalidated by an unforseen development tommorow. Even if today's prediction is correct the speed of development is such that, by the time anyone reads it, it is likely to be past history! Having said this, there are identifiable areas where we do not have a clear idea about how to go about things or where we do know that there is a better way. In these areas it is usually safe to point out that a change is on its way even if the nature of the change is uncertain.

For example, it is inconceivable that SCREEN 13, as we know it, will be the used screen mode in the future. With fast, high resolution graphics libraries such as Future Library being made so readily available, it is fairly clear that SCREEN 13 will be used less frequently as time goes on. For the near future, SCREEN 13 is certainly the screen mode that will be used, mostly due to its simplicity, as it will allow programmers to grow and learn in the various fields of 3D graphics programming, before they move onto higher quality, but more complicated screen modes.

The void in the Qbasic scene for high quality 3D games is certainly likely to be filled in the near future. It is most likely that this change will occur with the release of certain various 3D graphics libraries currently under production, which will enable programmers to produce 3D games with greater ease. The 3D library currenty under production by Badjas, of Future Software, is likely to be one of the the more prominent of these libraries, if not due to the name recognition of its creator, then due to the speed at which it runs. I have seen a very early, un-optimized version of it, and it certainly ran at a decent pace. One can only imagine what speeds this library will run at once it has been optimized and converted to ASM.

I certainly hope you have enjoyed this gaze into the past of 3D in Qbasic. It certainly took me a long time to research all this, but I found it thoroughly entertaining. I hope y'all agree with me on this! I imagine that a few readers are, at this point, saying "Hey, no mention of Enhanced Creations Project RT?!" This requires some explaining. Project RT is what is known as a raytracer. It is NOT a true 3D engine. Wolfenstein and Doom are examples of raytracers, whereas Quake and Tomb Raider are examples of true 3D games. We looked at the history of Qbasic raytracers in the last issue of QBCM.

Well, until next issue, cheers!




We have a lot of games for review this issue. If you have a Qbasic program that you would like us to review, then please email me at horizonsqb@hotmail.com and tell me the URL of the website where I can get the program from. Please DO NOT email your program to me.

Game: Mysterious Song
Developer: Darkness Ethereal
Minimum system: 386, 4MB RAM
Recommended: Pentium 100, 4MB RAM
Available at:
http://www.geocities.com/TimesSquare/Ring/1686 -----------------------------------------------------------------------------------

Mysterious Song is the brainchild of the well known Darkness Ethereal programmer DarkDread, whose programming wizardry has already given us Legend of Lith, Lianne in the Dark Crown, Pong 97, and The Secret of Cooey, which some of you may remember was pretty spectacular.

Mysterious Song casts the player as Spear, a knight of the Toren kingdom. Life here in Toren follows the usual role-playing game path: major task to complete (save the world from all the baddies that have been released by some dark force or other) broken down into small quests. Starting out with poor equipment and not many spells, the first task for any visitor to Toren is to find some money with which to buy better equipment (for example, weapons, armour, and extra health potions). The next step is to gain as much combat experience as is painlessly possible so that you can get your characters advancing levels. This increases their hit points and gives you the chance to spend points improving various skills, and getting more money. Fortunately there's a fair bit of kit lying around so you don't have to keep running back to the shop for extra magic potions every time you find $50.

Here we find Spear wandering about Toren castle. These tiles are very good indeed.

Fighting is good fun. In real life it's not to be recommended, but in Mysterious Song it's one of the best things you can do. You spend your time running around a beautifully detailed landscape and then, when you come across a baddie, the action stops and becomes a turn-based affair - you decide which character is going to do what (run, attack, cast ranged magic spells, etc) and then you have a pop at each other. Hopefully you won't be killed in the process, and you can then move on to the next level.

As you'd expect, because DarkDread has a lot of experience in this field, the difficulty curve's good. The baddies get progressively harder as you move through the game, but you're still able to deal with them because you've got porkier weapons and more hit points. So unless you're making basic mistakes (like having loads of scraps without allowing your characters to recoup hit points in between) you should be able to keep your party healthy for a long time.

Bang bang, pop pop, you're dead, I'm not.

The graphics and the graphics engine are of high quality. The scrolling is pixel by pixel (although you can change this in order to make the game run faster on slower systems), the tiles have been very well drawn, and the animation of Spear as he walks along is of an exceptional standard. I was particularly impressed with the sound in the game. It consists of background music which I must admit is the best I have ever heard in a Qbasic game. Interestingly, the majority of the music was composed by DarkDread, once again serving as proof of his multiple artistic abilities.

In retrospect, Mysterious Song is very competently written, and is involving enough to keep you at it for quite some time. A great deal of attention has been paid to details, and this game is consequently as close to perfect as I have ever seen.


Game: ShellShock
Developer: Jeremy Hammond (aka Xec96)
Minimum system: 386, 4MB RAM
Recommended: 486DX4/100, 4MB RAM
Available at:

A long time ago I had an 8-bit Golden China TV games set. I had a lot of games for that machine, though one of my favourite games was a shoot 'em up called 1942. ShellShock is very much like this old game, however, it has various obvious improvements that would be expected of a game running on 32-bit machines.

ShellShock does look and play much like 1942. What can I say, it's a blast from the past!

Surprisingly, ShellShock boasts something of a storyline. The game throws you into the year 2005. There is no longer war and poverty as we see today. Everyone is happy and has a future to look forward to. To avoid future conflicts, all weapons of mass destruction were buried deep under the earth's crust, sealed off from the world above, and guarded around the clock. Over the years the weapons, and the people guarding them were forgotton. Soon the population underground soared, though their world was very much unlike the world above, ravaged by chaos and disharmony. For various feebly-contrived reasons, these underground-people managed to descover the world above and then proceeded to take it over. The player is cast as a pilot (you're getting ahead of me already, aren't you?) who must battle against these savages and bring about a return of peace and order to society.

Despite the very poor storyline, the game is actually quite good. You fly about in a vertically scrolling world, shooting up other aeroplanes, tanks, and other such anti-aircraft weapons. This is all well depicted with high quality, smooth-scrolling graphics, that do look a lot like the graphics in 1942. There is no music in the game, however there are some good, though fairly repetitive sound effects. I must admit however, that the sound effects started to give me a headache after a while, so I had to turn them off.

The game may be controlled by either the keyboard, mouse, or joystick, and they all seemed to handle the game quite well. I did find the mouse control a little erratic at times, though Xec96 did mention that he intends to fix this at a later stage.

Pherhaps one of the best things about this game is that it is so customisable. There is a command line parameter to load in different worlds, and if one wanted, it would be fairly easy to make your own vertical scrolling shooter, using this games engine. Another thing that impressed me with this game is that it has its own site, and although the game is complete, Xec96 has certainly left room for further development through the ease of which extra levels may be implemented.

Overall, I was impressed with ShellShock. The game is fast paced and exciting, and certainly worth the download.


Game: Westfront PC - The Trials of Guilder
Developer: Paul Allen Panks (aka Dunric)
Minimum system: 286, 640K RAM
Recommended: As above
Available at:
http://www.geocities.com/dunric/westfront.html ----------------------------------------------------------------------------------

I love text adventure games. I do. (I feel like an alcoholic at the beginning of an Alcoholics Anonymous meeting standing up and saying, "I am an alcoholic.") So I approached Westfront PC with much interest. I was not dissapointed. The project took 6 years to complete, and it shows. The game is utterly huge, filled with loads of puzzles that swing from being fairly easy to maddeningly difficult, tenacious monsters, and addictive in-depth gameplay lasting several hundred hours. You'll need to keep your wits about you. A relaxed blast or pixie romp this certainly isn't!

The point of the game is to complete 25 quests. Once these quests have been completed, you've won the game. These quests are posted on a bulletin board in the village guild. Each of the quests have been wonderfully realised, and at times I found myself forgeting that I was playing a game. After a while you start to build a picture of this virtual world in your mind, which is truly remarkable - always a sign of a good text adventure game. Some of these quests can be completed ahead of schedule, depending on where you are in the game. However, some quests must be completed in order for another one to work. There are a few hidden quests. Some of them are easier to find than others. Dunric did mention that there are a few programmers cheats that you might discover purely by accident, however, I have yet to actually find one of these cheats myself.

The user-interface itself is of a very high standard. The time and date is displayed at the top of the screen, along with your various statistics. This is much better than in many other text adventures I've played where you had to type a certain command to get these results, which would then dissapear as soon as new information was displayed. In addition to that, there is a very good use of color in the WFPC. Text that serves a certain purpose will always be a certain specific color, which helps a great deal when playing the game. There is nothing more frustrating in these kinds of games than when you require certain information to perform a specific act, and you have to read a whole screen of tiny text in order to get it.

Another very interesting aspect to WFPC is the save game option, and trust me, you WILL want to save your game! There is no way on earth that somebody could play the whole game in one sitting. Not a chance! There is full password support so your friends won't be able to steal your character when you aren't looking and mess up all your hours of getting so far in the game. For this Dunric is to be applauded.

I have, thus far, found WFPC to be an utterly compelling and addictive game. I say 'thus far' because I haven't even come close to finishing this game yet. It's HUGE! If text adventures are your thing, then get this game now!


Game: Shadow of Power
Developer: Master Creating
Minimum system: 486DX2/66, 8MB RAM
Recommended: Pentium 133, 8MB RAM
Available at:
http://www.master-creating.de -----------------------------------------------------------------------------------

Shadow of Power is without a doubt the best Qbasic game that has yet been created. From the intro screen right to the end of the game, it is truly remarkable in every respect. Master Creating have obviously set out to use Qbasic's full potential with this release, having finally produced a game that reaches the standards that we've been promising for years.

The game is very different to anything I've ever played before. In many ways it's an RPG, yet it also boasts many elements found only in adventure games. On the other hand, the gameplay is at times more like a straight action game. This varied gameplay is pherhaps what makes Shadow of Power better than anything else currently kicking its way around the screens of Qbasic programmers of the world. Indeed, a game such as this will please any gamer, regardless of what kind of games he likes.

SOP throws you into a fantasy world filled with a variety of monsters, devius puzzles, and traps lurking around every corner. There are a number of quests that must be solved as the game goes along, and you do start to get a little lost due to the size of the worlds. Fortunately however, a little arrow appears on the screen when you are going the wrong way, serving to direct you to the right place. For this Master Creating is to be commended.

The little chap with a hat is a twibble farmer. The twibbles are terribly cute little things. My sister really wishes she had one. I do too - you could make a fortune selling them as pets.

The graphics in SOP are truly fantastic. The engine scrolls pixel by pixel, however, unlike most of the games around today, it isn't completely tile based. In SOP you are able to walk behind trees, buildings, and other such objects, which is unlike anything that has ever been done in the language before (erm, in theory that is). Each of the levels has its own unique graphics, and it has all been drawn with a great deal of care and deliberation. Though the graphics are small, you'll never find yourself saying "Now what is that supposed to be?" A lot of the graphics isn't static either. You are likely to find yourself being very surprised when you see a man take a bite out of some food, or a little elf chopping a pile of wood - and it's all in exquisite detail.

One of the best things about the graphics in this game is the way in which lighting has been used. Apart from the usual kind of shadows you'd expect, all of the characters have a shadow following them around, which looks very cool indeed. In places where there is a fire, or a candle, it lights up the walls quite nicely which adds wonderfully to the immersiveness of the game. Without a doubt, this game rates very highly in the area of optical poptitude! ^_^

I don't care where the arrow sais I must go. I am going to go this way and there's not a damn thing you can do about it! So there!

Like the graphics, the sound and music have been integrated into the game with much care, and it is really quite remarkable. The way in which sound and vision have been synchronised makes the sound effects seem to come from that place in the screen - always a tell-tale sign of excellent sound implementation. As for reservations, I've only got one really. Our main character in the game, Holger, is rather fond of saying "Oh s**t!" This sort of thing should have been excluded.

For once I am quite willing to stick my neck out. If you download one game this month, download this one. Miss this and you should be condemned to a life of playing play-by-mail games during a postal dispute!


Game: Progue II - The Walker Chronicles
Developer: Paul Allen Panks (aka Dunric)
Minimum system: Pentium 233 MMX, 32MB RAM
Recommended: Pentium 300 MMX, 64MB RAM
Available at:
http://www.geocities.com/dunric/progue2.html ------------------------------------------------------------------------------

Right. That's it. I've had just about enough. I've been trying to like this game for three days now, and it's finally defeated me. You win, Progue II. You're cr*p. However, me being me, I'm going to tell you all about it. But first, a small plot interlude. In 1936, a French archeoligist named Stefan Ludwig entered the famous ruins of Mordum in Progue Mountain. But he was never heard from again. Ludwig carried with him a jewel encrusted sword from the anciant Egyptian dynasty of King Tut. The sword is incredibly valuable, and being the greedy little man that you are, you simply must have it! Your mission is to find the sacred "Sword of Yaskbla", and then return it to the temple in Duarenguard.

This story certainly is extremely origional, and sounds like it would make a fantastic game. It's hard to imagine how it could be possible to make a bad game out of a story this good. What a mistake that thinking was indeed, but nonetheless, it's the thing that's kept me plugging away at Progue II for as long as I have.

The graphics are all dipicted on a tiny viewport in plain ASCII text. You'd think that this would result in the game being super fast. Not so. On my Cyrix MII300 the game is terribly, terribly slow (if it's slow on such a fast system, heaven knows what it's like on anything less). You move your character one step in any direction and it takes the tiny little graphics (or should I say ASCII?) screen about two seconds to fully refresh. I mean, I know that Qbasic is slow without the use of libraries, but two seconds?! That is just plain inefficient coding. And it isn't Qbasic's fault either - we have seen plenty of games, with much higher quality, full-screen graphics playing at a hundred times that speed.

The graphics when you fight against baddies are actually quite an improvement, however, consistant quality of graphics is essential to an immersive game, and thus the higher quality battle graphics actually do more harm than good.

No, this is not a screenshot of Pacman. It's Progue II. You'd think this little graphics engine would scroll quite quickly wouldn't you? Heh, how wrong you are!

The graphics may be terrible but at least it has decent sound. The game plays one of ten possible midi's in the background, and all of them are actually quite good. It seems kind of funny that a game such as Progue II would have good sound. When I showed it to a friend of mine, he looked around the room for a hifi, thinking the sound couldn't possibly be coming from such a poor quality game.

Once you actually get into playing the game, you find that it isn't that bad. The quality of the gameplay itself is much better than a number of other console style RPGs that spring to mind. However, the graphics engine is just too painfully slow. The game may be atmospheric, but in the end it's just depressing.


Game: Void
Developer: RibbonSoft
Minimum system: 386, 640K RAM
Recommended: 486DX2/66, 640K RAM
Available at:
http://bounce.to/ribbonsoft -----------------------------------------------------------------------------------

You are in a far-off planet called Nodus. There are mystical orbs there that give the holder wealth and power. The king of Nodus once owned them but had them distributed around the land to stop an evil being from seizing their power. His name is Krylin. Now, Krylin has sent his henchman out to retrieve the orbs so he can gain control of the planet. In order to prevent this, the king began to search for someone to retrieve the orbs before Krylin could get his grubby little paws on them. And, so the game begins.

Obviously the king is not going to hire just anybody to carry out this task, so he holds a test of skill, knowledge and cunning. The player actually has to take part in this, so, if you fail this test, you'll never get to play the actual game! Once the test has been passed, you begin your adventure across the planet Nodus to retrieve all of the orbs and basically have a pretty fun time doing it! This involves scrolling around in a pixel*pixel graphics engine, and solving puzzles along the way. A great deal of these puzzles includes getting past locked doors, and such, by finding the right key. Fear not however, many of the puzzles get much more devius than this, and the vast majority of them have been very well thought out.

The graphics are of a fairly high standard, though they are no match for the graphics in, say Mysterious Song. As far as the sound dapartment is concerned, well, I wish I knew! No matter how hard I tried I just couldn't get it to work! Pretty strange considering I am using a Sound Blaster 16 sound card - if I couldn't get the sound to work, then I imagine that few other people will either.

The eye is used to view objects in your inventory. You simply drag and drop objects onto the eye, and if it see's anything of interest, it lets you know.

I found Void to be a terribly addictive game. In fact, I found Void so addictive that I almost never got this issue of QBCM completed because I was too busy playing it! No matter what kind of games you fancy, this game will be a big favourite in your collection. It is certainly worth the download!





QBCM mini game of the month

This is a competition for the best Qbasic game under 40KB ZIPed. The best game I recieve will be included with the next issue of QBCM! In order to enter this competition, simply email your game to me at horizonsqb@hotmail.com

This month's winner is William Moores, who entered his fun little tank racing game. Congratulations! This game has terrible graphics, but the scrolling is smooth, and the game itself is very addictive! Check it out! It's TANKZ.BAS.

Those of you who entered your games and didn't win, don't worry. They are automatically re-entered into the competition, so who knows, maybe your game will win next time!

QBCM website of the month

This is a new competition for the best website dedicated to Qbasic. To enter, simply email the URL of your site to me at horizonsqb@hotmail.com


Last words


Whew! What a big issue this was! And this is only the second issue of QBCM ever! This is surely a sign of things to come!

Once again, please email any articles, letters, etc to me at horizonsqb@hotmail.com Any input you can provide will be greatly appreciated.

Thanks for reading issue 2 of QB Cult Magazine! Hope ya liked it ^_^

Cya next month!

-Matthew R.Knightatt