C'est de la bombe, mes amis! This issue is going to be beaucoup cool, so..umm..don't leave or anything. And if you're wondering why French is suddently de riguere to insert into my commentary, scroll on down to the mighty letters section. Just what is it that has us up in arms with joy? Why, it's five suprakeen articles by the best in the business, baby! First up to the plate is the edicion final of Petter Holmberg's seemingly never-to-end assembly series. Next week or so, we're starting a series or "in between articles" between issues, to begin with the .doc compilation of Petter's 6 month series! woo hoo!

On top of that oh-so-tasty morsel is the 4th part of the 3d Series. This time, MA*SNART and Alias have worked together to demonstrate voxel based 3d, a series that will encompass 3 issues and show you some of the totally radical speed-ups they've worked out. Up at trois is Pete to review Interplay's "Learn to Program BASIC". Does it have an easy to use interface and super-speed to make it a must-use for qb newbies, or does it blow more than certain presedential accomplices?

Yours truly is writing about how much most of you suck at writing RPG plots ^_^. My first game was your traditional "save the prince/king/princess in the midevil world" kinda story, too. But you can do better! Would you rather be playing a game with the story of Xenogears or the story of Gauntlet? Finally, Mandrake is here to present an article for beginner's on a common way of saving memory for your program. You probably won't learn much if you're a qb god, but you haven't seen as much newbie qbasic code as I probably have, and ta'int a pretty sight.

In other unrelated information, I was looking thru the "Database o' contacts" and didja know that our *sniff sniff* magazine is read in 19 countries on 5 continents by more than 1000 people a month! Right now, I know of readers in: The Good ol' US of A, That Canada country where we buy our trees from, the Dominican Republic, England, Scotland, Germany, Holland, Switzerland, Italy, Finland, Sweden, the United Arab Emirates, Egypt, Thailand, India, Australia, China, the Phillipines and New Zealand. Are you from another country? Worship us Americans, uhh, I mean, contact me and let me know! Especially if you're from Kyrgyzstan or something.

Next on the agenda concerns the QBTimes (see the Hot List). A letter written to them suggested that the two of us "combine into a bigger, better magazine". Unfortunately, that won't happen. Here's why:

• Two Editors on one magazine! Uyyy! Wait, I can't say "uyyy" anymore.
• We both have sort of a different focus. Here at qb:tm the focus is on game development, not necessarily qb coding. That's why we have assembly, game design, exclusive info on big new games, and midi creation articles, and will have art articles, in addition to only technical articles. I believe that QBTimes is trying to present themselves much like the old Basix Fanzine, with an emphasis on technical articles.
• Finally, with their writers like Mike Hoopman and Blackbird writing along side some of our guys like Petter and 19Day, there'd be nothing but articles like "Why MazeRPG will whip DA2" or "JumP is a much better game than Project rt ever will be". ^_^

Also, mebbe it's jus' me, but some of your aren't really the most perceptive little readers, cuz a few of you didn't seem to get our April Fools joke last month. I dunno, mebbe other countries don't have April Fools, but here all the media put in little joke stories just to annoy everyone, and we felt obligated to join them! Anyways, Cuby and Coby will not be using their pincers on various enemies in the first level of the "action strategy RPG" Project RT. It was a joke. Har dee har har ^_^.

Laters!

zkman

From last issue: "Another update occured with Seav's "The Labyrinth". This "first person tile engine" (think Legend of Lith 2, but as smooth scrolling as Doom) went to v1.7 with the latest update, which added 5 groovy tilesets and a better interface. We're looking forward to the version with the guns though."

First of all, did you download the demo and read the text file? Everything is explained there.

"5...tilesets?" What do you mean? I said I have a total of 4 wall tilesets and a tileset for the Player graphics. (You can now see each other in the 3D screen)

"version with guns"? This is the version with guns. I'm adapting a laser gun style of play. You know, see who's the better shooter by racking up points shooting your laser guns so don't expect fireworks in the game. The reason for why I didn't use conventional warfare type of guns is that it's going to be a bit complicated to program in the graphics and my primary goal is to *finish* the game.

Ver1.7 is already a playable version. Go play it with your friends and see who's the better shooter!

Seav

Hmm...about the 5 tilesets, I meant to say 5. It's 4 wall plus 1 player, for a total of 5. It should've been mentioned, though, as Seav said, that this is already a playable version, although what, again, I mean by "the version with guns" was a version where you could see the guns on screen. See for yourself at Seav's site.

I don't konw anything about the WinJammer program, but from what I've heard, it's very much over-complicated for what it needs to be. My experience with the midi composer I use, NoteWorthy, has been very good. Their interface is great and the registration fee is a mere $39 (one of the few things I've actually registered).

