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 either a renderer or a display surface f

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  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  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] 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 and may
> be unlawful. Internet communications cannot be guaranteed to be 

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 
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]

Argh! pygame.mixer.quit() is hanging.

('keydown', 'escape')
Exit progress: begin
Exit progress: pygame.display.get_init()
Exit progress: pygame.display.get_surface()
Exit progress: screen.unlock()
Exit progress: pygame.display.set_mode((16, 64))
Exit progress: pygame.display.flip()
Exit progress: pygame.display.quit()
Exit progress: pygame.mixer.quit()

Gumm


On Wed, Jul 16, 2014 at 2:49 PM, Sam Bull  wrote:

> On mer, 2014-07-16 at 14:36 -0700, B W wrote:
> > The issue seems to be in the shutdown/cleanup code of pygame.
>
> The program appears to only use the pygame.display module, so if it is
> currently crashing in pygame.exit(), then it may be an idea to try
> initialising and exiting individual modules, to see if the problem is in
> a single module's shutdown.
>
> So, replace pygame.init() with pygame.display.init(), and pygame.quit()
> with pygame.display.quit(). If the crash disappears, then start adding
> additional module init's and quit's and see if you can narrow the crash
> into a single module's quit() function. Other modules include
> pygame.mixer and pygame.scrap.
>
import sys
import time

import pygame
from pygame.locals import *

pygame.display.init()
pygame.mixer.init()
#pygame.scrap.init()  #pygame.error: no display mode is set
resolution = 1024, 768
image_size = 200
# these two lines run better over ssh -X ...
resolution = 196, 32
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)),
pygame.Surface((image_size, image_size)),
)
images[0].fill(Color('slategray2'))
images[1].fill(Color('slategray3'))
image_rect = images[0].get_rect()
bg_color = Color('black')
dx = -1
dy = -1
max_fps = 0
high_fps = 0
running = True
while running:

dt = clock.tick(max_fps)

fps = int(round(clock.get_fps()))
if fps > high_fps:
high_fps = fps
meter = 'o' * (fps  / 20)
pygame.display.set_caption('Fps {2}/{0} {1}'.format(fps, meter, high_fps))

scroll_rect.move_ip(dx, dy)
if not scroll_rect.contains(screen_rect):
dx = -dx
dy = -dy

screen.fill(bg_color)
line_num = 0
for y in xrange(scroll_rect.y, scroll_rect.bottom, image_size):
checker = 0 if line_num % 2 else 1
line_num += 1
for x in xrange(scroll_rect.x, scroll_rect.right, image_size):
image_rect.x = x
image_rect.y = y
if screen_rect.colliderect(image_rect):
screen.blit(images[checker], image_rect)
checker = 0 if checker == 1 else 1
pygame.display.flip()

for e in pygame.event.get():
if e.type == KEYDOWN:
print('keydown',pygame.key.name(e.key))
sys.stdout.flush()
if e.key == K_ESCAPE:
running = False


def progress(n):
print('Exit progress: {0}'.format(n))
sys.stdout.flush()

progress('begin')

progress('pygame.display.get_init()')
pygame.display.get_init()

progress('pygame.display.get_surface()')
pygame.display.get_surface()

progress('screen.unlock()')
screen.unlock()

progress('pygame.display.set_mode((16, 64))')
pygame.display.set_mode((16, 64))

progress('pygame.display.flip()')
pygame.display.flip()

progress('pygame.display.quit()')
pygame.display.quit()

progress('pygame.mixer.quit()')
pygame.mixer.quit()

progress('pygame.scrap.quit()')
pygame.scrap.quit()

progress('sys.exit()')
sys.exit()

progress('done')

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  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

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  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] 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] 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  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)  &&  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  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  wrote:

> 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  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 
> wrote:
>
>> Explicit, please? I'm not very good at riddles...
>>
>>
>> On Thu, Dec 6, 2012 at 7:31 PM, Tanner Johnson wrote:
>>
>>> 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
wrote:

> 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 . 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
to fill up your bag of tricks.

In addition to the resources mentioned for working with Tiled map files,
there is my favorite
pytmxloader
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
Library.
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
, a pyweek
warmup,
and the tile scrolling engine Gummworld
2.
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
wrote:

> On Wed, Nov 14, 2012 at 7:07 PM, yannisv  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 
> wrote:
>
>> On Thu, Aug 11, 2011 at 10:39 PM, Ian Mallett 
>> 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 wrote:

> 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  wrote:
>
>> That might work . . .  : )
>>
>>
>> On Tue, Jul 12, 2011 at 6:58 PM, Brian Fisher 
>> wrote:
>>
>>> 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  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  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 wrote:
>
>> On Tue, Jul 12, 2011 at 1:59 PM, Sean Wolfe wrote:
>>
>>> Dude

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 wrote:

> 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  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
here,
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  wrote:

> Basically, just use pygame.time.Clock to maintain a constant framerate.
>
>
> On Mon, May 2, 2011 at 5:40 AM, Jake b  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  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
>

[pygame] Request for guinea pig :)

[B W]

Howdy, folks.

I have a favor to ask. I don't have a Mac. Or a friend with a Mac.
Rent-A-Friend only comes with Linux.

As a favor to da Gumm would some kind pygamer with a Mac OS X be willing to
take Gummworld2 0.1.0 for a spin and let me know how it goes?

If you're up to the challenge, you only need Python 2.6 and pygame 1.9 to
run the examples. A quick QA run of the examples would be a great help, just
to make sure the scrolling works and the demos don't crash. Disregard the
lone pymunk example and the world editor if you like.

Sites:
pygame: http://www.pygame.org/project-Gummworld2-1733-3119.html
Google Code: http://code.google.com/p/gummworld2/

Potential benefits: return favors in kind; a personal space heater (laptop
required); rise in global happiness.

Thanks in advance for any assistance. =)

Gumm

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
wrote:

> 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 wrote:

> 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] peer-to-peer networked games

[B W]

If you can work with OpenGL, might keep your eye on PySoy.

http://www.pysoy.org/

Gumm

On Sat, Nov 6, 2010 at 2:48 AM, Miriam English wrote:

> Wow! Thanks Kris.
>
> I hadn't heard of this one. Croquet sounds very interesting. I didn't
> understand it all in my first quick read-through, but I'll look much more
> carefully at it after I've finished my story. I've built virtual worlds
> before and this seems like a great environment to work in. Fancy being able
> to edit source and have the modifications appear in realtime without
> stopping and reloading! Neat. Pity it's not python though. :)
>
> Yes, I've had a look at Minecraft and was very impressed with its cuteness,
> even though it looks very basic. I had no idea it was intended to let
> servers to share data like that. That's nearly p2p right there. All it takes
> is for every client machine to also be a server. (Well, not quite, but
> almost...)
>
> Cheers,
>
>- Miriam
>
>
> Kris Schnee wrote:
>
>> On 2010.11.5 8:09 PM, Miriam English wrote:
>>
>>> Okay, I've found some stuff that I hadn't heard of before that some of
>>> you folks might be interested in:
>>>
>>
>> http://en.wikipedia.org/wiki/Croquet_project
>> The Croquet Project seems to be similar to that. The indie game Minecraft
>> is apparently going to have servers linked so that a character can walk from
>> one server's world to another.
>>
>> A question that Croquet brings up is how to spread out the computation
>> between computers. There's a project called OpenSimulator that sets up
>> independent servers for the game Second Life, but I believe that works on a
>> more standard client/server arrangement. Croquet is set up so that the
>> calculation is done on every machine, which is inefficient but ensures every
>> machine does the same thing... at the cost of the system being as slow as
>> the slowest PC, if I understand right. At the other end of the scale, with
>> Minecraft it'd probably be possible for one server to let players easily get
>> hoards of valuable items, then try to walk onto a higher-difficulty server
>> with items intact. So for a game you'd have to think about which machine
>> enforces the rules against cheaters, and the more centralized it is, the
>> more it's like the client/server setup.
>>
>> If someone wants to test out building a Python P2P gaming system, don't
>> assume it has to be for real-time 3D games! Why not try making a P2P text
>> MU?
>>
>>
>>
> --
> If you don't have any failures then you're not trying hard enough.
>  - Dr. Charles Elachi, director of NASA's Jet Propulsion Laboratory
> -
> Website: http://miriam-english.org
> Blog: http://miriam_e.livejournal.com
>

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  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]

erstand your hint (hint: move some
> of the constructor code to a resize method and call that from in
> constructor, as well as the main) By constructor you mean the first
> __init__( variable, variable...) ?  This stuff doesn't come naturally to me,
> but I find 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  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] 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
archiveis
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 , 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
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  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] frame independant movement

[B W]

This is for folks who may have a continuing interest in the topic.

While trying to use GameClock I discovered a bug. While I was in there
a-squashing, I added a couple methods. Then I decided to take the prediction
demo to the next level and solve the screen-edge rebound problem, with
plenty of here's-why-and-how notes.

These are available at
game_clock.pyand
pygame.org/wiki/ConstantGameSpeed
.

Gumm

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  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  wrote:
>
>> On Sat, Oct 2, 2010 at 8:09 PM, kevin hayes  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.py
game_clock.py
pymunk 

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  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  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  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  > 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  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 wrote:

>
> > 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]

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  wrote:

>
> Any path editors out there?
>
> Mark
>

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  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
>  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  wrote:
> >
> >> Anyone have a function for calculating all the points on a line to be
> >> used for sprite movement?
> >>
> >> 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  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.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
>>
>>
>>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)
>>
>>
>>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 
>>   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] 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  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
>>>
>>> 
>>> 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)
>>> 
>>>
>>> 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 
>>>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  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.
>

[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


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)


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 
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 wrote:

> 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  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  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]

On Tue, Jun 15, 2010 at 9:53 PM, Hokan LUNDBERG  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/)
> 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.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] 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  wrote:

> Hi again!
>
> http://www.cs.iupui.edu/~aharris/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] 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  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  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.py&can=2&q=

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

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  wrote:

> Hello,
>
> I humbly present my networking library, 
> Mastermind.
> 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 
> gamethat uses it.  
> Seems to handle crowds pretty nicely.  Anyway, you may find
> it suits your needs.  Enjoy!
>
> Ian
>

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] question about Rect objects

[B W]

Hi, Alex.

On Tue, May 18, 2010 at 6:12 PM, Alex Hall  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.py&can=2&q=

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] 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  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] 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] 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] 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] pygame.image.save(...)

[B W]

On Wed, Apr 28, 2010 at 1:31 AM, René Dudfield  wrote:

> On Wed, Apr 28, 2010 at 5:26 AM, Ian Mallett  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]

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] 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] 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 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]

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] blit speedup

[B W]

On Sun, Mar 28, 2010 at 3:29 PM, Wakefield, Robert
wrote:

> 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  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 
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]

On Tue, Mar 2, 2010 at 2:54 PM, Greg Ewing wrote:

> 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 (). Does it
represent the raw keys? In my case, for UP arrow they are
(K_ESCAPE,K_O,K_A).

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 wrote:

> 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] pygame.mixer.init(frequency=?)

[B W]

On Thu, Feb 25, 2010 at 1:43 PM, Marius Gedminas  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

[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] DMs, what are you doing?!

[B W]

It seems I have to correct myself, too. Before Jordan does. :) According to
Jordan's home page, Ardentryst is one-... man/troll/whatever he is...
project, but for some non-coding contributors. Phew. Two years.

Very nice work, Jordan. If you are reading this, how did you get such a
horde of beta testers? I must learn the secret. =)

Gumm

On Fri, Feb 19, 2010 at 3:08 PM, B W  wrote:

>
> 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
>

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  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
>>
>> I 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
>

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

[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  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  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] 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]

On Wed, Feb 3, 2010 at 2:28 PM, Shadd  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] 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 wrote:

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

Re: [pygame] why is sometimes so much time between 2 frames ? (400 milliseconds instead of 30)

[B W]

Yes, your collision checking is wasteful and garbage is piling up. :)

You can see easiest this if you simply "import gc" and then "gc.collect()"
at the end of your main loop. As you make more penguins you will notice your
green meter grows a lot. It was killing my dual-core at around 20 penguins.

In a slapdash attempt to improve, I did the following in your main loop:

collisions = pygame.sprite.groupcollide(birdgroup, birdgroup, False,
False)
for bird in collisions.keys():
for crashbird in collisions[bird]:
if bird is not crashbird:
bird.crashing = True
bird.dx -= crashbird.pos[0] - bird.pos[0]
bird.dy -= crashbird.pos[1] - bird.pos[1]

This seems to do what you intended. You just need to handle the special case
where bird is crashbird, since a collision test always reports that a sprite
collides with itself.

With this minor rewrite I can have 170 penguins alive while maintaining 40+
FPS.

Gumm

On Sun, Jan 24, 2010 at 2:00 PM, Horst JENS  wrote:

> I wrote a pygame program with sprites bouncing around. fps and time
> between 2 frames is displayed (as number and as green bars).
>
> If many sprites are present, sometimes (like each half minute) there is
> a extreme huge value of passed time between 2 frames. (>400 instead of
> the usual 30).
>
> Is this some kind of garbage collection ? Is it because i copy a sprite
> group (for collision check) ?
>
>
> http://www.spielend-programmieren.at/wiki/doku.php?id=en:code:pygame:zeitproblem
>
> greetings,
>-Horst
>
> --
> Horst JENS
> horst.j...@spielend-programmieren.at
> http://www.spielend-programmieren.at
>

Re: [pygame] OpenGL textures flipped

[B W]

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

bw

[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
<>

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

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  wrote:

> Brilliant. RTWFM. :)
>
> ...I'll have the new stuff up shortly.
>
>

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 wrote:

> 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>> wrote:
>>
>>On Sat, Jan 2, 2010 at 8:27 AM, Michael George
>>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]

On Sat, Jan 2, 2010 at 8:58 AM, B W  wrote:

> On Sat, Jan 2, 2010 at 8:27 AM, Michael George 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