Rotary Controls/ Druin's Interface

[Derrick Renaud]

I need some more testing.  If anyone has their rotary joystick hooked up with a Druin-type interface, please test this code.  So if your rotary control is set to use inc/dec buttons to rotate, I need you to test this.  You will have to apply the attached diff and compile it yourself.

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.

I added the ability to set your "Analog Controls - Digital Speed" to 0.  Meaning MAME will not do the inc/dec for you.

So to test, set your "Analog Controls - Digital Speed" to 0.  Then set your "Analog Controls - Sensitivity" to 100%.  Then 1 press makes 1 step.

Remember the Ikari games have a copy protection hack that causes it to skip 1 step out of 13.  So that is normal.  Also please try autocenter to see if it works as you would expect if you really needed to use it.


thanks,
D.

[2600]

Worked fine for me on ikari and victroad.  Different driver, but I also tried ikari3, but it seems to be broken on rotating with keyboard currently even on the standard build.  I don't have time right now to test others, but am willing to test later if you need them tested.  I didn't try the autocenter, because I wasn't sure what the functionality was suppose to do. 


BTW, IIRC isn't the protection hack only for Guerilla War?  Why not have the hack  implemented only for Guerilla War instead of all snk_rot12 games?  If the protection is different then the one I'm thinking about, do you have any more information on it?

[Derrick Renaud]

Different driver, but I also tried ikari3, but it seems to be broken on rotating with keyboard currently even on the standard build.  I don't have time right now to test others, but am willing to test later if you need them tested.  I didn't try the autocenter, because I wasn't sure what the functionality was suppose to do. 

What kind of driver are you using.  This is meant to handle rotary type devices that use a button to increment and a button to decrement.  Setting the Digital Speed to 0 now makes MAME inc/decrement only once for each button press.

The current MAME is not broken when rotating with the keyboard.  If you hold the button down it increments at the Digital Speed * Sensitivity once every V-Blank/Input poll.  My code makes it increment once * Sensitivity for each press/release cycle.

BTW, IIRC isn't the protection hack only for Guerilla War?  Why not have the hack  implemented only for Guerilla War instead of all snk_rot12 games?  If the protection is different then the one I'm thinking about, do you have any more information on it?

I have not really looked into it to see when it is needed.  But if it is truly meant only for Guerrilla War then, yes it should be fixed for the Ikari Games.  I'll take a peek if no one else does.

D.

[2600]

What kind of driver are you using.  This is meant to handle rotary type devices that use a button to increment and a button to decrement.  Setting the Digital Speed to 0 now makes MAME inc/decrement only once for each button press.

The current MAME is not broken when rotating with the keyboard.  If you hold the button down it increments at the Digital Speed * Sensitivity once every V-Blank/Input poll.  My code makes it increment once * Sensitivity for each press/release cycle.

Your correct current MAME works fine on Ikari3, I mistakenly used the same cfgs as used with your patch.  This had Digital Speed set to 0 on the current build which obviously isn't going to work.

However, I am having trouble with your patch and Ikari 3.  All cfgs were deleted during testing.  Digital Speed set to 0 and Sensitivity set to 100%.  I understand that this is for keyboard devices and I'm using the default rotation keys of Z and X.  The guy will rotate a quarter turn after a couple "button" pushes, but no more after that first rotation.  Double checked on a keyboard as well.  I haven't tested any other games then mentioned before.

I have not really looked into it to see when it is needed.  But if it is truly meant only for Guerrilla War then, yes it should be fixed for the Ikari Games.  I'll take a peek if no one else does.

Sounds good.  That's what snk.c says, but I didn't know if there was any past history that I wasn't aware of and wasn't sure what the best way to implement it.

[2600]

I see why you were asking about what driver I was using.  What I meant was Ikari3 is in a different MAME driver then ikari and Victory road, snk68 vs snk.  Sorry about the confusion.

[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]

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.

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?).

Remember the Ikari games have a copy protection hack that causes it to skip 1 step out of 13.  So that is normal.

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)

ROMname	0 keydelta work?	Driver	Translation method
timesold	No	alpha68k.c	* 12 / 256
gondo	No	dec0.c	* 12 / 256
hbarrel	No	dec0.c	* 12 / 256
midres	Not Tested	dec0.c	* 12 / 256
downtown	No	seta.c	* 12 / 256
bermudat	Yes	snk.c	Table
gwar	Yes	snk.c	Table
ikari	Yes	snk.c	Table
victroad	Yes	snk.c	Table
ikari3	No	snk68.c	* 12 / 256
searchar	No	snk68.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]

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?).

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]

