+Stephen Moss Posted June 15, 2022 Share Posted June 15, 2022 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. Thoughts/suggestions? Quote Link to comment Share on other sites More sharing options...
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.