Main > Software Forum
Triggering a real knocker for Q*bert SOFTWARE SOLUTION
Level42:
Sorry 'bout that wacky title but this covers it...
In another thread Howard_Casto proposed for a software solution for triggering a real knocker for Q*bert.
Here's what he wrote:
--- Quote ---Well I played around with a solution today... it's either extremely smart, o extremely stupid, I'm not sure, but it works.
What I do is setup an external program that samples all open sound channels. What it's doing is "listening" for the knocker.wav sample to be played. When it's played the event fires. Considering how it shouldn't work at all (sound is too variable) I was suprised to find it worked 100% of the time with my tests. It seems that the knocker sound has a very flat ending (all the sample levels are complete 0's) which is very odd, so odd that this the is only noise in the game that does it. I could easily crop the sample as well so that only the flat part is played (which is inaudible).
Of course you wouldn't want this running all the time, but my app will support more than qbert and check for the current running rom, so it would only run when qbert is active.
pm me and i'll send you a test app later on in the week to play with.
--- End quote ---
My response:
So if I understand correctly you won't actualy hear the knocker.wav through your speakers ? That would be essential.
And how do you manage the output signal ? Personaly I would still like to see the Caps lock led triggered. Since I'm using a J-pac it's the easiest way to get the trigger signal out of the PC for me.
Also, would it be possible to cut-off some of the other sounds. Apparantly coily and Q*bert scream "too long" in mame.
Check out http://members.cox.net/brado426/QMAME
Here it is mentioned that:"Coily and Q*BERT now stop screaming the minute the knocker triggers
Howard_Casto:
The scream isn't an issue anymore. How mame does it now is the "fall" sample is played, immediately followed by the knocker sound. Qmame was made ages ago... the sample timing was cleaned up around .101
I'll have to supply a custom sample, but it should be possible to make a silent sound that still cna be detected. Right now I'm actually checking for teh absence of sound at the beginning of the sample, so crop it and it'll be good. See this thing works by "recording" a stereo mix of all the sounds going on in your computer. What a lot of people don't know is that when nothing is playing, your pc has a great deal of "white noise" floating around. On my pc it's around 145. But when a sound is played it cuts off all the chatter, so even a blank sound is real easy to detect from bg noise as it gives off a value of 0. Also since I'm looking for "dead air" volume and sample rate don't matter. 0 is still 0
Right now I'm whittling down the sample rate so that it'll even work on low end computers. I started at 44100khz and I keep lowering the rate and testing. So far I haven't ran into an issue of it not working so I'll keep going until it breaks.
Output is your choice. The next release of j5 (which will hopefully come out this wekend) will have support for multiple-ledwizzes, two parallel ports and the keybaord leds. I've made it in module form, so I can just drop it into this proggie.
I wouldn't reccomend the keyboard keys though especially the caps lock... let me explain: As you know lots of games use the keyboard leds. Their order is numlock, capslock, scroll lock. Numlock and capslock are used a ton, as insert coin lights. While I can technically block a key quite easily, I don't reccomend it. If you hook up your knocker to the capslock key you'll have to disable all led input for all other mame games as the least any led-enabled game uses is two. You might want to eventually wire your coin door lights to these leds. Scroll lock... not used so much so if you are going that route, use the scroll lock key. It's only used for some daphne games warlords, and maybe two others. Plus the scroll lock key is useless for typing as well. I don't even think it's used for anything anymore. So if you need to plug in a keyboard for maitenance you aren't going to be accidentally firing your knocker.
AaronGiles:
Wow, you sure are going to a lot of trouble to make this work.
I'd propose instead that you consider opening up a discussion about how to handle outputs from MAME in a more generic fashion. I've been thinking about how to support outputs both in the artwork (for visual ones) and for external support. The idea is to enhance what is already present in the rendering system and use names for outputs, and have values that they can be set to. For on/off type things, it would be set to 1 or 0. For items with variable values (like lamps that can have different brightness values), it would be some number from 0..65535 or something.
For external support, it would be OSD dependent obviously. On Windows, I would probably do the simplest thing and register for a new event and then just broadcast that event each time the output changes (perhaps throttled to same maximum rate). An external program could just listen for that event and do what it needs to do in response.
The goal would be to remove the keyboard LED crap from MAME proper and just post outputs this way. Someone else could write a standalone program that replicated the keyboard LED behavior (would be simple to do) if that's what was desired, or those LEDs could be routed to proper LEDs. There would be generic names for these ("led1", "led2", etc.) so they are easily tracked.
For Q*Bert, you'd just need to pick some name (like "knocker") and listen for the event that sets the "knocker" value to 1, and trigger your external item there.
Does this seem reasonable? It would also help MAME better document outputs in general. Right now, it doesn't do a good job because there is no common routines to call within MAME to signal the value of an output, so most of the outputs are just left dangling.
Buddabing:
--- Quote ---The goal would be to remove the keyboard LED ---meadow muffin--- from MAME proper and just post outputs this way.
--- End quote ---
There have already been attempts at this. A BYOAC user named gl.tter (he has since left) contributed some code called the "Light Signal Engine". It was very elegant. I incorporated his code into BuddaMAME.
Basically, the core or game drivers define "events", which get triggered during the course of program execution. An event can be a light turn on, flash, an animation playing, or the Qbert solenoid firing.
You could even define "triggers" which happen when a memory location meets certain criteria.
The code is able to control the keyboard LEDs or the custom LED controller that I designed. It is abstract enough so that any LED controller can be used, or a remote control solenoid for Qbert, or whatever.
I would be very happy if the keyboard LEDs were abstracted to the OSD, even if the LSE was not put into MAME. It's a big pain to hack the various points where the keyboard LEDs are used.
Level42:
Guys.......I just want my knocker to work :D :D :D
Don't care about all the other stuff....
I'm not into the blinky-blink Led-wizz stuff (yet)......
Navigation
[0] Message Index
[#] Next page
Go to full version