issue #11

Want to print? Use this version

Back issues are in the Archive

Go back to the main site

Download a zip version

Don't like frames? Kill 'em.

REM 'Letter from the Editor
Welcome to Issue 11 of Qbasic: The Magazine
ON KEY 'Hot List
This month's latest news
INPUT 'Your Stuff
Survey, Letters, a new MD and more!
PRINT 'RPG Battle Design
Lookin' to break standards with your rpg design?
LINE 'The Gallery
Check out our new shot of PP2
PRINT '3d: Part VI
The latest on voxel coding from Alias
VARPTR 'Tip o' the Month
nekro kicks off our new series with SBS files
MOD 'MOD Playing I
Bill McDonald shares tips on writin' MOD players
DRAW 'Art Basics II
Transparency, Bump Maps, and more from Gavan
END 'Next Issue
A thrill-packed preview of next month!

 

Letter from the Editor

By ZKman

"Scho-o-ol's out for the summer!..."

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!

 

Art, MODS, and Project RT =)

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

 

Back to top

qbasic Hot List

Compiled by ZKman

 

JPEG Viewing in Qbasic has arrived...
For the first recorded time in qbasic history, jpeg's are now capable of being displayed straight from QB, a feat accomplished not once, but twice over the last month! JPEG's, of course, are a heavily compressed, lossy image format short for Joint Photographic Experts Group picture format, and are notoriously known as one of the most difficult types of files to extract (right up there with mp3 and that ilk).

Dmitry Brant (dmitrybrant.hypermart.net) announced that he had completed his late last month, about the same time as Petter Holmberg (ec.quickbasic.com), whose decoder has been in the works for about a year. Jpeg's don't have much use in qbasic games, just due to the fact that both decoders are fairly slow compared to GIF or BMP decoders, and that jpeg is a "lossy" format, which means graphics won't stay pixel-perfect, but the accomplishment is still a testament to the implacable growth of ability qbasic's coding community have seen in the last year.

In related news, QBProgger has been workin' on a project, which already has the ability to load GIF and BMP files, and the loading is among the fastest in qbasic today. On top of that, the GIF2IMG also can load Gif89a, which is, as of now, unprecedented.

JPEG in qb, IRC, and Ultima

 

 

The QBMission
A page announcing a so-called "QBMission" was spotted recently. The goal of this mission is to debunk the constant remarks that "Qb is not and has never been commercially viable" by asking the major companies if any of their older DOS products we're written in Qbasic. One of the reported finds is that Ultima I, the classic CRPG, was actually written entirely in Qbasic!

The page invites you to contact any developers you know and ask if any of their games were done in qbasic, for report on the page, an effort qb:tm supports full-heartedly.

 

Just when you thought the treaty was comin...
The "library war" between Dqb and Dash seemed to be crawling to a virtual cease-fire in recent months, with both products going their separate ways with their target user group. But two recent announcements look to increase the battle to unheard-of proportion, as more libraries from some of Qb's top coders were announced recently in GSLib and FutureLibrary.

GSLib, by TheBrain (Puz, SpriteShop, PP2), has been called the "fastest library available", and qb:tm's tests confirm this. Right now, GSLib only has the sparsest of features, but looks to be one to watch if you're lookin' to increase multi-fold your game engine. FutureLib is from the guys of at Future Software and is to be a more complete library written in asm. Props to both of the authors for the 2 great new libraries!

 

Since We're talkin' 'bout Libraries
In terms of the "Big 2", there was quite a lot in terms of updates this month. Firstly, dqb1.6, whose specs were reported last month, was released to a good amount of applause despite some concern over a couple of bugs that have surfaced recently. Dash, which is beginning to be known as the Lib for Speed-demons, had all of the major subs cranked up in terms of speed, as well as having a lot of the code pipelined for Pentium performance.

