Ayayayayayaya! Summer approaches fast, flooding the ground with sunlight and warmth; but more importantly, giving QB Proggers more time home from school (or work vacation) to code inside! Summer is traditionally the boom-time for qbasic coding projects, and the non-paucity on the Hot List this month shows that not only is QB booming in quantity this time of year, but also in quality. Unfortunately, due to a vacation and some external circumstances, there will be no July issue. In August, though, we'll be back, and there will be in-between articles (probably 4 or more) in the meantime! Sorry!

To help you kick off this time of year, we've presented what we hope you guys will think of as one of the premiere issues so far. Gavan has gone the distance again this month with an excellently documented second part of his art tut, showing some advanced tile techniques for more realism and "3d" look. Alias is back with another part of the highly-read voxel tut, gettin' down into the code this month. Bill McDonald, the coder of Spacewar, among others, has got you guys a great MOD tut, for those wishin' to write a MOD player. Nekrophidius, on the teams for WoS, Kalderan and many others, has an article on the SBS File Format, to start off a new series called "Tip o' the Month".

Finally, I've got another RPG Design tut; this time, instead of focusing on story, we move onto battle engines, citing all the great reasons why copying DarkDread's engine is not the best idea for writing an RPG =). A few other changes in the content of the mag this month; first of all, the cgi Poll voting is *almost* finished, and, kill me if this doesn't happen, will be up next month. Also, the Must Downloads, a 7 month-old and getting-stagnant feature, has been overhauled, and will now (we hope) enthral interest more than it has in the past.

If you missed it, we've had a couple of specials put up during the last month. Firstly, there's an article on Debugging by me, and QBProgger and me teamed up to review the Adventures, a game from TMB Productions. Next month's specials will probably include something on QB4.0 vs. QB4.5, among others.

Finally, in our continuing quest to find where our readers are from, it was discovered that we have a reader in the Northern Mariana Islands, bringing the total to 22 countries on 5 continents. Qbasic truly is a universal language...

Ciao,

zkman

Hi, my name is Logan Hoehn, but I go by Mastermin on the net. First off, I'd like to say that I enjoy your magazine very much, and is far better than anything else on the net. I check your page frequently for new issues. I also like the between issue special articles, but I feel you may have rushed the latest one [on debugging].

Don't get me wrong, it was fairly interesting, especially the quotes from popular coders and their bugs, but I don't think that it really gave me any insight on better debugging techniques. I find that I rarely have debugging problems anyway, and my methods are good enough for me, so I don't really need any help with it anyway. I still think that maybe you should have spent a little more time collecting ideas and debugging methods before writing this article.

As far as your magazine goes, keep up the great work!

-Mastermin

Heya...thanks for the comments. The reason I print our email address at the bottom of an article is so that you guys can tell us what you thought of it. Specifically, the debugging article was aimed somewhat more for people with less than a year of coding experience, with the quotes put in for more advanced coders.

Sometimes, though, something that seems like a good idea for an article turns out not to be so - even though debugging is a very important part of programming, there's not much to write on it. We hope you like the next few specials better, and thanks for your comments!

You can take a look at this address.

Hope you like it!

David Karlov

Not too shabby! If you dig space shooters, check this out during the wait for AIIB, SaR2, Freelancer, and the others.

Secondly, I may just use [the Killers screenshot] graphics as final art, because it's no mystery that I suck when it comes to art. Music and code are a different story. However, because I'm using MIDI, I can't do the music, so I have a very talented MIDI composer doing that part. And why might I use these graphics? Well, maybe I can stir up some more controversy. Think about it...how many people have heard of WoS, if not just because of the naked woman in it? Is there any chance that there might be a reason I put that picture in it?

And finally, (sorry to make this letter so long), but those of you who witnessed the ongoing fight between me and zkman, keep your words to yourself because we settled our differences like grown adults. Something a lot of people in this community need to learn how to do.

nekrophidius

As monthly readers know, some controversy was stirred up over nekrophidius's fairly explicit new project "Killers". However, nekro is never one, as he says, to change his style because of other people. If anyone else has something to say in support (or not) of this letter, send it in and I'll print it in the next issue.

Some games, like Bob Sagat Killer 2000, work on my PC, and WAV files run perfectly, so what's the problem? Is it tough luck for me or is there a way to fix it? I'm sure other people have the same problem, so Help!

Plus, can you tell me where to get info on Vampira? It looks like a class game!

Timothy

