I’m overdue a few updates here, because a couple of important things have happened and I haven’t managed to find time to write about them yet. I’m going to start with emulation improvements on an arcade puzzle game from the year 2000.
Gunpey, a game that was apparently named as a tribute to the late Gunpei Yokoi (creator of the original Nintendo Game & Watch series) is an arcade port of the Wonderswan title of the same name, it was also ported to the Playstation.
Last time I looked at this driver was back in March of 2013 where despite making some good progress, I got stuck completely with the sprite compression.
Fast forward 5 years to March 2018 and I have some new progress to show. Peter and Morten, who have been working on numerous projects with me, hooked up some hardware to the Gunpey PCB that allowed them to log video ram read / writes. By using this hardware they were able to save the decompressed data for every compressed sprite, giving us plenty of plaintext material to use and hopefully make it easier to figure out the actual compression scheme.
As a step in this process the extracted data has been hooked up to MAME while the actual scheme is figured out. This gives correct sprites in all the cases where you could previously only see garbage due to the data compression. Obviously the work isn’t yet finished, but by using this data the game can be considered playable. Once the compression is figured out the end result should be the same, just with cleaner underlying code.
I also took the opportunity to add support for zoomed sprites, used when you launch an attack on the enemy. Here are some screenshots of the improved driver.
Working with the hardware also told us a few other things, like that the framebuffer is actually in the same RAM that the sprites get decompressed into, not a separate memory area, so there must be a way the game sets up the pointer so it knows where to write the framebuffer data. It was also confirmed that the framebuffer is double buffered. These features need hooking up.
One thing that isn’t yet clear is if the Arcade version really is meant to effectively run at 30 frames per second, only updating the screen every other frame. The Playstation release runs at 60 so appears to animate a lot more smoothly. There are registers to select the source of the drawing, but at the moment they really do only change every other frame, so this might require some further investigation. Unfortunately while there are a lot of original hardware YouTube videos none of them are HD 60fps videos recorded on a 60fps camera that could show me if the game is / isn’t meant to update every frame.
Anyway, here is a video I’ve recorded showing the progress so far, obviously this is a big improvement over how it has been in previous MAME releases.
If you need help figuring out the compression scheme, you know where to find me :-)
OG.
I can’t imagine it taking very long for Mamedev to emulate this game fully. Haze and company do this in their sleep.
OG is a lot better at decompession stuff than most of us are tho, although in this case I have a gut feeling it’s not actually going to be too complex once we actually figure it out, and having all the plaintext data will definitely make it easier. I don’t like to call on OG unless we are genuinely 100% stuck with something like this because there are many more important things he already has in his todo list.
Let’s find out.
Dear CrystalCore,
Just for your information, I’ve been a Mamedev for around 20 years or so.
Yours sincerely,
OG.
That comment sure made me chuckle :)
Another great job. We welcome all games even not so best (this one loooks promising).
Guys about one Atari proto title. Any chance to fix that nasty shadows in Vicious Circle. Just 4 that one I use old 0.72 mame version,. Regards.
I don’t see an easy way to fix it without a hack that would break other Jaguar titles.
The Jaguar hardware is stupidly complex, the MAME emulation is very much incomplete…