Designer: Idea: Allow touchscreen rotation to be defined as R0...R3 or swap/invX/invY

[NachtRaveVL]

When defining some of the associated input controllers (particularly the touchscreens), instead of using the R0, R1, R2, R3 values as the displays use, the designer shows a more brute-force SwapX/Y, InvertX, InvertY sort of checkbox setup that I think is unnecessary because these values can always be derived from R0-R3. In fact, it would probably just be worth it to allow it to be setup either way, that way those who don't want to do the math can do that or those - like me - who need to draw it out on a piece of paper to see it visually in order to wrap their mind around what values should be which can do that.

Anyways, I know it's not a very well documented piece of code, but the way I did the conversion was essentially:

         /*swap*/ rotation == R1 || rotation == R3,
         /*invX*/ rotation == R1 || rotation == R2 || rotation == HorzMirror,
         /*invY*/ rotation == R3 || rotation == R2 || rotation == VertMirror

ChatGPT told me my logic was correct, so I guess that helps.

[davetcc]

To be honest, this is how it used to work (and it did not work for all cases), the way it works now was suggested by multiple users when the above didn't work, and verified by myself. It was the only way that every possible touch screen over a wide range of libraries, hardware implementations, etc could be mapped.

You've got to understand that these touch interfaces are often glued on the top of a display, they are sometimes put on incorrectly, upside down, and any which way you could possibly imagine. The only way to ensure the library always works is to provide all three options.

This is a one off cost to get the touch screen mapped correctly, and it allows the system to support the maximum number of touch screens, I don't think this can be changed. I'll leave it open in case some of the users that recommended the way it works now want to comment.

[NachtRaveVL]

Oh wow, that's actually a really great point worth mentioning that I had no idea about. Thank you for explaining that to me, it seems so obvious now ofc. :3

Feel free to close ticket if it doesn't apply. That means then, by what you say, it may be worth not trying any sort of direct linking touchscreen input orientation to the display orientation as I'm currently doing. Hmm. Might have to go back and rework some of the way I did things in that regard with that knowledge.

As always thanks again Dave. =)