Respect, and keep up the good work

Damon

The reason that 19Day uses WinJammer in the examples for his tutorials is that that is the program which him, myself, and most of the major qb game composers are using right now. You can probably apply the basics from the article to the composer of your choice, though.

I just read the latest issue of qb:tm. As always, it was a pleasure!

Now I wonder about some things:
1) Where can I find the homepages for those people responsible for the NES emulators you're talking about? I wanna see them!!!

2) What's the address to Pasco's page?

3) Where did you get the idea that Project rt was going to be some sort of Wetspot 3d starring Cuby+Coby? I've certainly not discussed this with him. I think we'll have to sort this out in the next issue...

4) Where can I find DarkDread's new home page? I'd sure like to see it!!!

Petter

Nothin' like hearing from one of our beloved writers, especially one who organizes his letter nice and neat for us! ^_^

Here's some answers:
1) Go to www.dragonfire.net and click on NES Emulators. DDR-NES and uNESs are done in qbasic.

2) http://members.tripod.com/Pasco_QB.

3) April Fools! Bwahaha!

4) http://www.geocities.com/TimesSquare/Ring/1683

Jay Weemhoff

Many people ask for you to send qbtm over email, and I know that wouldn't work. That's why I think you should actually make it into a magazine and send it out! People would pay for a subscription and everyone would love it! Just an idea^^!

FINAL

If you want the newsstand edition, just send a box of M+M Peanut Butter to... heheh, actually, we don't have a print edition as of now. Unfortuanately, dynamics such as money would mean I'd probably needa sell a good 5,000 copies a month to afford the die cuts, etc., needed to print. Also, .pdf and preflighting is alot more time-consuming that html, and I don't have that kind of time now. Thanks for the words of support, though!

I thank you for your time!

Patrick

As far as I know, qbasic .exe's themselves are unaffected by the Y2k bug, and you can do a quick test for yourself by setting your computer clock ahead to Jan 1, 2000 and running Wetspot 2 or something similar. Of course, as Seav pointed out, qb program's using TIMER *will* crash if you're using them on midnight 01-01-2000 due to a midnight rollover overflow.

Why a forum? Well, qb:tm is every programmer's news source. A forum will allow us to discuss ideas, thoughts, whatever gets me off my um...."booty". If you already have a forum, where is it?

Also, I love the Grand Scimitar studios slogan..."Creating Fantasy, Inspiring Reality", beautiful!

Cya~

JCCS1554

Good suggestion! The reason we don't have a forum is that I *strongly* dislike that every qb site, even brand new ones, have a "general qb" forum. No one uses them when others such as the QBoard already have many users. However, much like Dark Ages Hint Board, I think a board for discussion about qbasic news could be pretty cool, especially since qb:tm has quite a bit more than 1000 visitors a month nowadays. What does everyone else think?

And thanks for the comments on my slogan.

qbasic: the magazine reserves the right to edit any letter recieved for purposes of clarity and space. But you already knew that.

Here's the results of the Issue 7 survey from Qbasic: The Magazine! We need more people to Vote! So do it!

 Favourite Game     |  Last Month  | Change    
 1. Wetspot 2              1           <> 
 2. Dark Ages (t)          2(t)        <>
 2. Mono. Shooter (t)      2(t)        <>
 2. SFB2 (t)               --          --
 2. Of Hell & Magic (t)    --          --
   
 Comments: The best game list stays similar to
   last month's compilation. SFB2 rejoins the
   top ranks.

 Favourite Utility  |  Last Month  | Change
 1. DirectQB               1           <>
 2. QMIDI                  2           <>
 3. SpriteShop (t)         3(t)        <>
 3. Svgalib (t)            5           U2
 3. Dash (t)               --          --
 3. GifLoad (t)            --          --

 Comments: Dash makes it back into the top, and
   dqb and Qmidi continue their hold on the first
   2 positions. PP256 drops off the list.

 Best Upcoming      |  Last Month  | Change
 1. Dark Ages 2            1           <>
 2. Last...Legends         --          --
 3. Xeno (t)               --          --
 3. Peanut Patrol 2 (t)    --          --
 
 Comments: Only Dark Ages 2 survives the shakeup
   in Best Upcoming. Project RT, MOTG and TheifGame
   all fail to make the top 4. Last of the Legends
   performed very well.

Vote today by emailing your votes for:
favourite game
favourite utility
Game/utility that you're most looking forward to.
Send your vote here. We should have form-based voting by next month.

