Re: [pygame] cdrom/joy-- design

[Ray Kelm <rhk@newimage.com>]

ShredWheat wrote:
> 
> as you should know, i've got the interface for the cdrom
> and joystick modules layed out all in front of me.
> (in scribbley-note form on the back of a paper, heh)
> 
> these two modules are very similar. they support a number
> of devices (although in most cases there will only be 1 or 0)
> (ok, 2 isn't too unusual, but more than that? heh owell)
> 
> it this point it looks like both modules will contain a
> sequence object containing all the available devices.
> what i'm choosing over now is if it would be best for
> another level of sub-objects inside that device object.
> for example, the joystick could either have some functions;
> >>> joy.get_num_axis(); joy.get_axis(0).
> or could offer a list of values;
> >>> len(joy.axis); joy.axis[0]

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.

> 
> the same sort of thing with the cdroms and their tracks..
> >>> cd.get_num_tracks(); cd.get_track_length(0); cd.play_track(0)
> or it could be
> >>> len(cd.tracks); cd.tracks[0].get_length(); cd.tracks[0].play()

A CD track is not a distinct object, as it can't do anything
by itself. cd.play_track(x) makes sense here, especially since
you can't play more than one at a time.
 
> as it stands, doing the element members as sequences like
> these examples will be a little more work, but that is not
> what's holding me back. i'm just wondering if there's more
> benefit? using sequences is a lot more 'python'. but as i
> try code with it, i find the functions names are a clearer
> (less punctuation is my guess)
> 
> two other quick changes i'm putting up for sanity checking...
> 
> changing open() and close() on the devices to init() and quit().
> open/close is a little ambiguous for cdrom devices.

Sounds good.
 
> cdrom interface will use seconds as the time unit, instead of
> the SDL 'frames' unit. i was thinking milliseconds might be
> better since that is the unit of time in the pygame.time module.
> (but milliseconds are a bit tiny when dealing with minutes)

Seconds is very python-like. like time.sleep() and friends.
 
> well, that's it. the good news is i'll be happy with either
> route, i'm just trying to choose the 'best'. this kind of falls
> back to the Surface/new_surface issue. the only difference is
> the "constructor" issue was settled because of a third factor--
> consistency. as for the joystick cdrom thing, we are left
> with two main factors.. python-style or clean-n-clear.
> 
> heh, in this case i'm leaning towards going with the python
> way and put the device elements into a sequence. anyone have
> some further logic to throw into the mix?
> 
> david, you mentioned you had a cdplayer for pysdl. if i
> could get the source for that i'd like to convert it to use
> both of these styles with pygame and take another look.
> (real-world usage weighs a lot more heavily for me, i haven't
> used the cdrom or joystick stuff before, so i can only imagine
> what code for it looks like)
> 

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