The most interesting news, though, came from the DirectQB camp recently, when Angelo informed us of the next big addition to dqb: Modem Code! Back in Issue 6's feature "The Future of QB", we stated that multiplay would becoming a huge force in the coming 2 years for qb'ers...and with it's inclusion into DirectQB, this could only become more likely. Whether the code is IRQ or TCP/IP was not revealed, but past trends show that IRQ will probably be the first included.

 

Progar.com - By Coders, for Coders
A new all-programming search engine at progar.com is approaching full-live. What's so special about that? Nothing, except that it heavily and prominently features QuickBasic sites! Despite being for everything from Z-80 assembly to Pascal, many of the top sites listed are QB sites, and QB is the first language listed on the index.

Go and sign your page up now!

 

Voxeling...
syn nine, coder of the excellent looking Vampira, recently showed off his excellent voxel program, which is currently the fastest in qbasic, and is featured in the new Voxel article by Alias. As we said last month, voxels have become en vogue very quickly in Quickbasic (but not at the expense of polygonal games, as this month's Upcoming Games show).

 

Plea of IRC! =)
A couple of frequent IRCers (Internet Relay Chat) have been rallying me to get some newbies onto the channel (like myself ^_^). IRC can be downloaded at mirc.com, and the channels #quickbasic and #qbasic are popular with some of qb's "old-timers" like class- and logiclrd, and are a great place to seek an answer to a code problem or talk about qb in general.

 

Short Programs...
Two "Short Program" contests have been occurring recently, and both are becoming very popular with some of qb's top coding talent. Lociclrd's online contest and the Codex are both looking for very short programs that can demonstrate how good an effect (or even game!) one can write in only a small amount of space. Check them out soon!

 

PB3d being ported to QB
PB3d, a PowerBasic program by Marko Dokic, which features blazingly fast 3d algos, is being ported unofficially to Qbasic by Jernej Sominjec. Although the speed-loss will probably be very signifigant, the polygonal codes are sure to help many beginner/intermediates learn or improve their 3d skills in our "native" language.

 

Virtual Memory in QB!
EMS and XMS were once considered a dream in Qbasic...impossible to attain; but they are both now commonplace. The next level of memory, Virtual Memory, which basically allows you to address gigs of memory for use in your game, has been done in qbasic, by Dark Ages 2 coder Elemental. This should lower the mem requirement on DA2 a couple hundred kb, while at the same time allowing better graphical effects.

This effect, although the source has not been released, is attained through using a disk cache, but still retains a good speed, according to Michael Hoopman of the DA2 team.

 

Free Boards at Future
Looking for a webboard for your qbasic site? Future Software is giving away free webboards at the address above. The boards have the capability to send email when you have responses like a disc.server.com board, and also have other features such as the ability to ban problematic users, and more. Check it out!

 

MOTG Newsletter
Soom Primal's game Masters of the Galaxy has a Listbot mailing of the latest news on the project, which you can sign up for at soomprimal.listbot.com. The mail is sent out approximately once per month.

 

United Proggers Online
The United Programmers Alliance, a group dealing with Qb, VB, and C++, is organising a group of coders who will help each other with each other's programs, in an effort to create more polished programs from all. You can find information on the UPO at this address.

 

Moving...
Last month, alternate logic, the Qbasic tutorial site moved to a new address at alternatelogic.quickbasic.com

Oops!
In our review of SpaceWar in last month's issue, we stated that it used BWSB to play the music, which it does not. Qb:tm regrets the error.

 

 

Hi-color prt, DA2 demo, Oham, and Distant Promises

 

Latest Game updates:
Qb:tm recently had the joy of playing the newest version of the Project RT engine, one which features hi-color graphics! While the svga eye-candy may look great, it may not make the final game due to the fact that it slows the down the engine by 50%. However, colored lighting may still make a low-color version of the game, using a theory similar to the way dqb's blender maps work.

 
 

 

Of Hell and Magic, the new action RPG by Progman, recently had a full version released to much acclaim. Featuring smooth scrolling, and Zelda-like gameplay, all qb coders should grab this *complete* marvel at this address. Next month, our review will tell you: better than Dark Ages?