Hmm...The reason BSK2000 will work (I think) is that it uses M/K's .mkj music format, and not qmidi or BWSB. I'm not sure if there is an option to get your soundcard to work with those 2 problems. Any readers care to comment?

I'm pretty sure syn nine's page is at bowdown.to/synnine. His old page is synnine.8m.com, so that might have a link to it too.

Hey, this is Bill. About your review [of SpaceWar]...

1) I originally made the game on 2 color 286's in computer class about 2 years ago. It was terrible, but got me 100%.
2) The "new" version only has updated graphics and sounds :)
3) The "engine" sucks! I can do much better now, and I just did a rush job on SpaceWar to finish it for the Qlympics. I didn't expect it to even get to the finals, let alone place third.

The music sounds repetitive because no one in Pyroelectric Software cand do music (we tried, but failed) and the Music engine is not BWSB! It's .HSC by Steve Bigras but modified for me. The .HSC format is only FM Music :( but with our upcoming game Pistol Force, it will have MOD music and still use dqb and have fades and all that stuff we've come to expect in a game.

Back to Spacewar, the AI sucks, yes, I know, but at least the routines are different for each type of ship. This was my first attempt at AI and I thought I did a pretty good job, but I guess you disagree.

Bill McDonald

Thanks for the information. About the AI, it's not "bad", but when I've just played Freelancer with planes and tanks criss-crossing and running to bomb and all that, it doesn't seem very adequate. But, remember, the 5.6 SpaceWar got is *not* a bad review. 1.0 is bad. 10.0 is good. 5.6 is average.

Anthony

I'd like to post up all of the files in Must Download and whatnot on the site, but I have a limited amount of space with which I can post files, and some of the games are too large. There are many browsers you can download, though, and then just open once you've connect via aol, like Neoplanet, Internet Explorer, or Netscape.

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)      3(t)        U1
 2. Agent Squeak (t)       3(t)        U1
 5. MiniRPG3 (t)           --          --
 5. Peanut Patrol (t)      --          --
  
 Comments: Wetspot 2 destroys all of it's competition
   this month.  Expect some shake-up here in coming
   months with the new games coming out...

 Favourite Utility  |  Last Month  | Change
 1. DirectQB               1           <>
 2. FutureLib (t)          --          --
 2. PP256 (t)              --          --
 
 Comments: DirectQB dominates the voting utterly
   in this survey.  Dash still hasn't made it back
   on the list, but the new upgrades might push
   it up.

 Best Upcoming      |  Last Month  | Change
 1. Dark Ages 2 (t)        1           <>
 1. ProjectRT (t)          3(t)        U2
 1. Freelancer (t)         --          --
 3. MiniRPG4 (t)           --          --
 3. Dash2 (t)              3(t)        <>
 3. S. Violence (t)        --          --
 3. WTSC (t)               --          --
 3. Kalderan (t)           --          --

 Comments: Enhanced gets the trifecta with Project
   RT tying for 1st.  Last of the Legends, tied for
   #1 last month, falls off the list.

Vote today by emailing your votes for:
favourite game
favourite utility
Game/utility that you're most looking forward to.
Send your vote here

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
The library that has it all: .fli players, sound, super-speedy graphics, special effects, the works.

Dash
A super-fast library by Danny Gump featuring pipelined code, but less features that DirectQB.

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!

Of Hell and Magic
An RPG by Progman, featuring smooth-scrolling, a fantasy story, and Zelda: Link to the Past style gameplay.

Battles in RPG's are very often the most significant part of a role-playing game design, but because of the success of games like Final Fantasy 7 among Westerners, and the influence of Darkdread's games on qb coders, prosaic battle layouts are the rule of the day in qbasic. This often leads to a dull and monotonous play for your users. You don't want battles to be used simply as a way to earn money or give challenge to a short title, having players lull into a "click-through" or "push-through" state of battling where one merely chooses "Attack" again and again. But what other kind of battle systems are there to use in your games? And how can nonconformity to past titles make yours a "legend"? Read on...

Types of battle engines
There are 3 basic types of RPG Engines that you should be aware of when creating an RPG. The entire design of your RPG, from seeing enemies or not, to whether NPC's need to be able to attack, to weapon choices, will rest of what type of battle engine you will use. Those three are the Strategy RPG (FF Tactics, DragonQuest, Shining Force), the action RPG (Zelda, Baldur's Gate, Shen Mue), and the "Final Fantasy"-style RPG (Final Fantasy, Shadow Madness, Breath of Fire). There are many sub-types in each of these types, and also room to make your own, fully fresh blueprint, such as Square's recent "Racing RPG".

