To quote Smitdogg “ShouTime got an insanely rare basketball game called 3 on 3 Dunk Madness.”
You can read the original post on Mameworld.
Needless to say, it’s a nice find, A game from Video System, and I’m guessing it’s a prototype.
Hardware wise it’s the same as “Quiz & Variety Sukusuku Inufuku” in MAME, so adding it wasn’t too tricky, although time consuming because the driver was missing quite a few features (most of said driver is copy+pasted from older Video System drivers)
I’m currently in the midst of refactoring some of the Video System implementations anyway as most boards use a common set of chips and we have duplicate (partial) implementations all over the source.
The sprite zooming is currently wrong, causing the players arms / legs etc. to appear dismembered, I remember having this issue with a similar basketball game, also on Video System hardware, the Banpresto / Video System ‘Super Slams’ so I’m guessing the actual sprite hardware is probably the same, at a glance that appears to be the case so my ongoing work in cleaning up the Video System drivers should help there.
As Smitdogg mentions the sound is rather glitchy and I’m guessing wasn’t quite finished in this build, although I could say the same about Fifa 13 for the 360, I’ve crashed that thing 30 times in a week, makes me wonder how it passed any level of certification at all ;-)
The game is full of debug code and debug menus, and the roms full of debug strings (there are lists of every speech sample etc. too although I haven’t a clue how to bring up a sound test menu) which further supports that this is a prototype, probably use during a US location test of the game.
Anyway, no video for now, just lots of screenshots. This might *not* make the u1 build which is due in a few hours. It has been submitted, but it’s a bit close to the deadline. Note, like the other game on the driver you can switch between 2p / 4p mode with one of the switches (probably a line on the board if the extra inputs are connected, because I see no dipswitches)
As mentioned in the comments of previous posts there are other interesting WIPs at the moment too
Luca Elia got SunA’s Star Fighter going, which like most SunA games had an insane amount of protection for a Korean title. This has been submitted and will be in u1.
I also pointed J.Wallace in the right direction w/regards the MayGay M1A/B fruit machine hardware, which now boots further. This hasn’t been submitted yet (still lots of work to go, and I realise the M1A driver hasn’t been fully split into clones yet either)
Great news! This was on my “must find” list :)
How’s the gameplay? Is it the same as Slam Dunk?
It’s Basketball, I’m about as good at judging how the gameplay is as I would be on a Mahjong game ;-) You run around, you pass the ball between players, you put it in the hoop, just seems like your typical Basketball title so on that basis I’d say it was a lot like Super Slams. The most interesting aspect by far is all the debugging stuff in there.
Hi,
I’ve spent the weekend figuring out how to properly implement the use of hash files for my frontend. Works okay so far in most cases, though I’m having some problems. I hope you don’t mind me asking about it here.
For example genesis/megadriv/megadrij support. The name of the hash file I got is megadriv.xml, though the driver is listed as a clone of genesis (shouldn’t the xml be named after the parent?).
The thing is that, when I try for example to run a game using the genesis driver, it is unable to find the rom in the /megadriv folder. It needs to be in the /genesis folder. That’s alright, but the weird thing is UME won’t find it there either if it’s 7zipped (haven’t tried zip). If uncompressed, it works.
Is this a bug, intended behavior somehow, or an oversight at my end?
The second problem I have is that using -verifyroms on a MESS driver is next to useless, in the sense that it takes an unreasonable amount of time to return the result – sometimes close to a whole minute? It’s almost instantaneous when verifying a MAME rom. Shouldn’t running a -verifyrom on those take longer since there’s more than one file to verify?
I’m running a self-compiled UME v0.147 on 32bit Kubuntu Linux.
I have some other questions but those can wait, I’d like to fix these two first.
Another idea I have is to improve the interaction with a running UME session. For example, UME could print messages to the stdout on certain events, such as game started, game over, 1UP, life lost, that sort of thing. I realize this would require feeding UME a file with per-game memory adresses it would need to monitor for these events. Then, any frontend could then receive these events and act upon them.
It could work the other way around too, by sending piped commands to stdin. MPlayer works this way – you can start it in slave mode, and effectively control it programmatically.
What do you think?
the system names / list names aren’t connected, some systems have multiple lists due to multiple media types for example.
I guess Genesis should be a clone of Megadriv really, although people might find it a bit weird having the 50hz system as parent.
Genesis, Megadriv, and Megadrij will all look in roms/megadriv because the list name is megadriv. I’m not sure why UME isn’t finding them there for you, I’ve tested zipped, 7zipped and unzipped, all work. I’ve also tested in the root /roms folder, that works too. I’d be interested in knowing if maybe you’ve actually found a way to create .7z files MAME can’t read, so far nobody has managed to present me with one. Your folder problem however suggests to me more a user error, like calling the other folder /megadrive instead? You are also correctly using the shortnames for the roms, right? It isn’t meant to find “mcdonald’s treasure land adventure (euro).bin.zip” only “mcdonald’s treasure land adventure (euro).bin” (uncompressed) or “mcdonald.zip / .7z” (compressed)
MESS has -verifysoftware, but it appears to check every single set in the list, I imagine -verifyroms is similar, these are really things you should discuss with the MESS guys, the behavior is just inherited from there and could possibly do with some refinement. This isn’t a UME specific thing, so as long as you phrase your questions in terms of MESS you should be able to discuss it with the developers at http://forums.bannister.org/ -verifysoftware is a recent addition I believe.
The stdout thing is beyond the scope of MAME / MESS, I know the modern commercial ports / emulations of games do similar to figure out achievements etc. but that’s not really what MAME is all about. Somebody might be able to hack such functionality into the cheat engine, but I doubt anybody on Mamedev is going to bother because it would be of more use for people trying to make money out of the project than anything else.
Please keep in mind that the UME builds I’m providing intend to stick religiously to baseline functionality, even if I disagree with changes made in MAME / MESS they get incorporated because I want to keep the codebase absolutely inline with the official repository.
Figured it out some more.
If I try to run a rom with the genesis driver, UME will only find the rom if either –
– It is zipped in the /megadriv folder
– It is unzipped in the /genesis folder
I probably overlooked the first option somehow.
My build does not appear to have the -verifysoftware switch, must have been pretty recent indeed. I’ll see if it’s in u1.
Thanks.
That kinda makes sense for legacy MAME reasons.
if you wanted to keep it unzipped in the /megadriv folder you’d probably also have to put it a folder by the name of the ‘shortname’ so /megadriv/sonic/
that’s because megadriv isn’t the system name (unless you’re running megadriv as a system) just the list name.
because genesis is the system name when you’re running genesis things get treated in a slightly different way.
by putting a *zipped* file in the genesis folder, it would be the same as putting a zipped file inside of ‘genesis.zip’ in the root of your rom folder, MAME/MESS won’t find it.
(yes, you could put all your genesis roms in a ‘genesis.zip’ as long as they weren’t zipped up again inside there)
maybe slightly confusing, but the behavior you’re seeing is expected.
the correct way to store your files is *zipped* in a folder named after the list. If you store things the correct way you avoid all this :-)
it would probably be less confusing if lists weren’t named directly after the system, a distinction between megadriv / genesis (the system names) by using megadriv_cart as the list name would probably help. Right now MESS doesn’t enforce any such rule tho, so you have the list name and system names the same in some cases. For systems with _cass and _flop lists the distinction is already much clearer.