Absolute Assembly
Petter Holmberg of Enhanced Creations's assembly converter. By typing in normal asm, this proggy will convert the asm into goods that qb will understand. Super-spiffy!

Dark Ages
One of the most engaging QB games ever, as well as one of the only complete rpg's. This was featured in PC Gamer! Check it out!

Groov Buggies
The best QB racer ever. Although it has some control problems and some clipping glitches, this wireframer set a new standard.

Lianne...in the Dark Crown
Darkdread best and most complete game. Many hours of gameplay, and featuring a battle system that's been imitated in countless qb projects since. Not to mention you get cat food from the enemies!

Monospace Shooter
Gradius' 2 color side-scrolling space shooter. Featuring very detailed enemies, flickerless animation and a devious AI, this game is a classic

Wetspot & Wetspot 2
Wetspot, the bubble-bobble like block-pushing action game was one of the best QB games when it came out, but W2 is just incredible. Super midi sound, great fast graphics, tons of variety, an insane number of levels...everything you could want. GET this game. Now.

SFB2
The BEST qbasic fighter. Ever. Even though it's wireframe, it has cool particles and smooth animation as well as rippin' gameplay.

PP256
Called the best tile editor in QB ever, PP256 has loads of tile-editing options at your disposal. If you use tiles in your game, you can't live without this.

DirectQB/DashX/Blast!
These 3 sets of libraries take QB graphics to the extreme. They all have strenghts and weaknesses, but you should check them all out before you start a big project. You'll save a lot of coding plus get a big speed increase (and in DQB's case, save memory). Try these now.

QMIDI4.1
This is the best version of Qmidi. Play .mid's in your game! The new qmidi4.1 rules! It has tons of features and a "light" version. Get it now!

Pb3d
Marko Dokic's 3d routines. Phong shading, gourard shading, environment mapping, you name it- it's here. If you want to see how to do good 3d, come here!

Hello and welcome to the sixth part of my assembly tutorial series. This part is also the very last one. No!!! I hear you screaming ;-) But the reason for this is basically that I have covered almost all of the important aspects of assembly programming. There's more to learn- there's always more to learn, but I think you'll have more use of other documents from now on. This series has been concentrating on the general aspects of asm programming. Now you are ready to start exploring stuff that interests you in particular. Maybe you want to learn more about interrupts, or you may be interested only in I/O port programming. There are lots of good documents to download about every aspect of assembly programming. It's not necessary for me to explain everything.

So, what should this last part be about? For the first time in this series, it hasn't been easy for me to decide. Therefore, this part will cover some miscellaneous stuff, mostly about some of the general aspects of assembly programming. I'll try to share my experiences of asm programming with you so you don't have to all the mistakes I've done.

Numbers in assembler:
When programming in assembler, it's very important to know how numbers are stored in the registers, the stack and the memory. It's especially important to know the difference between positive and negative numbers and how they are stored.

We begin by looking at positive integer values, i.e. the numbers 0,1,2,..,n: Positive integer values are the easiest ones to store. When you need to use a positive integer value in your asm code, the first thing you want to ask is: How high numbers do I need to store? It's easy to select the number of bits that needs to be used for storing a certain value. If you use n bits, the biggest number that can be stored is 2^n - 1, so if you use 8 bits, you can store any number from 0 up to 2^8 - 1 = 255. With 16 bits you can store any number up to 65535 and so forth. If you only need to use a number smaller than 100, you shouldn't use 16 bits to store it as 8 bits are enough.

The different bits in a binary number are numbered from right to left. The rightmost bit is called the least significant bit and it has the bit number 0. The leftmost bit is called the most significant bit. If it's an 8-bit numbered this bit is bit no. 7.

If you want to calculate what number you get if you set a certain bit to 1, you can calculate this with the following formula:

n = 2^b

where n is the number you want to know and b is the number of the bit. So if you set bit 5 to one, the number you get is 2^5 = 32.

Numbers that can only be positive are called unsigned values. A signed value is a value that can be both positive and negative. It's called signed numbers because the most significant bit of such numbers tell the sign of the number. If we have a positive value, the most significant bit is 0, but if we have a negative value, the most significant bit is 1. So 0 means + and 1 means -. This means that a signed number needs one extra bit just to store the sign of the number, so we get a lower maximum value with a certain amount of bits if we use signed numbers than an unsigned number. The biggest signed number that can be stored with n bits is 2^(n-1) - 1. So if we have an 8-bit signed number, it can have the maximum value of 2^(8-1) - 1 = 127.

