The Secret of Game Graphics

Amiga games often generate graphics that are saturated with colour and animate fluidly. But how do these graphics get from DPaint to the game's screen? Trenton Webb grilled Vivid Image until he got some straight answers.

Games are only as good as their graphics. That may be contention, but the initial visual impression makes or breaks a game. Even if it's got great gameplay and superb sound, you're unlikely to give it a second glance if the graphics have that Spectrum look. Only good graphics supported by cracking design can give a game a shot at the big league.

First Samurai from Vivid Image looks to be one of these contenders (check out the coverdisk demo now!). It has exemplary graphics and founded on solid gameplay; between them they weave a spell that makes the game memorable. No more proof is needed that Vivid Image can do the biz graphics-wise. So they were the folk we asked "how do game graphics work?"

Vivid Image were eager to explain, and show off their handiwork by way of example. The team, Mev Dinc, John Twiddy, Raffaele Cecco and Teoman Irmak gathered in Harrow to spill their secrets and to patiently explain what sprites, bitplanes and masks have to do with bashing folk in futuristic Japan.

While doodling in DPaint it's easy to switch around the palette, but when you start designing a game, colour choice is super important. The range you select on day one stays with you for the entire project. It's an ambiguous hypothetical question that demands a precise and instant answer.

Mev Dinc — As a general rule we allocate a certain number of colours for the main character, which remain constant throughout the game. In the case of First Samurai we used the first 8 of a sixteen colour palette. That artist can change the remaining colours to create different backgrounds, but the first eight have to remain the same.

Teoman Irmak — The main character was drawn in 8 colours but that was for a technical reason we didn't eventually exploit; storing less bitplanes. Every plane is made up of ones or zeros, and that's a pointer to a colour look up table. The more planes you've got, the more ones and zeros you've got, therefore the more colours you've got. We thought we could draw the player in eight colours — eight just happens to be a convenient number — which meant we only needed to use three planes and could have thrown one plane away to save on memory.

AF — So if you're using only 16 colours on screen, how come the sky appears to contain hundreds of different shades?

Raffaele Cecco — The sky is drawn in one colour but this can be displayed as any of the 4096 available. Because the colour itself can be redefined on each scan line, this effectively gives you as many different colours as you have lines going down the screen. It's the same colour number though, colour zero, so you don't actually lose any colours from the palette. The Amiga's 'copper chip' can change the colour on every scan line; so we are taking advantage of it, letting the hardware do the work. Then it's just a matter of choosing the right combination of colours.

AF — Once a palette has been defined then the artist can start work. But where exactly do you start?

Teoman — You can't really start with pretty pictures and then try to make them work, everything has to be broken down into exact quantities. It's quite mathematical at first, and you only start drawing when you've worked it out. If you're designing a walking sprite you have to know how many pixels the screen's scrolling. Then, you have to know exactly how many frames per second the game is running at. Both help determine how many frames of animation you'll need to use. We usually break a movement down into eight or multiples (or factors) of that.

I don't try and make people walk in nine frames any more, now it's either eight or 16, or four. Having said that, the main character in First Samurai, who I inherited from another artist, still walks in 10 frames! All the other characters walk in four, but that's a cheat, because the speed of the sprites deceives the eye. It should be eight, because you walk with your left foot and then your right. In fact they do a little skip in the middle, but they do it so quickly you don't notice. This saves frames and saves memory. Even today though there is a major problem with relatively slow frame rates. You get a skating effect where the character who's walking appears to be detached from the ground. Even the arcade machines do this, there is no solution other than a huge number of sprites.

AF — The technical side though is only half the battle once you've worked out your parameters, it's then down to good old artistic skill. What factors have you got to take into consideration when drawing the characters?

Teoman — If you draw a real person his head should be one eighth of the length of his body, that is the ideal. But when you draw that on the screen you realise that he's beginning to look like a stick insect. The proportions may be right but they look wrong. Disney noticed this for example, and drew his characters with three fingers because five fingers looked cluttered! You notice the odd proportions, but are willing to accept it, because of the cartoon feel. The Samurai character for example should strictly be taller, by one or two lines, then he'd be more in proportion. It does make a difference, and that adds a comic book feel.

AF — Fine, but the Samurai character in the file you supplied for the coverdisk is drawn in pieces surrounded by green boxes, why?

Raff — On all my 8 bit stuff I always used to work with individual sprites, whereas all the character graphics in First Samurai are combinations of sprites. Think of them as individual frames made up of collections of sprites.