The Strategy RPG generally relies on a few things: non-random battles, specific weaknesses/advantages, and large battlefields that allow a character to retreat as well as advance. Many strategic RPG's also employ a technique where every encounter is full-planned, and a long arrangement; something like only having 20 battles in a game, but having each last more than a half hour. The most important thing, though, is to remember that strategy RPG's have to allow a character to know the strengths and weaknesses of each type of enemy. For instance, a Ghoul can fire a magic spell at everyone within a radius of 2, but is weak against Water magic, or something similar. Also, formations should be allowed to gain an advantage. Remember, a strategy RPG means anything from allowing characters to fight on a simple grid-layout, to a full-fledged Warcraft in your RPG.

Final-Fantasy style RPG's are the most common type with qbasic coders, simply because they are not very difficult to code. A final-fantasy RPG generally means groups of "good characters" on one side of the screen, and "enemies" on the other, with each attacking in turn. The only problem with this setup is that it's very easy to get into a "click, click, yawn, yawn" system unless you throw in some tricks. For instance, how about allowing your character to steal from the enemy, or give the character a "special" ability if they kill each difficult boss. Keep in mind that stagnance is easy to accomplish with such a system, but with legerdemain of the method, a legend will be made.

The final "metasystem" is the Action RPG. This basically encompasses every RPG that has a different battle system than the two listed above, but is generally referring to Zelda-style gameplay. In such a system, there are no "turns"; basically, if you press the button, you swing your sword, if you click the mouse, you cast the spell. The enemies are almost-always on-screen in such a system, as well. But zelda-style is not the only flavour: games such as Samarai Showdown RPG allow you to fight your battles "Street-Fighter" sytle. With this system, you are free to let your mind run with an idea, but this generally accounts for the longest time spent programming, which is why you have seen it rarely in qb (Of Hell and Magic and Ziel being notable exceptions).

Now that I have a general idea...
Based on which of the 3 types of battle systems you choose, you can begin to design the other facets of your game and engine. For instance, will your engine need to allow for enemies on screen or off? In an action RPG, yes. In a FF-style RPG, they would be on the "battle screen". Another facet is whether you should be able to control when you're attacked or should it be automatic. In a strategic RPG, you generally have no way around a battle, and in Final Fantasy - style games, the battles are usually random. However, Action RPG's generally allow you to choose whether or not to engage a non-boss enemy.

Special abilities are very consequential to a player's enjoyment of an RPG. Not only do special abilities allow for additional eye-candy, they also allow the player to greater plan what they're going to do, and will test a player's patience (if they'll use a big ability now instead of later). Making special abilities, both for players and enemies, rare and important, will further the excitement over them, and also take humdrum gameplay away from your game, with players looking forward to something other than "attack". Special abilities also make good rewards for players at specific points; who can forget when they got each spell in Zelda 64?

Items are also affected by the choices you make when creating your battle engine. For instance, in a Fantasy RPG, there's no point in creating multiple weapons that are basically the same gameplay wise. Your players will not see the point. Instead, make each item/weapon/defense significant, and, if possible, make each effective against a certain type of enemy, so that there is no "best"; some are good some of the time, others better at other times.

Quality over Quantity
Making battles significant is the most important thing to think about when creating your engine. Because of this, always think of quality over quantity. For one, why have 59 variables tallied into the battle equation when a good number of them don't even matter? Why would a character even care about getting "Cooking +1" which will give a +.8% bonus against maggot rats? They won't. Instead of bogging down a system with Pen + Paper style numbers, use the computer's advantage over that medium to create systems adapted for the computer.

When a player looks forward to your skirmishes, and attempts to seek out all the ways in which to gain a slight advantage, or even says "Yeah, this is cool", as they play it, you have accomplished a good battle system. Although a battle system is not nearly as important as a good plot or character development in an RPG title, when the player feels the battles are "getting in the way", they are not quite tweaked. Good luck!

Do you like RPG's with Attack Strength Relative to the Gravimetric Weight of boots%? Lemme know.

Peanut Patrol 2's first screens to come out, this side-scroller cranks at 147fps on my 166.