The smallest signed number that can be stored with n bits is -(2^(n-1)), so with 8 bits, you can store any negative integer down to -(2^(8-1)) = -128. Thus, an 8-bit signed number can store all interger values from -128 to 127. Positive values are stored in the same way no matter if the number is signed or unsigned, but negative values are stored in an interesting form: The most significant bit is set to 1 to indicate it's a negative number, and the rest of the bits represents the maximum possible value with those bits plus one minus the absolute value of the negative number plus one. So if you have the 8-bit binary number -10, the most significant bit will be a 1 to indicate it's a negative number, and the rest of the bits will represent the number 127 + 1 - 10 = 118. This form of storing positive and negative numbers is called the two's complement.

If you want to convert a number from positive to negative or negative to positive, you could use the SUB instruction to subtract a value from 0, like this:

SUB AX, 0

This would work fine for all numbers. But you could also use the special assembly instruction NEG. NEG works just in the same way, but it's faster, takes less place in the memory and it's easier to understand what happens when you see a NEG instruction than if you see a SUB instruction. The syntax for NEG is simply:

NEG destination

The destination operand can be either a register or a memory pointer. So if you have the number -10 in AL and execute the instruction NEG AL, AL will become 10.

Sometimes it's necessary to convert an 8-bit number to a 16-bit number or a 16-bit number to a 32-bit number. This is easy if you have a positive number. For example: If you have a positive integer in AL and you want that number to be treated as a 16-bit value in AX, you only need to make sure AH is 0. But what about negative numbers then? How do you convert a number in the two's complement form upwards? Luckily, there are two instructions that does this for you. They're called CBW and CWD, short for Convert Byte to Word and Convert Word to Doubleword. Their syntaxes are:

CBW
CWD

Note that they don't have any input/output operands. That's because these instructions only works with the AX register. If you have an 8-bit number that you want to convert to a 16-bit number, you should put it in AL, execute a CBW instruction, and you'll get the correct 16-bit value in AX, no matter if it's a positive or a negative integer you've converted.

If you want to convert a 16-bit value to 32 bits, you should put it in AX and execute a CWD instruction. The result will be stored in DX:AX.

When to create an assembly routine and how to do it:
A little assembly code can often mean a huge improvement for a BASIC program. However, it's important to know when to use it and when to avoid it. There's no use to rewrite everything in assembler. There are two reasons you may have to write an assembly routine: It will speed up your program, or it will enable you to do something that you cannot do in QuickBASIC.

The speed issue is the most common reason for using assembly code. It's a well known fact that in an average program, 90% of the execution time is used to execute 10% of the code. By rewriting those 10% of the code into assembler, 90% of the time, your program will run faster. It's important to learn how to find those 10% of source code. Usually, it's something that is repeatedly called by the main program loop and involves a lot of calculations. If you manage to pinpoint the part of your program that slows it down the most, you should consider rewriting it in assembler.

It's also a good idea to use assembler when you need to do something that is hard to handle in QuickBASIC. One example of this was the keyboard handling example in the previous part of this series. The keyboard functions in QuickBASIC doesn't let you control the keyboard at the level we often need for computer games, but with a little assembly, we get all the control we want.

When you know what you want to rewrite in assembler, you may think it's going to be easy to implement your idea into a working routine, but you may be surprised at how hard it is to write the routine. Transforming your ideas directly to assembler can be very hard because you have to take so many technical issues into account. You may find that you run out of registers, that you start writing really unstructured code or that you simply don't know how to do some things in assembly.

My experience in assembly programming has told me that the best way to go is this:
First, start writing your routine in BASIC. This way, you'll be sure that you know every step in the process of writing the routine, and you don't have to mind about registers and other low-level stuff.
Then, start optimizing your code. Try to push your BASIC code to its limits. Even if the code still is terribly slow, you will discover how you can make it faster and better. If you wrote everything in assembler from the beginning, you probably would have missed these enhancements. Put comments everywhere in your source code so that you know what each line does.
When you have an optimized BASIC version, start rewriting it in assembler. You shouldn't try to make the final version right from the beginning though. Start by writing a pseudo-version, where you use variable names instead of registers and skip some low-level stuff like setting the memory registers correctly when you want to get a number from the memory. Make your assembly code similar to the BASIC version, so that you know exactly what you're doing. Put LOTS of comments into the code so that you know what every line does.

When you have your pseudo-version finished, start transforming it into a working version. Change variable names into registers, use the correct code to get a number from the memory and so forth. Put in even more comments, as the code will get harder to understand. The commenting should be so extensive that you can tell what each line of assembly code does just from looking at the comments. Divide the source into separate parts by using spacing and commenting, so that you can isolate the different parts of the routine just by looking at the layout of the source code. Even if you know what you're doing right now, you may have forgotten it after a few days. Looking at your own asm source without understanding it is really frustrating. DO NOT try to optimize your assembly code yet, try to make it work first. You will probably have a lot of bugs when you first run your routine, and you must fix them all before continuing.

