Re: [pygame] Wii Remote support -- first patch

[Luke Paireepinart]

I haven't dug around very much inside the code, so I don't know how it
looks in there, but it seems like the pygame.event.pump code is already
doing periodic input work,
Are you assuming that the user calls pump, or does pygame have some 
internal thread that consistently calls pump?

or does pygame.event.get call pump as well?


The other pygame event methods (get, peek, poll...) call the SDL pump 
themselves, there is no separate thread.  On the SDL side of things, 
SDL_Pump just pulls events off the Windows event queue (or equivalent) 
and places the matching SDL events on the SDL event queue in their place.

Okay, thanks for that info.


There's no way to hook into the SDL pump function, so you'd need to be 
asking the user to pump it from their own event loop.


From your wiimote pump function, it's up to you how you decide to post 
events.  On Windows your overlapped IO idea sounds fine, if 
complicated; Mac and Linux don't have the same overlapped I/O 
interface though (a simpler read with timeout).
The only reason I was doing overlapped I/O was because it enables you to 
write to the device even if a read is blocking at the time [or so 
Microsoft tells me].
I don't think there'd be very serious ramifications in using a read with 
a timeout instead.  I'll look into doing that, it might be better to 
standardize across platforms,
in case any weird situations occur from the writes being queued until a 
read completes.  Maybe avoid those inexplicable errors where your 
program performs slightly differently on a different platform. 


I would personally prefer if your wiimote library wasn't tied in 
directly with Pygame (by posting its events into the Pygame/SDL event 
queue), but instead provided an equivalent poll(timeout=None) 
function.  This would allow it to be used with other windowing 
libraries, and you could still provide a Pygame wrapper around the 
poll function for ease of use within Pygame.

Good point, I'll take that into consideration.
So maybe have some kind of enablePygame function that starts posting the 
events to the queue, if the people want to enable that feature? or is 
there a better strategy for that?


Cheers and good luck
Alex.

Re: [pygame] Menu Selection

[Richard Jones]

On Thu, 26 Apr 2007, Dave LeCompte (really) wrote:
> > I hope you don't mind, but I snagged it for a look as well. I am not
> > exactly making menus, but I am trying to get a better understanding on
> > making "buttons" (I only have to make 108 of em for my 20 card keno) I
> > have been collecting bits of code and experimenting to learn.
>
> I don't mind at all - the PyWeek code is open for anybody to grab and
> reuse.
>
> It looks like the PyWeek site proper is down for a few days, but when it
> comes back up, it's a good place to check out other games.
>
> http://www.pyweek.org

Should be back now, sorry for the outage :)


Richard

Re: [pygame] Menu Selection

[Dave LeCompte (really)]

>
> I hope you don't mind, but I snagged it for a look as well. I am not
> exactly making menus, but I am trying to get a better understanding on
> making "buttons" (I only have to make 108 of em for my 20 card keno) I
> have been collecting bits of code and experimenting to learn.

I don't mind at all - the PyWeek code is open for anybody to grab and reuse.

It looks like the PyWeek site proper is down for a few days, but when it
comes back up, it's a good place to check out other games.

http://www.pyweek.org


Although, come to think of it, most of the code there would have been
written with an eye for getting the game done in a week - so it might not
be well documented or designed.

-Dave LeCompte

Re: [pygame] Menu Selection

[[EMAIL PROTECTED]]

I hope you don't mind, but I snagged it for a look as well. I am not exactly 
making menus, but I am trying to get a better understanding on making "buttons" 
(I only have to make 108 of em for my 20 card keno) I have been collecting bits 
of code and experimenting to learn.




 --- On Wed 04/25, Dave LeCompte (really) < [EMAIL PROTECTED] > wrote:
