(WIP) David Haywood's Homepage - 模擬器

2013.08.15

"Road of the Hidden Bits"

One technique Seibu liked to use is encoding additional data with their
tile graphics in otherwise ‘unused’ planes, I encountered this before
when fixing the emulation Dynamite Duke where Seibu stored the priority
data in an extra plane of the tile graphics (I do wonder if the Alpha
in SPI might be done in a similar way, although it would be obvious if
the maths didn’t add up so unless there has been a massive oversight I
admit it’s a little unlikely)

Another technique Seibu liked to use is massive ROM based tilemaps. This
technique obviously has limitations (you can’t change the tiles, so you
can’t animate anything, but mean you don’t need any RAM or CPU power
beyond writing scroll registers to display huge scrolling backgrounds)
Actually Air Raid / Cross Shooter uses this technique along with custom
ROM modules on the PCB which end up acting more like background generators
containing both the graphics and tilemap definitions with no CPU access
other than providing co-ordiates of the background map to draw (hence
why that one isn’t emulated yet, we have no good technique for extracting
the data in a non-hacky way)

This post isn’t about Air Raid tho (Kale did make some recent
improvements to that, but without the graphics being dumped it’s never
going to be interesting) instead it’s about another Taito / Seibu
collaboration, this time the early Video Pinball title ‘Panic Road’

Panic Road employs both the techniques mentioned above, there is a single
extra bit of priority data in the tile planes representing the priority of
tiles vs. sprites, and the tilemaps are stored entirely in ROM.

What is unique about Panic Road compared to other Seibu devleopments is
that there are 2 more bits of ‘invisible’ data in the tile planes, these
are responsible for collisions and until now haven’t been understood
properly.

I took another stab at this yesterday, and this time managed to come up
with some good results. First of all I identified the priority bit (it
hadn’t already been identified) and implemented that, leaving me with
just the 2 bits of priority.

The collision readback window on the hardware was a 0×4000 byte region,
assuming that both collision bits can be read back then 2 bits of data
with a size of 256×256 occupy exactly 0×4000 bytes. The full area of t
he screen is approximately 256×256 (the edges are cut off for actual
display) so that was my starting point. Turns out that this was a good
theory, and the area is kind of a readback of the invisible (collision)
bits of screen data although the way it interacts with the scroll register
is a little strange, eventually I managed to figure it out tho.

As a result the game now appears to be playable. If anything the
sprite-sprite collisions are letting it down, but those are handled
entirely by the game software, so I have to assume them to be correct
unless I can find a reference video of the game being played properly
to prove me wrong. Actually a good reference video would be handy anyway
because sprite-sprite priorities are almost certainly wrong right now.
As a game it doesn’t seem to hold up very well compared to later video
pinball games, the physics are horrible and the entire game seems to
really revolve around you using the 100 ‘shakes’ you get per level to
get the ball to go where you really want it rather than any kind of
precise aiming skill. It’s no Pinball Dreams for sure!

http://mamedev.emulab.it/haze/pics2013/panicroad_1.png
http://mamedev.emulab.it/haze/pics2013/panicroad_2.png
http://mamedev.emulab.it/haze/pics2013/panicroad_3.png
http://mamedev.emulab.it/haze/pics2013/panicroad_4.png

The collision data is quite interesting, one bit of the data represents
solid objects, things the ball should not pass through, the second bit
represents areas where the flippers can take effect, I’m not entirely
sure why this was necessary but if you return blank data for those bits
in the readback the flippers simply don’t work.

I’ve used the MAME tilemap viewer to show some side-by-side shots of
the level graphic data, and the collision data below, there is no
separate shot for priority data as I’d already fully integrated it as
hidden data in the regular level graphics by the time these shots were
made. It should hopefully give a clear representation of the collision
types, you can clearly see where the flippers go from the different
colours collision map! This visual representation was very useful for
working out the meaning of the bits.

http://mamedev.emulab.it/haze/pics2013/panicr_bg0.png
http://mamedev.emulab.it/haze/pics2013/panicr_col0.png

and another level

http://mamedev.emulab.it/haze/pics2013/panicr_bg1.png
http://mamedev.emulab.it/haze/pics2013/panicr_col1.png

I’ve also put together 2 videos, both are playbacks of the same MAME
inp recording, one displays the regular backgrounds, the other displays
the collision map data instead.

http://www.youtube.com/watch?v=gWK0bk6hzoo&feature=player_embedded
(Regular video)

http://www.youtube.com/watch?v=X7n5i5QKN24&feature=player_embedded
(Collision map video)

Nothing especially complex here, it just required somebody willing to
experiment a bit and a fresh pair of eyes, I dare say anybody could have
actually fixed this.

As mentioned, a few things could do with verifying on the original
hardware (I especially wonder what the conditions are for falling down
the killer black holes in the middle of the playfield, although that
could be another sprite priority issue, or depend on the speed the ball
is moving)
______________________________________________________________________________

來源：http://mamedev.emulab.it/haze/2013/08/14/road-of-the-hidden-bits/

--

ポーラステーション
http://perryt0517.wordpress.com/

--