Now when you have a working assembly routine, you may want to try optimizing it even further by using smart assembly code. This should be the final step in the creation of your routine. If you start optimizing right away, you're risking to lose control over your coding, but if you have a working routine without optimizations to look back on, you will still know what you're doing and you know that your routine works even if you don't manage to optimize it so much.

Make sure your comments still explains what the routine does. Your optimized code will be harder to understand than the original version, so you need to watch out.

If you follow these steps, you stand a good chance of getting a really well- written and terribly fast assembly routine!

Optimizing your assembly code:
It's one thing to optimize a BASIC program by using assembly code, but you can also optimize your assembly code to gain even more speed.

Optimizing assembly code is a whole science itself, and I could probably write another tutorial series as long as this one just about asm optimization if I knew enough about it. There's so much to say about assembly optimization that I can only cover some of the basics here.
When optimizing an assembly routine, it's not enough to just make the separate instructions run faster by using smarter code. Many times you also need to look at the code as a whole and ask yourself what the code's actually doing. Your code may run at an near-optimal speed based on what it does, but maybe it's doing more than it has to. For example, you may have a routine that has a very time-consuming MUL instruction inside of a loop. You manage to make it run a lot faster by using a SHL instruction instead, and you think you've been very clever. But if you had taken another look, you might have discovered that you're actually doing the same multiplication over and over, and it would have been enough to do it once before the loop and save the result in a register for later use. By moving the MUL instruction above the loop you would probably have gained much more than by changing it to a SHL instruction.

Keep in mind though, that because your assembly code is so fast from the beginning compared to BASIC code, it's often unnecessary to mind about optimizing it. If your routine runs adequately fast for your program, it's better to leave it unoptimized since it's more readable that way. But it can also be really important to optimize your assembly code because it runs so often. Concentrate on optimizing loops and other assembly code that runs frequently. If you don't have room for all your variables within the registers, use the stack or the memory for the values you use the least, and save the free registers for the code inside loops.

Switching Registers:
Sometimes you need to exchange the values of two registers. If you only use MOV to exchange them, you will need a free register for temporary storage of one of the values. For example, if we have one value in AX and one value in BX and we want them to switch places, we could do this:

MOV CX, AX ; Store value of AX temporarily in CX
MOV AX, BX ; AX = BX
MOV BX, CX ; BX = CX (which is the old value of AX)

If you need to do this and you have no free register, the only solution seems to be to push a value to free a register, but there's a better way. You can use the instruction XCHG, short for eXCHanGe, to do it. The syntax for XCHG is:

XCHG destination, source

Where the source and destination operands can be registers or memory pointers. However, the source and the destination cannot both be memory pointers at the same time. With XCHG you won't need a temporary register, and thus the stack doesn't need to be used either.

Remove your jumps!
Another way to make your code faster is to avoid jumps in the code. This includes loops. Let's suppose you want to increase the AL register four times. The following solution seems obvious:

MOV CL, 4
IncLoop:
INC AL
LOOP IncLoop

But what's actually happening when the computer executes this code? Well, this is how the computer sees it:

Set CL to 4
Increase AL
Decrease CL
Is CL 0? No: Jump back one line
Increase AL
Decrease CL
Is CL 0? No: Jump back one line
Increase AL
Decrease CL
Is CL 0? No: Jump back one line
Increase AL
Decrease CL
Is CL 0? Yes: Continue execution

Now suppose that we rewrote the code into this:

INC AL
INC AL
INC AL
INC AL

When this code is executed, this is what the computer does:

Increase AL
Increase AL
Increase AL
Increase AL

As you can see, a loop isn't always the best choice. Replacing loops with repeated code is called unrolling. If the loop is executed so many times that it's not practical to unroll it completely, you can do a partial unrolling. For example, if you have a loop that executes 80 times, you can change it to a loop that executes 10 times with 8 copies of the loop code inside it.

It's not only certain instructions that makes an assembly routine slow: Wait states, bus transfers, the prefetch queue and dynamic RAM refreshes can also steal time, and avoiding these bad guys can be really hard.

For every new CPU that's released, assembly optimization becomes less important, not only because the processors get faster and faster, but also because they execute time consuming assembly instructions more efficiently. A MUL instruction for example, isn't as slow compared to an ADD instruction in a Pentium as it was on the 80286. On the other hand, the Pentium can execute several assembly instructions simultaneously if they fulfill certain requirements, so it's possible to optimize asm code for a Pentium by using these new features.