Alright, everyone think back two months, before I discussed landscapes and "fixed" VOXEL.BAS, long, long ago when I gave you the voxel-editing program to create your own voxels. Well, a lot has ahppened. Syn9 has released his voxel viewer. His uses a very similar format to the one I gave out two months ago, and with only a few changes they are interchangeable. In fact, there is a program that can change them, load them, save them, edit, and do a lot of other cool stuff! The downside is that it uses a totally different palette from the program I gave you at first.

Now I'm getting ahead of myself, I haven't even defined a list voxel yet! Silly me. Well, you remember that editor that I presented in the first part, it saved and viewed images in a 3D grid. This allows for wonderful detail and very level performance, but the voxels are limited in size. The only way around this without creating humongous arrays is to switch to a list voxel - that is, instead of storing whether there is a voxel at a given location, you store every location that there is a voxel.

OK, now that we understand what a list voxel is, we can draw it. The image viewer that Syn9 released is fully capable of that - fire the puppy up with your favorite voxelmap and watch it go! Now look at it: the detail, the power of creating whatever you want, and look at how fast it is! On my Pentium 90, I get just about 6 fps for most voxels. For any kind of cumputer that's NOT obsolete like mine, voxels are playable, even in QBasic. Also keep in mind that this is a fairly crude implementation - by Syn9's estimates, the new version should run about 10 times as fast. That's fast.

A little information about the voxel formats before I let you loose: there are 3 different QB voxel formats in existence: the SVF format used by the voxel editor in part 1, which is the same as the .tmp files that you get from it (you can actually rename and interchange them, you just have to change the extention to SVF. There's VXF, which supports up to 22 x 22 x 22 voxelmaps and is also based on a 3D grid, and XVG, which is a list voxel format that is changeable in size, so long as ((xsize^2 + ysize) * ysize + zsize) < 13000.

There are more things you can do. You could have something melt, or catch fire, or swirl into oblivion, or even change into a liquid that changes shape to match its container! The really exciting part it not necessarily the way to deform it but to animate it in more useful ways. Biped motion is one. It's possible to have heirarchial voxels, and if done right, one or more voxels could 'stick' to the floor while the rest of the voxel moves.... I'll save this for my series on physics though! No point spoiling everything!

In particular, I want to discuss interpolated model animation, which is a new technique aimed at smoothing out animation. Anyone who's played Quake on a really killer machine (>200 mhz) may have noticed that the models tend to jerk as they switch from one frame to the next. Because there are only a limited number of frames you can fit in and the FPS rate is really high, each frame is used several times in a row. This makes it appear choppy. However, if you you a frame that is "between" two frames that the current scene is between, rather than one or the other, you can make things much smoother. Smoother still, use a weighted average based on how far off this frame is from the scene and it appears smoothest of all - if you can pull it off. By this time you're probably using lots of math to do all this and for large models it can slow down a lot, bringing the framerate down to where it's no longer advantageous to use interpolation, that is, unless you have it optimized properly. In the new Vampira engine, developed by Syn9, it is actually fast enough that for even a lower-end pentium (>100 mhz) it's smoother than any frame-based animation out there. So, if you want to see this in action, wait for the new release of Vampira - it will no doubt rock the QB world.

Well, we covered a lot today, list voxels, file formats, and stunning new forms of animation. Join me next time to cover particles, and alternate methods of 3D projection.

Let Alias know that you can intrapolate quasi-physical voxelite models at 100fps on a 286.

For the longest time, QB programmers have been using the BSAVE command to save screens to files. However, the only problem we have faced is with the color palette. A typical BSAVE does not save the palette, so unless we work around this then our colors will be lost and our image appears messed up. Well, Rich Geldreich knew this as well, and he set out to solve the problem. His technique involved placing the color bytes above the image data in screen memory, where it wouldn't be seen, but where it could be easily accessed. When I discovered this technique, I gave it a name: SBS, short for Super BSave. Ever since, I've used this neat technique, and now I'll show you how to use it as well.

The main advantage to this technique is that when done properly, it is amazingly fast. We'll use a couple of tricks to obtain maximum speed from this unique technique. Also, keep in mind that this is designed for the typical SCREEN 13, and may not work in other modes.

---CODE SEGMENT:CUT AND PASTE---

'Access the screen memory segment
DEF SEG = &HA000
'Tell the video display to start at palette register 0
OUT &H3C7, 0

'Let's read the palette and place it above the video display
'We can do this because the video display is 65536 bytes, however, only 64000 are ever used.
'This gives us 1536 bytes to play with, we only need 768 so this works out perfectly
FOR a = 0 TO 767
      POKE a + 64000, INP(&H3C9)
NEXT

'Using the standard BSAVE, we can save the whole thing to a single file!
BSAVE "filename.sbs", 0, 64768
'Don't forget to restore the segment back to the default
DEF SEG

---END OF CODE SEGMENT---

That writes a 64775 byte SBS file to disk. Your screen is saved! Now, there are two ways to load the screen back in, using the standard BLOAD or using BLOAD with a few extra lines of code. So, here we go...

---CODE SEGMENT:CUT AND PASTE---

'Access the screen memory segment
DEF SEG = &HA000
'Load the file
BLOAD "filename.sbs"
'Now, we can read the palette from the screen memory above the visual screen
OUT &H3C8, 0

FOR A = 0 TO 767
      OUT &H3C9, PEEK (64000 + A)
NEXT

'Restore the default segment
DEF SEG

---END OF CODE SEGMENT---

There you have it. A set of super-fast screen read/write routines. Like a BMP file, this format is pretty large. However, using compression theories will eliminate that, but that's a story for another tutorial...

 

Petition nekro to call this the Super Extraordinary Humongous Happy Magical BSAVE (or SEHHMBS for short) at this address.

SECTION 1
1.1 Ramblings
Hey everyone! some of you might know me some of you might not. In any case my name is Bill McDonald head of PyroElectric Software. I have about 6 years of programming experience behind me so i consider myself pretty advanced, but not a god like Angelo Mottola, Toshiriro Horie, and all those other guys who can do 3d. I envy you!

This is my first tutorial so i thought an intro would be nice. Please excuse any spelling mistakes and so on.

1.2 Thanks
special thanks to
Brett Paterson of Firelight for his Tutorial
Angelo Mottola of Enhanced Creations for DQB and many other things
ZkMan for publishing this tut.
Jcv (where ever you are) for giving my mod player some competition
and all others who have helped me.

1.3 Blah Blah Blah get on with it..Disclaimer
I hate to do this but

Disclaimer:
Any use of this material or ideas/code presented in it is your own responsibility and the author takes no responsibility for what you do to your computer/data with this information. And all this other legal crap everyone doesn't read.

SECTION 2
2.1 What is a mod file?
What is a mod file you say? well a mod file is a music format originally started on the amiga computers. It consists of patterns and orders in which samples (wav files) are played a varying frequency's and intervals to produce a unique sounding music. Mod files have been around a long time so there are many formats it have evolved into but in this tutorial we will cover 4 channel, 31 sample mod files.

2.2 Why Bother?

• - Why not?
• - Its a programming challenge to do it in QB and it has been done only a few times by Me, JCV, and Rich GeidReich.
• - The music is great for a background in your games/demos.
• - It shows off your programming talent :)
• - It is good practise for all kinds of programmers

