Quote:
Originally Posted by Toffee
Really interesting reading all of this thread! 
Did you ever try to include parallax scrolling in your games ? It was only really custom Amiga games which did this well E.G Shadow of the Beast, Lion Heart, Agony, Elfmania etc.
[ Show youtube player ]
Notice the parallax effect on the lava
[ Show youtube player ]
I think the foreground playfield is in 4/5 planes because the background is done with repeating sprites using the copper! |
Thats a very nice use of the Amiga's hardware and like demo's you can tell it was designed for the Amiga because it stretches the playfields, hardware sprites and colours to the limit - there's a fairly complex copperlist driving all that activity.
I never really played with the Amiga's hardware that much because to use it in the ways this game does means designing things very specifically. Things like quantity and size of sprites and restricting horizontal scan lines of the background / foreground to 7/8 colours.
For example Gauntlet II easily had x12 16 colour sprites on a horizontal line which meant they had to be software based.
In Mortal Kombat the character sprites were again too big for hardware sprites, in MKI I initially created my blitter routine to use x3 16 colour hardware sprites for player 1, welded to a blitted strip for the rest. I couldnt use the 4th hardware sprite (remember there are only x4 16 colour, or x8 4 colour) because the screen width was stealing the 4th sprites DMA. I would have had to reduce the screen width by 16 pix to use the 4th and I think it was already 304 pixels wide visible (320 including the scroll buffer).
Then I ran into the A500's timing issue where a pair of the 3rd sprites planes would loose their DMA slot occasionally causing screen glitches - so I ended up turning the 3rd one off. It ended up being a right pain using the hardware sprites (all the extra code for managing the different data format for the hardware sprites) for little benefit. Remember the sprite source was in FastRAM so the 68K still had to decompress the data into the hardware sprite space in ChipRAM - hence I dumped it for MKII and nobody ever really noticed. Atleast I think I ditched it for MKII, I may have dropped it near the end of MKI development to reduce code size etc.
I was always frustrated by the knock on effect of game demands where you couldnt do one thing because of that which meant you couldnt then do something else etc. Whilst I loved the Amiga and it really is a cool piece of kit I its only design flaw was providing both the CPU and custom hardware direct access to all the memory all the time. It would have been better if the ChipRAM had been paged, so the 68K could see, say, 128K at a time whilst the custom hardware could see the other 384K. That would have given all the 68K's cycles for more hardware sprites, whilst the 68K could have truelly parallel processed controlling the custom hardware via the custom registers. That would have made the Amiga more like the arcade machines I was trying to emulate.
The other problem I had was creating games that were being written for all formats, sharing source graphics etc. at the time writing solely for the Amiga was a luxury my mortgage lender would not have been happy about
. But I do think the best games were the originals, that were developed specifically for the machine, so that the game had playability, smooth 50Hz framerate and gorgeous graphics, albeit with lots of background action and only a small amount of foreground action.
If you take the background away from the game you linked to above the foreground becomes a pretty boring place, take the background away from MKII and you still have a lot of action all the time. So I guess its swings and roundabouts.