[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Wiimote and I/O Questions

Hi,

yeah, as long as you make your api stable, then overriding the post
event function would be fine. ( of course don't worry too much about a
stable api until your code is complete ).

To make sure you separate things correctly, you could make pygame use your api.

So a wiimote pygame module would implement the post_event function...
and do anything else pygame specific required in there.

That would also make it nicely documented-by-example on how people
should interface with your library.

You could probably have a wiimote.init() function - that sets up
everything needed to use your module.

Cheers,

On 5/13/07, Luke Paireepinart <rabidpoobear@xxxxxxxxx> wrote: 
René Dudfield wrote:
> Hi,
Hey, thanks for the responses, Rene and Alex.
>> So, finally, I get to my questions:
>> 1. Is it really so bad to just have it run in a thread and use
>> forever-blocking file reads (do these use a lot of the CPU?)
>
>
> I think a thread is best here.  Then just post events into the pygame
> event queue.
>
> Before anyone cries out 'but threads are EVIL! and hard to use!!!!',
> users won't see this thread.  It will just post events into the event
> queue.
>
> A thread has the advantage that it can run at a separate frequency
> from the users main loop.
Personally, I think a thread is a good idea here too.
But I don't know every possible implication, and if someone had a really
good argument against a thread,
I would've tried to find an alternate way to do it.

Someone suggested that I keep the pygame-specific stuff decoupled from
the actual wiimote stuff so that it can be used
with other toolkits.
My idea in doing this is to have my wiimote class have a method called
"postEvent" that my update method calls whenever there's a change of state.

class wiimote(object):
   def update(self):
      ...do stuff...
      for each in changedAttributes:
          self.postEvent(each)

   def postEvent(self,stuffThatChanged):
      ... create Pygame event for stuff that changed, post it to the
event queue...

something like that.

the call to postEvent would indicate which attribute of the wiimote had
changed (button press / accelerometer data/ etc)
but it'd be up to the postEvent class to translate that into the proper
event structure and post it to the event queue.
That way, if anyone wanted to use the library for any other toolkit,
they could make a class which inherits from wiimote
and override just the postEvent function, adding in whatever
functionality they need for the task.
They could even just override postEvent with a null function and read
the attributes of the wiimote class instances directly,
whenever they needed to access the data.  but then they'd potentially
lose some data.
I guess, technically, they could just overwrite the self.postEvent
method for an already-defined instance too...
def f(unusedArgument):
   print "Hello, world!"
wiimoteInstance.postEvent = f
couldn't they?
That's bad practice, though, unless necessary, correct?


Well, all the other ideas I've come up with seem far less elegant than
this one.
Does anyone have a better way to do this?

>> 2. Does anyone know of a windows dll command that will read from a file
>> with a timeout?
>
> Not needed if you use a thread.
Yeah, that's an advantage.

-Luke