Horizons
Interactive Entertainment
proudly
presents
Issue 2 -
April 2000
Editor:
Matthew R.Knight
Email: horizonsqb@hotmail.com
QBCM is
available at the following websites:
http://alienqb.cjb.net
http://www.aurskogcity.8m.com
http://www.neozones.com/geoshock
http://neozones.tekscode.com
http://qbversions.cjb.net
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!
Contents
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
Foreword
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
I
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.
-Ambiance
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.
-DarkDread
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:
QB
You must instead type:
QB/L
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!!!!!!!!!!
-Cody
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! ^_^
News
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:
FUNCTION
MyABS (Number%)
IF
Number% < 0 THEN Number% = Number% * -1
END
FUNCTION
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:
1. PSET
2. LINE, CIRCLE
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...
SCREEN
13 : CLS
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:
ASSIGNMENTS:
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:
SCREEN
13: CLS
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
NEXT y
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!!!
Provgamer...
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.
Key%=9
Char$="A"
NewChar$=CHR$(ASC(Char$)+Key%)
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)AaY...^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:
CALL
ABSOLUTE(BYVAL DSeg%, BYVAL DOff%, BYVAL VARSEG(Sprite%(0)),
BYVAL X%, BYVAL Y%, SADD(asmput$))
where:
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.
PUSH BP
MOV BP, SP
MOV BX,
[BP+0C];Get the segment address of the sprite array.
MOV DS, BX
XOR SI, SI ;Set SI to 0.
MOV BX, [BP+10]
;ES = screen buffer segment.
MOV ES, BX
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.
SHL AX, CL
MOV CL, 6 ;Multiply y with 64.
SHL BX, CL
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.
SHR AX, CL
MOV BX, AX ;Store the width in BX.
LODSW ;Store the height in AH.
MOV AH, AL
MOV DX, 140 ;DX =
320 - sprite width.
SUB DX, BX
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.
POP DS
RETF A
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$))
where:
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.
PUSH BP
MOV BP, SP
MOV BX,
[BP+10];Get the segment address of the sprite array.
MOV ES, BX
XOR DI, DI ;Set DI to 0.
MOV BX, [BP+14]
;DS = screen buffer segment.
MOV DS, BX
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.
SHL AX, CL
MOV CL, 6 ;Multiply y1 with 64.
SHL BX, CL
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
SUB BX, [BP+0E]
INC BX
MOV AX, BX ;Copy BX(sprite width) into AX.
MOV CL, 3 ;Multiply width by 8.
SHL AX, CL
STOSW ;Copy (width * 8) to the sprite array.
MOV AX, [BP+08]
;Get the height of the sprite - (y2-y1)+1
SUB AX, [BP+0C]
INC AX
STOSW ;Copy height to the sprite array.
MOV DX, 140 ;DX =
320 - width.
SUB DX, BX
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.
POP DS
RETF E
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.
CLS
COLOR 1
INPUT "Enter your 1st number:", n
INPUT "Enter your 2nd number:", n2
product = n * n2 'Multiply the two numbers together.
COLOR 12
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
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"
NEXT
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"
NEXT
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
DO
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:
DO
PRINT "This message will go on forever!"
LOOP
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.
Graphics:
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...
SCREEN 13
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:
SCREEN 13
PSET (10, 100), 4
As you can
see, the syntax for PSET is:
PSET (x, y), c
where:
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:
SCREEN 13
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!
Cheers!
DarkDread
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
PRINT CHR$(PEEK(I));
NEXT I
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
PRINT CHR$(PEEK(I));
NEXT
----------------------------------------------------
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.
100 TEST
BIGLTRS
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
10080 IF LEN(PSTRING$) > CLIM THEN PSTRING$ = LEFT$(PSTRING$,
CLIM)
10090 LIM = LEN(PSTRING$)
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
10140 FOR CHRCNT = 1 TO LIM
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
10230 LPRINT CHAR$;
10240 NEXT PLACE
10250 NEXT CHRCNT
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;
END SUB
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!
Reviews
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.
QBCM VERDICT: 90%
-----------------------------------------------------------------------------------
Game: ShellShock
Developer: Jeremy Hammond (aka Xec96)
Minimum system: 386, 4MB RAM
Recommended: 486DX4/100, 4MB RAM
Available at: http://shellshock@hulla-balloo.com
-----------------------------------------------------------------------------------
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.
QBCM VERDICT: 78%
----------------------------------------------------------------------------------
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!
QBCM VERDICT: 100%
-----------------------------------------------------------------------------------
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!
QBCM VERDICT: 100%
------------------------------------------------------------------------------
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.
QBCM VERDICT: 25%
-----------------------------------------------------------------------------------
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 VERDICT: 82%
Competitions
------------------------------------------
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