Yes, it pobably needs to be:
"~(1 << (   (readinputport(5) * 12)   / 256))

Nah, don't think that's enough: Downtown does that order with ()'s, but still didn't work.

But I will be killing it in favour of the table method.

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.

[Derrick Renaud]

I think I'm also going to change the Digital speed to be /10 or so, for people that use that method.

Currently the digital speed * sensitivity is how much it is incremented each frame.  If I make the digital speed go in .1 increments, it might be easier to set for low speed devices (Ikari) and still work fine for higher speed (Arkanoid.)

D.

[u_rebelscum]

I think I'm also going to change the Digital speed to be /10 or so, for people that use that method.

Currently the digital speed * sensitivity is how much it is incremented each frame.  If I make the digital speed go in .1 increments, it might be easier to set for low speed devices (Ikari) and still work fine for higher speed (Arkanoid.)

D.

I like the that, too.  I don't have a suggestion on how, but as an observation...

Changing from keydelta of 1 to 2 is a 100% increase, but from 25 to 26 is only by ~4%.  A sensitivity change of 1% to 2% is also double, but from 101% to 102% is <1% and not very noticable, and from 200% to 250% is only 25%. 

It makes sense to be able to have 1/10ths from 0.0 to about 15.0, but once over that it's an impedance in the UI.  And it would be nice to adjust sensitivity above 256% (but not necessarily by ones) while adjusting by 1/10ths under, say, 15% whould be nice too.

I guess I'm asking you if you could try to change both the sensitivity and deltas to use 1/10th below 15, and to go above 256, and to be able to have larger jumps in the higher numbers in the UI.  The UI doesn't have to reflect the possible valid inputs (example: maybe you hand edit the sensitivity to 257.5 in the cfg file, but if you used the UI it would jump from 255 to 260).  Again, not sure how to do it, so ignore if you want.

Thanks, Derrick!

[Derrick Renaud]

These settings are all just byte values, so we only have values from 0-255.  I don't want to make a huge change like using 16/32 bit or floating point values.  Then I would have to add things like direct keyboard entry of the value.  Using the arrows would take to long to change value at those sizes.  And I have no ambition to add direct entry of the values.

So what we have is this:

Digital Speed = is the number of inc/decrements per frame/v-blank.  Currently integer values 1-255.

Sensitivity = a scaling factor applied to the Digital Speed in %.  So a Sensitivity value of 100 is 100/100 for a scaling factor of 1.  25 is 25/100, etc.

I really don't think the rest of the Team would appreciate me making those values more complicated by using thresholds that scaled it at different rates, or making it logarithmic or something, sorry.

What I propose is to just scale the current Digital Speed by 10%, making values of 0.1 to 25.5.  Then if you increase the sensitivity to 255%, you would have a maximum delta of 65.025 per frame.

Now if we use Arkanoid as an example.  It has a frame rate of 60Hz.  So if you held the button down for 1 second, the paddle would move 60*65.025= 3901.5 steps.  Or to put it another way, the paddle would move from 1 side of the screen to the other in less then a 1/10th of a second.  The current MAME does it in just 1 frame at the highest settings.

So by just prescaling the Digital Speed by 10 like I propose, it helps games that need a slow speed of rotation (lower resolution) to more easily get a rate you like, well still allowing the higher resolution game controls to work.

Also I think you got confused that I was changing the sensitivity to also be factored by 10.  I'm only changing the Digital Speed.  The whole reason for doing this is because, like you say, the low end of the scale is completed skewed.  Changing from 1 to 2 is a huge step.  So this will help smooth out the low end.  My other goal is to just make the Analog Controls easier to use and understand.

BTW, I will be throwing a couple of other ideas past you, once I get this done and the Rotary drivers we discussed fixed.

Hint - Are most stick shifts just a 1 of x type control?  Could they not just use the same inc/dec type concept, with a Digital Speed = 0, to change through the gears?  DON'T anyone get there hopes up on this idea.  Even if I implement the concept, I am not going though each game and changing the driver.  I would just implement the interface.

D.

P.S.  Typing all this took way longer then just adding the /10. 

[Derrick Renaud]