2.3 Memory Requirements and Programs needed
The memory requirement of a .mod player are steep unfortunately, 4 channel mods with 30 patterns will take just under 32k of conventional memory but you could always use EMS/XMS to hold the patterns. You always need to think of new memory saving techniques and ways to store that patterns that will use the least memory. The way I set up my first player was a array dimensioned to the size I needed to store the patterns and if there are too many patterns load as many as you can and then skip the rest and change the orders so that they don't point to non-existent patterns.

The programs you will need to run the examples in this tut are

• QB v4.5 - for library support and speed (haha, speed). You can find this at www.quickbasic.com
• DQB v1.61 - for the terrific sound engine among other things. you can get this at ec.quickbasic.com
• A working .mod player (Mod4win.com, or winamp.com)
• Some .mod files to play. I suggest getting axelf.mod - it has no effects, nor.mod - only a few effects and then impsible.mod - Mission Impossible, to test pattern jump effect
• Lots of Free Time :)

   
  

SECTION 3
3.1 Notes/Periods Explained (Terminology)
Ok, here goes..

• ROWS - go from 0 to 63 and each row in a 4 channel holds 4 notes
• NOTEs - are actually the sample number you play
• PERIODS - are the frequency you play the sample at
• ORDERS - orders are how the mod plays from 0 to length of song.
• PATTERNS - patterns are played in any ORDER, and are the physical information.

TYPE  LENGTH Bits RANGE           Basic
byte  1      8    0-255           String * 1
word  2      16   0-65,535        Integer
dword 4      32   0-4,294,967,295 Long

* This is as close to the actual ones that I could think of.. (anyone that can do better email me).