Finding errors:
One of the biggest pains of writing assembly code is to find and eliminate the bugs. Once you're done writing an assembly routine and tests it for the first time, it almost never works properly. Since the error often hangs your computer so that you have to restart it, you'll probably get no hint at where the error is. All there is to do is to start going through your code and search for bugs. This can be very hard and time-consuming. Here are a few ways to make the debugging easier:

First of all, "execute" the code in your head and try to see what the routine is actually doing. Write it down on paper and you may discover that you're doing something wrong.

If you still have problems finding the errors, try to execute only a part of your program. Take the first snippet of code, insert a JMP to the end of the routine and return the values that you're working with to the BASIC program so you can look at them and see if they're correct so far. Then, move down the JMP instruction a couple of lines and see if everything still is correct. If you continue doing this, you will eventually find out where the computer hangs and where the error is.

Keep in mind that some assembly instructions doesn't work with certain combinations of registers, memory pointers and direct values. if DEBUG won't accept an instruction that may seem correct, it may be because you're using a combination of input/output values that cannot be handled by that instruction.

Also, make sure the call to and return from the assembly routine is done correctly. Many times, I've struggled to find the errors in completely correct assembly code that won't run, just to find out that the error was in the CALL ABSOLUTE line in QuickBASIC. Check this before you start searching for errors in the assembly code.

There's an error in CALL ABSOLUTE assembly routines that's so common it's important that you know about it. It's very nasty because you don't have to write a single line incorrectly to get this error. It has to do with the DS register. Be VERY careful when you set the DS register. You already know that it's important to push the value of DS before you change it and POP it back at the end of your program, but there's another thing you have to know about DS. When you set it to another value than the original you won't be able to fetch values passed from QuickBASIC. Consider the following code snippet:

PUSH DS ; Preserve DS
MOV BX, A000 ; Set DS to A000h
MOV DS, BX
MOV AX, [BP+08] ; Get a variable from QB
POP DS ; Restore DS

Even if this seems correct, AX won't get the value of a QB variable. The value it will recieve is the value at DS:BP+8, which isn't the correct address. You must make sure DS points to the segment address it points to from the beginning if you want to read from or write to QB variables.

Doing nothing:
If you feel an urge to do nothing for a while, the assembly language has an instruction just for that: NOP. The NOP instruction takes up one byte in the memory, and when it's executed... Well, nothing happens at all! The syntax for NOP is:

NOP

Even though it doesn't do anything, it takes up a little amount of time. Actually, NOP is equivalent to XCHG AL, AL, which, of course, doesn't change anyhing.

It may seem silly to have such an instruction in the assembly language, but there's actually some use for it sometimes, for example if you want to leave some empty space in a program for data to be initialized later on. The NOP instruction occupies one byte in the memory.

And that was the final thing I had to say. I hope you've enjoyed this tutorial series and that you've managed to understand everything. Thanks to everyone who's sent me emails with comments on and suggestions for this series. If you want to learn more about assembly programming, there's LOTS of good info to find on the Internet. For example, Check out:

http://cs.smith.edu/~thiebaut/ArtOfAssembly/ArtofAsm.html

I thought I could finish with a list of all the assembly instructions we've covered in this series. This list divides them into groups based on what they do and explains their different functions. Try to tell what they mean before looking at the explanations and see if you know them all!

Good luck with your assembly programming!

List of assembly instructions:

Name       Meaning Data transfer: MOV       Copy values between registers and the memory PUSH      Put values on the stack POP       Get values from the stack LODS      Load string STOS      Store string MOVS      Move string IN        Read values from I/O ports OUT       Write values to I/O ports NOP       Do nothing Jumps: CALL      Call subroutine RET       Return from subroutine RETF      Return from subroutine in another segment JMP       Jump to another offset address LOOP      Perform a loop INT       Call interrupt routine IRET      Return from interrupt routine Conditional: CMP       Compare two values TEST      Compare two values JB        Jump if Below JBE       Jump if Below or Equal JE        Jump if Equal JAE       Jump if Above or Equal JA        Jump if Above JL        Jump if Less (signed) JLE       Jump if Less or Equal (signed) JGE       Jump if Greater or Equal (signed) JG        Jump if Greater (signed) JNB       Jump if Not Below JNBE      Jump if Not Below or Equal JNE        Jump if Not Equal JNAE      Jump if Not Above or Equal JNA       Jump if Not Above JNL       Jump if Not Less (signed) JNLE      Jump if Not Less or Equal (signed) JNGE      Jump if Not Greater or Equal (signed) JNG       Jump if Not Greater (signed) Data manipulation: ADD       Add two values together SUB       Subtract value from another INC       Increase value by one DEC       Decrease value by one MUL       Multiply to values together (unsigned) IMUL      Multiply to values together (signed) DIV       Divide value by another (unsigned) IDIV      Divide value by another (unsigned) NEG       Negate value (invert its sign) SHL       Shift bits to the left (unsigned) SHR       Shift bits to the right (unsigned) SAL       Shift bits to the left (signed) SAR       Shift bits to the right (signed) ROL       Rotate bits to the left ROR       Rotate bits to the right AND       Logical AND (1 if both bits are 1) OR        Logical OR (1 if one or both bits are 1) XOR       Logical XOR (1 if one bit is 1 and one bit is 0) NOT       Logical NOT (invert bit) CBW       Convert byte value to word value (signed) CWD       Convert word value to doubleword value (signed)

