One thing that has been on my ‘to look at list’ for a while is Race Drivin’ Panorama, a special 3 screen version of Race Drivin’.
Hard Drivin’ / Race Drivin’ alone is a bit of an insane hardware setup, and Race Drivin’ Panorama makes that even crazier by adding 2 extra slave video PCBs to drive each monitor (based on the lower resolution ‘Compact’ releases, using a standard monitor for each of the side views as opposed to the medium res one used by the center view)
Luckily as MAME’s device model has improved and more and more code has been converted to a device structure it has become easier to support multiple video boards etc. without having to duplicate large amounts of code or worrying about shared global variables etc. so I decided to take another look at this. As it happens there was actually one part of all of this that hadn’t been converted to a device yet, the Slapstic, and because we have more than one of them on this setup that was actually something, to my surprise, I had to upgrade.
Anyway, after doing all that, including converting the video PCBs etc. to act as devices and hooking up the serial connection between the boards (which was remarkably easy) we end up with the following
It’s actually playable (albeit very slow, it has rather a lot of CPUs)
Unfortunately there’s what I’m starting to strongly suspect is a MAME core bug causing partial updates to not quite work properly on everything except the primary screen, you can swap the order of the screens and the primary screen (be it a side screen or the main view) will always render correctly, but the other screens will only partially update the display, usually in the wrong places, causing those displays to stutter and appear incorrect frequently. There doesn’t seem to be any use of the ‘first_screen’ in the driver code, so I strongly suspect it’s something core level causing the issue. Fingers crossed somebody can help track that down, and this will be fully playable!
*edit* I’ve managed to find a kludge around the display update issue, however upon further testing the side-screens crash if you select the Roadster car. According to real hardware sources the game should display a full 3d view rather than the car panels at the sides for that car, which is probably related (the GSP seems to time out loading pictures in MAME, when I guess it should simply fail to load them because they’re not present?) I’ve put up a video of the thing in action here, although the sound is out of sync due to MAME not liking it when you record multi-screen games with dyanmic refresh rates ;-)
http://img.pandawhale.com/37381-well-done-sir-gif-Imgur-Wiserh-Tr7d.gif
Incredible, 3 screen race game and finally working
Need a performance test about this game
amazing haze XD :) almighty polygons behold
ooh nice one haze :))
i wonder if underclocking all those cpus a bit will help with the speed :p
the perfect setup for hang glider simulation
you’d want a monitor below you, like Hang Pilot gives you ;-)
actually with this game, while they only ever made 3 screen cabinets, the sub-screen menu gives you a variety of positions, so you could probably run with a grid of 5×3 screens (somebody with the original PCBs set it up as 5×1) I’m not going to try anything quite that insane in MAME tho, I think a 15 screen game would be pushing MAME a little too hard ;-)
about the core issues: is aaron gone for good?
he hasn’t really been active at all lately, it’s one reason I decided to look at this in the first place, because I figured nobody else would.
it’s confirmed as a core issue anyway. while you’d expect to see a ‘line’ going down monitors that are running at a different frequency to the display (which is what you see) the core fails to update anything that is ahead of that line (which due to the difference in frequencies can actually be the part of a previous frame that needed updating, not the future)
this is why partial updates on the game kept going from 384 and creeping back up to over 900 over the course of a few seconds, when really it should be a sol 954 – it was forgetting to do the partial updates for anything not in sync with the current screen, causing significant parts of the display not to be updated.
i’ve hacked around it, although I’m a bit bummed out at finding the game side screens fail when you select the racester, either it’s an additional protection check, or we don’t fail in the same way as the PCB when it can’t find the car panel graphics for that vehicle.
haze, are you a linux user? ? :?)
Would Driver’s Eyes [driveyes] work similarly with this setup?
No, he’s a linux hater :)
Awesome to see Race Drivin’ get some love! I own a dedicated upright Race Drivin cabinet with rare prototype ROMs that aren’t in MAME. There’s some cool features that were removed on the public release, including multi-monitor support for the standard-res board (Multisync PCB I think is what it’s called?).
Whoah, I did not expect to see this … awesome. Hard/Race Drivin’ was essentially the reason I went to arcades in my teens and got me interested in MAME. I’ll probably get flamed for this, but I can’t help go full-fanboy since someone’s giving this a bit of love. Any chance you might take a look at the motor output while you’re in there? I think the interesting bits are in AM_RANGE(0xb00000, 0xb7ffff) but I couldn’t make any sense out of it. I know, no force-feedback in MAME itself but it’d be fun to play around with in MameHooker.
I would sure appreciate the help. Some of these FF games are a piece of cake… some… well… they aren’t.
I remember playing one of these 3-screen Race Drivin’ machines. Something tells me they’re extremely rare.
Wow, I even didn’t know a triple screen version of this game was made!
Awesome job, Haze!
That is a crazy amount of cpu’s what is each ones purpose?