3.2 Setting up the arrays/variables
You will need to make a couple type array to hold the song info.

TYPE Song
Handle as integer
MK as string * 4
Length as integer
Channels as integer
END TYPE

3.3 Checking to see if its a valid .mod
For the header of the mod file it contains the name which is a 20 character string sometimes terminated by a null (0) character.

Before we load a mod we have to check that it is a mod. Every mod has a signature this is in the form of a 4 letter string that equals "M.K." The signature is stored at offset 1080 (438h) in the file, so it should be checked first.

At offset 1081 there should be "M.K." identifies it as a 4 channel 31 sample mod file. So the check should look something like this..

Open the mod file for binary
SEEK Modfile, 1080
GET modfile, , Song.MK

IF Song.Mk = "M.K." THEN
Song.Channels =4
ELSEIF
PRINT "Not a 4 channel mod file!"
END
END IF

SECTION 4
4.1 Loading the rest of the header
The rest of the header contains the sample info and the order/pattern info.

Sample information is stored at the start of a MOD file, and contains all the relevant information for each of the 31 samples. This includes its name, length, loop points, finetune and what not. 4.2 Data types for the sample headers
I think the best way to store information on the 31 instruments, is to store its information in a structure, then have an array of 31 of these instrument structures.

type SAMPLE
NAME as string * 22
LENGTH as integer
FINETUNE as integer
VOLUME as integer
LOOPSTART as integer
LOOPLENGTH as integer
end type
DIM SHARED Sample as Sample

4.3 Loading the Sample headers
So from here we loop 31 times and read in a block of information about the sample according to the loop counter. Load all the info into temporary strings first so you can manipulate the bytes and then store them in the proper array element.

for i = 1 to 31
- read in 22 bytes, store as NAME$
- read in 2 bytes, store as LENGTH$
- read in 1 byte, store as FINETUNE$
- read in 1 byte, store as VOLUME$
- read in 2 bytes, store as LOOPSTART$
- read in 2 bytes, store as LOOPLENGTH$
next I

The Name, Length, Loopstart and Looplength need to be caclulated with this formula (byte1*100h + byte2) * 2 I will provide my alternate formula in the next issue.

Byte1$ = LEFT$(Length$, 1)
Byte2$ = RIGHT$(Length$, 1)
Sample.Length = (ASC(Byte1$) * 100h + ASC(Byte2$))

For FINETUNE, if the value is > 7, subtract 16 from it to get the signed value

Conclusion
Well this is the end of the first part of my 5 or 6 (depending if I cover effects) part MOD player tutorial.

Thanks for reading

So SpaceWar is your favorite game? Lemme know what a mistake at this address.

First off, if you have not read last month’s article (issue 10), I suggest you do so now, as it covers several vital concepts not discussed here. That said, let us delve into more shading concepts. What is that I hear? Thousands crying "No, we hate shading, we don’t want any more freakin’ shading tutorials!" ? Worry not, this article concludes all that I know (or remember) about shading; in the following months I will discuss more interesting concepts like...explosions!!! (I sense that many have now gained interest).

bump mapping
As the title above so bluntly states, the first shading technique we will be doing is bump mapping. Q: What is bump mapping? A: Bump mapping is that thing that makes things look bumpy…yeah! Actually, its the simulation of unevenly distributed, or diffused, light, which makes surfaces look like they have a rough texture to them. This is perhaps one of the most useful techniques for making your objects look more realistic. Without bump mapping, some objects may look a little bit too perfect, or computer-generated. Generally, no real-world object is perfect, it usually is marred, scratched, or smudged in some way, even if to a infinitesimal degree. Bump mapping is also useful, of course, for surfaces that are purely intended to be bumpy; such surfaces would include rock, fur, rust, and dirt, to name a few. There are several types of bump mapping, each having its own unique use.

diffusion mapping
The first, and simplest type of bump mapping is called diffusion mapping. To start, draw and shade your object (1,1)-(2,1) as you normally would. Then "mix up" the shading regions a little by drawing pixels in the shade of one region into a neighboring region of a different shade (3,1)-(4,1). It is as simple as that. To make your object look more or less bumpy, mix up or do not mix up too much the shading regions, respectively. For flat surfaces, the process is fairly similar. Draw the base object (1,2)-(2,2) then mix up the shading regions (3,2)-(4,2). Make sure you do not just mix up the edges of the faces of your object, but the entire faces. You may have noticed that the diffusion is not random, but ordered, in the flat-surfaced object. You can either used ordered or random diffusion for any particular object, where appropriate. For example, a golf ball has evenly spaced valleys on its surface (hint: ordered diffusion), but sand paper has more randomly placed peaks (hint: random diffusion). What the hell are peaks and valleys, if not terrain features, you ask? Peaks are bumps that go outwards, and can be depicted by diffusing brighter shading regions onto darker ones, and valleys are bumps that go inwards, and can be depicted by diffusing darker shading regions onto brighter ones or some crap like that (:’).

