We were excited to move to the Amiga since it meant we had a CPU that was 8 times faster than the C64, had more registers and better instructions, but... there was no character mode to use. The bitmap screen was 16K big in 16 colour mode, 16 times bigger than the C64 character screen.
We had used 8x8 pixel blocks on Rainbow Islands in order to emulate the arcade machine. We stuck with that for Paradroid 90 as we had built a custom editor to build the backgrounds, and a custom lossless compression routine. After that, and a few discussions with the Factor 5 lads, we decided that 16x16 pixel blocks was going to be more space efficient and easier to restore the background behind the plotted objects. Despite the faster and better CPU, we couldn't rebuild the entire background every frame, something the C64 did as a matter of course. When an object passed over an area of the background we flagged up which characters needed patching up afterwards (I believe, it's getting tricky to remember).
The 16-bit machines had just a bitmap for the screen. The Amiga had a number of tricks up its sleeve over the Atari ST though, Firstly you could start the screen on any 16 bit boundary, so as well as setting smooth scroll registers to scroll up to 15 pixels, you could slide the whole screen to the right, or left, by 16 whole pixels, retaining most of the information on screen and not having to rebuild it. Then you could have 32 colours rather than 16, at a cost, or 64 colours on the A1200 and CD32. We also had 4 bits of red green and blue in the palettes rather than 3. The STE went up to 4, and the A1200 stayed ahead by going up to 8 for some really smooth fading effects.
Actually the Amiga also could handle 2 playfields, as used in such games as Shadow of the Beast. We did try that in an early version, with a 4 colour back playfield and a 7 colour foreground, scrolling in parallax. This gave us some nice extra depth, but the graphics artists weren't happy working in only 7 colours. The objects moving around over the background had to share those colours too, though we did later use the hardware sprites as well as software sprites. Foreground objects were also difficult to see because with only 7 colours, everything used them all.
Having abandoned dual playfield mode, we went for 32 colour mode, arranging the colours in pairs, light and darker, so that we could skim shadows under the ships by only clearing one bit-plane of data, making plotting a lot faster. It also made sense to put black as colour zero and white as colour 31 so that we could flash a sprite white by setting all the bit-planes to the mask bits of 1 where there is data and 0 where transparent. You could also then set a sprite to all black by clearing the mask bits on all bit planes.
In order to use the blitter most efficiently for plotting objects on screen in one 'blit', we had to supply mask data for each bit plane, which would necessarily be identical to the other bit plane masks. Otherwise you have to reset the data pointers to the one supplied mask for each of the 5 bit planes, so you had to do 5 consecutive blits. That was inefficient because you had to wait for the blitter to finish each bit plane before starting the next, whereas if you blit all 5 bit planes in one go then you can be preparing the next object's plotting data while the blitter does its job. So it was the old fight of space versus time.
You can use more memory to save processing time. Often that might mean working out some outcomes in advance in a table. An example would be calling the random number routine before the level starts say 256 times and putting the results in a table, and then just lifting out the numbers as the level plays, which is faster than calling the random number routine during play. You can still afford to maybe combine two different numbers from the table and have the pointers stepping through the data in different directions to give lots more combinations, and you can write the new results back into the table to really mix things up.
So, back to Uridium 2. I wanted all of the effects that the C64 had, plus any more we could think of. The shadows could be done with just plotting to a single bit plane, so nice and quick. Stars are easier to do on a bitmap screen because you only have to plot a single pixel for a star where the screen had space-colour. We had tried this out on Rainbow Islands. on Monster Island. Once you have collected the big gem on that island, the stars come out next game, if memory serves.
I took all the parameters of the control mode from the C64 version, plus allowed the Manta to fly upside-down. What that would have done to the pilot in reality is anyone's guess!
We added vertical scrolling in on later levels, just because. We also added a second Manta and some additional 1 and 2 player modes. Glowing colours were achieved by reserving two consecutive palette colours and changing them every couple of frames. Glowing colours can be useful for Uridimine ports, engines or lights. I also added the radar display later on, but with a twist that there could be radar jammers on the ships. Go near one and you lose some of the radar capabilities but can still just see through the static. Go near 2 or more jammers and the radar is useless. By destroying the jammers you get the radar back.
Choosing your limited palette can be agonising. Going back to Rainbow Islands, we had 16 colours per level, and some colours had to be consistent across levels, particularly the main player graphics, the rainbows and the gems. We tried to allow a couple of floating colours so that an island could have a bit of uniqueness. The arcade machine had less limitations because the sprites and the background each had their own palettes of 16 colours, plus they could have 2 or more palettes per level. We were always chasing the arcade hardware. John Cumming agonised for some time over getting the colours right, but it was worth it in the end.
Since the Uridium Manta was predominantly white, we reserved a small block of colours for the Manta and its weapons. I then let the graphics artists choose the rest, only stipulating that the bits of background you can crash into had to be easy to see. I can't say that it was easy to get graphics we thought were suitable. We had 4 or 5 graphics artists who gave it a go. Some of the schemes they came up with were really pretty and organic, but difficult to navigate at speed. We also found that the ships we thought would be the first few levels were too difficult for some people to play at first, so we had to do some even easier ones.
We also tasked the graphics artists with providing sprites for the levels. Some would be ships, others vehicles on the surface. Some created hatches that opened and closed, or laser turrets. Depending on how difficult the levels are to play, we would have to rearrange the levels. Whist some of the tuning, like Uridimine numbers and frequency was based solely on the level number, objects solely available on a set of 4 levels had their own tuning. We had an end sequence for Uridium 2 rather than sending you back to the first level with the difficulty racked up on the C64 version. End sequences can be expensive on graphics that are only used once. Arcade games didn't usually have them early on for the same reason and because they just wanted to see how far you could get on 10p against ever increasing difficulty.
The Amiga hardware sprites were a bit of a let-down, being only 16 pixels wide and once combined into 15 colour mode you had 4 per raster line, but they did show that by being the full height of the screen that you could switch them on and off, and that's pretty much what our sprite multi-plexors on the C64 were doing, just moving a sprite that has finished displaying high up the screen further down so it gets displayed again, at a small cost. You couldn't do any bit plane "tricks" with them to get shadows and they would display over the top of any software plotted sprites, so maybe good for bullets, things that move fast and don't linger. Quick to plot though, and no background clean-up needed afterwards.
We tried to add some additional weapons too, for the Manta. We found though that they tipped the balance of the game too much in the player's favour, so we had to rig them to run out fairly quickly. I did like the homing missile algorithm. Initially, because the homing missiles had a slow rate of turn they could miss a target, turn to have another go but not be quick enough, and end up orbiting the target. This was clearly not satisfactory, and you might now occasionally spot this starting to happen, but the missiles are now improved to recognise the looping situation and they go a bit further away before looping back successfully for the kill. Problem solved!
0 nhận xét:
Đăng nhận xét