Re: [pygame] Pygame for SDL 2, and how it may look.

[B W]

Hi, Leonard,

If you're talking HW textures (which require a hardware display context),
one can have multiple renderers; and it can be beneficial to do so. The
renderer determines blend mode and other aspects. It could be more
manageable and preferable to have a renderer for every occasion, so to
speak.

Textures are not very compatible with the surface paradigm. It would
behoove us to examine these side by side, and figure out a way to foster
both. Surface code will likely just drop in if you keep the same API, but
working with textures is a departure from the surface workflow. We do not
want to try and make textures behave like surfaces, or vice versa. E.g. one
does not blit a texture, and one does not flip the screen buffer. It
requires one to be cognizant of what data structure one is dealing with.

IMO, support for textures should not be an afterthought. They are a
premiere feature of SDL2, and will likely be appreciated and preferred as
people delve into them. You folks are probably already realizing this at
least a little bit. If so, then good. :)

Respectfully,
Gumm


On Sun, Apr 16, 2017 at 11:01 PM, Lenard Lindstrom  wrote:

> Hi Ian,
>
> Thanks for replying.
>
> On 17-04-16 01:43 AM, Ian Mallett wrote:
>
>> On Thu, Apr 13, 2017 at 3:25 PM, Lenard Lindstrom > > wrote:
>>
>> """Render an image to a window
>> This is adapted from the SDL 2 example at
>> > 1-hello-world
>> > 1-hello-world>>.
>> """
>>
>>
>> ​Heh, I'm friends with Will. We're at the same university.​
>>
>> import pygame
>> from pygame.display import RendererWindow
>> import os
>>
>>
>> def get_resource_path():
>> my_dir = os.path.dirname(os.path.abspath(__file__))
>> return os.path.join(my_dir, 'data')
>>
>>
>> def run():
>> pygame.display.init()
>> title = "Hello World!"
>> rect = (100, 100, 640, 480)
>> flags = RendererWindow.SHOWN
>> with RendererWindow(title, rect, flags) as win:
>> ren = win.renderer
>> flags = (ren.ACCELERATED  |
>>  ren.PRESENTVSYNC   )
>> ren.open(flags)
>> image_path = os.path.join(get_resource_path(), 'hello.bmp')
>> bmp = pygame.image.load(image_path)
>> tex = ren.new_texture_from_surface(bmp)
>>
>> for i in range(3):
>> ren.clear()
>> tex.copy_to_renderer()
>> ren.update()
>> pygame.time.delay(1000)
>> pygame.quit()
>>
>> if __name__ == '__main__':
>> run()
>>
>>
>> A window with renderer and a window with surface are implemented
>> as distinct subclasses of a standard Window extension type. Each
>> Window instance is an open window on the display. Window updates
>> are perform by methods on the corresponding renderer or surface.
>> Window and renderer specific constants, such as SDL_WINDOW_SHOWN
>> and SDL_RENDERER_ACCELERATED are class attributes, though they
>> could also be included in pygame.locals.
>>
>> This is preliminary design work, so feedback is not only welcome
>> but also necessary.
>>
>>
>> ​Is it possible to combine the renderer with the window? I don't see why
>> the renderer needs to be pulled out of the pygame.draw module, and indeed,
>> this could be confusing for existing code.
>>
>> I don't quite understand. The renderer associated with the RendererWindow
> instance is returned by the window's renderer property.
>
> Why are the window and the renderer separate objects? There is a
> one-to-one relation between a window and its renderer or a display surface.
> And a window cannot have both. To avoid duplicating a bunch of window
> specific methods I created a Window class, with RendererWindow and
> SurfaceWindow (not shown) as subclasses. Also, a surface can have a
> renderer, and a combined surface-renderer object makes no sense. Still, I
> haven't ruled out renderer-window and surface-window types yet. However it
> is done, I don't see an elegant representation of the relationships among
> SDL windows, surfaces, renders, and textures.
>
> For maximum backcompatibility, something like the following would seem to
>> fit better with the existing API:
>>
>> surf1 = pygame.display.Window(rect1,flags)
>> surf2 = pygame.display.Window(rect2,flags)
>> #...
>> surf1.blit(...)
>> surf2.blit(...)
>> #...
>> pygame.display.flip()
>>
>> I don't recall what was decided about the feasibility of implementing
>> SDL2-style or hardware-accelerated rendering, but I'd hazard that this sort
>> of API wouldn't map well to it. OTOH, I don't think the decision to
>> implement a modern graphics interface was decided in the first place (just
>> that we're currently adding some SDL2 stuff).
>>
> The user can choose 

Re: [pygame] No confirm instructions sent?

[B W]

The project name is HUD Light.

On Thu, Mar 16, 2017 at 9:09 AM, B W <stabbingfin...@gmail.com> wrote:

> I did upload a png along with the project entry. Maybe that is the part
> that failed. When I refreshed my projects, I didn't see the new one in the
> list. I will check again later when I have access.
>
> On Thu, Mar 16, 2017 at 1:28 AM, René Dudfield <ren...@gmail.com> wrote:
>
>> It looks like the new project saved... but there's no image. Did you
>> upload an image?
>>
>> I didn't see an error in the logs, and I just made a new project myself
>> with no troubles. Can you give me any other info?
>>
>> cheers,
>>
>>
>> On Thu, Mar 16, 2017 at 5:48 AM, bw <stabbingfin...@gmail.com> wrote:
>>
>>> It worked! Thanks.
>>>
>>> Now I am getting Internal Server Error when I try to create a new
>>> project. =)
>>>
>>> On 3/15/2017 4:49 AM, René Dudfield wrote:
>>>
>>> Sorry about that. Yes, that's fixed now.
>>>
>>> cheers,
>>>
>>> On Wed, Mar 15, 2017 at 5:12 AM, bw <stabbingfin...@gmail.com> wrote:
>>>
>>>> Hi, René. I am getting Internal Server Error when clicking the Resend
>>>> Confirmation button. No other details are provided, and I'm not receiving a
>>>> confirmation email. Dunno if you are looking into this.
>>>>
>>>>
>>>>
>>>> On 3/12/2017 1:34 AM, René Dudfield wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> hopefully a confirmation email arrived for you now.
>>>>>
>>>>> cheers,
>>>>>
>>>>
>>>>
>>>
>>>
>>
>

Re: [pygame] No confirm instructions sent?

[B W]

I did upload a png along with the project entry. Maybe that is the part
that failed. When I refreshed my projects, I didn't see the new one in the
list. I will check again later when I have access.

On Thu, Mar 16, 2017 at 1:28 AM, René Dudfield  wrote:

> It looks like the new project saved... but there's no image. Did you
> upload an image?
>
> I didn't see an error in the logs, and I just made a new project myself
> with no troubles. Can you give me any other info?
>
> cheers,
>
>
> On Thu, Mar 16, 2017 at 5:48 AM, bw  wrote:
>
>> It worked! Thanks.
>>
>> Now I am getting Internal Server Error when I try to create a new
>> project. =)
>>
>> On 3/15/2017 4:49 AM, René Dudfield wrote:
>>
>> Sorry about that. Yes, that's fixed now.
>>
>> cheers,
>>
>> On Wed, Mar 15, 2017 at 5:12 AM, bw  wrote:
>>
>>> Hi, René. I am getting Internal Server Error when clicking the Resend
>>> Confirmation button. No other details are provided, and I'm not receiving a
>>> confirmation email. Dunno if you are looking into this.
>>>
>>>
>>>
>>> On 3/12/2017 1:34 AM, René Dudfield wrote:
>>>
 Hi,

 hopefully a confirmation email arrived for you now.

 cheers,

>>>
>>>
>>
>>
>

Re: [pygame] PYGAME 2.0

[B W]

100 years from now there will be pygameweek, drawing crusty old diehards
from all over. I like old things. :)

I like new things, too. So https://bitbucket.org/gummbum/gsdl2/, cause
SDL2, pypy, and cffi. It is a pygame-like to enable ease of transition and
code porting. Effort has focused on the staples, so many features are yet
TBD. I wrote a full featured pilot game with it (a feature and performance
exerciser), and am currently making a larger one for fun. Anybody who
appreciates 100% Python and full access to the SDL2 libraries should be
tempted by this. Contributors welcome.

On Thu, Apr 14, 2016 at 11:46 AM, DiliupG  wrote:

> Hi Leif,
>
> I don't mind testing software knowing that I am testing it but there comes
> a time that you want to write a program and would like to use software that
> is quite stable. I am talking about the second stage here. I will install
> the new version based on your response but will not hold you responsible if
> my computer explodes or melts down due to a pygame malfunction. :)
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-2412134389832442932_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Thu, Apr 14, 2016 at 7:00 PM, Leif Theden 
> wrote:
>
>> Nothing wrong with being lab rats.  I've played with it a bit, and while
>> its not a "drop in replacement", it seems stable enough.  More testers is
>> better.  At one time pygame1 was in a "test" stageno need to fear it.
>>
>> On Thu, Apr 14, 2016 at 5:42 AM, DiliupG  wrote:
>>
>>> :-D
>>>
>>> Thanks for the response Noel but isn't the whole still in the "test"
>>> stage? Is it safe to uninstall 1.9.2 and Install this version? Or are we
>>> the lab rats? :-)
>>>
>>> On Wed, Apr 13, 2016 at 6:55 PM, Noel Garwick 
>>> wrote:
>>>
 lol, good point.  But I think that's what the SDL2 re-implementation of
 pygame is supposed to be, right?

 You can check out ren/pytom's github here..
 https://github.com/renpy/pygame_sdl2

 On Wed, Apr 13, 2016 at 12:53 AM, DiliupG  wrote:

> Since it's beginnings in 2000 isn't it time that we had Pygame 2 or do
> we wait till 2020 for that(so that version 2 comes 20 years later, like
> some kind of symmetry) ? Rene, I would like you to respond please..
>
> --
> Diliup Gabadamudalige
>
> http://www.diliupg.com
> http://soft.diliupg.com/
>
>
> **
> This e-mail is confidential. It may also be legally privileged. If you
> are not the intended recipient or have received it in error, please delete
> it and all copies from your system and notify the sender immediately by
> return e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited and 
> may
> be unlawful. Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability for any
> errors or omissions.
>
> **
>
>

>>>
>>>
>>> --
>>> Diliup Gabadamudalige
>>>
>>> http://www.diliupg.com
>>> http://soft.diliupg.com/
>>>
>>>
>>> **
>>> This e-mail is confidential. It may also be legally privileged. If you
>>> are not the intended recipient or have received it in error, please delete
>>> it and all copies from your system and notify the sender immediately by
>>> return e-mail. Any unauthorized reading, reproducing, printing or further
>>> dissemination of this e-mail or its contents is strictly prohibited and may
>>> be unlawful. Internet communications cannot be guaranteed to be timely,
>>> secure, error or virus-free. The sender does not accept liability for any
>>> errors or omissions.
>>>
>>> **
>>>
>>>
>>
>
>
> --
> Diliup Gabadamudalige
>
> http://www.diliupg.com
> http://soft.diliupg.com/
>
>
> **
> This e-mail is confidential. It may also be legally privileged. If you are
> not the intended recipient or have received it in error, please delete it
> and all copies from your system and notify the sender immediately by return
> e-mail. Any unauthorized reading, reproducing, printing or further
> dissemination of this e-mail or its contents is strictly prohibited 

Re: [pygame] Noob question: playing sounds

[B W]

Hi, you cannot use the dummy video driver if you want sound. At least I
have not figured out a way to do it. You need at least a 1x1 window.

Gumm

On Mon, Jun 1, 2015 at 2:11 PM, Philip Le Riche phi...@blueskylark.org
wrote:

  Just trying to get started with pygame and stuck at square 1. All I want
 to do is play sounds on a Raspberry Pi (Raspbian). No screen. Nothing
 visual. So I do:

 import pygame, os, sys
 from pygame.locals import *

 os.environ[SDL_VIDEODRIVER] = dummy

 pygame.mixer.init()
 sound = pygame.mixer.Sound(Exclamation.wav)
 sound.play(loops = 0)
 while pygame.mixer.music.get_busy() == True:
 continue

 Having saved it in file try.py, I do

 python try.py

 and get

 xcb_connection_has_error() returned true

 Yes, I've done an apt-get update and upgrade. I can make sounds with Sonic
 Pi but this produces nothing. Googling the error seemed to give no relevant
 results. Can someone give me a hint please?

 Regards - Philip

Re: [pygame] This program breaks on my Linux

[B W]

Hey, I bet you forgot about me! :)

I finally upgraded to Ubuntu 14.04. Alas, this problem did not go away.
Since the last message:

- I learned it doesn't matter if FPS is artificially capped; but faster FPS
seems to make the problem occur more reliably. This rules out throttled vs.
un-throttled.
- I learned it doesn't matter if the window is small or big; but smaller
gets faster FPS seems to make the problem occur more reliably. This may
rule out total blit calls and total pixels per frame.
- I learned it doesn't matter if the game uses the local display or remote
over a SSH tunnel. I think this rules out video drivers.
- incorporated the feedback from DR0ID, to put the exit calls outside the
main loop.
- incorporated the feedback from Sam, to use print statements to show exit
progress.

The issue seems to be in the shutdown/cleanup code of pygame. Yet, as I
indicated before the strange behavior (sudden permanent boost in FPS) is
observed well before program exit. Although this is harder to spot in
Ubuntu 14.04 because I'm getting near max FPS from the beginning.

The updated program is attached.

Gumm