Tell Petter that Norwegians give better massages than Swedes at this address.

This month in the gallery is "Killerz" by Nekrophidius. Although early in dev, it looks pretty freakin' cool, dontcha think?

In Ma Snart's 3D articles, he describes many methods of making 3D polygons, textures, and such, the things that can be accelerated with 3D cards. There are many ways of drawing 3D objects, and thankfully, they are not all polygons. The one I am going to talk about in this series is the voxel method. Ma Snart mentioned these vaguely, saying he preferred them, but he's not planning on covering them, so I will.

 
A voxel is hard to describe, but I have one analogy that may work: in 2D space (screen space) we have PIXELS which are approximations of area. They are square, arranged in a grid, and can be set to any color possible.

A voxel, on the other hand, is an approximation of volume, in 3D space. They are arranged in 3D grids (more on this later) and can be set to any color OR transparent. This way, we can make a volume-based drawing of an object, as opposed to recreating the surface of the object, as we do with polygons.

The big analogy here is the 3D / 2D counterparts. For example, a cube is the 3D counterpart of a square, a line is the 2D counterpart of a plane, a sphere is the 3D counterpart of a circle, and a pixel is a 2D counterpart to a voxel.

Now we can really get into voxels. As I said, a voxel is an approximation of volume. The most effective way to simulate a volume is with a cube-shaped volume. This way, when your 3D grid is drawn, there are no gaps. However, drawing a cube is horribly slow, and drawing enough of them to simulate a small item would bring any Cray XMP to its knees, let alone actual PCs! So, we have to fudge a little. We cannot draw a full cube, but on any of the 6 sides of a cube, it looks just like a square. So, where there should be a cube, we will draw a square that is large enough to completely cover the visual area a cube would cover. With that in place, we can draw a voxel knowing that it will look alright, and that there will be no gaps between pixels.

By the way, if your voxels are too small you will get gaps between them, which are quite visible - and very ugly. If you experience gaps, increase the size of your voxels one or two, and see if that makes a difference. I have seen many people try to do just points for their voxels - it doesn't work. You have to use squares larger than one pixel, typically 3-5 pixels wide. Another good idea is to pick odd numbers for sizes, that way, the voxels will be evenly centered, instead of being biased half a pixel in one direction. Biasing is a serious problem, especially in small maps, as two adjacent voxels may go in opposite directions and leave an empty spot, or gap. As I cannot possibly emphasize enough, GAPS ARE BAD.

Last year, Scott Mathews, Executive Producer of Presage Software came up with an idea. The idea wasn't to make the next full-length epic RPG or an action-packed first person shoot 'em up game. The idea hadn't been tried since the early 90's, in the world of 386's and Windows 3.1 . He planned to re-introduce BASIC to generation-X teenagers so that they could make their own games, be it a full-length epic RPG or an action-packed first person shoot 'em up game.

 
Mr. Mathews took his idea to Interplay, creator of games like Baldur's Gate, Redneck Rampage and Fallout 2, and told Brian Fargo, CEO of Interplay, of his plan. Brian approved, and soon, a team of programmers began to convert the non user friendly BASIC of the early 80's to an error-trapping, spiffed up and gutted-out BASIC of the 90's. They called it "Learn to Program: BASIC", and it was on store shelves within months.

This is where I come in. One day, while reading one of my sister's educational software order forms for school, I spotted a CD-ROM with the word "BASIC" written in huge letters on the side. The Scholastic book company does a horrible job describing their book order items, so I figured that the only way to investigate further would be to actually buy the CD.

Six to eight weeks later, my sister came home with a pile of Babysitter's Club books and Oregon Trail games, and handed the LTP: BASIC box over to me. I opened it up, finding a couple warranty papers, a manuel and a workbook, and of course, the CD. I popped it into my CD-ROM drive and was on my way...to a world of "Game making made easy!"