extrusion mapping
Diffusion mapping is only useful for surfaces with tiny, indistinguishable bumps; extrusion mapping, conversely, is intended for making larger, more discernible bumps. As the name implies, extrusion mapping takes a given pattern and "extrudes" it relative to the base object. However, the more complex a extrusion map you have, the more difficult it will be to apply it to the object. Anyway, to begin, draw and shade your object (1,3), then draw the extrusion pattern on top of it (2,3). Next take each chunk of the pattern and move it outwards, on the axis perpendicular to the face or curve of your extrusion (3,3) (for example, outwards from the middle of the cylinder would be in the down direction, and to each side, the chunks would move in their respective direction; the piece on the cap of the cylinder moves upwards). Finally, shade the sides of the extruding pieces in distinguishable shades, and shade the tops of the extruding pieces in a slightly lighter shade, to give them depth. The process is the same for flat faced objects (1,4)-(4,4).

pattern mapping
Again, the title is fairly self-explanatory. Pattern mapping takes a given pattern, but instead of extruding it, each region of the pattern is individually shaded. As the regions approach the darker parts of the object, they become darker. Starting off, draw a matte (unshaded) version of your object with a bump pattern on it (1,5). Then shade in each region accordingly (2,5)-(3,5): the regions closer to your hotspot (Remember that thing? It’s your imaginary light source :^} ) use brighter ranges of shades, and the regions farther away use darker ranges of shades. Finally, draw the shadow, and...what the hell is that thing taking up slot (4,5)? It looks like a bunch of grapes (mmm) grapy-flavor >:D. Heh, no. Ahem, anyway, flat shading is the same (1,6)-(4,6), except the regions of each face use similar color ranges.

specular mapping
This is perhaps the only bump mapping type whose name is not completely obvious. Specular mapping uses a series of highlights to determine the peaks of an object, then shades around each of these highlights and molds the respective shading regions together. For round objects, use a series of points to determine the highlights (1,7); make sure that the highlights get darker around the edges farthest from the light. Next, shade around the highlights and converge the shading regions (2,7)-(3,7). Finally, draw the shadow (4,7), et voila: a cheesy-poof! Flat objects are fairly similar to their rounder counterparts. First draw your object (1,8). Then, instead of finding highlights, you must find peaks (2,8). On these peaks, the vertices of each face will connect to the peak, and the newly divided regions are shaded accordingly (3,8)-(4,8).

transparency and refraction
Transparency is the characteristic of not completely reflecting light, and therefore letting light pass through. Transparent objects allow whatever is behind them to be viewed, unless they are refractive, in which case the above is not necessarily true. Refractive objects bend and distort light; if you have ever looked through a fishbowl, or another curved, glass object, you probably noticed that everything behind it is either bent out of shape or not visible. This is refraction in effect. Flat faces can also be refractive; a diamond, for example, is very refractive, which gives it that "sparkly look" you always see on the home shopping network :^). How does refraction work? Well, in simpler terms, the faces or curved surfaces project the image or background behind and perpendicular to them. So a refractive plane parallel and above a floor would project the floor directly below it onto its surface. Confused?

Do not worry, it is not vital that you know all that garbage above, just follow the tutorial and pretend to know what you are doing :’). Before we examine the following articles, you must first understand a relatively simple concept: static objects and moving objects. Static objects do not move at all, therefore they can reflect their surroundings to any degree you wish. So, for example, if you were to have a reflective object on top of a given background, since it would only be staying in one place, you could render a perfect reflection of the background. If that same object were to move onto another background, the reflection would be inaccurate and look paradoxical. Static objects are generally things that will be glued in place in your game, like a torch on a wall (note that static objects can be animated). Moving objects, however, will be subject to any type of background change, since they can potentially move. Thus, you must draw moving objects according to only an approximation of their environment (we did this last issue with reflective objects). Now, on with show.