On Sun, Jun 29, 2014 at 8:26 AM, bw stabbingfin...@gmail.com wrote:

 Hi, DR0ID,

 While it may not be elegant there is nothing syntactically wrong with what
 I did in the event loop. :) When the misbehavior is not occurring there is
 no problem exiting the program as it is designed.

 To get to the bottom of this I think someone with the right skills and
 knowledge would have to dig well beneath the Python code. I lack the
 requisites, unfortunately.

 Gumm


 On 6/29/2014 02:10, DR0ID wrote:

 On 2014-06-28 19:14, bw wrote:

 if e.key == K_ESCAPE:
 print(1)
 pygame.display.get_init()
 print(2)
 pygame.display.get_surface()
 print(3)
 screen.unlock()
 print(4)
 pygame.display.set_mode((16, 64))
 print(5)
 pygame.display.flip()
 print(6)
 pygame.quit()
 print(7)
 sys.exit()
 print(8)

 In this sequence it's understood 8 will never be reached. When the
 program exits normally 7 is printed and the program terminates. When the
 fps gallops away, indicating the problem has occurred, the last thing
 printed is always 6 and the program hangs. In all cases the pygame
 functions return, except for pygame.quit(). When trying other exit routines
 in lieu of pygame.quit() the exiting statement hangs, I presume because
 pygame's cleanup is called.

 Gumm

 On 6/28/2014 05:29, Sam Bull wrote:

 On ven, 2014-06-27 at 22:35 -0700, bw wrote:

 I attached the small program. I'm curious if anyone can run it and
 reproduce the problem. I plan on upgrading Ubuntu soon, when I am ready
 to risk it: maybe the problem will go away. I'll post the outcome--but
 I've been too busy to risk the upgrade, so don't hold yer breath. =)

 No idea what the problem could be. I can't reproduce it, but also not
 getting more than 130 FPS on my old laptop. I'm curious as to exactly
 when it crashes though, can you add some print statements to find
 exactly where it crashes?

  if e.key == K_ESCAPE:
  print(Before)
  pygame.quit()
  print(After Pygame exit)
  quit()
  print(Never reached)
  I'd also experiment with a couple of different exit functions,
 to see if
 that makes any difference. For example, try removing the pygame.quit()
 call (Pygame will exit safely with Python anyway, so it's a redundant
 call here), and using sys.exit() instead of the builtin.



  Hi

 Could it be that quitting pygame while processing the event queue (well,
 the if is in the loop where you process the events) isn't that nice?

 Maybe this does not address the actual problem, but might help finding
 the problem.

 I would prefer something like this (using the pygame.quit *after* leaving
 the while loop):

 running = True
 while running:
 ...
 for event in pygame.event.get():
 
 if event.key == K_ESCAPE:
 running = False

 pygame.quit()
 sys.exit()


 Also I thought (maybe I'm wrong) that pygame.quit() is registered by
 pygame in the 'atexit' module (so no needed to call separately if quiting
 the program, of course you need a pygame.quit() if you only want to quit
 pygame but keep python running).

 I hope that helps

 ~DR0ID



import sys
import time

import pygame
from pygame.locals import *

pygame.init()
resolution = 1024, 768
image_size = 200
# these two lines run better over ssh -X ...
#resolution = 196, 16
#image_size = 8
screen = pygame.display.set_mode(resolution, DOUBLEBUF)
screen_rect = screen.get_rect()
scroll_rect = Rect(screen_rect)
scroll_rect.width *= 5
scroll_rect.height *= 5
clock = pygame.time.Clock()
images = (
pygame.Surface((image_size, image_size)),

Re: [pygame] Circle cut off at 60+fps, fixed by display.flip

[B W]

Try this.

import pygame
from pygame import Color, KEYDOWN
w,h=800,200
fps=60
pygame.init()
screen = pygame.display.set_mode([w, h])
color=pygame.Color(white)
clock=pygame.time.Clock()
radius=20
x,y=800,100
speedx=-4
def get_bbox(x,y):
left = x - radius + speedx
top = y - radius
width = radius * 2 + abs(speedx) * 2
height = radius * 2
return pygame.Rect((left, top), (width, height))

while True:
old_x=x
x+=speedx
screen.fill(pygame.Color(black),get_bbox(old_x,y))
pygame.draw.circle(screen, color, (x, y), radius, 1)
get_bbox(x,y)
pygame.display.update([get_bbox(old_x,y),get_bbox(x,y)])
clock.tick(fps)



On Thu, Jun 12, 2014 at 7:32 PM, Abhas Bhattacharya 
abhasbhattachar...@gmail.com wrote:

 What is also quite surprising is that the circle gets cut off in the
 same direction in which it is moving. That makes me think it cant be a
 v-sync/screen-refresh issue.

Re: [pygame] Circle cut off at 60+fps, fixed by display.flip

[B W]

Oops. I spotted a couple things I changed to aid my experimentation, and
did not revert. They do not affect the operation of the program, but I want
to identify them as a red herring so you don't waste time wondering about
the differences.

The import Color and KEYDOWN. This had no impact on the behavior.

The calls to get_bbox() are reversed in pygame.display.update(). This had
no impact on the behavior either way.

The changes I made that do impact the code are the lines that contain
speedx.

Cheers,

Gumm


On Fri, Jun 13, 2014 at 9:42 AM, B W stabbingfin...@gmail.com wrote:

 Try this.

 import pygame
 from pygame import Color, KEYDOWN

 w,h=800,200
 fps=60
 pygame.init()
 screen = pygame.display.set_mode([w, h])
 color=pygame.Color(white)
 clock=pygame.time.Clock()
 radius=20
 x,y=800,100
 speedx=-4
 def get_bbox(x,y):
 left = x - radius + speedx

 top = y - radius
 width = radius * 2 + abs(speedx) * 2

 height = radius * 2
 return pygame.Rect((left, top), (width, height))

 while True:
 old_x=x
 x+=speedx

 screen.fill(pygame.Color(black),get_bbox(old_x,y))
 pygame.draw.circle(screen, color, (x, y), radius, 1)
 get_bbox(x,y)
 pygame.display.update([get_bbox(old_x,y),get_bbox(x,y)])
 clock.tick(fps)



 On Thu, Jun 12, 2014 at 7:32 PM, Abhas Bhattacharya 
 abhasbhattachar...@gmail.com wrote:

 What is also quite surprising is that the circle gets cut off in the
 same direction in which it is moving. That makes me think it cant be a
 v-sync/screen-refresh issue.

Re: [pygame] Alternate to graphics modules

[B W]

Hi, Elias. Just condensing all the responses. It seems if you want to do it
all in Python without requiring third-party modules or libraries, the best
answers is write your own interface to OpenGL. You may not have to write
everything from scratch. Take a look at pyglet's OpenGL bindings, they are
completely in Python. And pyglet has a liberal license which IIRC allows
copying and modifying (be sure to read the license and use your own
judgement).

The main reason I think this is your only option is because, wherever you
find a modern video card you are likely to find OpenGL already installed.
You can use other libraries, and I daresay you'd find them a lot easier to
learn and use, but these others are not already installed.

Hope this helps your pursuit.

Gumm


On Fri, Feb 8, 2013 at 6:11 AM, Noel Garwick noel.garw...@gmail.com wrote:

 True.  Still, some might see a distinction between the compiler taking
 code that a human has made, breaking it down and optimizing the calls into
 operations, and then assembling that vs. using python to make calls to
 functions written in python that call functions that someone else has
 written in C.

 Of course, all of this is just academic (vaguely :p).  The cool thing
 about this thread is that Elias' request was not met with use C, n00b, 
 suggesting python should be used for low level ops.., or even just
 silence.  Instead, pygame-users explained the logical issues with the
 request (that the OP likely wasn't aware of), and explained why the request
 becomes more of a question of semantics than anything else. As well, they
 offered suggestions for what could qualify as the next closest method to
 fulfill that request.  That is cool.

 But yeah:  If you want to use python's syntax to work with low-level
 graphics calls, the modules with low-level bindings can offer a pretty
 direct 'middle man.'  If you want to write C to use the libraries those
 wrap directly, that's a possibility (and not as hard as it looks at first.)
  Or if you really want to get into it (mostly just useful for education,
 but we wouldn't be here if pedagogy wasn't of some interest), try out some
 assembly.  You will need to emulate an older set of hardware, since as far
 as I'm aware things like 0x13h mode don't exist anymore, and as far as I
 know most APIs to directly access a graphics card are going to be in C (if
 I'm mistaken here, someone please correct me.)

 If your overall goal is to get a better understanding of how graphics and
 programming in general work, doing a small project in each of these
 languages in order could be pretty enlightening (this is how it 'clicked'
 for me, at least) -- tutorial links included:

 1. Pygame [Okay, so I take input, then I update the values from that
 input, and then I draw.. I guess that's easy enough?]
 http://inventwithpython.com/

 2. 6502 Assembly (NES) [Registers, memory management, reading/writing to
 ports/specific addresses, what loops, containers, and other things we take
 for granted actually look like, etc.]
 http://www.nintendoage.com/pub/faq/NA/nerdy_nights_out.html

 3. C [Working directly with C and SDL or OpenGL calls]
 http://www.lazyfoo.net/SDL_tutorials/ (SDL)   I'm not sure what a
 solid, modern opengl tutorial would be; can anyone provide a link? :p

 4. C/Pygame [Now that I understand how all that boilerplate works, I can
 feel comfortable using 'shortcuts', since I see the benefits they really
 offer (so now the only benefit of rolling my own is going to be '..just
 'cause' 95% of the time), and can foresee/avoid the things that could cause
 bottlenecks. Or I can use C since I want to experiment with designing more
 complex 3d shaders, physics, etc. Or just because I think it's fun to use
 C.]

 [Sorry for the wall of text; hopefully it's helpful]



 On Thu, Feb 7, 2013 at 11:20 PM, Julian onp...@gmail.com wrote:

 On 02/07/2013 10:06 PM, Ian Mallett wrote:

 The point is that you need to go through some kind of middle layer.
 Python code, by definition, does not interface directly with anything--you
 must go through some library/package--whether it is a built-in within
 Python's runtime, a 3rd-party distribution, or a wrapper you make around
 existing C functionality.


 Well, if you want to get really technical, only machine code interfaces
 directly with anything. C abstracts this so your code can work on more than
 one type of processor. Even assembly languages abstract a little bit, if
 I'm not mistaken, though it's pretty direct.

Re: [pygame] Pygame sound delay problem

[B W]

Hi, Joshua. In my own projects I've noticed lag with some sounds that
buffer tuning couldn't improve. Those I discovered were largely due to the
shape of the sound: there is a minute delay introduced by the SDL call but
it is almost unnoticeable when using a sound that has an immediate attack.
I am noticing this same kind of thing with your demo sound. When I load
this file into Audacity I see there is a short prelude of quiet until the
peak decibels are produced, which is quite detectable to my ear. Once I
edited out the quiet part with Audacity your demo produces a response that
seems much more immediate. If modifying the sound file in this fashion does
not solve your issue, it may be the way SDL uses your sound card which
unfortunately I think cannot be tuned (someone please correct me if I'm
wrong, I too would like to learn a new trick).

Hope this helps.

Gumm


On Thu, Dec 13, 2012 at 3:05 PM, Joshua_Blake tri_mag...@yahoo.com wrote:

 sound_test.zip
 http://pygame-users.25799.n6.nabble.com/file/n407/sound_test.zip
 I'm uploading a zip of the demo with one of the sounds I a using. A copy of
 the code is posted below. I did some more tests, and apparently in my
 previous efforts I somehow was passing an incorrect value into the pre_init
 call (which I'm assuming pygame was silently ignoring). So, after fixing
 that, the demo and my game run fine. But only on my XP laptop. On the
 desktop the demo runs fine, but the game still has the delay... what gives?
 Is there something in my windows 7 audio system that could be causing the
 delay? Or could it be in my game loop? If that's the case, why would it run
 great on my way old laptop and not on the really nice new desktop?

 import pygame, sys
 from pygame.constants import *

 pygame.mixer.pre_init(44100,-16,2,1024)
 pygame.init()

 BACKGROUND_FILL = (217,204,185)

 display = pygame.display.set_mode((400,400))
 clock = pygame.time.Clock()

 sound_obj = pygame.mixer.Sound('some_sound.wav')

 while True:
 clock.tick(30)
 for event in pygame.event.get():
 if event.type == QUIT:
 pygame.quit()
 sys.exit()

 if event.type == MOUSEBUTTONDOWN:
 sound_obj.play()

 display.fill(BACKGROUND_FILL)
 pygame.display.update()




 --
 View this message in context:
 http://pygame-users.25799.n6.nabble.com/Pygame-sound-delay-problem-tp405p407.html
 Sent from the pygame-users mailing list archive at Nabble.com.

Re: [pygame] Object not moving!

[B W]

Hi, Tanner.

A minor correction: blit(surface, rect) is allowed and has the same effect
as blit(surface, rect.topleft). This is explained in the documentation for
Surface.blit.

The real culprit, as Al indicated, is the third argument to blit, which
essentially causes nothing to blit once the rect's position (e.g. topleft)
moves outside the dimensions of the surface area. This can be a bit
confusing, and the mistake is not at all obvious when using the same rect
for the second and third argument so don't feel bad. :)

Gumm


On Thu, Dec 6, 2012 at 9:54 PM, Al Sweigart a...@inventwithpython.com wrote:

 Three things:

 1) The line should be: screen.blit(Guy.image, Guy.rect.topleft)

 If you look at the pygame documentation for the blit() method here:
 http://www.pygame.org/docs/ref/surface.html#Surface.blit

 The first parameter to blit() is the pygame.Surface of the image to draw
 (you have this right), but the second one should be a tuple of x,  y
 coordinates for the top left on the screen Surface that Guy.image gets
 drawn. That's why it needs to be Guy.rect.topleft, not Guy.rect. The third
 parameter is a rect object that shows what section of Guy.image is blitted
 to screen. You are drawing the entire Guy.image image, so you don't have to
 pass anything for the third one (it's the entire image by default). Passing
 Guy.rect is the exact same thing as specifying the full image, so you don't
 have to do anything.

 Basically, it was passing the pygame.Rect object Guy.rect instead of the
 tuple of two ints Guy.rect.topleft that was causing the problem.

 2) Change the indentation of the .blit() and .update() lines. They only
 need to be inside the while True: loop, not the for loop.

 3) Remember to fill the screen image with the background color, or else
 you will keep drawing the good guy image over and over on the screen. Add:

 screen.fill( (0,0,0) ) to the start of the while True loop. (If you don't,
 you'll see what I mean by drawing the good guy image over and over on the
 screen.)

 -Al



 On Thu, Dec 6, 2012 at 7:56 PM, Elias Benevedes 
 benevedesel...@gmail.comwrote:

 Explicit, please? I'm not very good at riddles...


 On Thu, Dec 6, 2012 at 7:31 PM, Tanner Johnson tbjohnso...@gmail.comwrote:

 I'm the 'point me in the right direction' type, so here's a vague
 description of where to go to fix this bug. If you want a more explicit
 answer, let me know!

 Take a look at the line where you're blitting the image and look at your
 inputs to that function. There's a problem there. Take a look at the blit
 documentation and see what you can do to fix it.

 Once you resolve that, you'll see a second bug, but the answer to that
 one should be pretty easy to figure out.

 Happy pygaming!


 On Thu, Dec 6, 2012 at 6:59 PM, Elias Benevedes 
 benevedesel...@gmail.com wrote:

 Hello everyone! I was having a little bug in my program. I HAVE NO IDEA
 WHY! I put print statements everywhere to check to make sure everything was
 being executed. Here is my code:

 import pygame, sys
 from pygame.locals import *

 pygame.init()

 screen = pygame.display.set_mode((640,480))

 class goodGuy(pygame.sprite.Sprite):
 def __init__(self):
 pygame.sprite.Sprite.__init__(self)
 self.image = pygame.image.load('goodGuy.png')
 self.rect = self.image.get_rect()
 def up(self):
 print 'up'
 self.rect[1] -= 10
 def down(self):
 print 'down'
 self.rect[1] += 10
 def right(self):
 print 'right'
 self.rect[0] += 10
 def left(self):
 print 'left'
 self.rect[0] -= 10
 Guy = goodGuy()

 while True:
 for event in pygame.event.get():
 if event.type == pygame.KEYDOWN:
 if event.key == K_UP:
 Guy.up()
 print 'Up'
 if event.key == K_DOWN:
 Guy.down()
 print 'Down'
 if event.key == K_RIGHT:
 Guy.right()
 print 'Right'
 if event.key == K_LEFT:
 Guy.left()
 print 'Left'
 if event.key == K_ESCAPE:
 pygame.quit()
 sys.exit()
 screen.blit(Guy.image, Guy.rect, Guy.rect)
 pygame.display.update()

 All that I want to happen is that for each respective arrow key, I want
 to move the image 10 pixels in that direction. Any help?


 --
 The validity of internet quotes are getting sketchy nowadays
 -Abraham Lincoln





 --
 The validity of internet quotes are getting sketchy nowadays
 -Abraham Lincoln

Re: [pygame] Re: Re-Blitting of already blitted items

[B W]

It is common to use an object to store your image and state info, such as a
sprite. Thus, you would have a list of sprite objects and flip on a state
attribute to signal it's been blitted. For any object that has not been
blitted the state attribute would be off.

Gumm


On Thu, Nov 29, 2012 at 3:38 PM, Elias Benevedes
benevedesel...@gmail.comwrote:

 The only problem is, every time the function runs (Inside the main while
 loop), the might be a change to the list. If there is, I want it to blit
 the new item, but not move anything other than that. I guess I didn't
 explain enough.

 On Wednesday, November 28, 2012, Al Sweigart wrote:

 Hey Elias. Sure, after your screen.fill(White) line, you want to add a
 call to a function like drawImagesInList(allpots). (Then get rid of the for
 loop after it.)

 You'll want to define the drawImagesInList() function this:
 def drawImagesInList(listOfImages):
 curx = 0
 for im in listOfImages:
 surface.blit(im, (curx, 0))
 curx += 50

 Now you can pass drawImagesInList() a list of pygame.image objects and it
 will automatically draw them across the screen.

 -Al


 On Wed, Nov 28, 2012 at 8:41 PM, Elias Benevedes 
 benevedesel...@gmail.com wrote:

 Hello everyone

 I was wondering if there was a way to make it so that you have items in
 a list representing images, a function adding to that list. Then, you have
 a function adding to that list. Then, you have a for loop blitting each of
 those pictures onto a surface, and adding 50 pix to the x amount for each
 iteration. The only problem is, every time the for loop iterates, every
 frame,  it adds 50 to the x amount AND re-blits the picture, moving it 50
 pix to the right. I want to make it so that every time the for loop
 iterates, it checks to see if that item has already been blitted. If it
 has, don't re blit it. If not, blit it 50 pix to the right of the
 previously blitted image. Here is the code, if nothing above made sense to
 you ( I tend to ramble):

 import pygame, sys
 from pygame.locals import *

 pygame.init()

 def loadImage(image, posx, posy):
 screen.blit(image, (posx, posy))

 screen = pygame.display.set_mode((640,480),0)
 healthpot = pygame.image.load('Health.png')
 manapot = pygame.image.load('Mana.png')
 pygame.display.set_caption('Inventory test')
 White = (255,255,255)
 allpots = [manapot, healthpot]
 curx = 0
 cury = 0

 while True:
 for event in pygame.event.get():
 if event.type == pygame.QUIT:
 pygame.quit()
 sys.exit()
 screen.fill(White)
 #screen.blit(healthpot, (0,0))
 #screen.blit(manapot, (50, 0))
 for i in allpots:
 loadImage(i, curx, cury)
 curx += 50
 pygame.display.flip()



 --
 The validity of internet quotes are getting sketchy nowadays
 -Abraham Lincoln




 --
 The validity of internet quotes are getting sketchy nowadays
 -Abraham Lincoln

Re: [pygame] [Pygame] Tileset Animation

[B W]

Howdy. I'd like to add to the decent suggestions.

If all you want to do is animate a sprite from a tile sheet, you can use
the Spritesheet recipe http://www.pygame.org/wiki/Spritesheet. It might
be useful as is, or you can tailor it to your needs. While you're there, be
sure to check out the pygame cookbook
http://www.pygame.org/wiki/CookBookto fill up your bag of tricks.

In addition to the resources mentioned for working with Tiled map files,
there is my favorite
pytmxloaderhttp://www.pygame.org/project-map+loader+for+%27tiled%27-1158-3692.html
which
comes with a very robust pygame demo.

If you care to study a great example of a map scrolling technique, I always
recommend Retro Game
Libraryhttp://www.pygame.org/project-Retro+Game+Library-1065-.html.
I call this a great example because it is a complete yet simple game
framework, making it exceptionally instructional.

The following few projects use Tiled, pytmxloader with pygame to great
effect: three pyweek competitions
http://code.google.com/p/multifac/, a pyweek
warmuphttp://code.google.com/p/multifac/downloads/detail?name=fort-izembo-1.zip,
and the tile scrolling engine Gummworld
2http://www.pygame.org/project-Gummworld2-1733-3879.html.
I imagine there are more out there. Projects such as these may offer a
potential for higher learning.

Finally, you might get more ideas and suggestions on IRC freenode.net#pygame.
Just ask your question and give it some time. Folks there tend to stay
logged in so they can catch up on chat once in a while. Long periods of
silence are not uncommon. They are not ignoring you, just sleeping or
gaming or watching TV, or doing things that are certainly better left
unknown. :)

Gumm


On Wed, Nov 14, 2012 at 11:52 AM, Radomir Dopieralski
pyg...@sheep.art.plwrote:

 On Wed, Nov 14, 2012 at 7:07 PM, yannisv yannisveza...@gmail.com wrote:
  Hello! Allow me first to apologize if this post is a duplicate,
 apparently my
  first one was not accepted and I just subscribed. Now, I've been trying
 to
  make a 2D RPG but I'm stuck. I cannot figure out how to properly use
  tilesets, and I cannot find any useful or beginner-friendly tutorials.
 
  First of all, I have the tileset of my main character. I want to slice
 the
  image into tiles and use them for my character's movement. Up, down,
 right,
  left.
 
  Secondly, how can I use a map I made with Tiled Map Editor with
 pygame? I
  simply exported my map as an image file, but I guess if it was imported
 in
  the code as tiles, with scenery and object layers, it would be easier to
 add
  things like collision detection etc.

 I ran a tutorial on that topic this year, the first part is recorded
 and the sources are available.
 https://ep2012.europython.eu/conference/talks/hands-on-with-pygame

 (I will be running an improved version of that tutorial in March on
 PyCon.US, *if* they accept it)

 --
 Radomir Dopieralski, http://sheep.art.pl

Re: [pygame] growing out of idle ide

[B W]

Tried many, keep going back to DrPython. Its Qt layout is a bit nicer in
Windows than Linux, though.

Gumm

On Thu, Aug 11, 2011 at 3:30 PM, Justin Hamilton 
justinanthonyhamil...@gmail.com wrote:

 On Thu, Aug 11, 2011 at 5:02 PM, Alex Nordlund 
 deep.alexan...@gmail.comwrote:

 On Thu, Aug 11, 2011 at 10:39 PM, Ian Mallett geometr...@gmail.com
 wrote:
  I'm pretty enthusiastic about IDLE, myself.  Unlike C/C++, Python is
  intuitive enough so that you don't need a debugger to use it.  It's
 somewhat
  liberating, in my opinion, to just go with the raw code.  I tend to find
  problems faster and more easily when the only thing I care about is the
  code.

 I like Komodo Edit/IDE here, it lets me do remote debugging.
 Which I find to be faster for me than just staring at the code.

 ---
 //Alex


 I'm a huge Emacs + python-mode + rope + yasnippet guy, but if you don't
 already know Emacs its probably a bit much to jump into. I've never used
 IDLE.

Re: [pygame] Re: SDL 1.3 blit speed

[B W]

Hi, Brian.

DR0ID and I have been discussing this particular technique. We're very
intrigued by the concept. It is a brain-twister, though! I searched far and
wide and haven't found any examples in any language. Would you happen to
know of an example, article or book discussing it in further detail?

Gumm

On Tue, Jul 12, 2011 at 10:32 PM, Brian Fisher br...@hamsterrepublic.comwrote:

 One particular technique for scrolling multi-layer backgrounds (that don't
 have parallax or animation anyways) is to have one large surface which is
 big enough to cover the screen, and to treat it as a wrapping buffer (so you
 do 4 blits to the screen from the surface in order to get the parts of the
 buffer as they wrap around the edges - hope that makes sense). Then as the
 background scrolls, you render in the newly visible parts into the buffer
 from your layers (using source clipping to get just the newly visible
 portion rendering on top of the newly offscreen part)

 It can have dramatic speed improvements compared to redrawing all layers
 every time because when you have a lot of layers with transparency, all that
 transparency gets flattened in the cache. The blit to the screen from the
 buffer is just a copy, it doesn't spend time on color-key or alpha blending
 (this technique is actually great for when you want alpha blended layers,
 btw, which can look better than color key).  Also, you'll have fewer blit
 calls as well, which means fewer native code crossings from python which are
 moderately slow.

 ...while animation and layers on top of animating characters don't work
 great with this technique, you can actually combine a dirty rect system with
 the wrapping buffer to address that, so as long as the use of the animation
 and the layers on top are sparsely used, you still get all the savings of
 not compositing the parts of the screen not affected by animation every
 frame.



 On Tue, Jul 12, 2011 at 7:02 PM, Brian Brown bro...@gmail.com wrote:

 That might work . . .  : )


 On Tue, Jul 12, 2011 at 6:58 PM, Brian Fisher 
 br...@hamsterrepublic.comwrote:

 If the layering is something that is consistent from one moment to the
 next, and you really have an overdraw of 3x, you can pre-combine and cache
 the visible parts, which could potentially make it take 1/3rd the speed
 (that's your goal, right?)


 On Tue, Jul 12, 2011 at 6:26 PM, Brian Brown bro...@gmail.com wrote:

 Yes, I'm only blitting the visible parts. It's the tile layering that
 causes 3x more blitting. (floor, carpet, and a possible wall for every
 tile.)
 Blitting the whole 300x300 map will take a very long time . . .

  . . .

 Okay so, will SDL 1.3 regular blitting be 3x faster?

 On Tue, Jul 12, 2011 at 11:52 AM, DR0ID dr...@bluewin.ch wrote:

 **
 On 12.07.2011 20:12, Brian Brown wrote:

 Thanks guys,
 I'm not using Pyopengl. (I found it a little too hard to use.)
 Pygame and SDL are working perfectly for me-- except-- I need faster
 blitting. That's all, I think.
 I've designed my game's graphics to simply rely on the blitting of many
 60x60 24-bit surfaces. (Approximately 300 to 500 blits per frame on a
 scrolling screen of 640x480 resolution. The game is tile based with an
 overlapping 3D illusion. The floor is drawn first, the mat second, and 
 the
 characters and blocks sorted by distance from bottom of screen are last.
 Should look fantastic when graphics are finished and when the fps is
 higher.)

  If SDL 1.3 will blit basic 24-bit surfaces (with a single colorkey)
 3x faster I think my game will work quite nicely.

  * I am using convert().
 * I'm *not* using per-pixel-alpha.
 * I even blit the freshly-loaded-surfaces onto a new surface to be sure
 the surfaces haven't inherited any unnecessary data from the png file. (I
 found this to significantly increase speed.)
 * The whole screen is scrolling so I use pygame.display.flip().
 * I think I'm using 24-bit images.
 * I need a high refresh rate for high speed chases with the local
 wildlife . . . (bear, tigers, unicorns etc.)
 * I'll have to try using surface.fill() instead of blitting . . .
 * My program's code is already running at a nice speed.

  Sounds like a great idea to continue programming with pygame and then
 later speed things up, but--

  It's just a little harder to program with slow graphics --My personal
 policy for low stress programming is to reward myself after every day of
 hard work by playing the game, and it's not the most fun in slow motion.

  Is there a way to convert 24-bit pygame surfaces to 8 bit RLE just
 to temporarily speed things up for testing?
 Thanks for the great advice guys.

 On Tue, Jul 12, 2011 at 6:14 AM, René Dudfield ren...@gmail.comwrote:

 On Tue, Jul 12, 2011 at 1:59 PM, Sean Wolfe ether@gmail.comwrote:

 Dude this was a really good answer. Respect


   Indeed, good answer.

 Also, are you using fast rendering techniques?

- Using 8 bit RLE encoded surfaces for the low colour depth images
- avoiding per pixel 

Re: [pygame] Re: SDL 1.3 blit speed

[B W]

That just hurt my brain. But I like it! :)

Gumm

On Tue, Jul 12, 2011 at 10:32 PM, Brian Fisher br...@hamsterrepublic.comwrote:

 One particular technique for scrolling multi-layer backgrounds (that don't
 have parallax or animation anyways) is to have one large surface which is
 big enough to cover the screen, and to treat it as a wrapping buffer (so you
 do 4 blits to the screen from the surface in order to get the parts of the
 buffer as they wrap around the edges - hope that makes sense). Then as the
 background scrolls, you render in the newly visible parts into the buffer
 from your layers (using source clipping to get just the newly visible
 portion rendering on top of the newly offscreen part)

Re: [pygame] Making animation.

[B W]

And a couple more I bookmarked. There are possibly more on pygame.org.

http://www.pygame.org/project-gradients-307-.html
http://www.pygame.org/project-Pygame+Advance+Graphics+Library-660-.html

For explosions, winking starts, muzzle flash, etc. you could search for
spritesheets, which are cheap but usually adequate.

Gumm

On Sat, May 28, 2011 at 9:40 AM, Jake b ninmonk...@gmail.com wrote:

 Take a look at http://www.pygame.org/project-PyIgnition-1527-.html

 ( you don't need openGL. )

 --
 Jake

Re: [pygame] Pygame: Fixed timestep demo?

[B W]

Jake,

Ian is correct. For meager demands pygame.time.Clock may suffice.

Here is a discussion on this mailing list, which starts out small, then goes
into some great detail about advanced needs, how and why, as well as some
cautions. Maybe more than you want. You can decide how far to go down the
rabbit hole.

http://archives.seul.org/pygame/users/Jan-2010/msg00146.html
http://archives.seul.org/pygame/users/Feb-2010/msg00020.html
http://archives.seul.org/pygame/users/Aug-2010/msg00079.html

Many folks roll their own. At least a few have taken a whack at making
something reusable.

http://www.pygame.org/wiki/ConstantGameSpeed (latest
herehttp://gummworld2.googlecode.com/svn/trunk/gamelib/gummworld2/gameclock.py,
though changes are untested in the field)
http://www.pygame.org/pcr/fpstimer/index.php
http://www.pygame.org/project-Game+Clock+demo-438-.html

None of them require a physics library.

Gumm

On Mon, May 2, 2011 at 7:20 AM, Ian Mallett geometr...@gmail.com wrote:

 Basically, just use pygame.time.Clock to maintain a constant framerate.


 On Mon, May 2, 2011 at 5:40 AM, Jake b ninmonk...@gmail.com wrote:

 What's the suggested way to use a fixed time step in pygame? I want to
 verify I'm using the right method. I want it for the case when you're
 not using a physics lib.

 ( There's resources at gaffer, and stackoverflow,  )
 but none specifically pygame that I found.

 Do you know of an example?

 --
 Jake

Re: [pygame] Sprite troubles

[B W]

 self.image, self.rect = loadImage('ground.bmp', -1)


I seem to recognize that function from somewhere. The pygame.org cookbook?
If so, -1 triggers the function to set the colorkey by picking the color
from the pixel at point 0,0 in your image. If your image is a solid color,
this would result in an image of essentially transparent pixels.

Gumm

Re: [pygame] how to change layer of a sprite in LayeredDirty group ?

[B W]

Hi, Horst.

If I recall correctly you can:

1. Set the sprite._layered attribute before adding sprite to the group.
2. Specify group.add(sprite, layer=n) where n is the layer.
3. Use group.change_layer(sprite, n) where n is the new layer.

Gumm

On Sun, Apr 17, 2011 at 8:43 AM, Horst JENS horstj...@gmail.com wrote:

 Hi,
 a question regarding pygame's LayeredDirty() group for sprites:

 how do i set or change the layer of a sprite in this group correctly ?

 At the moment (using pygame 1.9.1) i'm ony able to have the layer
 reflect the point of creating the sprite (newer sprites are on top of
 older sprites),
 but i can not use ._layer like i could in the LayeredUpdate group.

 I have also no results for using

 layer

 instead of

 ._layer

 (there is a comment int hte pygame.org wiki hinting to that)

 is there another trick to set / change the layer of a sprite in
 LayeredDirty groups ?

 greetings,
  -Horst

 --
 http://ThePythonGameBook.com

Re: [pygame] Mask collision detection

[B W]

Howdy,

Put your background image in a sprite object and add a mask attribute, just
like you do for Blok objects.

Then test for collisions with pygame.sprite.collide_mask.

Gumm

On Mon, Dec 13, 2010 at 1:27 AM, Petrovski
peter.b...@tweakedsolutions.nlwrote:

 Hi,

 I´m having some trouble with detecting collisions between 2 masks.

 What i´m trying to do is create a sort of a terrain with a polygon,
 then drop a box that should keep dropping until it hits the terrain.

 With the following code I get 2 masks that when checked with
 mask.count() are greater than 0.

 Problem is they are not detecting each other. I tried both
 pygame.mask.from_threshold and pygame.mask.from_surface to make a mask
 of the polygon. For overlapping detection I tried Mask.overlap_area
 and Mask.overlap. Both did not work.

 Any help would be greatly appreciated

 This is my code:
 +-Main class:
 import pygame
 import Blok
 from pygame.locals import *

 def main():

pygame.init()

screen = pygame.display.set_mode((750, 500))
pygame.display.set_caption('Spike 2')

#Backgrounds
background2 = pygame.Surface(screen.get_size())
background2 = background2.convert()
background2.fill((0, 0, 250))

background = pygame.Surface(screen.get_size())
background = background.convert()
background.fill((0, 0, 250))
background.set_colorkey((0, 0, 250), RLEACCEL)

#Make the terrain polygon
area = [(0, 300), (290, 475), (450, 200), (550,475),(750,350),
 (750,500),(0,500)]
colour = (250, 0, 0)
pygame.draw.polygon(background, colour, area)

clock = pygame.time.Clock()
zoneObjectSprites = pygame.sprite.RenderPlain()

while 1:
clock.tick(60)

for event in pygame.event.get():
if event.type == QUIT:
return
elif event.type == KEYDOWN and event.key == K_ESCAPE:
return
if event.type == MOUSEBUTTONDOWN:
if event.button == 3:
#spawn a box at the cursor position
mX, mY = pygame.mouse.get_pos()
Blok.Blok(mX,mY).add(zoneObjectSprites)

#Blue background and terrain
screen.blit(background2, (0, 0))
screen.blit(background, (0, 0))

#Get the mask of the terrain
#terrainmask = pygame.mask.from_threshold(background, colour,
 (1, 1, 1))
terrainmask = pygame.mask.from_surface(background)

#print the mask count to see if its big enough
print terrainmask.count()
for object in zoneObjectSprites:
object.gravity(terrainmask)
zoneObjectSprites.draw(screen)
pygame.display.flip()

 #this calls the 'main' function when this script is executed
 if __name__ == '__main__': main()


 +-Blok class:
 class Blok(pygame.sprite.Sprite):

def __init__(self, X, Y):
pygame.sprite.Sprite.__init__(self)
self.image, self.rect = load_image('blok1.bmp',-1)
screen = pygame.display.get_surface()
self.area = screen.get_rect()
self.rect.center = X, Y
self.gravityForce = 3
self.mask = pygame.mask.from_surface(self.image,255)
print self.mask.count()

def gravity(self,terrainmask):
dy = self.mask.overlap(terrainmask,(0,0))
print dy

#did we hit the ground?
if dy is not None:
print 'hit ground'
else:
newpos = self.rect.move((0, self.gravityForce))
self.rect = newpos

#kill object if it goes offscreen
if self.rect.top  500:
self.kill()

Re: [pygame] Overall volume control for sounds

[B W]

I too spent some time rassling with volume control. The result was an
extension of the conch module (
http://www.pygame.org/wiki/ConchMusicSoundToolkit) to provide
master/music/fx volume control for Trolls Outta Luckland. See gumm_sound.py
in the source package at
http://www.pygame.org/project-Trolls+Outta+Luckland-1358-2536.html.

Gumm

On Sat, Nov 27, 2010 at 12:47 AM, Janosch Gräf janosch.gr...@gmx.netwrote:

 Ivan DelSol wrote:
  I'm trying to write a system that has controls for overall sound
  effect volume. There does not seem to be a way to control all the
  sound channels... There doesn't seem to be a way to get pygame to pass
  channels by ID so that I could alter their volumes individually, let
  alone control the sound channels' volumes as a whole.
 
  Volume control seems like a pretty standard need in a game. Anyone
  else figured this out?
 
 
 Can't you just do it like this?
 for i in range(pygame.get_num_channels()):
c = pygame.Channel(i)
c.set_volume(your_volume)

Re: [pygame] more circles

[B W]

 it fascinating.  If you could just show me (more explicitly) how
 to do this, that would help.
 Thanks for the links, I will check them out.
 On Wed, Oct 6, 2010 at 10:02 PM, B W stabbingfin...@gmail.com wrote:

 You have to resize the rect *and* the image. You can use pygame functions
 Rect.inflate* and transform.scale, respectively, or you can do-it-yerself
 (hint: move some of the constructor code to a resize method and call that
 from in constructor, as well as the main loop).

 Also, the += and -= in the event handler cases are probably not doing what
 you intend. If you get the resize working so you can see the circle change
 and it grows or moves at a strange rate, re-examine those calculations.

 Gumm

Re: [pygame] Surface blitting not effective

[B W]

Your blits were copying the source to positions outside the target surface.
I always suspect this if I can't see my graphics. You can insert statements
like dlgsurface.get_rect().collidepoint(choicerect.topleft) or print
dlgsurface.get_rect().colliderect(choicerect) to tell whether the source
rect intersects the target rect.

I has a sneaking suspicion about the alpha problem and it paid off. Someone
who understands the internals of color alphas and surface alphas would have
to explain the why. :)

#Create menu surface
dlgsurface = pygame.Surface((xsize,ysize)).convert()
##change
#dlgsurface.fill(color)
dlgsurface.fill(*color[3:])
dlgsurface.set_alpha(color.a)
dlgrect = dlgsurface.get_rect(center=self.rect.center)
##new
drawrect = dlgsurface.get_rect()

cursor_rect = []
ypos = border

for option in options:
##change
#choicerect = option.get_rect(centerx=dlgrect.centerx, \
#top=dlgrect.top + ypos)
choicerect = option.get_rect(centerx=drawrect.centerx, \
top=drawrect.top + ypos)
dlgsurface.blit(option, choicerect)
##change
#
cursor_rect.append(cursor[0].get_rect(centery=choicerect.centery, \
#left = dlgrect.left+border))
cursor_rect.append(cursor[0].get_rect(
centery=dlgrect.top+choicerect.centery,
left=dlgrect.left+border))
ypos += option.get_height() + sep

Gumm

Sat, Oct 9, 2010 at 11:23 AM, Julian Marchant onp...@yahoo.com wrote:

 Attached is the file in question, comet_fighter.py (version 0.1.0.5).

 Game.menu() is supposed to show a menu. It takes the following arguments:

 options, cursor, anim_wait, color=pygame.Color(0,0,0,155), border=16, sep=8

 options is a list of surfaces used for the menu choices. cursor is a
 list of surfaces which animate to create the selection cursor. anim_wait
 is the time (in milliseconds) between each frame of animation for the
 cursor. color is a pygame.Color object with an alpha value, which is used
 to set the color and alpha of the back of the dialog. border indicates the
 number of pixels around the menu box, and sep is the number of pixels
 between each menu choice.

 The problem is, it doesn't seem to be working like it should.

 I tried calling Game.menu() in order to test it. It sort of worked, but not
 really. There are a few issues.

 First, the back of the menu is always fully opaque or fully transparent.
 Partial transparency isn't working.

 Second, and more importantly, the menu choices aren't showing up.

 Everything else seems to be working perfectly. I scanned my code at least
 twice, and I couldn't find anything wrong with it. Perhaps someone else can
 have better luck, or perhaps I'm doing something wrong?

Re: [pygame] more circles

[B W]

We are a supportive bunch, Kevin. From time to time even old-timers need
help.

Unless you are brand spanking new to computers and programming, or really
struggling to master the basics, I would expect you probably won't need a
tutor. You just need a few good resources.

Chances are someone has already answered any Pygame neophyte questions you
may have. The pygame-users mail
archivehttp://www.mail-archive.com/pygame-users@seul.org/info.htmlis
a very useful search resource. As well as Google which can turn up
good
problem-solution examples.

Mr. Jens, a fellow pygame-users subscriber, has put quite a bit of work into
his online The Python Game Book http://thepythongamebook.com, an
instructional book structured in chapters progressing from the ground up,
pictures, code, detailed explanations, and a rather good English
translation.

Pygame tutorials of shorter duration abound. Many good ones are available on
the pygame.org site.

For more advanced topics, Pygame gamelets
http://www.pygame.org/gamelets/offer demos in the form of small
working games. And you can search for
projects on pygame.org that match your concepts and dive into the code.

That only scratches the surface. If you ever need some serious inspiration,
check out pyggy.pyweek.org and www.pyweek.org.

Cheers.

Gumm

Re: [pygame] more circles

[B W]

You have to resize the rect *and* the image. You can use pygame functions
Rect.inflate* and transform.scale, respectively, or you can do-it-yerself
(hint: move some of the constructor code to a resize method and call that
from in constructor, as well as the main loop).

Also, the += and -= in the event handler cases are probably not doing what
you intend. If you get the resize working so you can see the circle change
and it grows or moves at a strange rate, re-examine those calculations.

Gumm

On Wed, Oct 6, 2010 at 6:07 PM, kevin hayes kevino...@gmail.com wrote:


 Hi,

 Well, I got it working.  The circle moves correctly according to keyboard
 input. The trouble I am having is with resizing the circle/sprite.
 Everything looks logical to me, but it won't function the way I want it to.
 I tried using the rect.inflate(x,y) method, but I couldn't see how to
 incorporate it. If someone could show me how to add the some resizing
 functionality, that would be great. I am going to be getting a tutor soon,
 so I won't be bringing my beginner questions to this board.  Thanks again to
 everyone who has assisted me.

 Here she is:

  MoveCircleSizeCircle.py
 Makes a circle that changes
 it's position and size by the
 keyboard, 10/3/10

 import pygame
 pygame.init()

 screen = pygame.display.set_mode((640, 480))

 class Circle(pygame.sprite.Sprite):
 def __init__(self, startPos, direction, reSize):
 pygame.sprite.Sprite.__init__(self)
 self.image = pygame.Surface((50, 50))
 self.image.fill((255, 255, 255))
 pygame.draw.circle(self.image, (0, 0, 255), (25, 25), 25)
 self.rect = self.image.get_rect()
 self.rect.center = startPos
 self.dx,self.dy = direction
 self.da,self.db = reSize

 def update(self):

 self.rect.width += self.da   #add to rects size by (x,y) values
 self.rect.height += self.db

 if self.rect.height  199:
 self.rect.height = 200
 if self.rect.width  199:
 self.rect.width = 200
 if self.rect.height  1:
 self.rect.height = 1
 if self.rect.width  1:
 self.rect.width = 1

 self.rect.centerx += self.dx   #move rect (x, y)
 self.rect.centery += self.dy

 if self.rect.right  screen.get_width():
 self.rect.left = screen.get_width() - 50
 if self.rect.left  0:
 self.rect.right = 50
 if self.rect.bottom  screen.get_height():
 self.rect.top = screen.get_height() - 50
 if self.rect.top  0:
 self.rect.bottom = 50
 def main():
 pygame.display.set_caption(Move the Circle with Arrows, Resize it
 with(0)+(9)-)

 background = pygame.Surface(screen.get_size())
 background.fill((255, 255, 255))
 screen.blit(background, (0, 0))


 circle = Circle([320, 240], [0, 0], [0, 0])
 pygame.mouse.set_visible(False)
 allSprites = pygame.sprite.Group(circle)
 clock = pygame.time.Clock()
 keepGoing = True

 while keepGoing:
  clock.tick(30)
 for event in pygame.event.get():
 if event.type == pygame.QUIT:
 keepGoing = False
 elif event.type == pygame.KEYDOWN:
 if event.key == pygame.K_DOWN:
 circle.dy += 2
 if event.key == pygame.K_UP:
 circle.dy -= 2
 if event.key == pygame.K_RIGHT:
 circle.dx += 2
 if event.key == pygame.K_LEFT:
 circle.dx -= 2
 if event.key == pygame.K_ESCAPE:
 keepGoing = False
 if event.key == pygame.K_9:  #resize by -2
 circle.da += -2
 if event.key == pygame.K_0:
 circle.db += 2   #resize by +2

 elif event.type == pygame.KEYUP:
 if event.key == pygame.K_DOWN:
 circle.dy = 0
 if event.key == pygame.K_UP:
 circle.dy = 0
 if event.key == pygame.K_LEFT:
 circle.dx = 0
 if event.key == pygame.K_RIGHT:
 circle.dx = 0
 if event.key == pygame.K_9:
 circle.da = 0
 if event.key == pygame.K_0:
 circle.db = 0

 allSprites.clear(screen, background)
 allSprites.update()
 allSprites.draw(screen)

 pygame.display.flip()

 pygame.mouse.set_visible(True)

 if __name__ == __main__:
 main()

 pygame.quit()

Re: [pygame] circles

[B W]

I like Ian's earlier suggestion, Kevin, which he only hinted at. But I sense
you're really struggling with how to extend your Circle class, and could use
an example to go with the explanations.

Note that every time you create a circle object with the Circle class,
you're executing the constructor __init__. So if you add some parameters to
__init__, then you can manipulate the creation and will get objects that
behave in the same manner but with different details. Details such as
position, direction, color, and anything else you need.

In the constructor do something like this:

class Circle(pygame.sprite.Sprite):
def __init__(self, position, direction, color, *groups):
pygame.sprite.Sprite.__init__(self, *groups)
#[use your same image and rect code]
self.rect.center = position
self.dx,self.dy = direction

Your update method is fine the way it is. As Ian points out, get rid of
update_circle2; it doesn't serve your purposes.

In main create some circles at different start positions, directions, and
colors, and might as well supply their sprite group since the Sprite
superclass's constructor can automatically add the sprite to the group for
you:

Circle([25,25], [+5,+5], Color(yellow), allSprites)  # top-left, going
down-right
Circle([640-25,25], [-5,+5], Color(red), allSprites)  # top-right, going
down-left

You may be wondering where the circles go, since you're obviously not
assigning them to a variable. They're in your sprite group, by virtue of the
pygame.sprite.Sprite.__init__(self, *groups) call.

I'm sure you can figure out the other two circles.

After making these changes, you can remove the few lines of main's sprite
initialization that no longer serve a purpose.

Hope that helps to get you over the hump.

Gumm


On Sat, Oct 2, 2010 at 7:38 PM, kevin hayes kevino...@gmail.com wrote:

 I just want to thank you for taking the time to help me out.  I'm going to
 take a break for a while and when I come back I'm going to look over your
 suggestions.  I hope to be able to answer some questions at some point
 rather than asking them.

 On Sat, Oct 2, 2010 at 7:24 PM, Ian Mallett geometr...@gmail.com wrote:

 On Sat, Oct 2, 2010 at 8:09 PM, kevin hayes kevino...@gmail.com wrote:

 At this point I don't really care if the sprites write over eachother...

 You should.  Because otherwise, you can't see anything.  I don't mean
 proper handling of occlusion; I mean not being able to see what's going on.
 The problem can be found by first figuring out why they are being drawn on
 top of each other.  In graphics programming the problem is almost always
 self-evident once you see what's actually happening.

 as long as that doesn't cause the program to crash.  I'm just trying to
 get four circles going diagonally from each corner.  The problem I'm having
 is with the update function...Do I write two update functions?  How do I get
 the update function to apply separate code for the two (or more) circles?

 Only one update function can exist.  What you CAN (and should) do, though,
 is have the update function do a different thing for each sprite.  Your
 second update function is never getting called, so delete it.

 Here is my code as it stands:

 Add this:
 circle2.dx = -5
 Then, you'll see that the sprites were being drawn over each other (and
 moreover, they were starting in the same position, so the yellow one darts
 off the screen to the left).  This latter is due to the fact that startPosx
 is never used.  Change your update function to change startPosx and
 startPosy instead of rect.center.

 Ian

[pygame] Orbiting bodies in pymunk

[B W]

Howdy, folks.

I made a small pymunk demo in which a Pygame sprite orbits the mouse
pointer. I'm trying to figure out a way to get an elliptical orbiting body.
Body.impulse is the only thing that appears to behave how I want, but after
many hours of experimentation there remain gross eccentricities in the orbit
that I can't resolve. The ball circles around the mouse a few times, its
orbit decaying, then flips around the other way; and cycles back and forth
between the two orbit-like patterns. It seems there are other influences at
work: pymunk physics I don't know about yet, or maybe precision errors, or
perhaps I'm just doing it all wrong.

I did the poring over docs thing, digging in modules, searching for demos
and articles, and came up rather empty. Certainly nothing on topic. I did
find a lot of complaints, though, about the dearth of pymunk demos. :)

If you are inclined to take a look, you'll need:
05_impulse.pyhttp://code.google.com/p/trollsouttaluckland/downloads/detail?name=05_impulse.pycan=2q=
game_clock.pyhttp://code.google.com/p/trollsouttaluckland/downloads/detail?name=game_clock.pycan=2q=
pymunk http://www.pygame.org/project-pymunk-780-2576.html

Use the down arrow to slow the ball if it gets going too fast, and move the
mouse a little to guide the ball into an elliptical path.

I sure would appreciate some new insight. Thanks in advance for any
assistance.

Gumm

Re: [pygame] moving a filled circle from top to bottom

[B W]

Hi, Kevin.

You already created the example. :) Just replace the few lines in your
__init__ method.

Note that this is not a better way of doing it. It's just an approach that
I find easier to work with when computing your graphics, i.e. procedural
graphics.

When you load your graphics from an image file, you get a surface sized to
fit the image and can get your rect from it. In contrast, when computing
your own graphics it might help to create your dimensions first (the rect)
and use the rect in plotting your graphics primitives.

Hope that explanation helps.

Gumm

On Wed, Sep 29, 2010 at 8:43 PM, kevin hayes kevino...@gmail.com wrote:

 Hey...my apologies for taking so long to get back to you, I was staying at
 a friend's house for a couple of days. I honestly don't understand your
 email. Maybe you could give me a small example...if you wish.


 On Mon, Sep 27, 2010 at 9:00 PM, B W stabbingfin...@gmail.com wrote:

 Changing the order might help with procedural images. Then you can make
 the rect's attributes work for you.

 self.rect = pygame.Rect(0,0,50,50)
 self.image = pygame.surface.Surface(self.rect.size)
 pygame.draw.circle(self.image, pygame.Color(0, 0, 255),
 self.rect.center, self.rect.width/2)
 self.image.set_colorkey(pygame.Color('black'))
 self.rect.center = 320,0

 Gumm

Re: [pygame] moving a filled circle from top to bottom

[B W]

Changing the order might help with procedural images. Then you can make the
rect's attributes work for you.

self.rect = pygame.Rect(0,0,50,50)
self.image = pygame.surface.Surface(self.rect.size)
pygame.draw.circle(self.image, pygame.Color(0, 0, 255),
self.rect.center, self.rect.width/2)
self.image.set_colorkey(pygame.Color('black'))
self.rect.center = 320,0

Gumm

On Mon, Sep 27, 2010 at 2:40 PM, kevin hayes kevino...@gmail.com wrote:

 Hey...thank you!  I'm now on someone else's computer, so I can't edit the
 code, but I trust that you are correct. Thanks again. Kevin


 On Mon, Sep 27, 2010 at 1:37 PM, Christopher Night cosmologi...@gmail.com
  wrote:

 It's extremely minor. Change the center of your circle from (320, 0) to
 (25, 25). The coordinates are with respect to self.image, not to screen.

 -Christopher


 On Mon, Sep 27, 2010 at 4:32 PM, kevin hayes kevino...@gmail.com wrote:

 Hi,
 This is my attempt at sending a circle(Sprite) vertically from
 the top of the screen to the bottom.  Can someone
 tell me how to change the code so it works?  Currently it is just
 creating a white screen. Thanks in advance. Kevin

 Attempt at moving a circle(Sprite) from top(of screen) to bottom

 import pygame
 pygame.init()

 screen = pygame.display.set_mode((640, 480))

 class Circle(pygame.sprite.Sprite):
 def __init__(self):
 pygame.sprite.Sprite.__init__(self)
 self.image = pygame.Surface((50, 50))
 self.image.fill((255, 255, 255))
#fill with white to hide square???
 pygame.draw.circle(self.image, (0, 0, 255), (320, 0), 25)
 self.rect = self.image.get_rect()
 self.rect.centerx = 320
 self.rect.centery = 0

 def update(self):
 self.rect.centery += 5
 if self.rect.top  screen.get_height():
 self.rect.bottom = 0


 def main():
 pygame.display.set_caption(Verticle Circle Sprite)

 background = pygame.Surface(screen.get_size())
 background.fill((255, 255, 255))
 screen.blit(background, (0, 0))

 circle = Circle()
 allSprites = pygame.sprite.Group(circle)

 clock = pygame.time.Clock()
 keepGoing = True
 while keepGoing:
 clock.tick(30)
 for event in pygame.event.get():
 if event.type == pygame.QUIT:
 keepGoing == False

 allSprites.clear(screen, background)
 allSprites.update()
 allSprites.draw(screen)

 pygame.display.flip()

 if __name__ == __main__:
 main()

 pygame.quit()

Re: [pygame] frame independant movement

[B W]

Alan,

With the GameClock recipe it'd just be a matter of decreasing
ticks_per_second (e.g. clock.ticks_per_second /= 5). Though if you're using
interpolation/prediction to smooth out your frames you may really notice
things like collision artifacts, as a wider separation of ticks versus
frames results in more predictive calculations between ticks.

This may be fine for continuous motion, but if the physics dictate a change
in speed or direction then the object visibly overshoots the point where it
should have changed. When the physics catch up during the next tick the
object jerks back onto the right path. Without a good predictive algorithm,
this is more noticeable when frame rate is much higher than gametick rate.

You can easily see this cosmetic problem in the GameClock demo by adding a
line (TICKS_PER_SECOND/5, 0), to SETTINGS.

I have noticed this in Internet games where the common design smooths out
network latency by using a prediction algorithm in the game client. There
may be ways to improve the cosmetics. But I have noticed that Internet games
usually seem to just not deal with the issue because it is adequate to rely
on the player's brain to compensate.

I first noticed this in Everquest: when other players' avatars inch forward
for a closer look at a mob of enemies they run out too far as displayed by
my client, and then suddenly they snap back to where the game server reports
they really are. At first I had many alarming moments, but eventually my
brain became adept at edited out the discrepencies and I did not notice them
unless I purposely looked for them.

On a nostalgic note... You EQ players, remember DC (disconnect) death? Lose
your server connection and wake up dead because the server assumed no
network packets meant keep going--which, if you were running, usually meant
you were on course for a cliff, ocean, lava, or gathering a train of hungry
critters. Rush out to buy a lottery ticket if you were saved by a wall or
snagged on a tree! Ah, the fun of that particular peril. :) A good
prediction here could have included keep-alive packets from the client,
and noticing their absence.