The number of space-shooters increased last month with 3 new announcements to join Sar2 and Freelancer. Firstly, RabidMoth sent us a demo of AIIB, which is a fairly innovative space-shooter. The graphics are fairly-good (they are fully polygonal), the special effects, such as zooming in on a ship you're chasing look very professional, and RabidMoth promises such advances as mission-style gameplay in future releases. Secondly, Eric Carr, of Spinball fame, showed off some shots of a new 3d engine called WTSC, which promises to solicit more "ooohs" and "aaahs" as the game progresses. No gameplay details are available, but past experience from Eric hints that this will be a very good title. Finally, Entropy sent us a very early shot of his new un-named space shooter, which looks to play somewhat similar to Space-a-Roo2. More details on all of these titles as they come.

Distant Promises, an RPG from DarkDread, had a first demo released recently, and looks to be one to watch. Featuring a Final-Fantasy style battle engine, and, more importantly, original plot and good development even at this demo stage, be sure and pick up this game as soon as you can.

Speaking about titles you need to pick up demos of, the second major demo of Dark Ages 2 was released recently, and to say it's a massive demo is an understatement. Featuring a world larger than the entire DA1 map, you can pick up items, talk to some NPC's, and see the first bit of story. Mike confirms that the next demo of DA2 will feature a demo of the much-touted battle system.

The Adventures, a side-scroller from TMB that was reviewed recently in qb:tm, was released recently, and features 13 levels, as well as some interesting cutscenes and gameplay. See our review for more!

A demo for Peanut Patrol 2 is said to be arriving sometime during the next week, according to The Brain. This game includes such things as Parallax Scrolling backgrounds, beautiful graphics, and some original gameplay.

Now this month's shorts: JPZorilla is working on a fighting game called Raging Fire which looks very promising. View it at his address...A screenshot of the much-anticipated XENO 2 was shown recently, and looks to be a huge improvement over the original, allowing for a complex wall and ceiling structure, as well as fast speed to boot...Senseless Violence, a Diablo-style game, is coming along, and graphically is one of the most advanced qbasic titles as of yet; keep an eye on this one...DeVo's new project called "Projx3d", a 3d engine soon to be a 3d lib, a la PB3d, looks very advanced, and challenges for one of the most advanced qb titles. Along with PB3d port, this should help crank development of 3d titles in qb...Finally, Agent Squeak, another highly-anticipated side-scroller had a demo released recently, and looks very interesting; from what we've seen, the object is to collect all the cheese on the level, and gain special abilities such as fire-breathing to kill the enemies.

That's all the latest news for this month. Remember, if you have any news or rumours, send them along to Qbasic: The Magazine

 

Back to Top

Input: Your Stuff

By ZKman

 

 

Here's what you had to say about last month. Be sure and send us more letters soon!

I've got a problem:
I can't download voxel.bas. If I click on it, the frame is redrawn and all that I can see are some boxes and letters on a white background. Can you help me? Could it be that it's caused by my browser? (Netscape 4.5)

Gunther

Easy to fix: Instead of left-clicking (I'm assuming you're using a PC and not a Mac), right-click and hold until a menu pops up. Choose "Save File as" or "Save Target as" or whatever it is, and there ya go.

 

 

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!

 

 

 

Hi...
There is another QB Space shooter you probably haven't encountered. I made StarFire in QB over a year ago. It was a fun (hopefully ^_^) and challenging space shooter, with bad sound, but ok graphics and good gameplay (lots of enemies and weapons).

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.

 

 

 

Ok, zkman, you wanted my comments, so here I am. First of all, I don't care what this Timothy guy says, and I also don't care if this game (Killers) is "disowned as a qb game". And you're right, I don't change my style just because people don't like it. Whether or not it is a qb game or not is irrelevant. Maybe a few people are jealous? I could just as easily make this in straight asm.

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.

 

 

 

