Re: [pygame] cdrom/joy-- design

["ShredWheat" <shredwheat@mediaone.net>]

> A joystick is a distinct real object, so it makes sense to
> be modeled as an object in python. You can manipulate them 
> seperately and simultaneously. A use for this is having the config
> util create an object with references to the different axes in
> distinct variable names which the game code uses. Thus remapping
> is simple, and requires minimal code. game.haxis.get_value() or 
> some such. Calibration should be considered too.

yeah, this idea is sounding better and better. although it's
almost as easy to save a joystick id number and axis id number,
it's no match for a nice easy object-oriented method.

i didn't see any 'calibration' support inside of SDL. if it's
easy i wouldn't mind adding some simple tools into pygame.
currently SDL reports axis as -32xxx to 32xxx. pygame is
remapping the axis values between -1.0 and 1.0. would some
simple tools to change how the joystick maps be useful? the
only things i can think of is the axis "center" and perhaps
an axis "dead area". thinking back to the days of calibrating
sticks... i guess you'd also want a min and max position for
each axis as well.
SDL doesn't offer anything like this, which leaves the question...
is this best left to the OS, or perhaps the running game should
handle this? for now i'll leave it out of pygame, but once all
pygame games start releasing with their own calibration code,
perhaps we can choose a good one and integrate? heh

another thing is the joystick hat controls. currently SDL
reports hat position as range of 1 to 8 going around clockwise.
(0 meaning centered, 1 being up). this is a pretty simplistic
way of doing the hat, but it is probably enough to get the job
done. (with the docstrings and help to use as a reference it's
no problem). i was trying to think if there was some better
method of reporting the joystick hat position. the only thing i
could really come up with is a tuple of two values representing
two axis. for example; centered=(0,0)  up-left=(-1,1), right=(1,0).
is that any better? it more intuitive to me, but code then requires
comparing two values instead of one. in some cases that makes it
easier, but others its more hassle. hmmm?

the last thing is what type of objects should these joystick
controls be? at first i was thinking it would just be a live
numeric value...
>>> print joystick.axis[0]
0.0

but this would then make it impossible to get an axis object
like in ray's example. i was also thinking it could be a simple
object that acted a lot like an int, but the value was always
the "live" joystick value
>>> print joystick.axis[0], joystick.axis[0]
0.0 0.2

this would solve the 'object' problem, because you could easily
get an object representing that axis...
>>> haxis = joystick.axis[0]; print haxis
0.0

the only problem with this is that it takes a little extra
effort to get a 'snapshot' of the axis value. this would be
the case i expect people want to use most. get a position of
an axis, then do some processing with that value. to get an
int value of the axis that isn't 'live', you'd need to convert
it to an int.
>>> haxis_value = int(haxis)

the only other option is to make the axis (and other joystick
gizmos) into full objects that contain a member function to get
the axis value. this is what ray used in his quick example. i'm
not opposed to this, only that it is by far the most "verbose"
method to getting a joystick position...
>>> joystick.axis[0].get_value()

this certainly isn't too bad, and the other bonus is if we later
add the calibration type functions they have a perfect place to
go, right onto the axis objects. phew, this will make for a handful
of builtin types for the joystick module... Joystick, JoyAxis,
JoyHat, JoyBall, JoyButton.

this seems like the best method to go with though. it makes for
a bit of extra length in the code, but it remains very clear.


going back to the rest of pygame. would this type of object
oriented input be welcome for the other input objects? keyboard
and mouse? currently you abstract the keyboard by just using keysym
values...
>>> firekey = K_SPACE
>>> if pygame.key.get_pressed(firekey): shoot()

to make it similar to the joystick it would be more like...
>>> firekey = pygame.key.get_key(K_SPACE)
>>> if firekey.get_pressed(): shoot()

oof, don't forget the mouse ball and buttons. argh, the way
the mouse and keyboard are done now makes me want to keep the
joystick more the way it is...
>>> player1joy = pygame.joystick.joy[player1joy]
>>> firebutton = 0
>>> if player1joy.get_pressed(firebutton): shoot()

but this really isn't as nice. it makes me want to go in
and change the keyboard and mouse interfaces completely. with
that done one could completely abstract between all input 
devices.. for example. "player1.firebutton" could be a keyboard
key, mouse button, or joystick button. doing something like
>>> if player1.firebutton.get_values(): shoot()

hmm, well for now i will do the joystick module like this.
once it is done, perhaps we will have had more time to discuss
the other two input devices.

urgh... who knew designing this stuff would batter my mind
so extensively??


____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org