Gumm

On Fri, Aug 27, 2010 at 10:42 PM, R. Alan Monroe amon...@columbus.rr.comwrote:


  In other words, use a small enough time step that the difference
  is not big enough to be a problem. But if you're doing that, you
  might as well pick one sufficiently small time step and use a
  variable number of them per frame, so that the physics is
  always predictable whatever the frame rate.

 While we're on the time topic, is there an easy way to do slo-mo, a la
 Peggle Extreme Fever or a Burnout multi-car pileup?

 Alan

Re: [pygame] frame independant movement

[B W]

Howdy,

Reviving this old thread. The comments by Patrick and Brian really intrigued
me, so I pursued the topic. Found a few interesting articles and one great
article. My study has resulted in a recipe for those of us continually
nagged by the question, how can I get constant game speed independent of
frame rate?. The demo requires Pygame, but the clock module only requires
Python.

GameClock (http://www.pygame.org/wiki/ConstantGameSpeed) derived from
deWiTTERS Game Loop (http://www.koonsolo.com/news/dewitters-gameloop/).

Cheers,

Gumm

Re: [pygame] Re: Keeping a sprite on screen with rect.clamp

[B W]

I found this implementation of Bresenham's Line algorithm efficient enough
for real-time:

http://en.literateprograms.org/Bresenham's_line_algorithm_(Python)?oldid=16281

Gumm

On Mon, Aug 16, 2010 at 7:43 PM, Mark Reed markree...@gmail.com wrote:

 I want to calculate a straight path of points between two points and
 each frame do:

 sprite.x, sprite.y = sprite.path[step]
 step++

 And have the sprite move along that line.  I've lost all basic math
 skills, and don't want to spend an hour debugging such a simple thing.

 Mark

 On Tue, Aug 17, 2010 at 9:41 AM, Luke Paireepinart
 rabidpoob...@gmail.com wrote:
  Can you be more specific about what you mean? Are you trying to
 interpolated points between two endpoints or what?
 
  Sent from my iPhone
 
  On Aug 16, 2010, at 8:13 PM, Mark Reed markree...@gmail.com wrote:
 
  Anyone have a function for calculating all the points on a line to be
  used for sprite movement?
 
  Mark
 

Re: [pygame] Re: Keeping a sprite on screen with rect.clamp

[B W]

If you're trying to plot curved paths in real-time...

This forward differencing algorithm is the fastest I've found to date:
http://www.niksula.cs.hut.fi/~hkankaan/Homepages/bezierfast.html. Though it
is only suitable for purposes where the curve does not have to touch all the
control points.

And this recipe, mentioned by Ciro, makes a decent foundation for a Bezier
editor: http://www.pygame.org/wiki/BezierCurve. For my purposes I modified
it to use the forward differencing function, and print the control points on
demand.

To use real-time curves in this manner I had to solve the same problem you
mention, Mark, that the distance between points varies and results in
unwanted sprite speed variations. I ended up tracking sub-pixel sprite
position as a float, and advancing to the next curve point when the distance
traversed meets or exceeds the distance between the current and next point.

Here's a recipe for calculating point-to-point distance:
http://www.pygame.org/wiki/CalculateDist.

For straight lines I've successfully used vector math to move a sprite small
distances each frame at an arbitrary angle. This is very efficient for
motion along a vector, but floating point errors cause this method to be
imprecise. If you're moving to a specific point your sprite will most often
miss the point and end up orbiting it, which requires the addition of a
terminal test case based, for example, on a distance calculation. Still,
this is very efficient. It also requires some additional vector math to
compute angles and points on a circumference. If there is an interest I'm
willing to post a recipe for these.

Gumm

On Mon, Aug 16, 2010 at 11:01 PM, Mark Reed markree...@gmail.com wrote:


 Any path editors out there?

 Mark

Re: [pygame] pygame.sndarray.array = ValueError: string size must be a multiple of element size

[B W]

Ask and ye shall receive. Here are a couple publicly available files that
demonstrate what appear to be two different problems with sndarray in the
blessed Pygame example.

WAV http://www.freesound.org/samplesViewSingle.php?id=4359 blows up on line
88, ValueError: shape mismatch: objects cannot be broadcast to a single
shape. This one kinda surprised me.

OGG http://www.freesound.org/samplesViewSingle.php?id=32083 blows up on line
108, ValueError: buffer size must be a multiple of element size.

Gumm

On Fri, Aug 6, 2010 at 10:28 AM, Lenard Lindstrom le...@telus.net wrote:

 I don't know. Try the sndarray example:

 python -m pygame.examples.sound_array_demos

 Otherwise there is something different about your sound files. Without an
 example that causes the problem there is nothing I can do.

 Lenard


 On 05/08/10 03:45 PM, B W wrote:

 Thanks for responding, Lenard, though it doesn't seem this applies to my
 problem. The sound file is loaded successfully. I can play() the loaded
 sound just fine. It is the conversion of the mixer.Sound object to a
 sndarray.array object that's blowing up.

 Gumm

 On Thu, Aug 5, 2010 at 12:26 PM, Lenard Lindstrom le...@telus.netmailto:
 le...@telus.net wrote:

Okay, this is technically not a bug. If the string is not a valid
file path then it is assumed to be sound data. This has to be
fixed somehow.

Lenard


On 05/08/10 11:36 AM, Lenard Lindstrom wrote:

 Hi Gumm,

You have found a bug. pygame.mixer.Sound does handle
ogg/vorbis files. But it doesn't raise an exception when it
can't find the file. Also, on Windows you may find that
calling pygame.init() before pygame.mixer.init() will prevent
playback, no sound. Either remove pygame.init, place it after
pygame.mixer.init or set the SDL_AUDIODRIVER environment
variable to 'waveout'.

Lenard Lindstrom

On 03/08/10 11:03 AM, B W wrote:

Howdy, folks.

Seeking enlightenment. Anyone seen this before, and how do
I rassle it into submission? Docs and web have been
unhelpful so far. I'm using pre-built software packages;
been using these for months without any issues.

This problem occurs with all ogg and wav files. I see that
Numpy is raising the exception, but I can't tell if it's a
problem internal to Numpy or a result of how
numpysnd.array is using Numpy.

Summary:
1. load OGG-Vorbis sound file with pygame.mixer.Sound
2. convert sound using pygame.sndarray.array
3. scratch head

CODE
import os, sys, numpy, pygame
from pygame.locals import *
pygame.init()
pygame.mixer.init(44100, 16, 2, 1)
sound = pygame.mixer.Sound('../sounds/laser_26667.ogg')
for n,v in [('OS',os.name http://os.name
http://os.name
 ),('Python',sys.version),('Pygame',pygame.version.vernum),

   ('Numpy',numpy.version.version),('Array
type',pygame.sndarray.get_arraytype())]:
   print '%s: %s' % (n,v)
sound_data = pygame.sndarray.array(sound)
/CODE

C:/Python26/pythonw.exe -u
 C:/cygwin/home/Gumm/devel/python/project/gummball/blah.py
OS: nt
Python: 2.6.5 (r265:79063, Mar 20 2010, 14:22:52) [MSC
v.1500 32 bit (Intel)]
Pygame: (1, 9, 1)
Numpy: 1.4.1
Array type: numpy
Traceback (most recent call last):
 File
C:/cygwin/home/Gumm/devel/python/project/gummball/blah.py,
line 9, in module
   sound_data = pygame.sndarray.array(sound)
 File C:\Python26\Lib\site-packages\pygame\sndarray.py,
line 95, in array
   return numpysnd.array (sound)
 File
C:\Python26\Lib\site-packages\pygame\_numpysndarray.py,
line 77, in array
   return _array_samples(sound, True)
 File
C:\Python26\Lib\site-packages\pygame\_numpysndarray.py,
line 64, in _array_samples
   array = numpy.fromstring (data, typecode)
ValueError: string size must be a multiple of element size

Any assistance appreciated.

Gumm

Re: [pygame] Spam on Tutorials page

[B W]

Nuke and ban some accounts. Like Steve, who put hairstylesx back after I
corrected freesound.org links. (I sure am glad I found that link, though. I
now have a new hairstyle *and* some cool new sounds! =)) Seriously, nuke the
bastard.

I don't recall how easy it was to sign up. Maybe there's an opportunity for
something less bot-friendly.

Nobody wants to be saddled with policing content, da Gumm included.
Especially if nothing is being done to control the abuses. I don't claim
that nothing is being done, because I honestly don't know. I'm just content
to fix em as I find em. But it seems a pointless exercise when my fixes are
broken the next day. Somehow abuses need to be policed; and culprits should
be tooorn into itsy bitsy PIECES and buuuried aliiive. (And a free Freeze
Dried Frog Paste to the first person who gets that last reference. :))

Gumm

On Thu, Aug 5, 2010 at 7:29 AM, Ciro Duran ciro.du...@gmail.com wrote:

 Hi,

 I've taken the task since some days ago to clean link spam from the
 tutorials page in pygame.org. Sadly, this is a losing battle, it's only a
 few hours before some guys adds the same links as always. And some of them
 don't even bother to edit the site, but rather revert to their spammy
 version. Is there any way to semi-protect this page and have someone curate
 this page?

 Ciro.

Re: [pygame] pygame.sndarray.array = ValueError: string size must be a multiple of element size

[B W]

Thanks for responding, Lenard, though it doesn't seem this applies to my
problem. The sound file is loaded successfully. I can play() the loaded
sound just fine. It is the conversion of the mixer.Sound object to a
sndarray.array object that's blowing up.

Gumm

On Thu, Aug 5, 2010 at 12:26 PM, Lenard Lindstrom le...@telus.net wrote:

 Okay, this is technically not a bug. If the string is not a valid file path
 then it is assumed to be sound data. This has to be fixed somehow.

 Lenard


 On 05/08/10 11:36 AM, Lenard Lindstrom wrote:

  Hi Gumm,

 You have found a bug. pygame.mixer.Sound does handle ogg/vorbis files. But
 it doesn't raise an exception when it can't find the file. Also, on Windows
 you may find that calling pygame.init() before pygame.mixer.init() will
 prevent playback, no sound. Either remove pygame.init, place it after
 pygame.mixer.init or set the SDL_AUDIODRIVER environment variable to
 'waveout'.

 Lenard Lindstrom

 On 03/08/10 11:03 AM, B W wrote:

 Howdy, folks.

 Seeking enlightenment. Anyone seen this before, and how do I rassle it
 into submission? Docs and web have been unhelpful so far. I'm using
 pre-built software packages; been using these for months without any issues.

 This problem occurs with all ogg and wav files. I see that Numpy is
 raising the exception, but I can't tell if it's a problem internal to Numpy
 or a result of how numpysnd.array is using Numpy.

 Summary:
 1. load OGG-Vorbis sound file with pygame.mixer.Sound
 2. convert sound using pygame.sndarray.array
 3. scratch head

 CODE
 import os, sys, numpy, pygame
 from pygame.locals import *
 pygame.init()
 pygame.mixer.init(44100, 16, 2, 1)
 sound = pygame.mixer.Sound('../sounds/laser_26667.ogg')
 for n,v in [('OS',os.name 
 http://os.name),('Python',sys.version),('Pygame',pygame.version.vernum),

('Numpy',numpy.version.version),('Array
 type',pygame.sndarray.get_arraytype())]:
print '%s: %s' % (n,v)
 sound_data = pygame.sndarray.array(sound)
 /CODE

 C:/Python26/pythonw.exe -u
  C:/cygwin/home/Gumm/devel/python/project/gummball/blah.py
 OS: nt
 Python: 2.6.5 (r265:79063, Mar 20 2010, 14:22:52) [MSC v.1500 32 bit
 (Intel)]
 Pygame: (1, 9, 1)
 Numpy: 1.4.1
 Array type: numpy
 Traceback (most recent call last):
  File C:/cygwin/home/Gumm/devel/python/project/gummball/blah.py, line
 9, in module
sound_data = pygame.sndarray.array(sound)
  File C:\Python26\Lib\site-packages\pygame\sndarray.py, line 95, in
 array
return numpysnd.array (sound)
  File C:\Python26\Lib\site-packages\pygame\_numpysndarray.py, line 77,
 in array
return _array_samples(sound, True)
  File C:\Python26\Lib\site-packages\pygame\_numpysndarray.py, line 64,
 in _array_samples
array = numpy.fromstring (data, typecode)
 ValueError: string size must be a multiple of element size

 Any assistance appreciated.

 Gumm

[pygame] pygame.sndarray.array = ValueError: string size must be a multiple of element size

[B W]

Howdy, folks.

Seeking enlightenment. Anyone seen this before, and how do I rassle it into
submission? Docs and web have been unhelpful so far. I'm using pre-built
software packages; been using these for months without any issues.

This problem occurs with all ogg and wav files. I see that Numpy is raising
the exception, but I can't tell if it's a problem internal to Numpy or a
result of how numpysnd.array is using Numpy.

Summary:
1. load OGG-Vorbis sound file with pygame.mixer.Sound
2. convert sound using pygame.sndarray.array
3. scratch head

CODE
import os, sys, numpy, pygame
from pygame.locals import *
pygame.init()
pygame.mixer.init(44100, 16, 2, 1)
sound = pygame.mixer.Sound('../sounds/laser_26667.ogg')
for n,v in [('OS',os.name
),('Python',sys.version),('Pygame',pygame.version.vernum),
('Numpy',numpy.version.version),('Array
type',pygame.sndarray.get_arraytype())]:
print '%s: %s' % (n,v)
sound_data = pygame.sndarray.array(sound)
/CODE

C:/Python26/pythonw.exe -u
C:/cygwin/home/Gumm/devel/python/project/gummball/blah.py
OS: nt
Python: 2.6.5 (r265:79063, Mar 20 2010, 14:22:52) [MSC v.1500 32 bit
(Intel)]
Pygame: (1, 9, 1)
Numpy: 1.4.1
Array type: numpy
Traceback (most recent call last):
  File C:/cygwin/home/Gumm/devel/python/project/gummball/blah.py, line 9,
in module
sound_data = pygame.sndarray.array(sound)
  File C:\Python26\Lib\site-packages\pygame\sndarray.py, line 95, in array
return numpysnd.array (sound)
  File C:\Python26\Lib\site-packages\pygame\_numpysndarray.py, line 77, in
array
return _array_samples(sound, True)
  File C:\Python26\Lib\site-packages\pygame\_numpysndarray.py, line 64, in
_array_samples
array = numpy.fromstring (data, typecode)
ValueError: string size must be a multiple of element size

Any assistance appreciated.

Gumm

Re: [pygame] 127.5

[B W]

Use a data set for your computational values and convert them to display
values as needed. I do this for sprites whenever I want micro speed
adjustments, which in essence lets them move fractions of pixels per frame.

Gumm

Re: [pygame] are individual midi instruments sounds copyrighted

[B W]

Relocating the furniture voids the warranty. If you need to move the
furniture under warranty to a new location, you'll either need to contract
an authorized, insured mover, or get the furniture re-certified by an
authorized representative of the manufacturer at the new location. These
expensive services are not covered under the maintenance agreement.

Gumm

On Tue, Jul 20, 2010 at 6:38 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:

 Thiago Chaves wrote:

 Sorry. Evidently you'll be able to buy professional broadcaster
 versions of the furniture, which is pretty much the same thing, but
 incredibly more expensive.


 Also, if you want other members of your family to be able
 to use the furniture, they will have to buy their own
 furniture, or you will have to get a special household
 furniture licence.

 And don't even think about letting visitors sit on your
 sofa...

 --
 Greg

Re: [pygame] are individual midi instruments sounds copyrighted

[B W]

Call the company and ask if your intended use case is allowed, or if there's
any loops you can jump through to get authorization.

Gumm

Re: [pygame] Re: [Pygame] Fading Between Two Songs

[B W]

I'm not aware of a convenient mechanism. I've just created logic to detect
when the song or sound ended (is_playing()) and started a new one. Setting
an event seems the most convenient way to manage it, though.

If anyone knows a better way I'd love to learn of it too. :)

bw

On Thu, Jul 8, 2010 at 4:42 AM, Fawkes fawkesga...@gmail.com wrote:

 Thank you for your help so far.

 I'd like to go with option 1. I got it to work, but there's a small
 problem I was hoping to get some help with: Is there a way to get
 queued music set up via the pygame.mixer.music.queue() to loop? It
 only plays once and stops.

 -Fawkes

Re: [pygame] [Pygame] Fading Between Two Songs

[B W]

Greetings, Urtling. There's a few ways, I think, and maybe more.

1. When you fade the song that's playing, also queue the next song at that
time: pygame.mixer.music.queue(). No fuss. The next song will start playing
immediately.

2. Tell Pygame to send an event when a song stops playing:
pygame.mixer.music.set_event(). As I recall, you have to use a valid Pygame
event type, such as something between USEREVENT and NUMEVENTS. Because this
passes control to your program, you can employ a programmed delay before the
next song.

3. Your game loop can check if the song is playing and start it up if it's
not: pygame.mixer.music.get_busy(). Likewise, this supports the option of a
programmed delay.

Gumm

On Tue, Jul 6, 2010 at 5:14 PM, Fawkes fawkesga...@gmail.com wrote:

 Hello,

 I need some help with using Pygame's music module. Specifically, is
 there a way to fade between two songs?

 Suppose I have a song playing called via:

 pygame.mixer.music.load('song1.ogg')
 pygame.mixer.music.play(-1)

 I tried to use Pygame's Music Module's fadeout, but that didn't work:

 [Song is already playing]

 pygame.mixer.music.fadeout(1000)
 pygame.mixer.music.load('song2.ogg')
 pygame.mixer.music.play(-1)

 The music fadeout function seems to block out all input during that
 time (Despite comments to the contrary in the documentation). I'd like
 to transition smoothly between those songs without blocking the user's
 input. Is there a good way to do this?

 Thanks in advance.
 -Fawkes

Re: [pygame] Questions about IDE and inflate()

[B W]

Hi, Hokan.

Try DrPython for editing and running. I've tried many and I keep coming back
to this one. It does not run via cmd. Hope it works for you. You'll also
need wxPython.

I suspect pygame.Rect.inflate() won't do what you want. Why do you want the
rect to be smaller than the cloud image; what are you trying to accomplish?

Gumm

On Tue, Jun 15, 2010 at 1:33 PM, Hokan LUNDBERG ho...@ikso.net wrote:

 Hi again!

 http://www.cs.iupui.edu/~aharris/pygame/ch07/http://www.cs.iupui.edu/%7Eaharris/pygame/ch07/.
 I would like the rects in the cloud-sprites to be smaller than the clouds
 themself.)

 class Cloud(pygame.sprite.Sprite):
   def __init__(self):
   pygame.sprite.Sprite.__init__(self)
   self.image = pygame.image.load(Cloud.gif)
   self.image = self.image.convert()
   self.rect = self.image.get_rect()
   self.rect = self.rect.inflate(-25, -25) # i did this
   self.reset()

Re: [pygame] Questions about IDE and inflate()

[B W]

On Tue, Jun 15, 2010 at 9:53 PM, Hokan LUNDBERG ho...@ikso.net wrote:

 Gumm:
  Why do you want the rect to be smaller than the cloud image; what are you
 trying to accomplish?

 I want to avoid that the plane is hit by a cloud just by being close to it.
 The rect of the cloud-sprite is bigger than the cloud image (since it is not
 rectangular), so when one play the plane game (
 http://www.cs.iupui.edu/~aharris/pygame/ch07/http://www.cs.iupui.edu/%7Eaharris/pygame/ch07/)
 one sometimes gets the feeling no, the plane did not touch the cloud! and
 still looses a plane. The author of the book recommends to use
 the inflate-method, and has it in one version of the game (
 http://www.cs.iupui.edu/~aharris/pygame/ch07/mpScore.pyhttp://www.cs.iupui.edu/%7Eaharris/pygame/ch07/mpScore.py),
 that helps for the right side of the clouds but not for the left side.. How
 to fix that?


Since the Sprite.Group uses the sprite's rect to draw, you should not modify
its size. what you are seeing is a side effect of that. There is a more
elegant way. Let me draw your attention to the sprite_collide function of
Sprite class; specifically to the function's collided argument, which is
the name of a collision-testing function to call.

The Sprite class also provides some callback functions that are ready for
you to use with sprite_collide.

If you want to use the cloud's rect, you should check out the
collide_rect_ratio callback function. This is essentially what you were
hoping to do by resizing the cloud's rect--but without side effects.
However, it has the drawback of strange collisions at the corners of
clouds.

Since clouds are not rectangular, but sort of round, I prefer
collide_circle. Using this callback function will avoid strange collisions
at a rect's corners.

An other question: Is there something like JOptionPane.showInputDialog() in
 some GUI library for Python? I.e. being able to show a dialox box for input
 by just one line of code. (My students like the dialog boxes of JOptionPane
 in Java very much and have asked me how to do the same thing in Python.)

 Thanks,
 Hokan


I haven't personally tried Albow, but I see it frequently recommended on
this mailing list. See pygame.org.

I purposely tried to give only light hints about collisions. If you're like
me, you enjoy the challenge of figuring it out. If you want more help,
though, please don't hesitate to ask. :)

Cheers!

Gumm

Re: [pygame] Writing a simple GUI

[B W]

In my mind, the player has to select which unit to perform an action on.
That target would be stored as state info in your game engine. Then your
attack() callback simply chooses the attack action, and the game engine has
the info it needs to execute the turn: player-attacking-target.

Gumm

Re: [pygame] google's native client

[B W]

It reads that way, yes. The author mentions DOM. What is that?

Gumm

On Wed, May 26, 2010 at 8:28 AM, machinimist machinimist 
machinim...@gmail.com wrote:

 http://mail.python.org/pipermail/python-dev/2009-June/090038.html

 maybe i am misunderstanding something but didn't he get full python
 working?

Re: [pygame] google's native client

[B W]

Knee jerk reaction. I simply expected yet another Web 2.0 product that had
to be plugged by Ad Block, NoScript, et al--yawn. But I can see now that
it's something much more. It looks really good on paper, as they say. If
Google can successfully pull off the design I'll be extremely impressed.
Thanks for the links!

And sorry, I did not mean to derail the thread. Please continue. :)

Gumm

On Thu, May 27, 2010 at 2:35 AM, machinimist machinimist 
machinim...@gmail.com wrote:



 On Thu, May 27, 2010 at 4:52 AM, B W stabbingfin...@gmail.com wrote:

 Aaaa run away! Security. :)


 why? :) have you looked into how native client works? it's not like
 activex.




 Gumm

Re: [pygame] google's native client

[B W]

Aaaa run away! Security. :)

Gumm

Re: [pygame] question about Rect objects

[B W]

On Mon, May 24, 2010 at 1:14 PM, Alex Hall mehg...@gmail.com wrote:


 Thanks. I am a student, but this is not an assignment, it is a summer
 project I basically decided to do a couple weeks ago.


There I go, jumping to conclusions. :) On the upside, I am now liberated to
post the grid done in sprites. If you're interested, look here...

http://code.google.com/p/trollsouttaluckland/downloads/detail?name=grid1.pycan=2q=

Left-click and right-click the squares to trigger swapping the image.

Gumm

Re: [pygame] question about Rect objects

[B W]

Hi, Alex.

On Tue, May 18, 2010 at 6:12 PM, Alex Hall mehg...@gmail.com wrote:

 In the meantime,
 do you have a place where I can find an example of drawing a grid of
 Rects?


I searched for a little bit and could not find any tutorials, or projects or
demos that highlighted a grid as a feature. While there are several small
games on pygame.org that do tic-tac-toe like grids, I did not find one that
appeared simple enough for a first study.

I whipped up a *very* basic demo that does the does the absolute minimum you
ask. I didn't want to give too much away to an aspiring student. :) The demo
lacks elegance and is not a good Python or Pygame example, but it may
provide the small hello world boost you need. Hope so. Find it here...
http://code.google.com/p/trollsouttaluckland/downloads/detail?name=grid0.pycan=2q=

Also, I would still like to put a rect into a boardSquare
 object (an object I have defined) so I can call something like
 board[i][j].Rect.changeColor(red) where changeColor is a method I
 implement. Is this not possible / a huge waste of resources?


What you describe is a common practice, and is generally encouraged. And
yes, if you have many, many squares, each with a copy of the same image, it
would likely be considered wasteful. As Jason suggests, you might economize
images by making a set of unique ones and sharing them amongst the squares.
On the other hand, a small board game's memory requirements is
insignificant. Still, I am sure that a demonstration of smart resource
management would be good for your grade.

To pursue this, you will want to define a class that implements the
changeColor() method; either your own class or by subclassing the Sprite
class. Next you will want to store your objects (or sprites) in a list or
dict for easy lookup. Using a dict will allow the index style board[i,j]
versus board[i][j], but you may find good reasons to stick with a list.
Lastly, if you go with Sprites I would recommend also creating a sprite
group (as Jason suggests) if only because its update() and draw() methods
can make your tasks much easier.

I still suggest you read a sprite tutorial on pygame.org. I predict that
demonstrating this acquired knowledge would be very good for your grade. :)

Gumm

Re: [pygame] Working with maps

[B W]

Food for thought. I've had very good results with FastPixelPerfect collision
detection. With this, however, your challenge will change to: how do I break
up the territories neatly, make them into images (sprites), and then puzzle
their bounding rects together just as neatly.

http://www.pygame.org/wiki/FastPixelPerfect?parent=CookBook

Gumm

Re: [pygame] Has anyone made an internet game?

[B W]

I challenge... oh noes! The service is down! =)

Gumm

On Tue, May 18, 2010 at 10:35 PM, Ian Mallett geometr...@gmail.com wrote:

 Hello,

 I humbly present my networking library, 
 Mastermindhttp://www.pygame.org/project-Mastermind+Networking+Lib-859-.html.
 It works out-of-the-box, and provides a simple programmer interface (as well
 as examples to help you get started).  So far, I've published one 
 gamehttp://www.pygame.org/project-Spacewar+Multi-1025-.htmlthat uses it.  
 Seems to handle crowds pretty nicely.  Anyway, you may find
 it suits your needs.  Enjoy!

 Ian

Re: [pygame] question about Rect objects

[B W]

Hi, Alex. Welcome to a fun world.

1. Resizing. See the docs for Transform. You will need to get the new
re-sized rect from the image afterward.

2. Keyboard. The docs for Event describe how to handle events. Pygame makes
it extremely easy. The docs don't seem to adequately explain how to check
modifiers (shift, alt, etc.); there are some great comments at the top of
the page that dig deeper, and list the modifiers. To test modifiers you'll
do something like e.mod  KMOD_SHIFT. You can catch multiple modifiers by
using logical-or on the KMOD_*.

3. Clicking on squares. By default Pygame queues mouse-click events, which
include attributes for button and coordinates. See the docs for Event. If
you're using Sprites you can test for collisions quite easily.

4. Once you climb the very mild learning curve of sprites, you will find
that using them is a lot easier than doing without. Handling sprites in
groups is also very convenient. Sprites must have an image attribute; and
must have a rect attribute in order to be drawn by its containing Group, for
a number of collision-detection routines, and for other potential reasons.

5. Rects. Rects are a geometric abstraction not to be confused with an
image. A rect defines merely the geometry of an image or other thing.
Sprites and rects work hand in hand, and are used even for non-drawing
purposes, because Rect is a very slick and wieldy Pygame feature. Examples
of frequent use: defining the screen dimensions; positioning an image or
sprite on the screen; rendering a small part of a large image; detecting
collisions; virtual spaces in game models. Rects: learn em, love em.

Note: Changing a sprite's image. In quick summary and just to be clear:
my_sprite.image = new_image; my_sprite.rect = self.rect.get_rect();
my_sprite.rect.center = my_pos.

Please read the very nice tutorials on pygame.org. They will lead you
through all this in an orderly fashion, save you the struggle of learning
the basics from an API reference, and likely answer any questions that you
may still have. While you are doing this, and any time afterward, please
feel free to ask questions of the mailing list. :)

