Jump to content

Discussion on a standard for rotary support going forward

Recommended Posts

I have noticed the corrections posted in the updated documents thread and will be getting on that shortly. But while working on that I also want to update the Rotary controller support information as there was some pushback with regards to modifying controller so they correctly identify themselves.

I would prefer to try and keep my updated documents thread to correction/updates posts and so have spin this discussion on rotary support in to a new topic.


As there should be lots of developers here perhaps I hope reason will prevail and a consensus of opinion can be found on a new standardized approach to rotary support, which can then be added to the documentation. Obviously, any well written program whether is supports a rotary controller of not should check the attached controller types and either...

a) Automatically switch to using the applicable control method where a supported controller type is detected or 
b) Display a message prompting the user to switch off and attach a supported controller type where an unsupported controller type is detected.


However, a problem arises with rotary controllers that do not correctly identify themselves to the Jaguar, as to the Jaguar they look like either no, Standard or a Pro controller. So what method should be used to deal with this as standard going forward to ensure future software/hardware compatibility?

It has previously been suggested to look for simultaneous L & R as that only occurs with a rotary controller, but I do not feel that is a very robust method as…

1) The software cannot wait indefinitely for such an input as it may not come if the user only has a standard/pro controller.

2) Although item 1 could be over come by using some sort of timer after which a Standard/Pro controller is assumed, a long a delay could be tedious for those with a standard/pro controller who just want to get on with it. Whereas too short a delay may prevent detection due to user reaction time or distraction, i.e. phone call or deliver, requiring them to reset the software in order to try again.

3) Because different rotary controller may have different numbers of positions per rotation and be rotated at different speed during such a detection stage it is possible that the combination of those factors combined with and chosen controller polling speed could result in the simultaneous L & R detection being missed.  


As any rotary controller that identifies itself as a standard/pro controller would need some form of manually input to select between rotary/non rotary control mode I propose that when software which supports rotary controllers identifies the attached controller as a Standard/Pro controller type used a simpler and likely more robust method of prompting the user to press one of two designated controller buttons to select the controller type is adopted. As the software can simply just sit in a loop for as long as it takes for the user to press either of the two designated buttons.

The question then becomes which buttons to use, my suggestion is 4 (Standard/Pro) & 6 (Rotary). Why, because 6 is almost a circle so sort of denotes something rotary, plus it is on the Right side of the controller and the right shoulder button of a pro controller, which would hopefully make it easy to remember as R for Right & R for Rotary, and 4 because it is on the opposite side and the left shoulder button on a pro controller.

Additionally, if that were to become the agreed upon method, then I also suggest that those buttons are reserved in future rotary supporting games as alternative L & R (or U & D as applicable to the playfield orientation) directions. While not of much use to those with a standard controller as using 6 means relinquishing A, B & C usage it does however allow those with a pro controller the option of using the shoulder buttons instead of the D-Pad for directional control, which some may find preferable.


Finally, Rebooteriods has a method of altering the polling (sampling) speed of the rotary controller, as rotary controllers have been made by various people it cannot be assumed that every rotary controller has the same number of position per rotation. Therefore, a controller polling frequency that may work well for you in testing with your controller may not work as well with a different controller, so I think it would therefore be beneficial for the standard to also states that rotary supporting software should include something similar, accessed via the option menu and save the settings to EEPROM so the user dose not have to reset it every time.    



Link to comment
Share on other sites

I think you've just invented a problem for a solution we already have. 


You don't have to wait for anything, you just scan for L/R and switch to rotary if found, else continue as standard. 


Check out rebooteroids or downfall or kobayashi maru for how simple and easy it is. 


It is not complex, cumbersome or hard to implement. 



My main issue would be with whatever you came up with would be different to what we have now, so in effect you are creating just another thing we'd have to check for, making it even more problematic by trying to make it simpler.

  • Like 2
Link to comment
Share on other sites

I have been summoned (via email notification) from my long slumber.


My controllers do not properly identify themselves, as there was no easy way to do so on the standard PCB, the controller type bits don't (as far as I recall) have any traces or headers it was practical to tap into, so I didn't.


Also from my recollection, Tempest doesn't have auto-detection for them. It's not anywhere in the source code that was floating around, which I believe was supposed to be the final build. However when I spoke to The Almighty Yak about it, he remembers having implemented auto-detection. I do not recall ever actually testing it myself to determine one way or the other.


But the simplest option is to make it an option in your main menu, and, since main menus are typically linear things, have both up and left navigate to the previous menu item, and down and right navigate to the next, that way regardless of if the user is on a rotary (no up/down typically) or not, they can navigate the menu, and, whilst navigating the menu, they're likely as not to hit both L and R simultaneously at some point, at which point boom there's your auto-detect.


As CJ says, it's not complex.

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...