Support - Nintendo Switch (SmileBASIC 4) adjustment request #1929
Description
Before I begin, I do want to note that I am using an RPI 4b, but with Bookworm through a suggest method of manual installation. If the problem is because of using Bookworm, then please close this and disregard it.
I found this tool recently, which has exactly what I was looking for. The ability to copy code/data I produce on my computer and then transfer that over to my Nintendo Switch through automated keystrokes to inject into SmileBASIC 4. Using the Paste Text feature does just that. While typing code manually is one thing due to readability, having to type up "raw" data is another, as I plan to compile data on my computer as raw characters that are not readable, and it would be incredibly tedious to attempt to type that stuff in manually. Via keyboard is the only way to inject this data. Being able to automate it is a blessing.
But, I am running into some issues. While Paste Text works, sometimes it misses some ENTER keystrokes, causing the next line of code to append to the current line, resulting in syntax errors and such when trying to run it. It may be doing this also with manual typing. When I was initially setting this up, I had tried an RPi0w, but because of the weaker single-core CPU, it was slower with the forwarding process. But, I don't recall if I ran into this missing keystroke issue, so it may be something regarding the Switch and/or SmileBASIC 4's means of accepting keystrokes. Perhaps my RPi 4b is too fast for it? I don't wish to drop the Pi's CPU clock to slow this process down as a means to remedy this because I have the Pi doing other things for my home network at the same time. Perhaps an option to delay between keystrokes, or even after specific ones like the ENTER key?
One nice thing about TinyPilot is that I can also use the mouse with this environment, but that too has problems. A mouse connected to the system (wired or via dongle) will operate normally, but not with this method of forwarding. The cursor on the Switch/SmileBASIC always gets stuck in the lower-right corner. I did take a look at the code, and it says it's dealing with relative positioning, but after some testing, I'm thinking the Switch/SmileBASIC is handling this differently. I think it's looking at it in absolute terms and adding to the cursor's current position where the value is always positive.
To test this, I placed the mouse cursor in the TinyPilot browser window to the top-left corner of the usable area at (0,0). I used SmileBASIC's ability to emulate mouse movement with the R-Stick, and manually moved the cursor to the upper-left corner of the screen. So they are both at the top-right. I moved the TinyPilot cursor one pixel to the right. How this reflected on SmileBASIC was that it jumped a good deal to the right. Moved the TinyPilot cursor back to the left in the x=0 position, the SmileBASIC cursor did not move. TinyPilot cursor moved to the right one pixel again-> SmileBASIC cursor jumped to the right. I moved the TinyPilot cursor one more to the right at x=2 position. An even bigger jump with the SmileBASIC cursor to the right, roughly double. Move TinyPilot cursor back one to the left at x=1 position. SmileBASIC's cursor still jumped to the right, but is shorter than the previous jump.
I don't know if this is something that can be adjusted so it continues to work as it has on other devices WHILE making it work correctly with a Switch and SmileBASIC, but perhaps an option to adjust how the mouse operates?