Gumm

On Tue, May 18, 2010 at 6:13 AM, Alex Hall mehg...@gmail.com wrote:

 Interesting idea. Is there a way of resizing an image? For example, if
 the user has a 10x10 grid, each square will be bigger than on a 15x15
 grid. Also, I will need to catch keyboard keys (mostly ctrl-m, space,
 enter, and space/enter with modifiers) as well as mouse clicks
 (differentiating between left and right) for each square. So maybe you
 left click a square, or move to it and press ctrl-m. Can Pygame detect
 where on the grid that is with some sort of onImageClick type method,
 or do I have to track coordinates?
 Looks like I have to do a lot more reading on sprites. I heard the
 concept and coding is more difficult than basic Pygame. Oh, you
 mentioned using rects even with sprites; I am not sure why, then, I
 would not just use colored rects in the first place, maybe define a
 blue, red, and white rect and then just overwrite the current rect
 with the appropriate color by changing the new rect's left/top
 arguments? Again, I am quite new to this; I have not even done it in
 another language as I have done with other things, so I am coming at
 it with no reference. Thanks!

Re: [pygame] Move sprite and stop it.

[B W]

I think I understand your move_to problem now. I had to invent that wheel
for myself a while ago and the math was not trivial for me. I had to get my
son to teach me new tricks. :) Even though they may not be the most elegant
math solutions, they are reliable.

