Pac-Mania qualifies for a sprite trick analysis by the skin of its teeth, despite almost intentionally refusing to use sprites for anything other than Pacman himself! There are a number of interesting techniques and tricks in this game, so I decided to analyse it anyway.
The game runs at 50 frames/second in dual-playfield mode. There's an 8 colour background layer, an 8 colour foreground layer (7 colours + transparent), and 4 attached sprites (15 colours + transparent) combined to create Pacman himself.
Because the programmers Pete Harrap and Shaun Hollingworth used overscan mode to make the screen so large, multiple sprites are disabled (always starting with the highest numbered sprite). This is the reason the game only uses the first 4 sprites.
Here's how the various layers look:
You may be wondering why the shadow under Pacman was not drawn into the sprite itself. The reason is because when Pacman jumps, the shadow would have stayed attached to him, ruining the illusion that he was jumping at all.
The programmers could have worked around this limitation (if required) by setting aside enough memory for the 2 Pacman sprites at their maximum jump height, and combining Pacman and his shadow into a new sprite.
The game could have easily re-used the 4 Pacman sprites to create the score at the top of the screen and avoid having to draw that each time, since the score is only 64 pixels across. It would have taken up the four sprites (in 3 colours + transparent) and would have been a perfect use of them, as Pacman cannot occupy that same position on the screen.
I would personally have also drawn the life counter in the bottom corner with sprites for the same reason.
Before each level begins, the game creates an enormous bitmap in memory (880x848 pixels) containing the background blocks and the dots that Pacman eats. This massive bitmap takes up 280k of chip memory, and when Pacman moves from one half of the map to the other, it switches the display pointers around. If you look closely, you will see that some of the dots on the map appear twice, and others appear four times! When a dot is eaten by Pacman, the game has to replace the background graphics (to erase the dot) in all locations on this huge bitmap:
Due to its size, it's not possible (or necessary) to double-buffer the background layer. The game simply scrolls it around by changing a few values in the copperlist.
The foreground layer is double buffered, and Pacman's shadow, the ghosts, the score, and the remaining lives are drawn onto this layer. Each 50th of a second, the game switches the buffers around so that there is never any flickering.
The first 8 colours in the palette are for the background layer, the next 8 are the foreground, and the final 16 are for the sprites. Five of the palette entries are black, but that's because the game has a black background (colour 0), colours 8 and 16 are transparent colours (so they could be anything), and both the foreground layer and Pacman sprites need to have black as part of their graphics, so they both need an additional black colour):
Avoiding use of sprites
I mentioned earlier that the game did as much as possible to avoid using sprites. When I first looked at the game, I wondered how the programmers managed to obscure parts of Pacman when he went behind the foreground layer blocks as seen here in the arcade version. The answer is - they cheated:
By making the blocks slightly taller and further apart, they left just enough room for Pacman to never be obscured by the block. If you look at where he is positioned when going horizontally, he's actually much further up the screen, and the dots also look like the're laying on the floor rather than hovering in mid-air like the arcade version. Every level uses exactly the same trick:
I am sure it would have been possible to copy the Pacman sprite into memory and then slice the relevant pixels out of him for the various effects, but the Teque team (probably wisely) decided it wasn't worth the trouble. You would have had to do the same trick to the ghosts too.
On the arcade version, when you eat a ghost, bonus points appear in front of Pacman and move up the screen. On the Amiga, they are drawn on the foreground layer (which is obscured by sprites), so they also appear behind Pacman.
To avoid sprite tricks, they stretched tiles, moved Pacman up the screen, blitted the score and lives, but full credit to programmers Pete Harrap and Shaun Hollingworth for a fine non-sprite-trick conversion!
Atari ST comparison
The game was released by Grandslam in 1988, and at that time the majority of Amiga games were nasty Atari ST ports. It was refreshing to see that Teque created a custom Amiga version, so they should be commended for doing that, especially when you consider the crap that other software houses were releasing.
The mighty Amiga made the Atari ST hardware look second rate when both versions were compared. The Amiga version features possibly the largest low-resolution game screen ever (340x272 pixels) compared to the Atari ST (320x200). To really show the difference, the Atari ST screen has been displayed blown up to the same size as the Amiga version:
To really illustrate the point, the Atari ST's game area is 176x200 pixels (35,200 pixels in total, or 55% of the screen). The Amiga's game area is 340x272 pixels (92,480 pixels total, using 100% of the screen). And comparing the two platforms, the ST's game area is only 38% of the size of the Amiga version!
Because the Atari ST cannot smooth scroll the screen using hardware, the entire screen had to be re-drawn whenever Pacman moved. To get around this problem, Teque decided to create an enormous static panel on the right hand side on the screen. Truthfully, it looks reasonably good considering it's 16 static colours, but the gameplay suffers badly as you cannot see the ghosts approaching. The Amiga version updates 50 frames per second on PAL displays, double that of the Atari ST refresh rate.
The title screen is obviously much nicer on the Amiga with an extra 16 colours available:
The colours used on the level select screen look pretty dire on the poor Atari ST when compared to the Amiga too. I have no idea why they went for bright red, maroon, black and combined it with calf-shit yellow on the ST:
Finally, here's the copperlist for anyone interested:
Chip Addr: Copper instructions ; Comments -------------------------------------------------- $000057D4: 0096 0020 ; DMACON = 0x0020 $000057D8: 0101 FFFE ; Wait for vpos >= 0x01 and hpos >= 0x00 $000057DC: 0162 0000 ; SPR4CTL = 0x0000 $000057E0: 016A 0000 ; SPR5CTL = 0x0000 $000057E4: 0172 0000 ; SPR6CTL = 0x0000 $000057E8: 017A 0000 ; SPR7CTL = 0x0000 $000057EC: 0132 4FF4 0130 0000 ; SPR4PT = 0x00004FF4 $000057F4: 0136 4FF4 0134 0000 ; SPR5PT = 0x00004FF4 $000057FC: 013A 4FF4 0138 0000 ; SPR6PT = 0x00004FF4 $00005804: 013E 4FF4 013C 0000 ; SPR7PT = 0x00004FF4 $0000580C: 0096 8020 ; DMACON = 0x8020 $00005810: 009C 8001 ; INTREQ = 0x8001 $00005814: 0100 0200 ; BPLCON0 = 0x0200 $00005818: 1001 FFFE ; Wait for vpos >= 0x10 and hpos >= 0x00 $0000581C: 0122 F47E 0120 0000 ; SPR0PT = 0x0000F47E $00005824: 0126 F4E6 0124 0000 ; SPR1PT = 0x0000F4E6 $0000582C: 012A F54E 0128 0000 ; SPR2PT = 0x0000F54E $00005834: 012E F5B6 012C 0000 ; SPR3PT = 0x0000F5B6 $0000583C: 1801 FFFE ; Wait for vpos >= 0x18 and hpos >= 0x00 $00005840: 00E2 05C0 00E0 0004 ; BPL1PT = 0x000405C0 $00005848: 00EA 7220 00E8 0005 ; BPL3PT = 0x00057220 $00005850: 00F2 DE80 00F0 0006 ; BPL5PT = 0x0006DE80 $00005858: 00E6 A164 00E4 0002 ; BPL2PT = 0x0002A164 $00005860: 00EE D024 00EC 0002 ; BPL4PT = 0x0002D024 $00005868: 00F6 FEE4 00F4 0002 ; BPL6PT = 0x0002FEE4 $00005870: 0108 0040 ; BPL1MOD = 0x0040 $00005874: 010A FFFE ; BPL2MOD = 0xFFFE $00005878: 01A2 0440 ; COLOR17 = 0x0440 $0000587C: 01A4 0550 ; COLOR18 = 0x0550 $00005880: 01A6 0660 ; COLOR19 = 0x0660 $00005884: 01A8 0770 ; COLOR20 = 0x0770 $00005888: 01AA 0880 ; COLOR21 = 0x0880 $0000588C: 01AC 0990 ; COLOR22 = 0x0990 $00005890: 01AE 0AA0 ; COLOR23 = 0x0AA0 $00005894: 01B0 0BB0 ; COLOR24 = 0x0BB0 $00005898: 01B2 0CC0 ; COLOR25 = 0x0CC0 $0000589C: 01B4 0DD0 ; COLOR26 = 0x0DD0 $000058A0: 01B6 0EE0 ; COLOR27 = 0x0EE0 $000058A4: 01B8 0FF0 ; COLOR28 = 0x0FF0 $000058A8: 01BA 0FF2 ; COLOR29 = 0x0FF2 $000058AC: 01BC 0FFF ; COLOR30 = 0x0FFF $000058B0: 01BE 0000 ; COLOR31 = 0x0000 $000058B4: 018A 0EC0 ; COLOR05 = 0x0EC0 $000058B8: 0188 008E ; COLOR04 = 0x008E $000058BC: 018E 004C ; COLOR07 = 0x004C $000058C0: 018C 0008 ; COLOR06 = 0x0008 $000058C4: 0182 0666 ; COLOR01 = 0x0666 $000058C8: 0180 0000 ; COLOR00 = 0x0000 $000058CC: 0186 0888 ; COLOR03 = 0x0888 $000058D0: 0184 0AAA ; COLOR02 = 0x0AAA $000058D4: 0190 0000 ; COLOR08 = 0x0000 $000058D8: 0192 0000 ; COLOR09 = 0x0000 $000058DC: 0194 00A2 ; COLOR10 = 0x00A2 $000058E0: 0196 0A00 ; COLOR11 = 0x0A00 $000058E4: 0198 0CC0 ; COLOR12 = 0x0CC0 $000058E8: 019A 0CCC ; COLOR13 = 0x0CCC $000058EC: 019C 006E ; COLOR14 = 0x006E $000058F0: 019E 080E ; COLOR15 = 0x080E $000058F4: 0102 000A ; BPLCON1 = 0x000A $000058F8: 0104 0044 ; BPLCON2 = 0x0044 $000058FC: 1B01 FFFE ; Wait for vpos >= 0x1B and hpos >= 0x00 $00005900: 0100 6600 ; BPLCON0 = 0x6600 $00005904: FFDF FFFE ; Wait for vpos >= 0xFF and hpos >= 0xDE $00005908: 2B01 FFFE ; Wait for vpos >= 0x2B and hpos >= 0x00 $0000590C: 0180 0000 ; COLOR00 = 0x0000 $00005910: 0100 0200 ; BPLCON0 = 0x0200 $00005914: FFFF FFFE ; End of copperlist ; Wait for vpos >= 0xFF and hpos >= 0xFE
Post your comment
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments
Popular Sprite Tricks
2 sprites are displayed then repositioned horizontally right across the screen to create the colourful static background. The remaining sprites are used for the main character, the status bar and player bullets.
The 16-colour background layer was created by using all 8 hardware sprites and repositioning them across the screen. The same 64 pixel wide graphics are repeated across the entire play area.
One of the first jaw-droppingly beautiful Amiga games that still looks great today. Sprites were heavily re-used on the screen, along with priority changes to make them appear between the playfields.
The amazing tunnel sequence was created with a 6 frame animation sequence made with only 4 colours and mirrored vertically. The asteroid layer sits on top of this, with a status panel and player ship made of sprites sitting on top.
hi, no more articles?
Bren McGuire 02/08/2020 1:33am (3 years ago)
Very interesting article (and nice blog).
Could you also include the analysis of the new Atari STE version ?
it's fullscreen, smooth scrolling and all.
the chiptune still sucks though :)
Djamé 18/10/2018 8:43am (5 years ago)
It would be interesting to describe Pacmania on the Acorn Archimedes, 100% software coded using its CPU. The author spoke about it, either video or comments on YT. Thanks.
Xavier Louis TARDY 12/12/2017 7:42am (5 years ago)
Very interesting reading.
Thank you for posting.
The article refers to the 16-bit versions of the game that were released in 1988.
STE was released in 1989 and the updated version was released in 2016, so i believe that such comparison is out of the context.
alex76gr 09/07/2017 6:42pm (6 years ago)
The Atari version of Pac-Mania was updated for the STE in 2016 :-). What about including it in your comparison?
Gerry 17/02/2017 10:28pm (6 years ago)
Very interesting indeed!
I have to agree with Anthony about the Lionheart review.
Also Awesome from Psygnosis would be interesting too, especially the scaling dragon.
VincentGR 06/01/2017 12:23pm (6 years ago)
great work, as you always do. It would be very interesting to analyse how Thalion made one of the technically best amiga games ever...Lionheart
Anthony 21/11/2016 1:25am (7 years ago)
Thanks a lot for all the very interesting articles, found the site a while ago and since then reading in detail all you write. Please keep the good work!
lurk 16/11/2016 6:15pm (7 years ago)