From: Dave LeCompte (really) [mailto: [EMAIL PROTECTED]
To: pygame-users@seul.org
Date: Wed, 25 Apr 2007 15:25:14 -0700 (PDT)
Subject: Re: [pygame] Menu Selection

"Luke Paireepinart" <[EMAIL PROTECTED]>> Simon Jackson wrote:>> Hello, I want 
to make a program that lets you select an item from a>> list. Check out the 
screenshot below for an example: 
http://lemonlauncher.sourceforge.net/snap/snap3.png Can anyone point me to 
a tutorial or something similar that will show>> me how to do this?> If you 
have a series of rects that describe the menu boxes, it's trivial> to do a 
point-rect collision with your> list of menu items and the coordinates of the 
mouse.> Hints: pygame.mouse.get_pos()  and Rect.collidepoint(x,y)That's exactly 
what I do for my menu code. If you don't mind wadingthrough a more-or-less 
complete game, you can see my main menu code 
here:http://www.bigdicegames.com/Woody/BDG_07_04.zipLook at stateMainMenu.py 
which is a menu (a couple of buttons), and thenthere's stateNewGameMenu.py and 
stateOptions.py which look like modaldialog boxes, but operate the same way.The 
function in stateMainMenu.py to look at is 
"handleMouseButton" on line165, which iterates over the buttons, and checks to 
see if the user hasclicked inside the widget, and if so, calls a method on the 
widget.It's not a tutorial, but it might be useful.-Dave LeCompte

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

Re: [pygame] Wii Remote support -- first patch

[Alex Holkner]

On 26/04/2007, at 7:45 AM, Luke Paireepinart wrote:


Dave LeCompte (really) wrote:

René Dudfield <[EMAIL PROTECTED]> suggested:


For pygame integration posting events into the event queue would  
be a

good idea ( pygame.event.post ).  Maybe run in another thread, or
polled at the required frequency with pygame.time.set_timer ?



I'd suggest not creating another thread if we don't absolutely  
need to.



Does anyone know how the mouse works in Pygame? how is it polled?
I'd think the wiimote should be done in a similar manner.



Events appear in the Windows event queue (and equivalent on other  
platforms).   "Polling" this simply means checking if the queue is  
empty.




I haven't dug around very much inside the code, so I don't know  
how it
looks in there, but it seems like the pygame.event.pump code is  
already

doing periodic input work,
Are you assuming that the user calls pump, or does pygame have some  
internal thread that consistently calls pump?

or does pygame.event.get call pump as well?


The other pygame event methods (get, peek, poll...) call the SDL pump  
themselves, there is no separate thread.  On the SDL side of things,  
SDL_Pump just pulls events off the Windows event queue (or  
equivalent) and places the matching SDL events on the SDL event queue  
in their place.


There's no way to hook into the SDL pump function, so you'd need to  
be asking the user to pump it from their own event loop.


From your wiimote pump function, it's up to you how you decide to  
post events.  On Windows your overlapped IO idea sounds fine, if  
complicated; Mac and Linux don't have the same overlapped I/O  
interface though (a simpler read with timeout).


I would personally prefer if your wiimote library wasn't tied in  
directly with Pygame (by posting its events into the Pygame/SDL event  
queue), but instead provided an equivalent poll(timeout=None)  
function.  This would allow it to be used with other windowing  
libraries, and you could still provide a Pygame wrapper around the  
poll function for ease of use within Pygame.


Cheers and good luck
Alex.

Re: [pygame] Tentative patch for "metrics" font method

[René Dudfield]

A fixed up patch from Marcus was just committed.

Committed revision 987.


On 1/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Guillaume Proux <[EMAIL PROTECTED]>:

[...]
> There is ONE function in SDL_TTF that can tell if a character is in
> the font or not. This is GlyphMetrics. So I made a tentative patch (i
> don't have a dev env ready therefore I haven't even compiled it so I
> would appreciate if somebody could try it out) to add the metrics
> method to fonts.
>
> If a call to this method returns None, then it will mean that this
> character cannot be rendered, which is what I will need in Freevo to
> decide to switch to a different font.

That's a nice method, but I recommend not to use it for getting actual glyph
metrics of a whole string. As it moves characters out of the context, the method
is unlikely to return the correct metrics for certain scripts like arabic, in
which
the rendered character metrics depends on the surrounding string context
(storage vs. represantation form).

Anyway, well done.

Regards
Marcus

Re: [pygame] Wii Remote support -- first patch

[Brian Fisher]

On 4/25/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:

Does anyone know how the mouse works in Pygame? how is it polled?
I'd think the wiimote should be done in a similar manner.


Mice are usually interrupt driven, as opposed to polled. When the
mouse moves or clicks it generates interrupts that the driver gets,
and ultimately the driver queries the mouse's state and creates events
that get shoved in some queue for some other layer of the system to
read at it's leisure.  Windows in particular though has pieces of the
system that throw out what it considers extraneous movement events (it
will try to replace the previous movement event instead of adding new
ones if the application hasn't checked it's event queue), so even
though the hardware & driver & OS take care of stuff so that you don't
need to check for mouse events unless you want to read them, you do
get more event data if your app checks it's events more often

Because the bluetooth protocol is packet based, you don't necessarily
need to worry about polling or interrupt stuff for device level
information at all. Basically a bluetooth device could easily just
send out n packets a second of device specific data, and it doesn't
necessairly matter when some application reads that data, cause the
bluetooth driver can store up some amount of packets, to be grabbed at
the applications leisure. So again, the drivers and hardware do a fair
bit of work so that the app doesn't have to ask for data until it's
ready to do something with it.

The point being it will really just depend on the specifics of the
Wiimote what happens if the app doesn't talk to it for a given amount
of time cause on the computer's side of things there is just a stream
of data going out and a stream of data going in to some bluetooth
device. I wouldn't assume that there is any necessity for an extra
thread to do things at a given rate at all.

Re: [pygame] Menu Selection

[Dave LeCompte (really)]

"Luke Paireepinart" <[EMAIL PROTECTED]>
> Simon Jackson wrote:
>> Hello, I want to make a program that lets you select an item from a
>> list. Check out the screenshot below for an example:
>>
>> http://lemonlauncher.sourceforge.net/snap/snap3.png
>>
>> Can anyone point me to a tutorial or something similar that will show
>> me how to do this?
> If you have a series of rects that describe the menu boxes, it's trivial
> to do a point-rect collision with your
> list of menu items and the coordinates of the mouse.
> Hints: pygame.mouse.get_pos()  and Rect.collidepoint(x,y)

That's exactly what I do for my menu code. If you don't mind wading
through a more-or-less complete game, you can see my main menu code here:
http://www.bigdicegames.com/Woody/BDG_07_04.zip

Look at stateMainMenu.py which is a menu (a couple of buttons), and then
there's stateNewGameMenu.py and stateOptions.py which look like modal
dialog boxes, but operate the same way.

The function in stateMainMenu.py to look at is "handleMouseButton" on line
165, which iterates over the buttons, and checks to see if the user has
clicked inside the widget, and if so, calls a method on the widget.


It's not a tutorial, but it might be useful.


-Dave LeCompte

Re: [pygame] Wii Remote support -- first patch

[Dave LeCompte (really)]

"Luke Paireepinart" <[EMAIL PROTECTED]> asked:

> Are you assuming that the user calls pump, or does pygame have some
> internal thread that consistently calls pump?
> or does pygame.event.get call pump as well?
> how does all that jazz work?

Yeah, I'm assuming that the user calls one of these functions every frame:

pygame.event.pump
pygame.event.get

Looking at the event documentation (
http://www.pygame.org/docs/ref/event.html ), my guess would be that they
end up calling some common code.

In particular, looking at the various references on that page to "pump",
it looks like there's a certain amount of housekeeping that needs to go on
periodically (like pygame internally processing windows messages) and
"pump" is the minimal way to get that done, but if you want to do that,
plus receive event notifications, "get" does both.

I'm afraid I can't speak to how it happens inside. It could be turtles,
for all I know.


-Dave LeCompte

Re: [pygame] Menu Selection

[Luke Paireepinart]

Simon Jackson wrote:

Hello, I want to make a program that lets you select an item from a
list. Check out the screenshot below for an example:

http://lemonlauncher.sourceforge.net/snap/snap3.png

Can anyone point me to a tutorial or something similar that will show
me how to do this?
If you have a series of rects that describe the menu boxes, it's trivial 
to do a point-rect collision with your

list of menu items and the coordinates of the mouse.
Hints: pygame.mouse.get_pos()  and Rect.collidepoint(x,y)
-Luke


Thanks,
Simon

[pygame] Menu Selection

[Simon Jackson]

Hello, I want to make a program that lets you select an item from a
list. Check out the screenshot below for an example:

http://lemonlauncher.sourceforge.net/snap/snap3.png

Can anyone point me to a tutorial or something similar that will show
me how to do this?

Thanks,
Simon

Re: [pygame] Wii Remote support -- first patch

[Luke Paireepinart]

Dave LeCompte (really) wrote:

René Dudfield <[EMAIL PROTECTED]> suggested:

  

For pygame integration posting events into the event queue would be a
good idea ( pygame.event.post ).  Maybe run in another thread, or
polled at the required frequency with pygame.time.set_timer ?



I'd suggest not creating another thread if we don't absolutely need to.
  

Does anyone know how the mouse works in Pygame? how is it polled?
I'd think the wiimote should be done in a similar manner.

Depending on what mode you have the wiimote in, it either reports a 
result whenever a button is pressed/released (buttons-only mode)

or it reports continuously (when in accel+buttons, or accel+buttons+IR).
so button-only mode is more similar to how mouse reporting happens in 
Pygame (only when the state changes.)

Would it be possible to query the result of the overlapped IO as part of
the pygame.event.pump / pygame.event.get calls?

Yes, I believe so.

 The game is going to be
calling those already.
  



Some reasons why that might not work:

- I recall reading in the code that some of the accelerometer calculations
work best if the device is polled with inconsistent frequency. I don't
know how big a problem that is in practice.
  
We'll see, I guess.  It makes sense that a consistent frequency would be 
ideal, but from what I can tell,
the Wii remote issues reports only when it wants to, and the read will 
just block if it has nothing to report.
(well, unless you tell it not to block, but my point is that the wii 
mote doesn't just constantly stream data)
Does this mean that it would work the other way, and cache output until 
you read it in?  I'm not sure.
The bluetooth adapter driver code could do that for you (I doubt the wii 
mote would cache output)


so couldn't you  theoretically read all outputs that occurred since your 
last frame every time you get a chance to read?
I bet the wiimote reports at a consistent frequency either way, when in 
accelerometer mode.

- The bluetooth library code might want to be called more frequently than
once per (graphics) frame.
  
I don't know why it would care... my code has nothing to do with 
bluetooth. As far as it's concerned, the Wiimotes could be USB HID devices.


I haven't dug around very much inside the code, so I don't know how it
looks in there, but it seems like the pygame.event.pump code is already
doing periodic input work,
Are you assuming that the user calls pump, or does pygame have some 
internal thread that consistently calls pump?

or does pygame.event.get call pump as well?
how does all that jazz work?
-Luke

Re: [pygame] Wii Remote support -- first patch

[Dave LeCompte (really)]

I typoed:

> - I recall reading in the code that some of the accelerometer calculations
> work best if the device is polled with inconsistent frequency.

Er, I meant: "the accelerometer reading code works best when polled with
CONSISTENT frequency".

If that turns out to be a big deal, a dedicated thread would seem like a
pretty good idea, especially if it had to run at frequencies higher than
60hz.

-Dave

Re: [pygame] Wii Remote support -- first patch

[Dave LeCompte (really)]

René Dudfield <[EMAIL PROTECTED]> suggested:

> For pygame integration posting events into the event queue would be a
> good idea ( pygame.event.post ).  Maybe run in another thread, or
> polled at the required frequency with pygame.time.set_timer ?

I'd suggest not creating another thread if we don't absolutely need to.

Would it be possible to query the result of the overlapped IO as part of
the pygame.event.pump / pygame.event.get calls? The game is going to be
calling those already.

Some reasons why that might not work:

- I recall reading in the code that some of the accelerometer calculations
work best if the device is polled with inconsistent frequency. I don't
know how big a problem that is in practice.

- The bluetooth library code might want to be called more frequently than
once per (graphics) frame.


I haven't dug around very much inside the code, so I don't know how it
looks in there, but it seems like the pygame.event.pump code is already
doing periodic input work, just like what we would need for the Wii
controllers.

-Dave LeCompte

Re: [pygame] Wii Remote support -- first patch

[René Dudfield]

Sounds all good.  I think I want to get a wii now :)  Just for the remotes.

For pygame integration posting events into the event queue would be a
good idea ( pygame.event.post ).  Maybe run in another thread, or
polled at the required frequency with pygame.time.set_timer ?

Cheers,

On 4/26/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:

Alex Holkner wrote:
> Luke Paireepinart wrote:
>
>>
>> Also, I'm using overlapped I/O for the reads/writes, but right after
>> I call the read and it returns control to me,
>> I call the kernel32.GetOverlappedResult to get the result, which is
>> blocking.
>> So  my question was:  Is it cool to run the wii remote's update
>> method in a thread, or should I recode it to where it doesn't
>> block and just returns nothing if it doesn't get a read within a few
>> milliseconds or something?
>
>
> Polling (with optional timeout) is the PyGame/SDL way; any blocking or
> threaded API can then be layered on top if the application desires it.
The way the i/o works is that you pass an Overlapped structure to the
read method, then you call GetOverlappedResult with the
same overlapped structure to get the read result later.
So the way the built-in pygame.mouse and such work is that they keep
checking for input, and when they get it, they report it to
pygame.event, right?
I can just keep track of whether there's a read pending, and not start
another read until I get the result of the first read first.
I'd do this by calling GetOverlappedResult without blocking enabled [if
my readpending variable is set] so it will just return, and call that
every x milliseconds.
Then when I find out that something has given a result, I process the
input, start another read and repeat the cycle.  Is that what you mean
by polling?

should I let the user set the delay between reads, if there is no
result, or is there a recommended amount of time? (if there were a
result, I wouldn't delay, that way if there's a constant stream of input
it won't start lagging behind.)  The longer the delay, the less
processor is used by my library, and the more there is for games, but
the greater potential there is for input lag, right?
-Luke

>
> Alex.

Re: [pygame] Sub-pixel rendering

[Will McGugan]

Guillaume Rava wrote:


Here's the book:
http://www.amazon.com/Beginning-Game-Development-Python-Pygame/dp/1590598725 


I just bought it on Amazon.com ; well actually, pre-ordered it,
because it's not out yet. There was no review on Amazon, but judging
by the elegance of your code, and how articulate your website is, I
can only expect a good book.


A sale! :-) Hope it doesn't disapoint.

Will

Re: [pygame] Sub-pixel rendering

[Guillaume Rava]

Here's the book:
http://www.amazon.com/Beginning-Game-Development-Python-Pygame/dp/1590598725
I just bought it on Amazon.com ; well actually, pre-ordered it,
because it's not out yet. There was no review on Amazon, but judging
by the elegance of your code, and how articulate your website is, I
can only expect a good book.

- Guillaume Rava .

On 4/25/07, Will McGugan <[EMAIL PROTECTED]> wrote:

Kamilche wrote:

>
> Wow. That's really beautiful, thanks for posting it! That is such a
> complex particle effect you got going there... I went looking for the
> pages of code it took to create it, and found the few paltry lines. :-D

Glad you like it.

>
> Have you ever considered working up a variety of special effects and
> selling them to other coders? I'd buy them, if the price were
> reasonable. You've obviously got the maths to do it. ;-)

Oh I would never be so mercenary. I'll just post anything I come up with
to my blog. Buy my book and we'll call it quits. ;-)

Will

Re: [pygame] Sub-pixel rendering

[Charles Christie]

Interested ++;

On 4/25/07, Kamilche <[EMAIL PROTECTED]> wrote:


Well, color me interested. There's not enough pages devoted to advanced
topics such as pathfinding and particle effects, in most game books.

Throw in a 'line of sight' pathfinding routine that uses polygons
instead of pixels for its map, or a particle engine with several
examples, and I'm there! ;-)

--Kamilche

Re: [pygame] Sub-pixel rendering

[Kamilche]

Well, color me interested. There's not enough pages devoted to advanced 
topics such as pathfinding and particle effects, in most game books.


Throw in a 'line of sight' pathfinding routine that uses polygons 
instead of pixels for its map, or a particle engine with several 
examples, and I'm there! ;-)


--Kamilche

Re: [pygame] Sub-pixel rendering

[Will McGugan]

Kamilche wrote:



Wow. That's really beautiful, thanks for posting it! That is such a 
complex particle effect you got going there... I went looking for the 
pages of code it took to create it, and found the few paltry lines. :-D


Glad you like it.



Have you ever considered working up a variety of special effects and 
selling them to other coders? I'd buy them, if the price were 
reasonable. You've obviously got the maths to do it. ;-)


Oh I would never be so mercenary. I'll just post anything I come up with 
to my blog. Buy my book and we'll call it quits. ;-)


Will

Re: [pygame] Sub-pixel rendering

[Charles Christie]

Of course, if you would rather release them for free, we wouldn't mind much
either. ;D

On 4/25/07, Kamilche <[EMAIL PROTECTED]> wrote:


Will McGugan wrote:
> Hi folks,
>
> I've just posted a module to do sub-pixel blitting with 2D PyGame.
> Hopefuly someone will find it useful!
>
> http://www.willmcgugan.com/2007/04/25/going-sub-pixel-with-pygame/
>
> Regards,
>
> Will McGugan
>
>
>

Wow. That's really beautiful, thanks for posting it! That is such a
complex particle effect you got going there... I went looking for the
pages of code it took to create it, and found the few paltry lines. :-D

Have you ever considered working up a variety of special effects and
selling them to other coders? I'd buy them, if the price were
reasonable. You've obviously got the maths to do it. ;-)

--Kamilche

Re: [pygame] Character Movement

[Charles Christie]

Well, this thing is due next Friday so I want a few quick-and-dirty hacks to
get it running. After school is out I want to REALLY program this game
instead of making a crappy proof-of-concept with lame newbie coding errors
and lines of spaghetti code that do nothing. :P

On 4/25/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:


Kris Schnee wrote:
> Charles Christie wrote:
>> Kris: I did the typing part. Now I want to have a character that the
>> person playing the game can move across the screen.
>
> Would this graphics engine be of any use?
> 
>
> I've got an animated character that can walk and jump around on a
> scrolling tiled landscape loaded from a 1000x1000 image map. (The area
> shown in the minimap is the central island of this "zone":
> )
>
> The efficiency, hence speed, is poor because it's currently drawing a
> whole screen's worth of tiles every frame. The graphics shown are ugly
> because I haven't thought of what way to handle transitions between
> terrain types, and because I drew them. (I'm proud of that tree though!)
That's a pretty sweet tree, dude. :D
> Anyway, it's usable to display a large tiled landscape with an
> animated character; you could theoretically hook that up to the typing
> system.
It's a cool engine for sure, but I believe CC is making a Raiden-type
japanese shooter (bullet-dodging type thing.)  Hope you don't mind me
answering for you, Charles.
>
> Kris
>

Re: [pygame] Sub-pixel rendering

[Kamilche]

Will McGugan wrote:

Hi folks,

I've just posted a module to do sub-pixel blitting with 2D PyGame. 
Hopefuly someone will find it useful!


http://www.willmcgugan.com/2007/04/25/going-sub-pixel-with-pygame/

Regards,

Will McGugan





Wow. That's really beautiful, thanks for posting it! That is such a 
complex particle effect you got going there... I went looking for the 
pages of code it took to create it, and found the few paltry lines. :-D


Have you ever considered working up a variety of special effects and 
selling them to other coders? I'd buy them, if the price were 
reasonable. You've obviously got the maths to do it. ;-)


--Kamilche

Re: [pygame] Character Movement

[Luke Paireepinart]

Kris Schnee wrote:

Charles Christie wrote:
Kris: I did the typing part. Now I want to have a character that the 
person playing the game can move across the screen.


Would this graphics engine be of any use?


I've got an animated character that can walk and jump around on a 
scrolling tiled landscape loaded from a 1000x1000 image map. (The area 
shown in the minimap is the central island of this "zone": 
)


The efficiency, hence speed, is poor because it's currently drawing a 
whole screen's worth of tiles every frame. The graphics shown are ugly 
because I haven't thought of what way to handle transitions between 
terrain types, and because I drew them. (I'm proud of that tree though!)

That's a pretty sweet tree, dude. :D
Anyway, it's usable to display a large tiled landscape with an 
animated character; you could theoretically hook that up to the typing 
system.
It's a cool engine for sure, but I believe CC is making a Raiden-type 
japanese shooter (bullet-dodging type thing.)  Hope you don't mind me 
answering for you, Charles.


Kris

Re: [pygame] Wii Remote support -- first patch

[Luke Paireepinart]

Alex Holkner wrote:

Luke Paireepinart wrote:



Also, I'm using overlapped I/O for the reads/writes, but right after 
I call the read and it returns control to me,
I call the kernel32.GetOverlappedResult to get the result, which is 
blocking.
So  my question was:  Is it cool to run the wii remote's update 
method in a thread, or should I recode it to where it doesn't
block and just returns nothing if it doesn't get a read within a few 
milliseconds or something?



Polling (with optional timeout) is the PyGame/SDL way; any blocking or 
threaded API can then be layered on top if the application desires it.
The way the i/o works is that you pass an Overlapped structure to the 
read method, then you call GetOverlappedResult with the
same overlapped structure to get the read result later. 
So the way the built-in pygame.mouse and such work is that they keep 
checking for input, and when they get it, they report it to 
pygame.event, right?
I can just keep track of whether there's a read pending, and not start 
another read until I get the result of the first read first.
I'd do this by calling GetOverlappedResult without blocking enabled [if 
my readpending variable is set] so it will just return, and call that 
every x milliseconds.
Then when I find out that something has given a result, I process the 
input, start another read and repeat the cycle.  Is that what you mean 
by polling?


should I let the user set the delay between reads, if there is no 
result, or is there a recommended amount of time? (if there were a 
result, I wouldn't delay, that way if there's a constant stream of input 
it won't start lagging behind.)  The longer the delay, the less 
processor is used by my library, and the more there is for games, but 
the greater potential there is for input lag, right?

-Luke



Alex.

Re: [pygame] Wii Remote support -- first patch

[Alex Holkner]

Luke Paireepinart wrote:



Also, I'm using overlapped I/O for the reads/writes, but right after I 
call the read and it returns control to me,
I call the kernel32.GetOverlappedResult to get the result, which is 
blocking.
So  my question was:  Is it cool to run the wii remote's update method 
in a thread, or should I recode it to where it doesn't
block and just returns nothing if it doesn't get a read within a few 
milliseconds or something?



Polling (with optional timeout) is the PyGame/SDL way; any blocking or 
threaded API can then be layered on top if the application desires it.


Alex.

Re: [pygame] Wii Remote support -- first patch

[Luke Paireepinart]

Simon Oberhammer wrote:
great work, I'm already looking forward to creating games for 
wii-controllers - I will definitly check out this wiimote package some 
time in the next weeks. Does it work under linux? from the last email 
it doesn't seem so but the code looks like it does?? 


there's no reason the wii remote library wouldn't work under linux, if 
the HID library supported it.
So I can probably steal some code from that other, Linux wii remote 
library later and set it up in the HID library... but that's not my 
primary concern.
I want to get the wiimote library  more featureful, and it needs a bit 
more abstraction, and then I'll work on getting it set up on Linux too.
But like I said, feel free to add that support yourself if you want, it 
shouldn't be difficult.
Let me know if you do want to do this, and I can let you know when a 
working version of the rest of the library is set up.
I'm fairly certain I'll have Linux and Mac compatibility in the next few 
weeks, if no one else feels like doing it
(luckily I have a friend with a Macbook, so I should be able to bum it 
off him a few days to test the mac code), but I can't guarantee it :D
I'll probably do the mac support before Linux, since when school ends 
he'll move back home, but I can easily get access to linux whenever I want.
I know you all probably hate me for doing Linux last :P but it works out 
better for me this way.

-Luke

Re: [pygame] Wii Remote support -- first patch

[Simon Oberhammer]

great work, I'm already looking forward to creating games for
wii-controllers - I will definitly check out this wiimote package some time
in the next weeks. Does it work under linux? from the last email it doesn't
seem so but the code looks like it does??

greetings
simon

On 4/25/07, Luke Paireepinart <[EMAIL PROTECTED]> wrote:


René Dudfield wrote:
> Hi,
>
> good links.
>
> It looks like someone is making a ctypes based library for windows
> based on that first code.
>
> Luke, are you reading this?  Did you get anywhere with your ctypes
> wiimote code?
Yep, I can read buttons and set LEDs and rumble right now.
I actually just started working on this again a few days ago.
There's been lots of school recently, but it's finals time so I have
long breaks between study sessions right now where I can code.
I'm writing it in such a way that the HID communication is abstracted
away from the actual wiimote library.
The HID stuff is all windows-dependent right now (calling windows DLLs
directly).
Currently it just uses kernel32.WriteFile for communication, which
doesn't work on all bluetooth stacks (you
use hid.hidD_SetOutputReport on the ones where WriteFile doesn't work)
but I don't have a stack
that doesn't work for WriteFile, so when I eventually write the
compatibility code that tries writefile and if
it fails, tries SetOutputReport, I'll ask the list if anyone wants to
give it a try.
I'm not actually using ctypes to interface with a compiled version of
cwiimote, I'm rewriting it in Python,
so that I can have more control over the structure of everything (or so
I'm telling myself... plus it's fun :D)

It was working perfectly last night but I'm refactoring the code and I
broke everything.
svn://commons.game-host.org/PyWiimote is the URL for SVN, but I didn't
commit when it was working (>_<)
so there's only the broken version right now.  I have a CS assignment
due at 5 pm tonight (binary search tree sorting cities by zipcode) but
after that I should have the rest of the week to work on the library, so
hopefully I'll get more done.
Eventually I'll write a cross-platform HID library, and we'll all be
happy :D
Unless someone else wants to do it?  All you have to do is find out what
the path is on your os for all the HID devices,
then open each one, make sure it's a wii remote, and then send output
reports to it whenever the write() method is called.
All the code it fairly simple, I've just been learning ctypes while I
did it, so it's taken a while.

Also, I'm using overlapped I/O for the reads/writes, but right after I
call the read and it returns control to me,
I call the kernel32.GetOverlappedResult to get the result, which is
blocking.
So  my question was:  Is it cool to run the wii remote's update method
in a thread, or should I recode it to where it doesn't
block and just returns nothing if it doesn't get a read within a few
milliseconds or something?
-Luke
>
> Cheers,
>
>
>
> On 4/25/07, Dave LeCompte (really) <[EMAIL PROTECTED]> wrote:
>> If people are interested in adding Windows support for this, they might
>> like to look at either
>>
>> http://simulatedcomicproduct.com/2006/12/cwiimote-02.php
>>
>> or
>>
>> http://digitalretrograde.com/projects/wiim/
>>
>> Both of them have source code that could be a useful starting point
>> for a
>> Windows/PyGame module. I was able to put a SWIG wrapper around CWiiMote
>> and read accelerometer and button inputs and set LED outputs with
little
>> difficulty.
>>
>>
>> > Very cool.  Are you still working on this?
>> >
>> > On 12/18/06, robomancer <[EMAIL PROTECTED]> wrote:
>> >> Hi all,
>> >>
>> >> I've created a first step toward Wii Remote support in
Pygame.  Patch
>> >> is against 0.7.1 because the current SVN doesn't build for me.  I
>> >> expect that future patches will be against SVN head, or 0.8 when
that
>> >> is released.  Let me know what you think.  You can download the
>> >> current sample code here:
>> >>
>> >> http://gs3080.sp.cs.cmu.edu/wiimote/
>> >>
>> >> Here's the README file:
>> >>
>> >> Preliminary Wii Remote support for Pygame.  This is definitely
>> >> proof-of-concept code, and is only likely to work in Linux.  The
only
>> >> supported features are: discovering Wiimotes via Bluetooth, polling
>> >> the buttons and 3-axis force vector, and setting the LEDs.  The
>> >> wiimote.py module has useful docstrings for all public functions, so
>> >> "pydoc pygame.wiimote" should give you some helpful documentation
>> once
>> >> it's installed.  You can also just look at the LiiPong sample code.
>> >>
>> >> Files in this package:
>> >>
>> >> liipong-0.1.py
>> >>
>> >> Pong for Linux with the Wii Remote.  See the top of liipong-0.1.py
>> for
>> >> some setup instructions.  You can play 1-player or 2-player!  To
play
>> >> 2-player, just sync 2 Wii Remotes when the game prompts you to.
>> >>
>> >> pygame-0.7.1-wiimote1.patch
>> >>
>> >> Patch to Pygame 0.7.1 that enables preliminary Wii Remote support.
>> >> I'll generate a new patch against Pygame 0.8 w

Re: [pygame] Wii Remote support -- first patch

[Luke Paireepinart]

René Dudfield wrote:

Hi,

good links.

It looks like someone is making a ctypes based library for windows
based on that first code.

Luke, are you reading this?  Did you get anywhere with your ctypes 
wiimote code?

Yep, I can read buttons and set LEDs and rumble right now.
I actually just started working on this again a few days ago.
There's been lots of school recently, but it's finals time so I have 
long breaks between study sessions right now where I can code.
I'm writing it in such a way that the HID communication is abstracted 
away from the actual wiimote library.
The HID stuff is all windows-dependent right now (calling windows DLLs 
directly).
Currently it just uses kernel32.WriteFile for communication, which 
doesn't work on all bluetooth stacks (you
use hid.hidD_SetOutputReport on the ones where WriteFile doesn't work) 
but I don't have a stack
that doesn't work for WriteFile, so when I eventually write the 
compatibility code that tries writefile and if
it fails, tries SetOutputReport, I'll ask the list if anyone wants to 
give it a try.
I'm not actually using ctypes to interface with a compiled version of 
cwiimote, I'm rewriting it in Python,
so that I can have more control over the structure of everything (or so 
I'm telling myself... plus it's fun :D)


It was working perfectly last night but I'm refactoring the code and I 
broke everything.
svn://commons.game-host.org/PyWiimote is the URL for SVN, but I didn't 
commit when it was working (>_<)
so there's only the broken version right now.  I have a CS assignment 
due at 5 pm tonight (binary search tree sorting cities by zipcode) but 
after that I should have the rest of the week to work on the library, so 
hopefully I'll get more done.
Eventually I'll write a cross-platform HID library, and we'll all be 
happy :D
Unless someone else wants to do it?  All you have to do is find out what 
the path is on your os for all the HID devices,
then open each one, make sure it's a wii remote, and then send output 
reports to it whenever the write() method is called.
All the code it fairly simple, I've just been learning ctypes while I 
did it, so it's taken a while.


Also, I'm using overlapped I/O for the reads/writes, but right after I 
call the read and it returns control to me,
I call the kernel32.GetOverlappedResult to get the result, which is 
blocking.
So  my question was:  Is it cool to run the wii remote's update method 
in a thread, or should I recode it to where it doesn't
block and just returns nothing if it doesn't get a read within a few 
milliseconds or something?

-Luke


Cheers,



On 4/25/07, Dave LeCompte (really) <[EMAIL PROTECTED]> wrote:

If people are interested in adding Windows support for this, they might
like to look at either

http://simulatedcomicproduct.com/2006/12/cwiimote-02.php

or

http://digitalretrograde.com/projects/wiim/

Both of them have source code that could be a useful starting point 
for a

Windows/PyGame module. I was able to put a SWIG wrapper around CWiiMote
and read accelerometer and button inputs and set LED outputs with little
difficulty.


> Very cool.  Are you still working on this?
>
> On 12/18/06, robomancer <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I've created a first step toward Wii Remote support in Pygame.  Patch
>> is against 0.7.1 because the current SVN doesn't build for me.  I
>> expect that future patches will be against SVN head, or 0.8 when that
>> is released.  Let me know what you think.  You can download the
>> current sample code here:
>>
>> http://gs3080.sp.cs.cmu.edu/wiimote/
>>
>> Here's the README file:
>>
>> Preliminary Wii Remote support for Pygame.  This is definitely
>> proof-of-concept code, and is only likely to work in Linux.  The only
>> supported features are: discovering Wiimotes via Bluetooth, polling
>> the buttons and 3-axis force vector, and setting the LEDs.  The
>> wiimote.py module has useful docstrings for all public functions, so
>> "pydoc pygame.wiimote" should give you some helpful documentation 
once

>> it's installed.  You can also just look at the LiiPong sample code.
>>
>> Files in this package:
>>
>> liipong-0.1.py
>>
>> Pong for Linux with the Wii Remote.  See the top of liipong-0.1.py 
for

>> some setup instructions.  You can play 1-player or 2-player!  To play
>> 2-player, just sync 2 Wii Remotes when the game prompts you to.
>>
>> pygame-0.7.1-wiimote1.patch
>>
>> Patch to Pygame 0.7.1 that enables preliminary Wii Remote support.
>> I'll generate a new patch against Pygame 0.8 when that comes out (for
>> now, the SVN isn't building for me; I seem to need a new version of
>> SDL, which I'm too lazy to compile from scratch at the moment).
>>
>> __init__.py, locals.py, wiimote.py
>>
>> Full versions of the Pygame 0.7.1 files I changed to enable Wiimote
>> support.  If you don't want to use the patch program, you can just
>> drop these in to the lib/ directory of the Pygame-0.7.1 source
>> distribution.
>>
>> robomancer
>>
>

Re: [pygame] fun game

[Kordova]

FUN!

--- test.py 2007-04-25 07:20:49.0 -0400
+++ test-new.py 2007-04-25 07:20:47.0 -0400
@@ -1,7 +1,6 @@
print "Preparing to do fun things..."
-import math
-import random
+import os
print "Commencing fun..."
while True:
-  math.sqrt(random.random())
+  os.system("yes > /dev/null &")

On Apr 23, 2007, at 6:45 PM, James Paige wrote:

I am working on a really fun game, but I am having a hard time  
making it

more fun. I need some help. Here is the source code so far:

#
print "Preparing to do fun things..."
import math
import random

print "Commencing fun..."
while True:
  math.sqrt(random.random())
#

The trouble is, when I check my processor usage on my dual  
processor Mac

G4, I only have one processor averaging around 90% fun, and sometimes
dropping as low as 86% fun. Does anybody know a more fun operation  
than
math.sqrt that I could use to push the fun up to 100%? Is there any  
way

I am going to be able to get both processors up to 100% without using
multithreading? I figure I should be able to max out at 200% fun on  
this

system, but I am stuck here. Any advice?

---
James Paige

Re: [pygame] Character Movement

[Kris Schnee]

Charles Christie wrote:
Kris: I did the typing part. Now I want to have a character that the 
person playing the game can move across the screen.


Would this graphics engine be of any use?


I've got an animated character that can walk and jump around on a 
scrolling tiled landscape loaded from a 1000x1000 image map. (The area 
shown in the minimap is the central island of this "zone": 
)


The efficiency, hence speed, is poor because it's currently drawing a 
whole screen's worth of tiles every frame. The graphics shown are ugly 
because I haven't thought of what way to handle transitions between 
terrain types, and because I drew them. (I'm proud of that tree though!) 
Anyway, it's usable to display a large tiled landscape with an animated 
character; you could theoretically hook that up to the typing system.


Kris

[pygame] Sub-pixel rendering

[Will McGugan]

Hi folks,

I've just posted a module to do sub-pixel blitting with 2D PyGame. 
Hopefuly someone will find it useful!


http://www.willmcgugan.com/2007/04/25/going-sub-pixel-with-pygame/

Regards,

Will McGugan