I uploaded this very basic demo:
http://trollsouttaluckland.googlecode.com/files/sprite_test.py.

Line 104 is the call to sprite's move_to.

Line 106 is the code to swap the locations.

The real work of move_to is done in the class and supporting functions.

Cheers.

Gumm

Re: [pygame] Running Python 2.5 alongside 2.6

[B W]

Very recent discussion on the Python 2.5 vs 2.6 topic:
http://www.mail-archive.com/pygame-users@seul.org/msg13877.html

If you want to run two Python versions, you can do so by managing some
environment variables. Here's what I do in Cygwin:

PATH=append search path for Python executables and scripts
PYTHON=directory where python or python.exe resides
PYTHONPATH=search path for Python packages and modules

Here is an example from my Cygwin environment, and it is easy to script the
switch:

PATH=$PATH:/cygdrive/c/Python26:/cygdrive/c/Python26/Scripts
PYTHON=/cygdrive/c/python26
PYTHONPATH=/cygdrive/c/Python26/DLLs:/cygdrive/c/Python26/Lib:/cygdrive/c/Python26/Lib/site-packages:lib
export PATH PYTHON PYTHONPATH

Good luck in Winders. It's a bit cumbersome to manage a switch, but it can
be done.

Gumm

Re: [pygame] pygame.image.save(...)