/10 does not seem to add significant advantage.  So I'm gonna skip that idea.

[u_rebelscum]

These settings are all just byte values, so we only have values from 0-255.  I don't want to make a huge change like using 16/32 bit or floating point values.  ...

I really don't think the rest of the Team would appreciate me making those values more complicated by using thresholds that scaled it at different rates, or making it logarithmic or something, sorry. ...

Also I think you got confused that I was changing the sensitivity to also be factored by 10.  I'm only changing the Digital Speed.  The whole reason for doing this is because, like you say, the low end of the scale is completed skewed.  Changing from 1 to 2 is a huge step.  So this will help smooth out the low end.  My other goal is to just make the Analog Controls easier to use and understand.

-edit- you posted while I was writing, but I'll leave this in:

I like the factor by 10 for the low end, but (if you use analog inputs) 2.55x is sometimes not high enough; it seems some games might need 1.5%, others around 475% depending which spinner you need.  (But as you point out, 255% * the keydelta is enough for digital inputs.)   

I didn't think it through, but I guess I was hoping you could fix two stones with one bird by changing both delta and sensitivity to be sub unit on the low end but larger number on the high.  Something like 16 bit int values (factored by 10) with the UI changing the steps the UI can edit to scale depending on the value, not some complicated scaling scheme from an 8 bit var to a logarithmic-like delta/sensitivity value.  IE: up to 16 bit vars (for 0 to 10000 values, aka 0.1 to 1000.0%) + a UI change (just so you don't have to go by tenths on the high values even though those number are valid) + the factor by 10.  And that delta and sensitivity would be handled the same in the UI.  But as you say, this is not an easy change like factoring by ten.  

Me coding a UI change: shutter.  Never mind.  edit: Especially since you're not doing the factor by ten.

BTW, I will be throwing a couple of other ideas past you, once I get this done and the Rotary drivers we discussed fixed.

Hint - Are most stick shifts just a 1 of x type control?  Could they not just use the same inc/dec type concept, with a Digital Speed = 0, to change through the gears?  DON'T anyone get there hopes up on this idea.  Even if I implement the concept, I am not going though each game and changing the driver.  I would just implement the interface.

Anything but fast balls. 

As for stick shifts, oh boy.  There were many original setups; how they're currently emulated is another issue.  OTTOMH:

Hi-low with one switch at hi (or low).
Hi-low with two switches (sort of like a 2-way joystick, but it's either high or low).
Up-Down shift with two switches default in center (much like a 2-way joystick).  <-- This one would fit naturally with the zero delta speed.
1-4 shift with four switches (much like a 4-way joystick).
1-4 shift with two analog POTs (sort of like a "4-way analog" stick) that the ROM translated to gear numbers.

I'll have to look into the numbers.  Changing the drivers to match whatever you do is something within my ball park, I think.

[Derrick Renaud]

Hello

Did you get the PM?

D.

[u_rebelscum]

Hello

Did you get the PM?

Didn't read it until Sunday night, after I read this post, sorry.

[Lilwolf]

So, hows it going?

I have my rotaries hooked directly up and using analog+ mame for the games it works... but these are exactly opposite to the ones listed here. 

Does it look like this is going to be workable for all games at some point?

[Derrick Renaud]

So, hows it going?

I have my rotaries hooked directly up and using analog+ mame for the games it works... but these are exactly opposite to the ones listed here. 

Does it look like this is going to be workable for all games at some point?

Not sure what you mean by exactly opposite.

But the code is coming along nicely.  I have ikari and the others working without the gwar hack, and I have gwar working so you don't notice the hack.  It now only affects 1 frame, so you don't notice the missing step.  The rest of the games will be easy to fix once my core input changes are done.  All the rotary games will support Digital Speed = 0 for single stepping.

Stay tuned.  But I have a 3 parties this week, a couple next week, then Christmas,  then a boxing day party, a couple of New Years parties, so....

D.

[Derrick Renaud]

Here is a diff of what I have so far.  It makes all the snk.c and snk68.c games operate similarly.  So you can now rotate exactly 1 step per button press on these games using a Digital Speed = 0 and Sensitivity = 100%.

There is no longer a 13th phantom step in the snk.c games.  So when you rotate 13 times, your player rotates 13 times, not 12 like it did with the old gwar hack.

Do a clean build, or crash!

Please try this out and let me know any problems.  The rest of the games will be basic to convert now.

D.

[u_rebelscum]

Here is a diff of what I have so far.  It makes all the snk.c and snk68.c games operate similarly.  So you can now rotate exactly 1 step per button press on these games using a Digital Speed = 0 and Sensitivity = 100%.

There is no longer a 13th phantom step in the snk.c games.  So when you rotate 13 times, your player rotates 13 times, not 12 like it did with the old gwar hack.

Please try this out and let me know any problems.  The rest of the games will be basic to convert now.

Ikari and ikarijpb worked fine for me.  I like the code how the 13th position is faked for gwar.

One question popped up when looking at the code that you probably don't know the answer either :

The dial_8_gray[] 'gray' code array isn't a exactly a gray code (you're using the same values from the current driver).  I tested changing it to the gray code I'd expect it to be (changed the last value, 0x0f, to 0x02), and that worked just as well as 0x0f AFAICT.  Is there some reason the 0x0f value was used instead of 0x02 originally?  If the bootleg was to hook up to an unmod'ed  8-way stick or 8-rotary, I'd expect it to be 0x02 as that's how the four switches would look, but it was a bootleg so I can't be sure it should be that way...