This is about virtually every Qbasic game with sound; it's a major prob for me. You see, qmidi and BWSB games only support the realms of 220 to 22F when finding sound cards. Unfortunately, my card is on address (or is it interrupt) 22H. So I can't hear any music on many games, like Wetspot 2 and SaR2.

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.

 

 

 

Hi. I was just wondering if you could, in your next issue, post links to all the files that are featured in your magazine (Dark Ages 2, SFB2, etc.) or maybe even post them on your site. Due to my connection (Aol), I am not always able to download items at other sites, though I find I can always download items at your site. Thanks for the site,

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

 

You need this stuff!

We've got a slightly different format in the Must Downloads this month. From now on, we'll be displaying the 10 programs you *need*, and that's all. And the ratings will go in terms of pure playability or usefulness, not nostalgia. So here's the new list (in no particular order)! Oh, and if you see somethin' missing, write in and tell me!

 
  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!

 

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.

 

QBRPG's
 

One of the classic qbasic sites on the internet, formerly run by Apester, and now by the venerable LordQB, Qbasic RPG's is one of the best choices for your RPG needs. Tutorials, links, a board, game info, it's all here.

This site is one of my personal favourites, and, if it would've been updating more, probably would've been one of the first awardees. We hope that the new site (and know that it will) rebirths into a qb mecca, as it's history and legacy proceed it.

One of the Classics...

Back to Top

battle design

By zkman

Be original!

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).

 

 

Shining Force - a Strategy RPG

 
 

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.

 

Back to Top

Gallery

By Zkman

 

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

 

pp2

 

Back to Top

3d: Part VI

By Alias

 

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.

Interpolation for Dummies =)

 

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.

 

 

A pic of syn nine's Editor

 
  Now that we have list voxels I want to discuss twhat you can do with them. First, the pros: list voxels can be larger, more elaborate, take less space, and in many cases are faster to draw than their grid-based counterparts. They are generally more versatile, lending themselves to particle physics and path-based movement better, and animation methods not frame-based. The cons: they typically have a larger data set, they're nigh impossible to change, defining a definite limit is difficult, they can be slower, and debugging them is a true nightmare. Case in point: the other example program for this month was to be a list voxel loader that loaded a list voxel and then exploded it... I couldn't get it to work. Apparently either the loading or conversion code is screwy and I couldn't get anyone to help me. I am hopeful that within a week I will be able to release it as an addendum to the article. And now I want to discuss the things you can do with list voxels: You can blow them up. I'm serious: a particle explosion never looked so good. When the program is released load up your favorite voxel character or madel and let her rip - you can try your favorite character, object, powerup, villain, or whatever. You can use the effect for more than death sequences though - (*LEAK AHEAD*) One of the weapons from my upcoming game, Attack of the Blobeteers, will be the Discumbobulator, which makes the enemy turn into a bunch of pixels that kind of flutter away in all directions for a minute before re-cumbobulating.

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.

Download syn nine's voxel editing program

Back to Top

tip of the month

By nekrophidius

S
B
S

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.

F
I
L
E

F
O
R
M
A
T

Back to Top

mod 1

By Bill McDonald

Wanna know how to do a MOD player?

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.

 

Back to Top

Art by Gavan

By Gavan

 

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).

Transparency, Refraction, and more

 

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 (:í).

 

 

Mmm...examples =)

 
 

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.

 

Specularly highlight *this*

 
 

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.

 

Back to Top

next issue

By Zkman

It's the end of the issue as we know it

Next issue is sure to be bangin', with bunches of articles including more .MOD, art, and 3d action, as well as a probable review of "Of Hell and Magic" and possibly the start of a new series which I promise will be *very* interesting. Also, be sure and check back every couple weeks to read the "in-between" specials we've been posting! Remember, the next issue isn't coming until August, but check back for the in-between articles! Also, don't forget to register your QB company with the Visionaries Exchange. Till next time... END

 

Back to Top