[B W]

On Wed, Apr 28, 2010 at 1:31 AM, René Dudfield ren...@gmail.com wrote:

 On Wed, Apr 28, 2010 at 5:26 AM, Ian Mallett geometr...@gmail.com wrote:



  several hundred files every time it tries to save.  Oh well, user error.



 hehe.

 A place I worked at in the 90's would call an 'user error' an UBD error ;)

 Luckily no one ever asked them to explain what this UBD error was.
 Perhaps they wouldn't like to find out it stood for User Brain Dead.

 Definitely not a UBD error in this case though.


Lol. I never heard that one. We'd say Problem somewhere between chair and
keyboard.

Glad you figured it out, Ian.

Gumm

Re: [pygame] Running Python 2.5 alongside 2.6

[B W]

Actually, the outcome I got from that previous thread is that for a few
significant reasons 2.5.4 is still the best choice for Windows:

1. MSVC++ runtime availability on target systems, and library distribution
constraints.
2. Packaging readiness (although I've been able to use pygame.org's py2exe
recipe fine with Python 2.6).
3. The largest code base.

And maybe other reasons you'll have to discover and weigh for yourself. So
if leaving that note up saves a lot of new folk from pain and agony, I'm all
for it. When I was a day-old nub I appreciated seeing the tip. I rather
think it needs a small explanation so people who are compelled to look
deeper can understand the why.

My two bits.

Gumm

Re: [pygame] informal poll on Windows python version

[B W]

Welcome to me too hell... =)

WinXP Pro SP 2
WinXP Home SP 2

Python 2.6 (and side-by 2.5.4, in case someone forces me to use it some day)
Pygame 1.9.1

Gumm

Re: [pygame] Move sprite and stop it.

[B W]

There are no stupid questions. Unless you work at my company where they seem
to abound. :)

You need to control all the details of sprite position in a loop with
increments and conditions. There's no move_to in Pygame, though many of us
have coded our own move_to functions we might be willing to share. There are
plenty of basic examples on pygame.org (http://www.pygame.org/wiki/tutorials)
that illustrate this much better than we can express in emails.

Not sure what you mean by swapping two sprites. Do you mean to replace a
sprite's image?

Gumm

Re: [pygame] Source rect for sprites in a RenderUpdate group

[B W]

Without knowing details, one can only conjecture. You might use
Group.update(*args) to get info to each sprite. The sprite group in turn
calls Sprite.update(*args). You can pass anything, such as a source rect to
use in computing relative offsets, a list or dict of rects, or a callback
function.

Gumm

Re: [pygame] Source rect for sprites in a RenderUpdate group

[B W]

I failed to mention that if you truly want to leverage MVC you might simply
send data to the View in a message attribute.

Gumm

Re: [pygame] Source rect for sprites in a RenderUpdate group

[B W]

Sounds to me like you'd want to create a subsurface of your larger image
each game tick before calling group.draw() or sprite.draw(). Reference
pygame.surface.Subsurface().

self.image = pygame.surface.Subsurface(self.full_image, self.source_rect)

Gumm

Re: [pygame] Source rect for sprites in a RenderUpdate group

[B W]

I had difficulty following the explanation. Sorry If I misunderstand what
you're trying to accomplish, Vincent.

On the drive home I was thinking about this. The following little demo might
suit your purpose?

http://trollsouttaluckland.googlecode.com/files/subsurf_as_viewport.py

It assumes you want to draw only a small portion of a large panning image in
a static area of the screen. Ignore the math; it's only there to produce
some interesting movement. The relevant parts are the rects, subsurface, and
blit.

Gumm

Re: [pygame] blit speedup

[B W]

On Sun, Mar 28, 2010 at 3:29 PM, Wakefield, Robert
rjw03...@engr.uconn.eduwrote:

 Do you have any recommendation for the best way to get an OpenGL engine
 running, especially going Pygame surface to OpenGL texture?  I'd like to
 preserve platform-independent .py files or executables if possible.

 glLib (and upcoming glLib Reloaded)
Gloss
PyGL2D
Rabbyt

glLib and PyGL2D are written by nice people active on this mailing list.
Only one of those still appears to be maintained (*nudge pymike* :)).

