A while ago I made a gamepad library, but it wasn’t very easy to use, so I decided to make a new one.
You can also find the project here
I also made a small demo using this library to show off some of the cool stuff you can do.
The controls are
A (or B on a switch pro controller) = Draw
ZL = Clear
ZR = Speed boost
L/R = Change pen hue
I found these two confusing, because they have nothing to do with the stick, except for your expectation that the user will call them with stick coordinates as inputs. It’s kind of the opposite of the usual newbie student mistake of building specific input values into the code inside a procedure. You’re making the user of the block provide information that really should be provided inside the procedure if it has “stick” in its name.
Otherwise very nice, as expected. :~)
I mainly made them named like that, because they’re common operations that people would want to use with joysticks.
Would something like this be better?
Not being a gamer, I don’t understand the distinction between “x” and “x-axis,” so I’m not sure. But if the “gamepad” input tells you which joystick you’re using, I should think it wouldn’t need any more inputs.
With each joystick, it has 2 axes, x and y. 0 is when it’s at rest position, and then each axis is a number between -1 and 1 representing where the stick is positioned at. Typically the axes for each joystick is placed next to each other in the actual list, but I wanted to give the programmer freedom to choose which axes they want to use. For example, they could make it really confusing and use the x axis on one joystick, and the y axis on the other joystick (there’s probably some game out there that it would make sense to use this control scheme). I suppose I could just have one input that says which joystick to use, but then also accept a list of axes indexes. That way it’s easy for users to use on the surface, but still give advanced users more control.
So, “x” and “x-axis” mean the same thing, so changing the label doesn’t change my objection. I want DIRECTION OF STICK ___ taking a joystick number as input, and sure, if you want, it can also let you drop LIST 2 1 onto that input to use X from joystick 2 and Y from joystick 1. If you want that feature to be discoverable you could even call the block DIRECTION OF STICK(S). But the user shouldn’t have to know that GAMEPAD _ AXES reports a two-number list in order to use the block.
I can be dead wrong, but I believe the xy axis is the orientation of which the joystick CAN rotate, and xy is how for it IS rotated. (Or tilted)
Not what I meant. And I don’t exactly know how to explain this better.
can’t a joystick rotate 360 degrees?
I feel like it’s important to know that the gamepad api has no knowledge of how many sticks there are, it only sees axes.
Here’s the axes list while I have the left joystick pointed up right.
It’s the position of it in a Cartesian plane, so this
I added 2 blocks to turn this position into a direction and magnitude (distance from center) because there are many uses for those operations.
I feel like it’s important to know that the gamepad api has no knowledge of how many sticks there are, it only sees axes.
I’m confused. Isn’t the number of sticks half the number of axes?
So, the inputs should be labelled X VALUE and Y VALUE or, if you really want to be pedantic, AXIS 1 VALUE and AXIS 2 VALUE? But, again, I don’t think the user should have to deal with axis bookkeeping at all.
I mean, think about a sprite! The POSITION block (like X POSITION and Y POSITION) doesn’t take any inputs; it’s Snap!'s job to know where the sprite is.
Hmm yeah, that’s true, maybe I should group them for an easier interface.
wouldnt things like analog triggers/buttons also count as axes? or are those different
Oh yeah, those are axes, I didn’t think about it cause I don’t have a controller (with me) that has analogue triggers. Though I did notice that with the gamepad api, each button does have a va\ue prop, which is a number. That could be the value of an analogue trigger, but I can’t test it.
sorry, what?
Oops, I meant “notice”
