Quote:
Originally Posted by StingRay
These are no bad words. It's just impossible to judge code quality when you don't have any actual code to look at.  |
Here is some code then, I don't know about quality but I recall enjoying writing it...
It's called "STRIPPER - SPRITE STRIP BLITTER (16x16x16 COLOUR HARDWARE SPRITE EMULATOR)"
It creates a software/blitter version of the Megadrives hardware 16x16 sprites because the utilities which extracted and processed the graphics from the coin-op were originally designed for the Megadrive. Although the colouring was changed for the Amiga given the palette was different.
In a nutshell, and if my memory remembers (it was 15 years ago!). Each frame was cut up into 16 x 16 characters. As this was done the frames were moved about slightly (as 16 pixel high strips) and flipped in both X & Y to try to match the current character with one which had been created previously. For example there is usually a 16 pix x 16 pix "space" between a fighters legs when standing. But the space may lie across a 16 pixel boundary. So moving the characters slightly and flipping/flopping squeezed the character set size. So each fighter frame then consisted of a map grid file which held character references to the SCH file. All the frames were stored pointing one direction and hence need to be reflected realtime as required.
Each 16 x 16 tile was then compressed using Nick Pellings code to squeeze everything further.
The game logic runs at the same pace as the coinop (60Hz), and the screen is refreshed every 1,2,3 or 4 vertical scans (there is a nobble somewhere for PAL to account for 50Hz). So sometimes there are moments when the game logic is refreshed 4 times for a single screen refresh. This had to be done to maintain the fluid nature of the game and cope with the amount of screen processing required.
The 16 x 16 pixel characters were decompressed, shifted, flipped and flopped into a frame buffer by the 68000 from fast ram (512K to 1024K) to chipram. So once a frame had been built there was no further build overhead until the frame was changed. I recall that changing direction caused a cycle hit because of all the reflecting required but that once a cycle of frames had occurred (for eg whilst standing) that the reflections wouldn't be required until the fighter changed direction again. But now I cant see how that would have been possible, without delving into the code that is and I dont have time right now.
Once built the frame was then blitted onto the screen using a standard cookie cutting minterm (16 colour sprite onto a 32 colour screen, the 5th plane was cleared/set using the mask).
There were 2 screens one being built whilst the other was displayed then they got flipped to display the new frame (see the memory map above).
A full copy of the background was stored in memory for a set of fast blits to remove what was drawn on the hidden frame last time, "MrSheen" cleaned this up with a few simple rectangular blits.
One of the benefits of an A1200 (with 2MB RAM) was having a word reflection table (128K) and the code was written to fully use the 68020's (256 byte?) cache for the reflection of a 16 x 16 character. One of the reasons why running on the A1200 was smoother.
The sort routine at the top of the file was good in that it had a low overhead if the data was in roughly the right order, which for this game wasn't really an issue but the routine was used in lots of other games where sprites were sorted vertically and on lots of platforms from all the 8-bits to ST and Amiga - I originally created it on the BBC Micro. I worked at Gremlin in Birmingham, based at US Gold / Centresoft and we had the office in Sheffield plus Derby (which became Core) and there were loads of developers coming and going etc.
I had a copy of Atari ST Ramrod (the only one) but cant find it now. There was an Amiga version too but it was mainly an ST game (Amiga version was smoother thanks to the blitter, it didnt use the hardware sprites but should have done etc).
I still have all the code, the development tools and my Mega4ST plus an A600 Amiga so if I cobbled a parallel cable together I could in theory re-build the game onto a pair of floppies but time is always an issue
. It was a Gremlin game which was never completed because Kev Bulmer and I left Gremlin to go freelance (Golden Axe for Probe/Virgin I think).