[Lilwolf]

What I meant was that I have all the games working which you dont in this list

timesold No alpha68k.c * 12 / 256
gondo No dec0.c * 12 / 256
hbarrel No dec0.c * 12 / 256
midres Not Tested dec0.c * 12 / 256
downtown No seta.c * 12 / 256
bermudat Yes snk.c Table
gwar Yes snk.c Table
ikari Yes snk.c Table
victroad Yes snk.c Table
ikari3 No snk68.c * 12 / 256
searchar No snk68.c * 12 / 256

by using an old analog+ mame and direct connect. 

And the others might have a problem with that phantom click. 

I have considered using both direct connect and a druin board.  (so xybot would also work) but never got around to see if it would work. 

Anyway, I love to see work done on these great games!

[Derrick Renaud]

Here is a diff of what I have so far.  It makes all the snk.c and snk68.c games operate similarly.  So you can now rotate exactly 1 step per button press on these games using a Digital Speed = 0 and Sensitivity = 100%.

There is no longer a 13th phantom step in the snk.c games.  So when you rotate 13 times, your player rotates 13 times, not 12 like it did with the old gwar hack.

Please try this out and let me know any problems.  The rest of the games will be basic to convert now.

Ikari and ikarijpb worked fine for me.  I like the code how the 13th position is faked for gwar.

Yes, it pretty much works transparently now.

One question popped up when looking at the code that you probably don't know the answer either :

The dial_8_gray[] 'gray' code array isn't a exactly a gray code (you're using the same values from the current driver).  I tested changing it to the gray code I'd expect it to be (changed the last value, 0x0f, to 0x02), and that worked just as well as 0x0f AFAICT.  Is there some reason the 0x0f value was used instead of 0x02 originally?  If the bootleg was to hook up to an unmod'ed  8-way stick or 8-rotary, I'd expect it to be 0x02 as that's how the four switches would look, but it was a bootleg so I can't be sure it should be that way...

Yeah, I never really looked into it much.  I do not have the real control to get the real gray code values.  So I really don't want to change it without proof.

Also I don't like the Boothill gray code.  The last to values are 0x50.  So did the gun really only use 7 positions, easily done now with PORT_POSITIONS(7), or is the table wrong?  But 0x20 wouldn't fit in either of the 0x50 values in gray code.

No more time to code till after Christmas, and maybe not till after New Years.  Plus I received a MB4391 for testing.  Yeah, finally emulate that little SOB.  

D.

[Derrick Renaud]

What I meant was that I have all the games working which you dont in this list

(snip)

by using an old analog+ mame and direct connect. 

And the others might have a problem with that phantom click. 

I have considered using both direct connect and a druin board.  (so xybot would also work) but never got around to see if it would work. 

Anyway, I love to see work done on these great games!

It's not that I don't have them working, It's just that I was only testing the snk.c drivers, but did not mention that.  All rotary games will be able to use the new code, but I won't be going through them and doing them all myself.

The phantom click (snk.c only) is gone now.  But it won't be submitted for a while.

My code changes are turning out to be a whole input re-write along with the UI, so I do not know where it will end up, or when.  I will post as worthwile progress is made.  I may even scrap some of my planned ideas if it gets outta hand.  Who knows.

D.