dithered transparency
Dithered transparency combines an object with its background by dropping out every other pixel (in a "checker board" pattern). The beauty of this method is that dithered-transparent objects are not static, that is, they can be placed on any background and still look properly transparent. However, dithered transparency really only looks acceptable at higher resolutions (I would estimate 640x480 at the least), and it does not really work with small objects. To make a dithered-transparent object, first draw the object as you normally would (5,1), except the shadow should be a darker shade of the object’s base color. Next, drop out every other pixel of the object to the background color (6,1); the easiest way to do this is with diagonal lines of a 45 degree angle (slope of 1), in the background color. Flat objects are exactly the same (5,2)-(8,2).

hue/value (HV) transparency
HV transparency works in the following manner: the background hue (color) is changed to the object color, where the object and background meet (this is called colorizing, the process of changing one color to another). The background texture keeps the variations of its respective values (brightness levels) in each shading region of the sphere. So, for example, say the background texture has four values that make up its texture; whatever hues it has does not matter. In the brightest shading region of the object, the texture is turned to four bright values of the objects hue, to replace the four values that make up the background. HV transparency only works correctly on static objects. First we must have a background on which we can work with our HV transparency (I chose a rock texture in this tutorial). Once you have a suitable texture, cut out the shape of your object from one part of the texture, then cut out the shadow as another piece (5,3).

First we will work with the object cut out. If you do not have a "color replacer" tool in your paint program, you may find this part difficult (a color replacer replaces the secondary color with the primary color). You will want to replace the brightest region of this cut out with bright values of your object’s given hue, and the darker regions with subsequently darker values of the object’s hue (6,3). This should result in a shaded object that has a texture visible behind it (unless you messed up, which is most likely the case :0) ). Then the shadow piece is replaced with a fairly dark range of the object’s hue (7,3) (this makes sense because shadows cast by transparent objects are the color of the object). Then you piece the shadow and the object together in their respective places on top of the background where you cut them out (8,3). Flat objects (5,4)-(8,4) are similar, except the individual faces are cut out and replaced with single color ranges.

psuedo-refraction
Pseudo-refraction is not a static method, but on the other hand, it does not look as accurate as true refraction (explained shortly). Pseudo refraction is almost similar to the pseudo-reflection discussed last issue, except that the process is reversed. Where ever a face cannot reflect the ground, it refracts the ground. Thus, much of the upper hemisphere of a sphere would refract the ground below it, or the same with the top face of a cube. First, make a normal sphere (5,5), then find its refraction region (6,5), which should be a something like a crescent shape near the top. The crescent should not touch the top (it’s a little anomally of refraction, I’m not sure what physical law is behind it :] ). Anyway, next shade the region in whatever fashion suits you, so long as it is distinguishable from the rest of the object.

Flat-surfaced objects (5,6)-(8,6)refract slightly differently; Whichever faces point outwards away from the ground (usually the upper pieces of a flat object), these regions refract, or partially refract, given their angle. Shade these regions in some other way than their counterpart faces. You may wonder why the other faces of these objects are not transparent. Remember that refraction bends light, so the side and lower faces of an object cannot "see" the ground below them; the only thing the can "see" is air, so they are shaded normally. You may choose to make your refractive objects transparent, but it does not always look good and is simpler left alone.

true refraction
Finishing up, we have true refraction. True refraction is static because it refracts the texture below it, not just an approximation of the background. We will start by cutting out the refractive pieces for a cylinder and the cylinder’s shadow (5,7). Note that the bottom cap area of the cylinder is where the top will refract (refractive surfaces reflect directly below them, or in whichever direction the inside of the surface points), so we cut it out for a top piece. Next we draw the side regions normally, as they refract nothing; the shadow is colorized by a dark value of the object’s hue (6,7). Then the top (refractive) region is colorized according to how much light it recieves (7,7). Finally, everthing is pieced together. The flat object (5,8)-(8,8) follows the same rules as the one in (5,6)-(8,6), except that it uses true refraction, and the pieces refract chunks of the background in the opposite directions of their respective surfaces. That is it!

conclusion
These are all of the shading techniques I will tell you, but it does not stop there. You can combine any of the shading methods to produce unique objects (try making a texture mapped, bump-mapped, refractive, reflective, irregular object!). You can invent your own shading techniques for interesting objects. Anyway, count down the days to the next tutorial, because it is about one of the most important concepts to good game graphics: seemless tiling!

Beg Gavan once every 27 minutes to do art for your game too by emailing him here.