Main > Software Forum
Rotary Controls/ Druin's Interface
Derrick Renaud:
I'll have to check Ikari 3 in the next few days, when I get some time to code.
Gotta go get the Christmas tree out of the attic. I think I should just rig a hoist that lowers it from the ceiling ready to use. Maybe by remote. :)
D.
u_rebelscum:
--- Quote from: Derrick Renaud on December 03, 2006, 07:18:45 pm ---What it does is inc/dec only once as soon as the button is pressed. Then does not change until the button is released and pressed again. That way you get exactly 1 rotation every time a button is pressed. No more messing with MAME analog settings to get your control to work close to proper.
--- End quote ---
I like the idea!
The problem is there's two general ways the game drivers convert the mouse data to the expected data. Ikari and others that use the same method (ie: look in a table) seem to work for me.
However, heavy barrel and some others do it much simpler (just a "~(1 << (readinputport(5) * 12 / 256))", examples: scr/machine/dec0.c, lines 41-85). Your changes don't work with this way because each button changes the mouse input by one, but that's multiplied by 12/256ths, so you have to press the button about 21 times to rotate one tick (I counted 20, 21, & 22: varies because of rounding and miscounting?).
--- Quote ---Remember the Ikari games have a copy protection hack that causes it to skip 1 step out of 13. So that is normal.
--- End quote ---
I thought this was edited so it only effected the one game gwar in the early 0.10x or late 0.9x, but it looks like it's back to all the games working the same (13 spaces instead of 12). I know I did had a hack in analog+ that did this, but IIRC, the mame code was much cleaner.
edit: here's the games I tested and looked at the code, if the change worked, what driver the game is in, the the method the driver uses to translate the dial input into what the game expects. (I sorted by driver)
ROMname0 keydelta work?DriverTranslation methodtimesoldNoalpha68k.c* 12 / 256gondoNodec0.c* 12 / 256hbarrelNodec0.c* 12 / 256midresNot Testeddec0.c* 12 / 256downtownNoseta.c* 12 / 256bermudatYessnk.cTablegwarYessnk.cTableikariYessnk.cTablevictroadYessnk.cTableikari3Nosnk68.c* 12 / 256searcharNosnk68.c* 12 / 256
Looks like the multiply and divide method doesn't like the change.
Derrick Renaud:
Thank's for the table of info. I'll have to look into making them all similar. At least now I know what 2600's problem is.
Boy, would I like to see the whole input system overhauled again. It really should allow input from real devices only in the driver. Then the input system would convert from different devices to what the driver needs. This would remove all input hacks from the driver.
But this would be a huge change, breaking every game. The input system of each driver would have to be checked.
D.
Derrick Renaud:
--- Quote from: u_rebelscum on December 05, 2006, 11:49:11 pm ---However, heavy barrel and some others do it much simpler (just a "~(1 << (readinputport(5) * 12 / 256))", examples: scr/machine/dec0.c, lines 41-85). Your changes don't work with this way because each button changes the mouse input by one, but that's multiplied by 12/256ths, so you have to press the button about 21 times to rotate one tick (I counted 20, 21, & 22: varies because of rounding and miscounting?).
--- End quote ---
Yes, it pobably needs to be:
"~(1 << ( (readinputport(5) * 12) / 256))
But I will be killing it in favour of the table method.
D.
u_rebelscum:
--- Quote from: Derrick Renaud on December 06, 2006, 10:25:48 am ---Yes, it pobably needs to be:
"~(1 << ( (readinputport(5) * 12) / 256))
--- End quote ---
Nah, don't think that's enough: Downtown does that order with ()'s, but still didn't work.
--- Quote ---But I will be killing it in favour of the table method.
--- End quote ---
Thanks for doing the work, Derrick! Talk to Mr. Do, though. He was thinking of messing with the rotary code, too, but I think your work would make his work unneeded.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version