Mev — The idea of using the head, body and legs separately was so we'd be able to overlay sprites. So when you have 3 boxes you can join them together and create animation frames. This way the game makes maximum use of the sprites the artist generates. The aim is to try and create as many frames of animation from as few sprites as possible.

John Twiddy — Teoman designs the main character sprite and uses DPaint animation to test them until he's happy. Then, he cuts out the individual components and arranges them in a regular format, with each sprite placed within a rectangular box.

Raff — We have a unit size where each sprite is regarded as a box 32 pixels wide by 24 down. The main character is always made up from three sprites, with maybe a sword sprite as well. If you wanted to store that as one big sprite (square) there would be masses of wasted memory within its borders because it's blank. But these boxes don't have be stacked end to end, they can be overlaid, which minimises the blank spaces.

AF — So how is this DPaint 'sprite sheet' turned into something the game can use?

John — Teoman does an animation sequence in DPaint where he takes each individual frame and arranges them so you can see where the top left hand corner of each sprite box is.

Raff — We always work on the top left hand corner of the sprite box as the reference point.

John — Then within DPaint, it's possible to measure where the corner of sprite block is in relation to the others. These relative positions, coordinates, are then typed in manually, effectively constructing a single frame reference for a group of sprites.

Raff — The sprites come to me as a DPaint file. These are compacted with a utility of John's, so if a sprite is only 10 pixels high the game doesn't bother storing the extra 14 empty lines of the box. Then I chop them into individual sprites and I'm left with a lump of memory that's got all the individual sprites and the relevant information regarding each one: how tall they, are how big it is.

AF — But how does the game use these chopped sprites?

Mev — If you imagine it as a pool of sprite data, then each sprite square on each sprite sheet has its own unique number. For instance, the first frame of the main character's walk might be made up of sprite '1' for the head, '14' for the body and '64' for the legs. So every time that frame is displayed you just call out the relevant sprites from that pool of data. This technique allows you save memory by using certain sprites from one frame to build another. The body for example may not always change in relation to the legs. In First Samurai we used the hero's body as part of an opponent for instance. It's the same body, but with a different set of legs and heads, which saves a lot of memory. The most important thing is to use the sprites as efficiently as possible, it's the repeat factor. Another benefit of using regular sized boxes is that even after you've cut out all the sprites and implemented them in the game, they can still be changed. If one of the sprites looks wrong, all you have to do is give that file back to the artist. Then, after the artist has made the modification, the sprite can be re-chopped and slipped back into the pool without touching the program. Because you've just got a list of numbers with the sprites allocated to them. If the sprite happens to not exist because it has been deleted, that doesn't matter, the number doesn't change. It's not like a word processor where you chop out a letter and the other letters jump back.

Raff — In the final game you actually store the decompacted (shrunk) file that's been chopped into individual sprites, along with their masked form. So all the information is there to use instantly when the game calls that sprite number. All the sprites (and their masks) that are universal, common to the entire game, are stored in one separate block of memory. All the opponents and items that change for each load are stored temporarily. This way you don't have to load the same set of sprites twice which helps keep the loading time to a minimum and helps to maximise memory usage!

AF — So the game knows which individual frames to use but how do they animate?

Raff — For each character you create to sequence, a list of individual frames to cycle through. For the Samurai it's conditional, dependent on joystick movement to select sequences. For the opponents it's their attack routines that stipulate which sequence they'll follow. A sequence also defines what collision areas and hit values each frame has.

AF — The Amiga has custom hardware — chips to drive sprites. Does this make life easier?

Raff — Hardware sprites! Well you're only allowed eight to start off with. When you start scrolling that's cut to seven and they have to be drawn in four colours. To use 16 colours you halve the number of sprites and three hardware sprites isn't a lot. There were just too many limitations to use for First Samurai.

Mev — They are very efficient though, because they're driven by the hardware. That's why we wanted to take advantage of them and use them for the parallax effect on the moons.

AF — You mentioned masking, what's that and how is it used?

Raff — A mask is effectively an inverted outline. Imagine that you just cut out the outline of a sprite and from that the Amiga, using the blitter, can calculate which parts of the background should show through and what areas are obliterated by the sprite. The mask tells the Amiga which exact pixels within the sprite square get priority and should be printed instead of the background. And if you make the mask slightly larger than the actual sprite, you can create a slight outline that helps it stand out against the background.

Teoman — You can't always guarantee that the player will always look good against all backgrounds, as some may use the same colours as him. The player has a darker outline which helps avoid most of the problems. It's just like the mouse cursor which is drawn in a light colour with a darker outline, so it can work on any background.