Those two and Gloss are 100% Python, if memory serves me. Be mindful that
Gloss is Gnu GPL.

Gumm

[pygame] Python 2.5.4 or 2.6

[B W]

Howdy.

Pygame download page claims python2.5.4 is the best python on windows at
the moment. This has been the status since I began with Python and Pygame
about 1.5 years ago. While I appreciate suggestions that save me time and
agony, it is my nature to always ask why. If the doc says take this pill, it
will save your life--I gotta ask! Call it a compulsion.

Why should I prefer Python 2.5.4 on Windows?

Will Python 2.6 ever be crowned king? What factors are holding it back?

Will Python 3 ever be crowned king? What factors are holding it back?

I'm mostly interested in the opinions of the people who assess such things
at a technology-readiness level, such as the Pygame maintainers and people
who follow bug management and other objective indicators. Not particularly
interested Gumm's personal experience is it works okay responses. :)

Thanks in advance.

Gumm

Re: [pygame] super surface... a surface made up of many smaller surfaces

[B W]

On Sat, Mar 6, 2010 at 11:44 AM, Kris Schnee ksch...@xepher.net wrote:

 On 3/5/2010 10:40 AM, René Dudfield wrote:

 However, sometimes we would like to operate on a whole bunch of
 smaller surfaces stuck together.


 I've done several projects using a full-screen scrolling tilemap. That is,
 sprites walking around on a blanket of 2D tiles drawn from an array as big
 as 1000x1000 referencing a set of 50x50 tiles. That wasn't practical to do
 using a Pygame Surface, due to the size, so each frame the system figured
 out the range of all visible tiles (based on the POV character's location)
 and drew those. It wasn't very efficient, but it did work, and it's an
 example of a surface built from many actual Surface objects. (Will link to
 code if you want.)

 I did something very similar with Gummworld. The supersurface was not a
single Pygame surface, rather a virtual surface made of a 2D array of
sprites each with its own image. The Pygame drawing surface was the visible
display; only I found that Group.draw()-ing all the terrain sprites and
allowing Pygame to automatically crop them was in larger cases more
efficient than cropping the drawing scope in Python. Still, it did indeed
waste memory having all those sprites, each with their own image, outside
the display area. The level design was rectangular, and if the map is
irregular then large portions of the supersurface could possibly have many
unused sprites; which led to a crude sparse map implementation, where an
array cell with a None value would be ignored. It's a simple paradigm in
which the special cases tend to center around conserving memory and CPU.

That initial attempt got me thinking about a room paradigm. A level is
analogous to a building or a floor with rooms connected by exits. Rooms
don't necessarily have walls, and exits are not necessarily visible. They
are just internal geographic and navigational elements, respectively. An
exit links two rooms. Exits can be visible objects such as a door or portal
or an invisible line on the ground. Using an exit changes the interactive
context from room A to room B. If you choose so, your room could scroll.
With some drawing savvy neighboring rooms could scroll seamlessly. The
player might not even notice that an exit was used and there was a room
change.

Though the room paradigm seems elegant to me and potentially
memory-efficient, it presents its own significant challenges: resource
management (real-time loading and garbage cleanup); game hiccups from
resource management; spacial relationship of rooms and exit hot spots;
interacting with objects through an exit; room linkage errors.

So on the one hand we have a level structure that is easy on the programmer
and harder on the machine; on the other a structure that's easy on the
machine and harder on the programmer. I know others have solved such issues,
and there are game engines that provide a display/resource/world/etc.
management framework so you can focus on game intelligence, content, and
world design. But they are systems and languages unto themselves, and if I
don't like an aspect I can't always change it. That is why I was happy to
find Pygame.

But not for the first time I am thinking it would be awesome to have some
higher level toolkits, somewhere comfortably between Pygame and a full-blown
game engine. It seems many of us have put a lot of time and effort into such
toolkits, with varying degrees of success. I am wondering if the
supersurface would fit better as an official-like Pygame add-on. It might
even trigger a series of integratable toolkits that offer standard ways of
solving higher level problems like I've seen suggested: scenes, tiling,
transitions, map scrolling, path-finding. =) *cough* Me and my grand
schemes...

But if your thoughts go in another direction, René, I would love to hear
more.

Gumm

Re: [pygame] Optimising a tile map renderer

[B W]

Here are a few OpenGL libraries I've got my eye on. They all look usable,
though some may be dunner (more mature) than others. OpenGL rendering pretty
much makes drawing sprites the least expensive operation in your program,
and these libraries make OpenGL 2D programming a breeze. They all support
Pygame surfaces.

PyGL2d - http://www.pygame.org/project/972 ##recent activity after long
last?
glLib - http://geometrian.com/Programs.php  ##and a new superbeta, I see :)
Gloss - http://www.pygame.org/project-Gloss-1155-.html
Rabbyt - http://matthewmarshall.org/projects/rabbyt/

Gumm

Re: [pygame] Unprintable characters

[B W]

Clean slate.

UniCode does not seem to be completely functional in SDL. As this thread
from 2006 suggests (
http://old.nabble.com/Arrow-Keys,-and-keysym.unicode,-SDL-1.2.10-td5030718.html)
you may need to do some platform-specific special handling of certain
keyboard events. The SDL version used in Pygame may have changed in the last
four years, but the behavior does not indicate so. Of course, there is still
the possibility that I am a floundering UniCode noob. I'm sure one of the
Pygame devs could clarify.

Check this out.

##begin python##
import unicodedata
import pygame
from pygame.locals import KEYDOWN
pygame.init()
pygame.display.set_mode((10,10))
while 1:
for e in pygame.event.get():
if e.type == KEYDOWN:
print 'key', e.key
print 'unicode len', len(e.unicode)
print 'unicode name', unicodedata.name(e.unicode, 'no name')
print '--break--'
##end python##

The following output is on a Compaq 6910p Windows XP laptop, Python 2.5.4,
Pygame 1.9. I can't explain why Python's name lookup is failing on a
carriage return, or why the two Intel platforms I have access to (Windows
and Ubuntu) return an event.key that is greater than an 8-bit value for
cursor keys.

##begin program output##
key 32
unicode len 1
unicode name SPACE
--break--
key 13
unicode len 1
unicode name no name
--break--
key 273
unicode len 0
unicode name
Traceback (most recent call last):
  File C:/tmp/unicode.py, line 11, in module
print 'unicode name', unicodedata.name(e.unicode, 'no name')
TypeError: need a single Unicode character as parameter
##end program output##

A Ubuntu 8 Compaq desktop, Python 2.5.2, Pygame 1.7.1, produces the same
results.

Gumm

Re: [pygame] Unprintable characters

[B W]

Assuming these are UTF8 characters, the encoding is backwards compatible
with ASCII. Therefore, you should be able to use the ASCII chart to classify
non-printable character codes (0-31 and 127).

Gumm

On Tue, Mar 2, 2010 at 1:43 AM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:

 René Dudfield wrote:

 Hi,

 I guess you could compare to various K_ variables?


 That's probably the most reliable way.

 An alternative would be to write a small test program to
 find out the unicode chars produced for various keys by
 experiment. I'm not sure they would be the same on all
 platforms, though.

 --
 Greg

Re: [pygame] Unprintable characters

[B W]

On Tue, Mar 2, 2010 at 2:54 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:

 B W wrote:

 Assuming these are UTF8 characters, the encoding is backwards compatible
 with ASCII. Therefore, you should be able to use the ASCII chart to classify
 non-printable character codes (0-31 and 127).


 There's no standard ASCII code for arrow keys, however, and
 I've seen at least some systems translate them into non-ASCII
 unicode characters.

 True. There is no ASCII code for a cursor key. Those keys send multi-byte
raw ASCII sequences, unlike other keys that send a single byte. I notice
Pygame (or SDL?) seems to cook them into a semblance of ASCII. However, for
the Enter key on my Winders event.key reports 13 as expected, while UP arrow
reports 273 (blank string?) which is higher than 255.

I haven't had a need to delve into event.unicode (type 'unicode'). Does it
represent the raw keys? In my case, for UP arrow they are
(K_ESCAPE,K_O,K_A).

Gumm

[pygame] pygame.mixer.init(frequency=?)

[B W]

Howdy.

I can't seem to find any clear info on my problem. I'm hoping someone here
has dealt with this.

I have two songs. One has a bitrate of 48000, the other 44100. If I allow
Pygame (SDL mixer) to use the default frequency, the playback speed of the
songs is distorted. If I explicitly set the mixer frequency to match a song
so it sounds good, the other sounds distorted.

Reinitializing the mixer is not a good option. There are other sounds that
need to play, and would be interrupted by a reinit. Resampling the songs is
not ideal, either, as Vorbis is a lossy format and sound quality is
obviously lost in re-sampling.

Does anyone have a recommendation? Are all sounds in an implementation
expected to have the same bitrate?

Thanks in advance for any insight. :)

Gumm

Re: [pygame] pygame.mixer.init(frequency=?)

[B W]

On Thu, Feb 25, 2010 at 1:43 PM, Marius Gedminas mar...@gedmin.as wrote:

 On Thu, Feb 25, 2010 at 10:37:36AM -0800, James Paige wrote:
  On Thu, Feb 25, 2010 at 10:31:12AM -0800, B W wrote:
  I have two songs. One has a bitrate of 48000, the other 44100. If I
 allow
  Pygame (SDL mixer) to use the default frequency, the playback speed
 of the
  songs is distorted. If I explicitly set the mixer frequency to match
 a
  song so it sounds good, the other sounds distorted.
  
  Reinitializing the mixer is not a good option. There are other
 sounds that
  need to play, and would be interrupted by a reinit. Resampling the
 songs
  is not ideal, either, as Vorbis is a lossy format and sound quality
 is
  obviously lost in re-sampling.

 Is that a theoretical observation, or can you actually hear the
 difference?

 Yes, I can hear the difference, especially in high treble fidelity.

Well, it is only one song. I will just exclude it from the pick. Thanks for
the replies.

Gumm

Re: [pygame] DMs, what are you doing?!

[B W]

Thanks for the replies, all.

I confess I was fishing. :) As I am wrapping up Trolls Outta Luckland I
found myself looking for the next challenge. And reflecting. For such a
narrow game, many aspects of TOL gave me quite a challenge. I had quite a
lot of passive help in the form of docs, papers, examples and media
resources. I also had some significant help in the form of tips,
suggestions, and math mentoring from individuals. Though I've been
programming for many years, it was my first fully developed game. It was a
graduation, and it gave me an appreciation of the time and effort required
to create a complete work.

Even so, and even though I am satisfied with the results, I recognize there
are parts of TOL that I could continue to polish, and a core that can grow
beyond what it is. And it occurs to me if it was not a one-troll project it
might have become something more. By contrast take a look at Ardentryst
(search pygame.org), a project that had many invested contributors. And it
shows. I don't think there is one element of Ardentryst that is not
sugar-sprinkled. I'm sure it got that way because over time various project
members spurred an effort to change each aspect from plain to dazzling. I
find that notion, and the resulting Ardentryst, inspiring.

What next? I do not want my next project to be another one-troll project.
Maybe a few trolls. Or a troll and a few whatever you are. I don't know yet
if I would like to lead a team, or be a follower, or if a collaboration of
peers would function acceptably. I just don't know! Like I said, fishing. :)

I do know I've wanted to make a RPG since playing those crude but lovable
things on my first computer. I want it to be personal, absorbing,
intelligent, tactical, and candy good. It's a high mark, and I know I
wouldn't be able to hit it alone. I don't have enough hands or brains. But
maybe enough computers if I raid my shelves.

If anyone is like-minded, I'd like to continue a discussion at
http://groups.google.com/group/gumms-rpg-cloud. If a small group has enough
interest and patience to seed the cloud and stick around to see what falls
out, we just might get something going.

Gumm

Re: [pygame] DMs, what are you doing?!

[B W]

I been checking out your Shining Sea demo, Kris. I like it. We will have to
see in what direction the project goes. I'll certainly keep your modules in
mind. Thanks. :)

Gumm

On Fri, Feb 19, 2010 at 9:22 PM, Kris Schnee ksch...@xepher.net wrote:

 On 2/19/2010 6:33 PM, Henrique Nakashima wrote:

 The library I've been working on might be useful, if the project is a 2d
 tiled RPG:

 http://www.pygame.org/project-LibRPG-1293-2321.html

 http://www.pygame.org/project-LibRPG-1293-2321.htmlI haven't worked on
 it for about two months, but the map part is working nicely, what is
 halfway done are menus.


 You could use my simple UI library Driftwood, seen here:
 http://kschnee.xepher.net/pics/080710trade.jpg

[pygame] DMs, what are you doing?!

[B W]

I'm curious. :)

Is anybody out there working on a dungeon crawler?

My interests travel specifically along this line:

   - RP with a storyline and character building
   - PVE
   - real-time combat and movement (not turn-based)
   - melee-range-magic
   - not too deep in stats or skills
   - plans for network co-op a plus

Gumm

Re: [pygame] Regarding two Pygame-related events

[B W]

Me too!

(How did I overlook this?:))

Gumm

Re: [pygame] Problem with simultaneous key presses

[B W]

I just tried Control key, it works great. Thanks for the suggestion.

Gumm

On Wed, Feb 10, 2010 at 10:09 AM, Jason M. Marshall j...@yahoo.com wrote:

 For your default keys, I suggest Up, Down, Left, Right and left Ctrl. The
 modifier keys (Alt, Ctrl and Shift) are less prone to blocking than Space.

 Jason

Re: [pygame] Problem with simultaneous key presses

[B W]

Well crap. I was hoping that it was not woven into the fabric of space-time.

Thanks for the article, René. An explanation is the next best thing to a
solution. :)

Gumm

On Mon, Feb 8, 2010 at 11:23 PM, René Dudfield ren...@gmail.com wrote:

 hi,

 keyboards are evil:
 http://www.sjbaker.org/wiki/index.php?title=Keyboards_Are_Evil

 you can try changing around they keys... some combinations are better
 than others.

 cheers,

[pygame] Problem with simultaneous key presses

[B W]

Howdy, folks.

The following small program demonstrates a problem with key presses.

http://trollsouttaluckland.googlecode.com/files/test.py

The program accepts cursor keys and space key to simulate moving and firing,
respectively. It accumulates keydown and keyup events, translating
combinations into diagonal movement. If you press up+left, for example, the
box moves diagonally upward and left. This works as intended.

Theoretically you can also fire the ray while moving. However, while moving
diagonally this only sometimes works. If for example I press space while
holding down up+left, the space key event is sometimes lost or blocked. I
can't tell which. But the result is that sometimes while moving diagonally
the ray fires and sometimes it does not.

This occurs on Windows XP, Python 2.5.4, Pygame 1.9.1release-svn2575. I've
also seen it in Pygame 1.8.1.

Does anyone have some insight on this odd behavior? Thanks in advance. :)

Gumm

[pygame] Trolls Outta Luckland v1.0.0 final

[B W]

The space shooter enthusiasts' release. Have fun.

http://www.pygame.org/project-Trolls+Outta+Luckland-1358-2493.html#

Gumm

Re: [pygame] write sound to file for fast loading?

[B W]

On Wed, Feb 3, 2010 at 2:28 PM, Shadd itash...@gmail.com wrote:

 I think it would be easier to simply use a loading screen before a part of
 the game (f.e. entering an area) and there load any sounds that might come
 in use into that part. It surely would be nicer to see than lag during the
 gameplay.
 Of course this could not be the best solution, but if there are not better
 options, this would be the better to use.

 I used pre-loading with a please wait screen before. It sucked. Like 20
seconds on a fast computer to load a bunch of songs. A very very very long
time on a slow computer.

Changed to pygame.mixer.music FTW.

Thanks. :)

Gumm

Re: [pygame] frame independant movement

[B W]

This is kind of a caveman method that might waste a few precious FPS, but I
used it successfully (I think--I mean, nobody complained my game runs like
crap. :))

