How Layer Priority Works (and GnG update)

A nice graphical effect is to have the characters go underneath elements in the screen. Like the soldier behind the palm tress in Commando.

One way to create this effect is to have that background drawn directly on the sprite layer, using sprites as though they were tiles. That is the approach followed in Commando. If you boot up Commando in your FPGA and press F10 the sprite layer will disappear. You'll see that along with the soldiers, the top of the palm trees and the bridges disappear too. By the way, in case you didn't know, you can blow up the palm trees with grenades!

But using sprites as background tiles is cumbersome. The position in the screen of each sprite must be updated as the background scrolls around. This requires software attention. So hardware developers came to the rescue.

All games had to merge the different graphical layers: characters, background(s) and sprites (or objects). Which layer was to be shown upfront depended upon its colour. If the characters were not blank, then those had priority. If sprites were not blank then the sprites. Then one scroll layer, then the other. Colours were not absolute RGB values, but just an index in a palette memory (sometimes in ROM, sometimes in RAM). So whether or not a pixel was blank was determined by the index in the palette. CAPCOM games use index 15 as the blank value. But along the colour index, there were some other bits for each pixel. Some of them could indicate which subpalette to use. And one of them could be used to promote or demote layers. 

A particular bit could be set to send a sprite behind the background, or to push the background over sprites. This one bit approach is useful, but you can imagine that it forces that background tile to have a blank region that would look just black on screen if there are no sprites around. An even better technique, seeing in Tiger Road, for instance, is to assign a scroll tile to the background or foreground depending on the colour index. So for some palettes, colours zero to seven would be drawn in the background but eight to fifteen in the foreground. This creates the nice effect of having more graphical layers than they actually are.

This can be seen in the opening of Black Tiger, when the dragon appears behind the mountain. The mountain is a background element and the dragon is made of sprites but priorities are reversed depending on colour. The opening of Tiger Road also shows enemy soldiers passing behind a rock, which is another background tile that has been promoted to foreground element by colour.

This priority selection was normally made using a 256x4 PROM memory (256 positions, each one of 4 bits). The inputs to this memory were colour indexes from different screen regions. The output was a value identifying the layer to be drawn: 0 characters, 1 scroll, 2 sprites, for instance. MAME normally does not use the PROM memories for this, yet they are available and documented as part of the project.

I normally use the priority PROM but I didn't do it for Ghosts'n Goblins. Recently I discovered that in my hand made priority equation I had lost one overlapping case. I have modified the core to include it. I must say that I haven't noticed any difference while playing so the actual software may not be using it. Just in case, there is an update file in the JTBIN server.