Raff — Using masks you can get some nice effects. For example, on some crystals later in the game, instead of using a solid mask we have one that's stippled. As the masked area alternates, it looks as if the crystal is semi-transparent, because you can see the background through it.

AF — So you've got the character sprites, then it's just a case of drawing the background?

Raff — Backgrounds are actually built like a jigsaw puzzle. One load will contain several hundred blocks which are used to build the background. You don't actually need to store the map as one huge screen. There's just a map in memory with each location represented by numbers which reference background blocks. These blocks are 32 pixels wide by 16 pixels deep. In the First Samurai there's about three hundred blocks per level.

Mev — The backgrounds are constructed in a similar fashion to the sprites and like the sprites each block can be used many times throughout the level.

Raff — Background blocks are actually a lot simpler to handle than sprites as your don't have to bother compacting them, because they are always a full block and there's no mask.

AF — What makes a good background block?

Teoman — When you're drawing background blocks you have to have a mental picture of what you're doing. Most people would draw a pretty picture and then cut it up in blocks, but that's an inefficient way. Ultimately it's the best way, it looks far better, but you end up with thousands of blocks which are used only once. The more useful way is to think in blocks. You have to have a blocky way of looking at things, start seeing things as bricks.

John — You always have to make an object work within the block of 32. You have to make any pattern repeat in multiples of 32 pixels across by 16 down. That way when they're fitted together they merge. Tricks like dark black shadows on the edges of a block can be used to help it blend into the block next to it.

AF — In First Samurai there's a neat effect where the sprite walks behind some of the background, how's that done?

Raff — To get the 3D effect where the sprites go behind some areas of the background, you have to print the screen in three stages. First you print the background, then you print the sprites on top of that and then you print foreground blocks on top of that. In First Samurai we added another stage because someone had the bright idea of having masked background blocks overlaid on top of everything else. Here you take a background block and treat it as a sprite. Take for example the tree seen at the beginning of the demo. You can't just lift the whole tree and slap it on. It needs to masked because it's an irregular shape. I create the mask by assuming that wherever there is sky colour in the block then the background will show through. Then you can overlay that reduced shape on the top of the masked background, but that starts to slow the game down if it's used too much.

AF — Often the background itself seems to animate, is this done with sprites?

John — Certain areas of the background actually cycle through a series of animations and as the screen's being updated anyway, it takes no more processor time. The original spec was to run every 12 frames a second. As it turned out, thanks to Raff's "super efficient" code we could have run at 25 frames a second. The sprite animation was geared around 12 frames a second. But by using background animations we can add that extra illusion of movement and action.

AF — So once you've got the sprites and background, is the information, coordinates etc. typed in to the game where they are united with the core game program?

Mev — We wanted to write a graphics package specifically for the game, which would allow us to implement our ideas and experiment with them quickly. So, John wrote a game editor which multi-tasks with DPaint. This allows Teoman to build up the map backgrounds and test them. If they need adjusting he just flicks back to DPaint and puts it right. Therefore the editor was the first thing we started to program.

Raff — I insisted upon it. It's hard to develop a game without some kind of map editor.

Mev — John is actually still working on the editor now and it's always being enhanced, as the game design develops.

John — I was making more modifications to it only last night!

Raff — New features are always being added. One late introduction was the ability to turn background blocks upside down, effectively doubling the number of blocks. Although we hadn't implemented it initially, it was easy to do, but we just hadn't thought of it.

Mev — It now looks as if the editor will be finished in parallel with the game. It's now very powerful as it allows you to play around with the map.

Raff — And I don't have to type in bit tables, it's pick and place!

AF — So you can toy with the background blocks in the editor, but how is the game assembled?

John — What you can stand on is determined by a separate map which we call the edge of road. This has much smaller squares than the background map, and that's a facility of the editor. It allows you to define what you can stand on, what's solid, what you can jump through and what you can climb up.

Raff — The graphics aren't "assembled" as a screen until they are called in the game, but there is a facility in the editor however which allows you to see the backgrounds, the background 3D and the masked 3D simultaneously. And over this we create the edge of road map and store information as to what starts an attack or initiates an effect. The fire sound effects, for example, you only hear it when you reach a certain effects block. It's simply a block that activates the effect when it either appears on the game window or the player sprite touches it.

The way I use an effects block may vary. The bat effects block for example triggers as soon as it appears on the game's screen, it's a global command. Whereas others may refer to a specific opponent's which appear from where you've laid down the specific effects block.