Run a frame-flipping benchmark for a second or two as part of your program's
startup, in which you blit the whole screen each frame and record the
average FPS (or minimum FPS if you're a glass-half-full guy). Then pick some
arbitrary percentage of computational overhead you want to reserve for
worst-case game computations, say 10% or 15%, and shave that off the top:
max_fps = bench_fps * 0.15. Then clock.tick(max_fps) to throttle your frame
rate.

Hypothetically you can get near-max FPS on any system. You could then code
your game speed factor in the manner described by the others in this thread.

Not all computers are created equally, though. One may excel or not in any
area depending on the parts and how well they are intergrated. There may be
some systems on which this kind of fudging doesn't work so you could also
provide a means for the user to manually cap FPS if consistent frame rate is
important.

Gumm

Re: [pygame] write sound to file for fast loading?

[B W]

These are .ogg loading from disk using pygame.mixer.Sound('filename.ogg'),
the largest of which is 7 MB.

I can't believe I overlooked pygame.mixer.music. Pardon me while I flog
myself.

This does exactly what I want. Thanks, Brian and Olof, for suggesting it!
Works like a charm.

Gumm

[pygame] write sound to file for fast loading?

[B W]

Howdy, folks.

I have a problem I've been studying a while and I can't figure out a
solution. Pygame or SDL--not sure which--is pretty slow at loading sounds.
For large sounds, like songs, this means significant pauses in your game; or
very long loading times at startup if you have a few of them to load.

I tried using a thread to load a song, but as expected that only resulted in
a very laggy game for the duration.

So I was thinking it might be faster to pre-process a song: load it via the
mixer, write the buffer to a data file, then later load it into an array and
feed the array to the mixer. I can see that part of that idea is implemented
in _sndarray.py, but I didn't really want to require numpy and I couldn't
see how to convert that module's code to my purpose anyhow.

I'm strikin' out. Is this even feasible, or is it a hair-brained scheme
doomed to failure? Has anyone solved this problem, and would s/he be willing
to share? :)

Gumm

Re: [pygame] BUG : self-made pygame events don't work under Windows XP

[B W]

Hi, Amaury.

The docs recommend that event.type stay between NOEVENT and NUMEVENTS. So
you are restricted to that range. Not sure if this is the cause of the
inconsistencies you're seeing, but Pygame can be expected to work on any
support platform if you follow the rules.

Even though your choice of Event type is restricted, you can put virtually
anything you want in your own events. This opens up a huge potential for
customization.

For example, you could use an attribute like usertype to store any number
of user event  types. And you are not restricted in regards to its contents,
or even a particular data type. And you can have any number of attributes.

Here is one way to make your own event types.

e = Event(USEREVENT, usertype='alist', userdata=[1,2,3,4])
pygame.event.post(e)
...
for e in pygame.event.get():
if e.type == USEREVENT:
if e.usertype == 'alist':
print e.usertype, e.userdata

Note tou probably do not want to use spaces in your dict keys, like you did
in the example. If you do, you will need to use getattr() to access them.

Hope this helps.

Gumm

On Mon, Jan 25, 2010 at 4:10 PM, Amaury Lepicard amaury.lepic...@ensc.frwrote:

 program works well
 qith the values 42 and 43. This may not be possible, isn't it?

[pygame] OpenGL textures flipped

[B W]

Hey, all.

An OpenGL noob problem. Loading a texture from an image, let's say some.png,
is oriented upside-down and backwards when displayed. I've noticed this in
two cases, I'll present the simplest.

I was looking at this nice module
http://www.pygame.org/wiki/SimpleOpenGL2dClasses?parent=CookBook. I made a
32x32 image in GIMP according to the module's instructions and put an
alphabetic character (L in the upper left corner) on it so I could see the
orientation. When I run the module's __main__ demo the image is displayed
upside-down and backwards. The image is attached to this post for those who
care to try this.

I experimentally modified the code in function createTexDL based on a
recollection of something I read once: the coordinate system for geometric
objects (lines, triangels, etc.) is not the same as that for textures.
Geometry has origin 0,0 at the bottom left corner, whereas textures have
origin 0,0 at the upper left corner.

So the original code which displays upside-down/backwards...

# Bottom Left Of The Texture and Quad
glTexCoord2f(0, 0); glVertex2f(0, 0)
# Top Left Of The Texture and Quad
glTexCoord2f(0, 1); glVertex2f(0, height)
# Top Right Of The Texture and Quad
glTexCoord2f(1, 1); glVertex2f( width,  height)
# Bottom Right Of The Texture and Quad
glTexCoord2f(1, 0); glVertex2f(width, 0)

Became this, the right orientation facing forward and upright...

# Bottom Left Of The Texture and Quad
glTexCoord2f(0, 0); glVertex2f(0, height)
# Bottom Right Of The Texture and Quad
glTexCoord2f(1, 0); glVertex2f( width,  height)
# Top Right Of The Texture and Quad
glTexCoord2f(1, 1); glVertex2f(width, 0)
# Top Left Of The Texture and Quad
glTexCoord2f(0, 1); glVertex2f(0, 0)

I'm posing this puzzle because I can't find where I think I may have read
about the coordinate systems (I *will*, but in the meantime this is eating
at me). I don't know enough yet to tell if this flip-behavior is due to an
anomaly in my OpenGL environment or if the way I've mapped the texture is
correct. And I'm sure the module's author saw that his/her images displayed
correctly, which kinda makes me unsure of anything.

You OpenGL experts, could you please properly align my thinking on this
topic?

Thanks. :)

Gumm
attachment: foo.png

Re: [pygame] OpenGL textures flipped

[B W]

I could not have asked for a better explanation, Brian. Thanks so much.

bw

Re: [pygame] Rotation Performance

[B W]

It could just be the Atom.

http://www.trustedreviews.com/cpu-memory/review/2008/08/14/VIA-Nano-vs-Intel-Atom/p3

Gumm

[pygame] Pygext and Opioid2D?

[B W]

I am intrigued by these two projects. But the home and source links are
dead, and there have been no updates in nearly two years. Anyone know what
happened to them or their author?

http://www.pygame.org/project-pygext-103-.html
http://www.pygame.org/project-Opioid2D-459-.html

Gumm

[pygame] Trolls Outta Luckland v0.0.7-beta is up

[B W]

http://www.pygame.org/project-Trolls+Outta+Luckland-1358-2441.html

Phew. Now I will take a short break and check out the recent activity on
pygame.org.

Hope you enjoy. Please leave a note.

Gumm

[pygame] Trolls Outta Luckland - 0.0.4

[B W]

For those of you who yawned at v0.0.3... :)

http://www.pygame.org/project-Trolls+Outta+Luckland-1358-2419.html#

Many thanks to Michael George and Bryce Schroeder for the first round of
discussions, which I found very helpful. Looking forward to more.

Gumm

Re: [pygame] Trolls Outta Luckland - 0.0.4

[B W]

On Sat, Jan 2, 2010 at 8:27 AM, Michael George mdgeo...@cs.cornell.eduwrote:

 In 0.0.4:

 ImportError: Bad magic number in lib/game_globals.pyc
   in file
 /home/mdgeorge/tmp/trolls_outta_luckland/Trolls_Outta_Luckland.py
 Traceback (most recent call last):
  File Trolls_Outta_Luckland.py, line 1012, in module
   main()
  File Trolls_Outta_Luckland.py, line 989, in main
   jukebox = gumm_sound.Jukebox()
 NameError: global name 'gumm_sound' is not defined


 Hm...

Taking a guess: ./lib/ or /home/mdgeorge/tmp/trolls_outta_luckland/lib needs
to be in your sys.path. The game automatically adds ./lib/ so this should
work:

$ cd /home/mdgeorge/tmp/trolls_outta_luckland
$ ./Trolls_Outta_Luckland.py

Gumm

Re: [pygame] Trolls Outta Luckland - 0.0.4

[B W]

On Sat, Jan 2, 2010 at 8:58 AM, B W stabbingfin...@gmail.com wrote:

 On Sat, Jan 2, 2010 at 8:27 AM, Michael George mdgeo...@cs.cornell.eduwrote:

 In 0.0.4:

 ImportError: Bad magic number in lib/game_globals.pyc


 $ cd /home/mdgeorge/tmp/trolls_outta_luckland
 $ ./Trolls_Outta_Luckland.py

 Gumm


Forget that. Looks like this is going to be a learning experience.

What version of Python are you using, Michael? Bet it's not 2.5.4. And I'll
bet that lib/*.pyc need to be recompiled. Which is unfortunate, because I
pre-compiled the many many many hitmasks so you wouldn't have to. Compiling
those requires 2 GB of RAM and will kill Windows (and maybe Linux) systems
that have a decent size paging file configured.

Doing some research. Meanwhile, if my hunch is right: I'll need to figure
out how to set up a proper install that re-compiles the libs. Does anyone
know of a way to compile huge .py with a tiny amount of RAM--say, less than
500 MB?

Gumm

Re: [pygame] Trolls Outta Luckland - 0.0.4

[B W]

Brilliant. RTWFM. :)

Simple, elegant, and smart fix. I'll have the new stuff up shortly.

bw

On Sat, Jan 2, 2010 at 9:25 AM, Michael George mdgeo...@cs.cornell.eduwrote:

 Have you tried using the pygame.mask module?  I suspect that it will be
 fast enough to not have to do preloading.  Doing hitmasks the way you are
 (i.e. in python) has huge overheads.

 --Mike

 B W wrote:



 On Sat, Jan 2, 2010 at 8:58 AM, B W stabbingfin...@gmail.com mailto:
 stabbingfin...@gmail.com wrote:

On Sat, Jan 2, 2010 at 8:27 AM, Michael George
mdgeo...@cs.cornell.edu mailto:mdgeo...@cs.cornell.edu wrote:

In 0.0.4:

ImportError: Bad magic number in lib/game_globals.pyc


$ cd /home/mdgeorge/tmp/trolls_outta_luckland
$ ./Trolls_Outta_Luckland.py

Gumm


 Forget that. Looks like this is going to be a learning experience.

 What version of Python are you using, Michael? Bet it's not 2.5.4. And
 I'll bet that lib/*.pyc need to be recompiled. Which is unfortunate, because
 I pre-compiled the many many many hitmasks so you wouldn't have to.
 Compiling those requires 2 GB of RAM and will kill Windows (and maybe Linux)
 systems that have a decent size paging file configured.

 Doing some research. Meanwhile, if my hunch is right: I'll need to figure
 out how to set up a proper install that re-compiles the libs. Does anyone
 know of a way to compile huge .py with a tiny amount of RAM--say, less than
 500 MB?

 Gumm

Re: [pygame] Trolls Outta Luckland - 0.0.4

[B W]

Thanks for the assist, Michael.

For now, I uploaded a light bundle to SourceForge, sans music, so folks
don't have to re-download the music to get a bug fix. In the process of
uploading a music pack.

Gumm

On Sat, Jan 2, 2010 at 10:21 AM, B W stabbingfin...@gmail.com wrote:

 Brilliant. RTWFM. :)

 ...I'll have the new stuff up shortly.

Re: [pygame] Trolls Outta Luckland - new release

[B W]

On Tue, Dec 22, 2009 at 8:59 PM, Michael George mdgeo...@cs.cornell.edu wrote:
 B W wrote:

 I'm not sure what you mean.



 If I move the mouse east, the cursor moves east.  If I then start moving the
 mouse west, the cursor immediately jumps to the west of the ship, even if
 it's currently on the east.

And what happens if you move the mouse east and leave it there? Ship
keeps moving east until it hits the edge?

Gumm

Re: [pygame] Trolls Outta Luckland - new release

[B W]

On Mon, Dec 21, 2009 at 9:33 AM, Michael George mdgeo...@cs.cornell.edu wrote:

 I, for one, liked the mouse interface after playing a couple of games.  I'm
 of two minds about showing the cursor.  On the one hand it makes it clear
 what's going on in terms of the limited speed movement.  On the other, it's
 kinda distracting.  Have you tried hiding the cursor during play?

I agree, the visible mouse cursor really distracted me at first. But I
got used to it. This was after trying with an invisible cursor. I
found myself in a constant state of over-correction. You can easily
try it and see what it's like: find the Pointer class in lib/ui.py,
fill the image with Color(1,1,1) after it's loaded.

 Another thought I had (and this probably needs experimenting to work out
 well) is to try to use the mouse as a directional control rather than a
 positional control.  In other words, currently when I move the mouse to the
 left, the desired position of the ship moves left; perhaps instead the ship
 itself should move left.  The problem with this is how to specify how much,
 and also how to retain the speed limit.  Mice are designed to be positional
 controls, so that might be weird.

I rassled with that for some time before I came up with a method. The
ship moves to the mouse cursor by pathing along the points of a
Bresenham line. I put a throttle on the pathing increment to keep the
speed constant, simulating joystick motion. It definitely looks
contrived, and distracting, and likely reduces the sense of immersion.

Nevertheless, because there's a lot of hand-eye involved in wielding
an invisible mouse there probably needs to be a visual cue. But I
think I get what you're saying. Correct me if I'm wrong. Picturing it
this way... I nudge the mouse left, thrusters on the opposite side
fire to move the ship in the direction of mouse motion. The farther I
drag the mouse to the left, the brighter the thrusters burn. They die
down over time, unless I give them another nudge with the mouse. Oh
no, I flunked fizzix. :)

That would definitely require more thought to control. I'd have to
nerf the baddies quite a bit. But hey, if it gets the adrenaline
pumping--yeah, baby.

 While I understand your concerns (I'm a perfectionist too on my games) I
 think having a fullscreen option is the way to go.  I modded the source and
 changed it to use your fullscreen options in game_globals.py, and enjoyed it
 that way.  I think a menu entry to toggle fullscreen would be fine.  Also, I
 would probably lock the cursor inside the window in windowed mode.

I took Bryce's suggestion to heart. I am looking into offering
fullscreen as an option. I need to revamp my speed timings, though, to
accommodate varying frame rates, something I realized in retrospect
needed to be done anyway. This will exact a delay, but it's important.

 A few other constructive comments:  I like the way the high scores work
 better than other games, where I quickly end up with Mike Mike Mike Mike
 Mike.  However, having to input a player name every time is kind of a pain.
  Moreover, having to type with the mouse is a double pain.  It would be
 better IMO if you saved the player name (and maybe offered a change player
 button in the menu).

I agree. I will save you from that tedium. :)

 There seems to be a glitch when the invaders return to their home -
 sometimes they teleport from the end of their arcs to their stationary
 positions.  Perhaps a roundoff error getting multiplied out or something?

I fixed that once. I think it was a symptom of pathing outside the
playfield. Must have come back when I adjusted the paths' control
points after widening the playfield. Must kill bug...

 The stage counter increments immediately when you destroy the last guy, it
 seems it would be better to increment it when the next stage starts.

That bugs me too. I would not have tolerated it forever. Now I have
greater purpose. :)

 I got 27k and stage 8!

Damn, you beat me. That puts you on top of the rock. The installed
scores are fictitious, so COLGUMM, et al, don't count. (Some poor soul
who doesn't read this will surely waste years trying to get 100,000
exactly. =)

 Keep up the good work!  I think this is a nice game (despite being refried
 beans :))

 --Mike


Great feedback, Mike. You gave me a lot to think about. Thanks so much
for taking the time.

Gumm

Re: [pygame] making game distribution easier, part 1.

[B W]

This is such a great idea. I love it.

Thinking it through some has hurt my brain, though. But not as much as
manually resolving dependencies. I think obviously the biggest
challenge is going to be the dependencies. I lost count of how many
times I gave up on trying out someone's cool project when resolving
dependencies became too big a hassle. I consider myself of high
technical aptitude, but not in that area--I'd rather go play Diablo
some more. And if I was a regular joe, I'd definitely go play Diablo
some more.

Managing dependencies somehow with the distributor is imperative.
René's suggestion, having standard platform builds, seems the only
realistic way to go. Still, it could be a daunting ordeal just to
validate your app on all the platforms, even if you reduce the parts
to: 1) hardware architecture; 2) OS level; 3) Python runtime and
libraries; 4) times, say, two--one each for the current and previous
stable runtimes. That's a lotta work just to validate an app. I can't
imagine the work required to make all the environments.

But if you have a Python runtime build for each major system platform,
and they are at least 95% cross-platform compatible, it should greatly
simplify distribution as well as dependency resolution. And app
developers could code around the 5% if/when they are identified and
documented.

As Patrick points out, if you stay current you should be mostly okay.
It seems most devs and teams strive to make their new releases
backwards compatible, and phase out their deprecations to minimize
impact.

The only real difficulty the app developers need to worry about, then,
is how to distribute dependencies not provided by the platform. For
example, if you presume to install them in Python's site-packages or
site-wide library paths, you will eventually create conflicts.

It would require a lot of effort, multi-teamwork, and tight
organization. But the results could be so great. Developing for the
platform then becomes a design decision. And da Gumm can try all your
apps widdout hurting his brain no more, instead of playing Diablo
again. =)

Well... I'll never give up Diablo.

Gumm

[pygame] Trolls Outta Luckland - new release

[B W]

Ahoy, pygamers.

v0.0.3 is posted.
http://www.pygame.org/project-Trolls+Outta+Luckland-1358-2402.html

Ain't this like the third space shooter out this month? Sorry...
promise, we did not conspire to flood you with shooters! :)

Anyway, I'd been wanting to do a shooter for a very long time so here
it comes. A little tired of the joystick and keyboard scene with its
clumsy 2- to 8-way motion. Thought I would go mouse for a big change,
try and get N-way. And that seems to be working great. I poured many
hours in over the past few days, and it shows. Please check it out, I
hope you like.

I haven't gotten any feedback yet. Not even a first post1 Makes
me wonder if my stuff is broke. :) Let me know if you have any
problems with the site. And thanks for your interest.

Gumm