Main > Main Forum

Buddabing's LED controller

Pages: << < (63/69) > >>

gl.tter:


--- Quote from: SirPoonga on June 15, 2005, 05:16:29 pm ---But dial AND joy8way are defined IN mame which is the controls you use and map.

--- End quote ---

I think you've misunderstood me.

SirPoonga:


--- Quote from: gl.tter on June 15, 2005, 05:29:35 pm ---For example, let's say the 1st P1 button on your control panel gets spit out by your encoder as key 'A'.  At the light driver end, a user then associates a light under this button with 'A'.  Whenever I see that 'A' is pressed (wherever it comes from), I signal it.  I don't care what game input it's actually mapped to with this scheme.
--- End quote ---
I understand now, so you are just watching what gets pressed and sending a certain signal to light a certain LED.  Would it be better as a service running in the background, that way it works for any software?  not put it in mame but have a service that is always running, always monitoring keypresses and other inputs?


--- Quote ---To use the trackball analogy, if you map a trackball to a dial, I send that the trackball is enabled, not the dial.

--- End quote ---
Now tha tI know what you are doing this doesn't make a diffeerence.  But to enlighten you dotron has BOTH tball and dial setup.  you don;t map tball to dial.  It's a hack.


--- Quote ---Of course when it comes to signalling which controls are in use, I get false positives as discussed.  I could scan controls.dat and eliminate those game inputs which are bogus, and (working backwards) the lights that shouldn't light.
--- End quote ---
I have to read about false positives you talked about.  Depending on how it is done it might not be as big of a problem as one might think....  TBC...


SirPoonga:

Now let's say one doesn't want a button to light up when pressed, but wants to use this LED board to light up the controls a games uses.  Then LSE could be incorporated into the FE or Viewer as I mentioned to correctly light up the contorls used.  right?

gl.tter:


--- Quote from: SirPoonga on June 15, 2005, 05:35:07 pm ---I understand now, so you are just watching what gets pressed and sending a certain signal to light a certain LED.

--- End quote ---

Essentially yes - except I send that the input was pressed - the light driver figures out how to represent this in lighting.  The LSE signals are deliberately designed to be descriptive of an event, not specificially about lighting.  This allows light drivers to do whatever they want - want to 'brighten' a button as it is pressed?  Sure.  Or not.  Or maybe change the RGB colour from green (button enabled) to white (button pressed)?  All up to the drivers.


--- Quote ---Would it be better as a service running in the background, that way it works for any software?
--- End quote ---


SirPoonga:


--- Quote from: gl.tter on June 15, 2005, 05:45:52 pm ---
--- Quote ---I have to read about false positives you talked about.  Depending on how it is done it might not be as big of a problem as one might think....  TBC...

--- End quote ---

I meant the phantom buttons that aren't used for anything (and anything else like that I don't know about yet).

--- End quote ---

Ahh yes.  The only problem for your end with phantom buttons is if mame says 4, game actually uses 3, you then need to filter that out using controls.dat.

BTW, read above, you might have missed one of my posts because you were typing at the same time.  the FEDEV pzip file I provide has some of the information you thought was missing form controls.dat.  And it has the algorithm suggestion when using controls.dat.  Which is basically check if game is in controls.dat, if not check the game's cloneof, if not check the games romof, if not there is no game entered related to that game, deal with as you wish.

Pages: << < (63/69) > >>

Go to full version