John — It's important to remember that the screen display is just an isolated window on the game and edge of road maps. It's like a word processor where you only see part of the document. But because the edge of road map is held complete for each level, it's possible to keep track of opponents even when they are off the edge of the screen.

AF — And with the editor the artist assembles the backgrounds, then the programmer puts the edge of road and effects blocks on?

Mev — Raff actually did the background maps himself, because he felt that it was easier to design the maps and implement the game elements. If the artist had created the map, then the designer would have to work around what the artist had done.

John — The problem is that the artist is going to make gaps too wide so you can't jump across them or roofs too low so you walk under them without even realising it. You don't want those kind of problems.

AF — So is all this done on an Amiga?

Raff — No, I develop on a PC, PDS editor slaved to my Amiga, which just sits there and breaks down a lot.

John — The maps, background and edge of road are built on the Amiga and then the data is uploaded on to a PC, where it's assembled into a game; this is where the code and routines that drive the game are added. Then, when we're testing we just squirt it down a wire into the Amiga. We use this system because if the game crashes, you never lose your code which is still in place on the PC. If you were testing the game on the machine it was written on, you run the risk of losing the code due to data corruption every time it crashes.

AF — Once you've got all the graphics, the backgrounds, the maps and effects assembled how does the game process them all and produce a screen of graphics?

Raff — What you've got is an invisible 'screen' where the next overall games display is calculated and made ready to print. When it's been created, the hardware just switches to that 'screen' and displays it. While it's displaying that one, the next is being stuck together on the invisible screen. It's called page flipping or screen switching. The beauty of it is, that no matter how many sprites there are, it will never flicker because everything's always done on the hidden screen. The worst that can happen is that the game will slow down, but it will never flicker.

AF — In what order does the program assemble all this information?

Raff — Well a simplified version of the main game loop goes like this, although each of these stages contain several other sub stages, but the full list would take pages!

MOVE THE MAN — Call the routine that handles the man's movements. It checks the joystick for any movement and then move man routine works out where you've moved: left or right, up or down.

UPDATE COORDINATES — Depending on the man's movements, determine where exactly in the map you're pointing the screen. As the Samurai is the constant what can be seen is determined by his position.

PROCESSING EFFECTS BLOCKS — That will determine which sprites get initialised. The game checks to see if anything is triggered by the character's position.

BUILD UP THE BACKGROUND — This is done on an invisible screen that you can't see yet. All the relevant background blocks are called from the block data pool.

MOVE ALL THE SPRITES — This may include some of the ones triggered off by the effects blocks and you also take the ones that were on screen in the last frame, moved on to their next frame of animation.

PRINT THE SPRITES — Mask the inverted outlines of both man and opponent sprites, then print them on to the background.

PRINT THE BLOCK 3D — Print the 3D background blocks over the top of everything. No mask is needed as the block is a rectangle and it can be slotted straight into the memory map.

PRINT THE MASKED 3D — Mask over the background and sprites and then print the masked 3D blocks.

CHECK FOR COLLISIONS — Check to see if any of the opponents hit the man and vice versa.

STATUS CHECK — has the player's energy gone below zero etc? If this is the case a new sequence will be called next frame.

LOOP — Re-run to the top of the list and start all over again.

For loop see loop. A new screen is being drawn every 25th of a second and the character sprites are moved and redrawn every 12th. Commanding the animated sequences via the joystick, the monitor's window on the world scrolls around the game map following the character. Every joystick command simply calls stored sprites and backgrounds which assemble on screen. Once the character sprite encroaches on an effects block, the game calls the respective enemy sprite into action.

Behind all the graphics lay the game routines, the alien 'intelligence' and the intuitive judgement involved in game design. It takes good graphic work though to tell their story, to create that magic. Using sleight of screen and processing speeds that outstrip the human eye, the game appears to flow fluidly as you fight the latest monsters in a terrifyingly picturesque world. It's hard to believe that the entire game is simply displayed as a series of static screens, that nothing ever actually moves. It is easy to forget though when you encounter the bats!

Who is that Masked Man?

When a screen is drawing it has to do so in one fluid motion, drawing horizontal scan lines from the top left hand corner to the bottom right. Obviously the game can't draw the background then go back and draw the sprites on top of that so 'holes' have to be cut in the background where the sprites will appear. This is where masks come in. Like a pastry cutter the mask is the exact shape of the sprite. With the coordinates calculated from the man's movement and the using the reference points of each 'sprite box' within the next animation frame the program knows exactly where the top left hand corner of each sprite box will be placed. The mask — an inverted outline — of the sprite is then taken and stamped onto the background. The game will now not print any parts of the screen obliterated by the solid part of the sprite, but will print background where the empty part of the sprite box falls.