Learn to Program: BASIC is a BASIC interpreter that takes BASIC programming to a new level. It is also a teaching aid that teaches you how to program in LTP: BASIC. It makes it user friendly, easier to learn and use, and is thoroughly documented to make it so that you will have absolutely no problems looking up help on a command or subject.

 
Backstory
We'll be blunt: "You're a fantasy prince on a mission to rescue a princess/brother/father" doesn't cut it anymore. Influences such as Advanced Dungeons and Dragons and the Ultima series seem to have made people think that an RPG means swords, taverns, and orcs. While not the worst possible story we can think of, generic fantasy is too often predictable, is overused, and (ask many veteran programmers) will often leave you too bored to finish your project.

Since the halycon days of computer design, great strides have been made on story design both on computer and on pencil and paper roleplaying. Instead of making a generic fantasy RPG, try looking at some of today's popular Roleplaying games for influence. What about Cyberpunk, where a form of the internet is more dangerous than weapons; or Fallout, where pimps and fantastic characters populate a post-apocalyptic scene; or Homeworld, where you are the last member of a spacefaring race trying to find it's home. Besides offering greater events and chances for character growth, these stories will seem more interesting to players of your game.

Instead of going sci-fi or generic fantasy, try looking at historical literature for rpg story ideas. How about a game set in renassaince era Italy, with ruling families, and lots of seafaring? Or what about a game where you play a pirate running from British galleons whilst trying to "salvage" some booty from passing mercantile ships? Possibly being an American GI on a mission to assassinate Hitler in 1944 could be interesting? Maybe the Salem Witch trials, Imperial Japan and China, or Ancient Babylon are more along your lines. There are infinitisimal different backgrounds to use for your game; don't limit yourself to "Orcs and Trolls" fantasy

Of course, if you really want fantasy, a background like Shadowrun's, where elves jack into networks, and cyborgs battle dragons could be more along your lines.

Events
Events are the things that people will remember about your game years after they play it. They won't remember drinking beer at a tavern with Gehenna, but they might remember when a high-level NPC sacrifices himself muttering that "he will return...much stronger". They won't remember that they got 4032 gold in Dungeon 6B, but they might recall a Player Character dying, such as Aeris in FF7.

The things to remember when thinking up "events" are: Death, Explosions, and "Boss Fights". Many classic books feature one of the main character's dying, because this is something that will strike a player's heart. It's not enough just to have the character be struck down by an orc, though. Having a character sacrifice themselves, or die at the hands of an enemy who will reappear later in your game will inspire your character to keep playing. In non-fantasy settings, exploding something such as the main enemy's weapon, or having the enemy destroy the character's hometown, will have the same effect.

Remember that blindly fighting battle after battle can be tedious. Be sure that events are fairly frequent in your game, and the player will continue and enjoy it more.

Character Interaction
There are three main parts of character interaction to keep in mind: PC to PC, PC to NPC and PC to enemy. And by character interaction, I don't mean "Hello, MATT. Go left to my castle!". Watch some of your favourite movies or read some of your favourite books and see the qualities that occur between the characters. Is there a love interest between two of the main characters? Does the villain taunt the hero? You can apply all of these to RPG's.

Player Character to Player Character interaction is fairly important, as theoretically, a group of players will remain together throughout the entire game. After events, perhaps their "friendship" towards each other will grow better or more hostile. Maybe 2 of the characters will grow a dislike of each other and you have to sort it out. Perhaps one of your PC's will become depressed and it's up to you to cheer him up and keep him fighting. In a game featuring only one main character (such as Zelda), PC to NPC fills the void left by the non-interaction the main character will have with other PC's.

Love between two main characters has occured in nearly all famous literature and cinema because it adds more realism and depth to the monotonous enemy fighting. Many popular video games have drawn on this fountain, such as games in the Final Fantasy series, and even Super Mario Brothers, and you should definitely keep it in mind when designing your characters.

PC to Enemy Interaction is the final thing that we'll talk about. First, you should write down some words to describe your enemy. Is he an enigma to the PC's, well-known in the world, or does the main character know him as a childhood friend? The main enemy and his cohorts should appear regularly throughout the game and should have a well-defined mission that the characters will discover. Riddle Games and taunting are also effective gameplay and storyline elements.

Hopefully after reading this document, you guys' will be able to see the ways to create interesting and original Roleplaying storylines. And remember, Generic Fantasy sucks!

Do you wish there were no RPG's and all of us wrote Pong clones? Lemme know.