So what does the editor do?

John Twiddy — The editor has to use the Amiga's operating system, so that it can access hard drives, second drives and of course DPaint. Using the editor is simple. You select blocks, that have already been defined, from a menu and past them down on the map.

Each block of background, 3D background, masked 3D background or background animation frame only has to be defined once and then it can be tried, tested and included with the click of a mouse button. Previously, all this would have to have been typed in, which is hard work and far more hit and miss than a graphic interface.

Will it be used to develop other games? "We've spent so much time developing this editor, that if we don't use it again we ought to be shot!"

Collision Detection

Collision detection uses boxes. For a sprite you just specify a box size for that sprite. Anything going into that area is considered to be a hit. For each character, you'll have two boxes, one for where the body is vulnerable and one for where the weapon strikes. To check, the game just has to cross reference "Has that opponents sword square hit my vulnerable square and vice versa?"

So say for example that the sword is coming down on an opponent, before it actually draws the opponent it checks the boxes and if it's actually hit the opponent then it draws it as all white. Obviously depending on the frame of the sequence the sprites in that box size will change and that has to be manually typed in for each sprite. And to aid playability, the hero gets a slight collision advantage, with a smaller vulnerable area and more generous sword zone.

First Samurai Instructions

First Samurai is a tough and highly slick arcade adventure with strong beat em up overtones. With excellent graphics, merciless pace and outrageous sound, make sure you've a joystick in port two, a serious attitude problem and the volume turned full up.

After loading you are faced with a title screen which has a red pulsing border. After approximately 30 seconds of decompacting this screen changes and pressing fire starts the game. It's dying time!

The plot concerns a murdered Samurai master and his young pupil's search for the culprits. The lad starts without weapons and must use his karate skills to kill enemies. After a few clean kills he earns himself a sword to help in his quest. What's more, the boy's master is on hand in spirit form to help out in particularly tough situations.

When you first appear, stand still and practice the fighting moves — it's the only place where you won't be attacked, so make the most of these few moments of peace. When you're ready make your way to the right and be ready to battle.

If the swooping bats hit the First Samurai then his life energy is depleted (the arm found at the bottom left of the status panel). Hits also knock down the kid's Bushido rating, but this can be corrected by bashing beasties. Each kill adds to his Bushido power (shown by the sword in the bottom right of the status panel). When the sword is half complete, a blade flies into his paws and it's slice and dice. His fighting moves vary when using the sword, so again practice if you get a few spare seconds. Be warned that if the sword power goes below half, due to hits, then the sword will disappear.

Bushido power has another advantage, it allows you to stipulate the restart point for the next life. If the Samurai finds a pot — like the one he started next to — then he can crouch behind it and invest Bushido power in it. This means if he dies (when he dies!) the game begins from that point and not the far left. This saps about half of your available Bushido power, so kill something quick afterwards! You don't have to do this, but it is a useful trade off of current power for a good start next time round.

There is no definite aim in the demo, except points based slaughter, but there is a huge map to explore. On your travels you will come across a few features that will further either the score or the quest. First and foremost are the baskets of food. These need to be sliced a few times before they scatter grub all around, which puts life back into the rapidly shrinking arm gauge. They also have an excellent sound sample and are worth searching out just for the 'wow' factor.

To pick up any weapons or bonuses that litter the landscape the Samurai just needs to duck over them. If it's a weapon — knife or axe — then pressing fire while the joystick is centred will cause a missile to fly out in the direction he's facing. These may not be accessible though if the Bushido rating is low. The current extra weapon is displayed in the centre of the status panel between the lives, counter and the strength rating.

On top of the weapons are the magical tools by which the Samurai may invoke some of his master's power. The most powerful of these are the bells which summon the old guy. Used at the right moment (look for the Master's ghostly image) they can make the impassable passable. When you wish to use one, let the joystick centre and hold down the fire button. The current magical item carried is displayed to the right of the lives counter.

If all the monsters are to be found, Samurai must also search out the breakable flooring. Struck with either sword or foot, these areas give way revealing new caverns and dangers. Remember though if the floor is knocked from under a monster then it also falls, so time those cuts.

First Samurai is a game of exploration and experimentation. If you get stuck, try cutting into the scenery or using a special item next to the problem. If you use the logs and you are still stuck, then you've finished the demo — when you get there that description will make sense!

Scans

The Secret of Game Graphics was reproduced from Amiga Format issue 28 (November 1991) on pages 25-31.