Re: [pygame] https://pygame.org/

[Patrick Mullen]

Thank you for the new site! So refreshing to see activity.

On Thu, Mar 30, 2017 at 9:17 PM, DiliupG  wrote:

> That's the way to go. SO much happening with Pygame this year can't even
> keep up! Great! :)
>
> On 31 March 2017 at 00:16, Al Sweigart  wrote:
>
>> Instead of imposing a timeout after a certain number of login attempts,
>> I'd recommend setting up Google ReCAPTCHA. I did this with a site I'm
>> developing and I was surprised how easy it was to set up:
>>
>> Go to this page logged in as your Google/Gmail user to add your domain:
>> https://www.google.com/recaptcha/admin#list
>>
>> This site has the setup guide: https://developers.goog
>> le.com/recaptcha/intro
>>
>> On Tue, Mar 28, 2017 at 11:09 PM, René Dudfield  wrote:
>>
>>> Emailed you privately about the login problem. I expect you may have
>>> been using a different email address.
>>>
>>> The 4 per hour on login urls is a limit which helps stop bots hacking
>>> into the website. It also helps to stop spammers creating lots of
>>> accounts/spam. I can't really remove that because of this. I can try to fix
>>> any login issues though, so legitimate users don't have issues logging in.
>>>
>>> I reset the ban for you, so you should be able to try and login 4 more
>>> times :)
>>>
>>>
>>> cheers,
>>>
>>>
>>>
>>> On Wed, Mar 29, 2017 at 7:20 AM, DiliupG  wrote:
>>>
 having login problems again! today! and this 4 per hour business is
 taking too much time. Can't you remove that or at least make it higher than
 that?

 On 14 March 2017 at 11:04, DiliupG  wrote:

> sounds good. I look forward to contributing to make this a great page
> and make it easier for all.
>
> On 13 March 2017 at 15:06, René Dudfield  wrote:
>
>> Thanks Diliup! I'm hoping it won't take too much time. I want to make
>> it as low amount of work as possible for the moderators.
>>
>> Will be in touch some time in the next week.
>>
>> cheers!
>>
>>
>>
>>
>> On Mon, Mar 13, 2017 at 9:20 AM, DiliupG  wrote:
>>
>>> I would like to volunteer to keep SPAM and abusive messages away
>>> from the pygame site if you guys would let me do it. I can spare a few
>>> hours each day. The documentation if FULL of it and maybe due to that
>>> reason now NO ONE can add even a positive comment.
>>>
>>> On 13 March 2017 at 12:04, René Dudfield  wrote:
>>>
 On Mon, Mar 13, 2017 at 5:24 AM, Bork Air <
 dan.fisher112...@gmail.com> wrote:

> again, your website looks like shit
>
> the original green one had some design
>
>
>
 Speaking of which...

 If anyone wants to help with the joyful job of helping to moderate
 abusive comments, please get in touch.



>>>
>>>
>>> --
>>> Kalasuri Diliup Gabadamudalige
>>>
>>> https://dahamgatalu.wordpress.com/
>>> http://soft.diliupg.com/
>>> http://www.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.
>>> 
>>> **
>>>
>>>
>>
>
>
> --
> Kalasuri Diliup Gabadamudalige
>
> https://dahamgatalu.wordpress.com/
> http://soft.diliupg.com/
> http://www.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.
> 

Re: [pygame][website] A different approach to a new website

[Patrick Mullen]

Pygame is dead. Still a very capable library, but it isn't really going
anywhere from what I can see, and I have little faith that the website will
go anywhere no matter who tries to help out. You posted yourself all of the
failed efforts in this area, what makes you think you will succeed? I
recommend making a wider python-related game development website that does
not focus only on pygame. There are many other options out there - pysdl2,
pygame2, python-sfml, pyopengl, pyglet, and more that I have played with in
the past but cannot remember right now. Having a project repository focused
around python, and with information about various libraries, but NOT
focused on a specific library would be the best approach forward in my
opinion. A good example of what I would like to see is haxe.io. It
highlights cool mostly game related things being done with haxe, and you
can find out about new libraries. There are various good blogs in the
python world that focus on web development, but not many that highlight
games. And each python game library has it's own little corner (in pygame's
case, a very old and broken corner that new visitors walk or run away from
very quickly) without much crossover.

On Wed, Sep 21, 2016 at 5:18 AM, DiliupG  wrote:

> Why don't you start working on the site and open it in a separate place
> and call it pygame 2016 something? Else we will end up going round and
> round with these long dialogs with nothing really happening. It could be
> www.pygame2016.blogspot.com or something similar.
>
> Diliup Gabadamudalige
>
> On 21 Sep 2016 4:08 p.m., "Alex Z."  wrote:
>
>> > These kinds of proposals would be much more successful if Alex were
>> able to come to the mailing list with a fully functioning demo using live
>> data that could be commented on and iterated on by the community.
>> See this: > - a complete redesign that never got launched (11-2009):
>> https://groups.google.com/d/msg/pygame-mirror-on-
>> google-groups/rUC5CrroA3U/TzWTWL5cFOUJ
>> There was an approach like this. As the site maintainers didn't like the
>> site, it never got launched, that's why I didn't come up with a solution.
>> Although I might do some prototypical views.
>>
>> > Pygame needs a site where a community can form around and share our
>> works (like right now!), and where new people can understand how to get
>> going and discover Pygame at their speed, using the OS that happens to be
>> in front of them. On that last point, I speak for kids who want to make
>> games and who don’t get a choice of their OS, in contrast to us adult
>> engineers.
>> I agree, that's the main reason why I want a page redesign. Of course
>> it's nice to have a good looking website, but what's *always *more
>> important than appearance is content and ease of use. As an experienced dev
>> you can handle poorly designed websites and still find what you are looking
>> for (mostly), but a beginner (children / young students) will just be like:
>> "screw it, then I'll just go back doing whatever". So I really feel the
>> need to make the site "child-friendly" (why not just do a second site for
>> that? --> read below). Nevertheless as a designer I got a fable for
>> good-looking aesthetics.
>>
>> > leave the old pygame site alone and build any amount of new ones. We
>> will all visit everyone according to our need. Aren't there hundreds of
>> Python sites?
>> Yes, there are hundreds of Python sites, but often they got different
>> topics to talk about. We are talking about a website for (more-or-less) a
>> Python-library. I think if we had many sites that (in the worst case) are
>> fighting a tough SEO battle about who is the better site, it will lead to
>> more confusion than we already got with the single site. Even worse if
>> these two sites offer similar functionality.
>>
>> > My question to you is, why does the Pygame website have to be built
>> from scratch as a custom solution?
>> In the head description of the form I state:
>> > Whether the old site is updated or we do a complete redesign, how hard
>> it will be to port the old data and who will maintain it is not important
>> in this first step.
>> Sorry that I didn't mention this in my post, I don't think that it is
>> impossible to gradually improve the old site, but to know if it's possible
>> we need to know, what needs to be improved. After that, I can talk to the
>> site owners if the desired features can be implemented by improvement, or
>> if we need a completely new site.
>> By the way: illumine stated (first link in my post):
>> > The current website is made with PHP and some website technology made
>> by Phil which he used to make dozens of websites professionaly.  This is
>> what Phil chose to use as the website maintainer in early 2005.
>> > [..] This time we decided it would be better to do it in python, and
>> also have a team of website maintainers.  Since not so many pygame
>> developers people know PHP, and that has meant 

Re: [pygame] Re: sprint this weekend

[Patrick Mullen]

I don't know if starting over or reverting is better than movement. At this
point any movement is good. I would rather see us build on something that
people are building on than try and get a project going (which keeps not
seeming to go anywhere). But the new layout is pretty tough to swallow. I
remember commenting as such before when this design was proposed - I
thought it was abandoned. It's appalling on many levels:

Horizontal scrolling is not fun, keeping reading left-right and scrolling
up-down helps us compartmentalize better. Having so many different,
unrelated pieces of content in one screen is distracting and confusing.
While scrolling over you may suddenly, without warning, find yourself on a
different section of the site, and you have to look up at the menu to even
know which section you are on, because they all look the same. The width of
the users browser fundamentally changes how the site feels. At the
fullscreen view that I normally browse in, I see about half of the about
module. It's super distracting! When reading through the reddit content, my
eye keeps being pulled over to the about, and then I can't even read it
because it is cut off. And then, when I go over to the learn section, the
question and answer module is cut-off. So if I want Q+A, I have to click on
learn and then click on the right arrow. It is unintuitive and clunky
at the same time. If you are going to make it clunky, it might as well be
consistently clunky.

The priority of which content is displayed where doesn't feel right. The
first page should be about helping newcomers figure out what pygame is,
whether they should use it, and where they can get help. Content you want
to see shouldn't be cut off on the sides of the screen forcing you to
scroll around to find it. If you scroll down just a little, you lose all
context of which section you are in, as well as what any of the modules are!

I don't get the music player. It doesn't seem to fit.

General color scheme, fonts, and layout look ugly. Sorry to say.

Some ideas to fix it:

* Rather than squish all sections on the same window, keep them separate.
Don't allow scrolling between sections, just update the div with each
section
* Include a table of contents in each section to show which modules are
available. It's painful to have to horizontal scroll several times to even
see what's there.
* I would actually stick with the tried-and-true content column + sidebar
column style. You can have the more important modules in the left column
with more width, and stack them vertically, with less important ones on the
side, also stacked vertically. For example, learn would have on the left:
about + tutorial + cookbook, and then on the right: help and a shorter
length list of q+a (which can be expanded potentially?)
* Ditch music player or have a link to pop one up in a new window if people
want it.

... for a start.

On Tue, Aug 18, 2015 at 10:03 PM, Luke Paireepinart rabidpoob...@gmail.com
wrote:

 Al,
 What sort of mistakes are you talking about and where do you draw the line
 of starting over vs. fixing mistakes?
 --
 From: Al Sweigart a...@inventwithpython.com
 Sent: ‎8/‎18/‎2015 5:57 PM
 To: pygame-users@seul.org
 Subject: Re: [pygame] Re: sprint this weekend

 I highly recommend switching to the old site and abandoning this design.
 There's a lot of things about the new design that don't work from a design
  usability perspective.

 It's clear that a lot of work has gone into the new site, and I don't want
 to disparage these efforts. But the end result is a site that is worse than
 the previous one. Honestly, I don't think the new design can be salvaged.
 It's best to cut losses, go back to the old design for now, and try again.

 Again, this criticism sounds blunt and rough, but the new design has
 several large mistakes that any web designer would point out. There were
 issues with the old site, but I think the best course of action is to
 switch back to it and abandon this new design.

 -Al

 On Tue, Aug 18, 2015 at 11:01 AM, Jeffrey Danowitz danow...@bezeqint.net
 wrote:

 I know that sadly I have not been a big participant in all the amazing
 things happening lately in PyGame.

 However, I think that the new site is absolutely amazing and wonderful. I
 am not an expert in making usable websites. I am just talking from my own
 personal experience after having my jaws drop at the plethora of material
 included in the site. I think that those who worked on this and actually
 did the work should be congratulated. It’s really an awesome experience to
 come to this new site and see how this project has developed.

 I would be happy to find out about things that need to be done with this
 project that perhaps I can help out with. Feel free to be in touch with me.

 Jeff

 On Aug 18, 2015, at 17:53 , Paul Vincent Craven p...@cravenfamily.com
 wrote:

 I think the site should be formed around the top use cases. I think the
 book don't make me 

Re: [pygame] Re: pygame.image.get_extended() = 0 Tried everything- should I just give up?

[Patrick Mullen]

https://bitbucket.org/pygame/pygame/issue/210/pygame-on-mac-osx-extended-image-support

What do you get when you are compiling pygame. Is it finding the jpeg and
png libraries?

On Thu, Apr 9, 2015 at 5:28 AM, JeffreyDanowitz danow...@bezeqint.net
wrote:

 I'm starting to get the idea.

 If I do not use the brew SDL then there is no SDL-config. So aha SDL will
 probably not work even though it is compiling.

 If you just drag-drop the SDL into the Frameworks, how do you make/get the
 sdl-config command? Anyone know?

 If I can do this, perhaps I can continue on...



 --
 View this message in context:
 http://pygame-users.25799.x6.nabble.com/pygame-image-get-extended-0-Tried-everything-should-I-just-give-up-tp1854p1857.html
 Sent from the pygame-users mailing list archive at Nabble.com.

Re: [pygame] Pygame_sdl2

[Patrick Mullen]

I'm looking forward to trying this out. I used your PGS4A for my pywright
engine which was pretty helpful. I've recently ported my current game to
pysfml because pygame seems like a sinking ship. I made it abstractly
compatible so I can toggle the library pretty easily, so I'll see if I can
get a build running on this to try it out. SFML is pretty good, but I've
had platform related issues. Most other attempts to make a better pygame
change the api too much - which kind of makes sense for a new project, but
having one actually be compatible would be great.

On Sat, Apr 4, 2015 at 11:42 AM, Tom Rothamel t...@rothamel.us wrote:

 I mentioned this in passing a few months ago, but I think it's time to
 formally announce Pygame_sdl2.

 Pygame_sdl2 starts with the premise that the Pygame API is important. The
 Pygame API has been used by thousands of games, libraries, and engines, and
 is being taught to beginning programmers. Preserving the Pygame API is
 important, as it means that those games, libraries, and engines will keep
 running, and those programmers' experience will not become obsolete.

 At the same time, SDL2 support is beneficial for a number of reasons. SDL
 1.2 is now obsolete, and has been for a while. New features, and ports to
 new platforms - especially the important mobile platforms - have been added
 to SDL2, and SDL2 only. For a while, I tried to add Android support by
 maintaining, as part of PGS4A, a port of SDL 1.2 to Android,
 but that proved to be very difficult as mobile platforms keep evolving.

 In October of last year, Patrick Dawson and myself began work on
 Pygame_sdl2, a reimplementation of the Pygame API using SDL2 and related
 libraries. The goal of the project is to allow games written to the Pygame
 API to run, using SDL2, on desktop and mobile platforms. We've also exposed
 some SDL2-provided functionality in a way that remains compatible with
 older code.

 At least for now, Pygame_sdl2 is available at:

 https://github.com/renpy/pygame_sdl2

 It's been used - as part of my Ren'Py engine - to release multiple games
 on Windows, Mac OS X, Linux, and Android, and I've been able to get
 Pygame_sdl2 to run on iOS, but haven't submitted to the App Store yet. This
 process, which included at least one Steam release, helped to
 shake out the more obvious problems.

 Pygame_sdl2 is written in a mix of Python, Cython, and C. Use of the
 Cython code massively simplified the project - by not having to worry about
 the details of python bindings, we were able to get the initial version of
 Pygame_sdl2 running in a short amount of time. Newly-written code is
 licensed under SDL2's Zlib license, while the code we imported from Pygame
 is licensed under the LGPL. (The LGPL's terms control distribution.)

 Pygame_sdl2 implements a large portion of pygame, but not all of it.
 Currently implemented modules are:

 * pygame_sdl2.color
 * pygame_sdl2.display
 * pygame_sdl2.draw
 * pygame_sdl2.event
 * pygame_sdl2.font
 * pygame_sdl2.gfxdraw
 * pygame_sdl2.image
 * pygame_sdl2.joystick
 * pygame_sdl2.key
 * pygame_sdl2.locals
 * pygame_sdl2.mixer (including mixer.music)
 * pygame_sdl2.mouse
 * pygame_sdl2.scrap
 * pygame_sdl2.sprite
 * pygame_sdl2.surface
 * pygame_sdl2.sysfont
 * pygame_sdl2.time
 * pygame_sdl2.transform
 * pygame_sdl2.version

 Experimental new modules include:

 * pygame_sdl2.render

 Current omissions include:

 * Modules not listed above.

 * APIs that expose pygame data as buffers or arrays.

 * Support for non-32-bit surface depths. Our thinking is that 8, 16, and
 (to some extent) 24-bit surfaces are legacy formats, and not worth
 duplicating code four or more times to support. This only applies to
 in-memory formats - when an image of lesser color depth is loaded, it is
 converted to a 32-bit image.

 * Support for palette functions, which only apply to 8-bit surfaces.

 There are a few additions to the pygame API, including support for the
 application lifecycle events on Android and iOS, IME-based text input, and
 SDL2 renderers.


 While I plan to, at the very least, maintain this indefinitely to support
 Ren'Py, my hope is that it could be useful to the larger Pygame community.
 For now, Pygame_sdl2 could probably benefit from testing, both informal
 reports of missing APIs and incorrect implementations, and someone helping
 to integrate the relevant portions of the pygame test suite.

 The modules that have not been implemented are often that
 way because we don't have much experience with them - for example, I've
 never been able to wrap my head around the thingarray modules. So help
 implementing those, or porting the Pygame implementations, would be
 appreciated.


 For now, pygame_sdl2 has been maintained as part of the Ren'Py github
 organization, but if there's enough interest in contributing and expanding
 it, it might make sense to break it out into its own project.

 Anyway, thank you for reading through this message, and for trying out
 pygame_sdl2.

Re: [pygame] Feature discussion, proposals

[Patrick Mullen]

The thing is, hardware makers tend to strive to optimize the most used
paths. I don't have any internal knowledge of modern hardware, but
following this logic, 32 bit blitting may actually be the most optimized as
it is the most common method of rendering. By using convert(), you let the
hardware decide which path it thinks is the most optimized.

On Wed, Mar 18, 2015 at 4:13 PM, Mikhail V mikhail...@gmail.com wrote:

 On 18 March 2015 at 23:05, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
  Mikhail V wrote:
 
  1. It turns out that 32 bit surfaces is an overkill in most cases. Good
  that there is 8 bit mode.
 
 
  What evidence do you have of that? Have you done any
  benchmarking?

 Evidence of what? I ment, almost all the time I don't need so much
 bits per pixel, unless I want to see realistic photography. Many
 programs I wrote exploit index processing only. rgb encoded formats
 just don't apply for most algorithmically created image and
 processing, regardless of performance or 'realism'.
 And less bpp should be faster memory to gpu memory transfer, I
 imagine? If my source is say 4 bits per pixel then converting it every
 cycle to rgb  and transfering it per 24 bpp stream format is not the
 best practice.

 Mikhail

Re: [pygame] informal poll on Windows python version

[Patrick Mullen]

windows 7 64bit, 32 bit python 2.6, pygame 1.9.1

Also had python2.5 installed alongside 2.6 for a while, but I can't remember
the last time I ran it. Occasionally I check to see if my programs run in
old versions.

Re: [pygame] Re: GSOC project proposal: Finishing the movie module

[Patrick Mullen]

I would love to see this!

On Sun, Mar 7, 2010 at 8:00 AM, Tyler Laing trinio...@gmail.com wrote:

 Oh another critical bug: a lack of subtitle support! (Well, critical to me)

 -Tyler


 On Sun, Mar 7, 2010 at 7:46 AM, Tyler Laing trinio...@gmail.com wrote:

 Hello all!

 So I am applying again this year, to properly finish my project last year.


 The movie module was largely finished in last year's GSoC project,
 however, it wasn't quite ready for release, with a few bugs and not
 compiling on windows.

 My proposal is to fix up those bugs, get it compiled on windows and polish
 it up for general release.

 The bugs were if I recall correctly:
 -Sometimes desyncs
 -memory leaks
 -slow performance for SDL screens.
 ...various other as-yet undiscovered bugs

 In addition, I'd be able to fix and complete the alternative video
 players.

 Thank you in advance,

 --
 Tyler Laing
 Science and Tech Editor
 The Phoenix Newspaper
 (1) 250 863-4869

 University of British Columbia - Okanagan
  University Way
 Kelowna, BC UNC 109
 Student Services Building




 --
 Tyler Laing
 Science and Tech Editor
 The Phoenix Newspaper
 (1) 250 863-4869

 University of British Columbia - Okanagan
  University Way
 Kelowna, BC UNC 109
 Student Services Building

Re: [pygame] Problem with simultaneous key presses

[Patrick Mullen]

Using keymapping is always a good idea; besides allowing users to change the
keys or get around the keyboard problem, you also make it easy for you to
change the default controls if you feel they don't work anymore. Plus, it is
easier to code with them - you don't have to remember which key does
something, if keys[MOVE_LEFT] is more descriptive than if keys[K_a].

On Tue, Feb 9, 2010 at 6:21 PM, Kris Schnee ksch...@xepher.net wrote:

 On Tue, 9 Feb 2010 07:52:07 -0800, B W stabbingfin...@gmail.com wrote:
  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. :)

 Yeah, it's a problem some of us have encountered before, and it seems to
 vary by keyboard so you can't easily plan around it. How about reading a
 text file on startup, of the form:
 move_l: k_leftarrow
 jump: space...

Re: [pygame] frame independant movement

[Patrick Mullen]

The nice thing about limiting the framerate versus having calculations be
done based on time passed is that it is much more consistent. With dt
calculations you will often get huge jumps on slower computers and extra
slow movement in cases on fast machines, just do to inaccuracies and error
in the calculation.  On a slower machine, no matter which timing method you
use it will be unpleasant.

One method for having a smooth variable framerate, without the issues of
variable time calculations, is to have a fixed time step. Each frame, you
may process more than one timestep, if you need to in order to keep up. The
timestep has a fixed amount of time it is supposed to similate, say, .02,
which would be 60 times per second. If the user is able to run at 60 fps,
they get very smooth animation, as only one step is occuring on each frame.
If the user can only run at 30 fps, they will get two steps each frame, so
it will be jerkier, but still accurate. If they can only run at 10 fps, you
would set a limit on it (maybe the max is two timesteps in a frame), so
things would be slower for them but maybe still playable.

def dostuff(dt):
   man.x += speed*dt

GAMESPEED = .02

while 1:
   dt = clock.tick()
   max=2
   while dt0 and max:
  dt -= GAMESPEED
  max -= 1
  dostuff(GAMESPEED)

There might be other problems with this, I've never done it this way, only
seen it referred to. I know in some engines, like doom3, the physics of
everything, game logic etc, happens at a fixed 30hz rate; whereas animation
of the scene is much smoother.

I am usually lazy and just do clock.tick(30) lol.

Timing gets even more interesting when you do multiplayer, then you are
dealing with different time rates for each player. Fun stuff :)

On Wed, Feb 3, 2010 at 3:38 AM, René Dudfield ren...@gmail.com wrote:

 On Wed, Feb 3, 2010 at 7:06 PM, DR0ID dr...@bluewin.ch wrote:
  On 03.02.2010 11:25, inigo delgado wrote:
 
  Another thing you can do is just use Clock to limit the FPS to 60 or
  something, but then your game will run slower if you're not getting 60
 fps.
 
  Well, true, but you MUST determine the framerate that  you want for your
  game, otherway you will get a 60 FPS in your PC, 70 in another and 120
 in
  another one that is much more faster/newer than yours and in witch your
 game
  will turn unusable at this framerate
 
  I do this:
 
  while(true): #principal loop
 # get current time
 t = time.time()
 
 doAll()
 
 #At the end i get the time needed to do the calculatons  flip
 T = t - time.time()
 delta = T - 1/desiredFrameRate
 if (delta  0): # if the cycle has been done too fast
 time.wait(delta)
 This way you have your desired framerate or the maximum possible.
  Additionally you can do this:
 else:
 GLOBAL_T = GLOBAL_STANDAR_T - delta # delta is = 0, - and - is +
 
  Being GLOBAL_T the t that you use for your position calculations and
  global_standar_t the value of global_t if delta is 0.
 
  Hi
 
  You will get different framerates only if you don't limit the fps. Using
  http://www.pygame.org/docs/ref/time.html#Clock.tick you will have always
 the
  specified framerate except if the cpu can not keep up (then it will run
  slower), but on faster machines tick will wait, similar to what you do
 (tick
  might be more accurate).
 
  ~DR0ID
 


 Just another note... use Clock.tick_busy_loop if you don't mind
 burning a bit of cpu to get far more accurate sleeping.  The OS sleep
 is often a bit random - and not really meant for accurate sleeping.


 cu,

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

[Patrick Mullen]

On Tue, Feb 2, 2010 at 9:27 AM, B W stabbingfin...@gmail.com wrote:

 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


Of course the big downside to mixer.music, is that you can only have one
file loaded at once. This is bad if you want to mix :) Then you have to use
sounds, and suffer the loading issues.

[pygame] pygame.image.save corrupts surface in memory

[Patrick Mullen]

Problem: When calling pygame.image.save(colorkey_surface, surf.png), the
colorkey_surface in memory loses the color_key information.

Workaround: I call the set_colorkey function after the save

It's not a big issue, but I wouldn't expect that saving an image should
affect the actual surface being saved.

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

[Patrick Mullen]

I like this idea. Ever since I can remember I have always used a
similar method for distribution of my games. I went through the py2exe
pain once, creating a minimal setup.py that would import all of the
dependancies I need, along with some fine tuning to eliminat stuff
that it always pulls in that I never actually need, recompressing
things with better compression, etc. But the actual game code is run
from a separate directory. It means I never have to run setup.py again
to release new versions, just pop new source files in there and it's
done. (And patch using the same patch files on multiple platforms!)

It wasn't very well planned or thought out, nor had as many targets as
you are going for, but I think this is something that should be
available to people. It's a missing piece of the puzzle. Ok, I
learned all this stuff. How do I distribute my game? py2exe? setup.py?
WHAT?

Some issues:
Not only do you have to target different OS, but when making a general
launcher, you have to think about the various versions of python. So a
separate set of launchers for each python. Not a big deal probably,
you download the launcher set for the python you are using. Just can't
forget it. Probably 2.5 and 2.6 are the only important targets at the
moment. Does any game lib work on 3.0 yet? Probably not enough at the
moment to worry about it.

Also, different versions of libraries. Probably using the most stable
version available by default is fine. But I know of a few cases where
the right version of a library is not constant across platforms. I
can't remember what those cases are but I've run into it :P Probably
not as much of an issue, as long as it is easy for people to add
libraries that are on systems they don't have access to.

Also, I'm confused. You say that it should include useful libraries,
but not pygame, because pygame is too big? I would think pygame is one
of the most important things to include. It doesn't really matter how
big the toolkit is, as long as the resulting zip file are as small
as they can be. Libraries not needed can be deleted from the result,
or maybe the build function can take a list of libraries used. The
py2exe method of guessing libraries doesn't really work that well.

I think it's wise to not focus on the it could be like steam!
aspect. If that comes as a result, so be it, but it's somewhat beside
the point. I still expect a lot of people would wind up only making a
windows release or using py2exe thinking it hides their source, but
probably less if there was something like this available. Lol.

Hope this works out.

On Tue, Dec 8, 2009 at 10:54 AM, René Dudfield ren...@gmail.com wrote:
 Hi,

 I've been working on plans to make distributing games easier.  So
 people can more easily let their friends and families play games they
 have made.

 Part of this plan is to make binary creation easier(zip files
 containing your game for each platform specifically).

 The current situation is that people need to get py2exe py2app,
 cx_freeze and other modules setup, and working in their setup.py file.
  Then they have to adjust things for how their game works, and then
 get access to every platform.  Unfortunately each of these things
 changes occasionally, so old setup.py files do not work for other
 people.  This results in people not making binaries for every
 platform, and makes it hard to share games with your friends and
 family.

 So the plan is to make our lives easier creating distibutables for
 every release of some game we make.



 Basic idea:
 ===

 To be able to copy your game into a directory for each platform and
 your job be done.
     `cp -r YOUR_BITCHIN_GAME game_launcher_macosx/games/`
     `cp -r YOUR_BITCHIN_GAME game_launcher_win_x86/games/`
     etc...

 Then you can zip up that directory and send it to a friend.  There
 will be a python module available to automate this stuff.



 Make a game_launcher package for each platform.
 ===

 Where this bundle would be something like:
   - game_launcher_macosx
   - game_launcher_linux_x64
   - game_launcher_linux_x86
   - game_launcher_linux_arm
   - game_launcher_win_x86
   - game_launcher_win_x64
   - game_launcher_win_symbian

 That is have a directory with binaries for each platform.

 Then you can easily make your game work for that platform by copying
 your game files into a directory like this:
     `cp -r YOUR_BITCHIN_GAME game_launcher_macosx/games/`

 Your game would have to have a run_game.py script which calls your
 games main function and starts up.



 Libs.
 =

 Most commonly used python game libs would be included (numpy,
 pyopengl, pyaudio, PIL etc).

 These generic bundles would have many of the common modules used for
 making games included.  You can just copy in any other libs you need.
 If the module requires platform specific code, then that can either be
 made independantly or otherwise.


 It would allow people to create 'game_launchers' for 

Re: [pygame] Ncurses RTS?

[Patrick Mullen]

There also is a pygame port of curses, in some state of completion, if
you google around for it.

On Sun, Dec 6, 2009 at 5:55 PM, James Paige b...@hamsterrepublic.com wrote:
 On Sun, Dec 06, 2009 at 05:34:30PM -0800, Yanom Mobis wrote:
    I know this doesn't actually involve pygame, but I was wondering if it
    would be possible to use the Python Ncurses module to make a realtime
    strategy game. Something in the vein of dwarf fortress (you can see
    screenshots at: http://www.bay12games.com/dwarves/screens.html ), but more
    of a traditional RTS than a rougelike/citybuilder game.

 I am sure you could, but one word of warning is that python's standard
 curses module doesn't have a Windows version last time I checked
 (*checks again, yep*)

 There is a wcurses work-alike module that you can find, although IIRC it
 has some minor differences that you will have to keep in mind if you
 want your game to work cross-platform.

 Gosh I love/hate Dwarf Fortress :)

 ---
 James Paige

Re: [pygame] State of the math branch

[Patrick Mullen]

I think there are many cases where one might want, say, the halfway
rotated quat between two, or due to varying framerates with things
like network code, (or even just for animation purposes) you might
want to have varying rates, or skip to a different t value. I don't
see how an iterator would be useful in these cases. You would have to
do a 2 step rotation once to get the midway rotation, iterating an
iterator once is pretty unintuitive; and for varying speeds during a
rotation, you would need to recalculate a new iterator every frame.

I haven't looked at it, but intuitively it seems to be trying to wedge
one concept into a very different one. If there were only one
implementation, I would much prefer the t version.

On Sat, Nov 14, 2009 at 11:06 AM, Lorenz Quack d...@amberfisharts.com wrote:
 Hi René,

 René Dudfield wrote:

 Feel free to merge it into the trunk.  It'll be easier for other
 people to try it out(binaries, and other things hooked up with trunk),
 and you can also use the build bot to check for errors on other
 platforms(like compilation/testing).

 Ok. I'll see if I can make it this weekend.

 The (s)lerp idea with the iterator seems a good one.  I've been
 thinking about doing something like that with line drawing
 functions... that instead of drawing return the (x,y) coords of where
 it would draw pixels.  I wonder if it still might be useful to let
 people supply a t argument, just because people are used to it...

 My hope is that the iterator is intuitive enough so nobody will miss the
 t-version. also my version should perform better because it only
 calculates a rotation-matrix once while otherwise you would have to
 recalculate it on every call for the new t-value.
 So for now I would stay with:
 There should be one-- and preferably only one --obvious way to do it.
 and wait and see if there is strong demand for a t-argument version.

 However, they could just supply one step.

 unfortunately I don't think it's that easy to convert from the iterator
 interface to the t-arg interface. you would have to something like this:

 def slerp_t(start_vec, end_vec, t):
    idx, steps = t.as_integer_ratio() # new in python 2.6
    return list(start_vec.slerp(end_vec, steps))[idx]

 which is pretty ugly.

 I guess there is going to be a 4 element quaternion?  What about a
 Vector4?  Which matrix sizes are you thinking of doing?  I guess 3x3,
 3x4 and 4x4?  Or just 4x4?

 I was planing on implementing quaternions and only square matrices.
 Is there a use for Vector4? Implementing it would be quite easy but
 do we need it?
 Also, what would be a use case for non-square matrices?

 I noticed one commit log said there was trouble with the buffer
 interface?  Is this part still a trouble?

 Yea. I didn't really understand which parts of the buffer protocol belong
 to the 2.x protocol and which belong to 3.x and what should be supported.
 In general I found this topic a bit confusing and the docs didn't help.
 I have to look into that some other time when I've got the nerve for it.

 Functions like vector_elementwiseproxy_mul,
 vector_elementwiseproxy_sub etc, could probably share a lot of code,
 and then for the different part use a switch statement to do the
 different function.  Something like this:

 static PyObject *
 vector_elementwiseproxy_mul(PyObject *o1, PyObject *o2) {
    return vector_elementwiseproxy_generic(o1, o2, VECT_OPS_MUL);
 }

 Where the vector_elementwiseproxy_generic function would have the
 switch statement on the various flags passed in.

 I'll take a look at it.

 thanks for the feedback. looking forward to more of it :)

 yours
 //Lorenz


 On Thu, Nov 12, 2009 at 10:31 AM,  d...@amberfisharts.com wrote:

 Hi List,

 I just wanted to give you a short summery of the development in the math
 branch.
 The goal of the math branch is the inclusion of several math related
 types
 like vectors, matrices and quaternions.

 Right now I consider the implementation of vectors in 2 and 3 dimensions
 as
 feature complete.
 What this means is that I can't think of more functionality that I want
 to
 implement and all methods pass their unit tests.
 I encourage everyone interested to take a look and make suggestions if
 they
 find functionality missing.

 The current version is not written for maximum performance.
 For example Vector2 and Vector3 share many functions so no dimension
 specific
 optimizations are implemented. So the current implementation should be
 considered a baseline for future optimizations.
 To gauge future improvements I intend to write a rudimentary performance
 benchmark.

 I don't consider the API to be set in stone. Especially concerning
 mutability. Currently vectors are mutable.
 If however it turns out that there is no significant performance hit in
 making them immutable I tend to do so.
 Obviously this will only happen once I have some performance results.

 After that Matrices will be up next.


 thanks for your time and suggestions.

 //Lorenz


 PS: 

Re: [pygame] Python IDE for windoz

[Patrick Mullen]

The main reason I don't use IDLE is because I have had issues in the
past with it's runner locking things up. Also editing more than one
file at a time is a bit painful. I switched to SciTE for non-ide
programming after about 2 years of using IDLE and never looked back.
That said, IDLE is more competent than it is often given credit for.

I definitely agree with you about some IDE features being overkill and
slowing things down instead of speeding them up.

On Sat, Oct 10, 2009 at 11:49 AM, Ian Mallett geometr...@gmail.com wrote:
 I came to the conclusion that IDEs are designed to make your life easier by
 pinpointing bugs, adding breakpoints, compiling nicely, etc.  I use IDLE
 because it doesn't have any of that--it's just a compiler and a
 text-editor.  I don't have trouble; I think not having spiffy features
 encourages one to write better code in the first place.

Re: [pygame] duplicate images

[Patrick Mullen]

You actually can still share the same image between sprites:

image = pygame.image.load(image.py)
s1 = Sprite()
s1.image = image
s2 = Sprite()
s2.image = image

They have the same image but can be placed in different groups, or put
at different places.

On Fri, Oct 9, 2009 at 9:02 AM, Thiago Petruccelli
thiagopetrucce...@gmail.com wrote:
 Thanks everybody! Problem solved.

 I couldn't just blit the same img in different objects because they're
 contained in sprite.Groups (OrderedUpdates). Every image in my game is in a
 class that extends Sprite. But the copy command of the image solved the
 problem.

 thanks everybody =)
 --
 Thiago Henrique Petruccelli


 On Fri, Oct 9, 2009 at 3:09 AM, Jake b ninmonk...@gmail.com wrote:

 How are you handling the windows. ( Do you have a class that stores its
 location? )
 It sounds like what happens if two variables point to / and modify the
 same object.
 [ Whereas you want the same image, but different location ]

 You can create a new sprite object, for every unit. But you are able to
 load it's image one time, shared among 100 (or more) units on screen.

 Or you can skip using SpriteGroup()'s entirely, by just blitting the
 surface at a location. ( like RB[0] said ).

 Here are a couple tutorials that may interest you:

 pinman's sprite group tutorial:
 http://www.sacredchao.net/~piman/writing/sprite-tutorial.shtml

 pygame.org's  sprite group tutorial:
 http://www.pygame.org/docs/tut/SpriteIntro.html

 and pygame.org's Sprite documentation:
 http://www.pygame.org/docs/ref/sprite.html

 example shows how you draw multiple sprites with one image.

 Psuedo-code example 1
 close_img = pygame.image.load(close.png)
 windows = [ Window(), Window() ] # two windows, wiih defaults

 # for every window
 for current in windows:
     x,y = current.location()
     screen.blit( close_img, (x,y) )


 # ==


 This second example is taken from piman's tutorial: If you want to load
 the image the first time the class is instantiated, and every instance uses
 the first image, you can do this.

 real code: example 2
 class MySprite(pygame.sprite.Sprite):
     image = None

     def __init__(self):
     pygame.sprite.Sprite.__init__(self)

     if MySprite.image is None:
     # This is the first time this class has been instantiated.
     # So, load the image for this and all subsequence instances.
     MySprite.image = pygame.image.load(image.png)

     self.image = MySprite.image


 # ==

 # Then you could have code like this:

 # ==

 # load map
 units = []
 units.append( Wolf() )
 units.append( Troll() )

 # draw
 for unit in self.units:
     unit.move()
     unit.draw()

 # your loading and drawing code is now defined inside class Wolf() and
 class Troll().
 # You could even write a wrapper, so that you can do something like this:

 class Unit(pygame.sprite.Sprite)
     # base class.
     # ... like the above MySprite class, but adds a filename as argument.
     # also can handles locations, movement, and .draw() that all units
 need
     def __init__(self, filename ):
     # ... code snipped, saves to variable class.

 # Wolf uses default blit, movement, attack, etc... functions
 # only needs to define image.
 class Wolf(Unit):
     def __init__(self):
     Unit.__init__(self, wolf.png)

 # troll draws extra ontop of default
 class Troll(Unit):
     def __init__(self):
     Unit.__init__(self, troll.png)
     def draw(self):
     #overwrides default blit, here.

 see also: cookbook: sprite sheet.
 http://www.pygame.org/wiki/Spritesheet?parent=CookBook

 hope that helps :P
 --
 Jake

Re: [pygame] duplicate images

[Patrick Mullen]

On Thu, Oct 8, 2009 at 11:56 AM, Thiago Petruccelli
thiagopetrucce...@gmail.com wrote:
 Hi!

 I am using windows(ugh) in the interface of my game, and then I made a close
 button. My game structure load all images in the startup of the game; but
 when I try to copy then, things don't work as I wanted... when I close a
 window and open another (wich is supposed to have a copy of the close button
 with his own properties), it happens that the close button appears in the
 old place, not in the right place in the opened window. I tried to use de
 copy command from the copy module, but it didn't work. It seems that python
 thinks it's the same object; I want to make a duplicate of it.

The copy module is a brute force copy method that doesn't know any
implementation details of what it tries to copy. It should be used
rarely, if ever (I've never used it).

Pygame images have their own copy method to use if you need to make a copy.

#The original image
close_image = pygame.image.load(close.png).convert()

#Make first close image
window_close1 = close_image.copy()

#Make second close image
window_close2 = close_image.copy()


The rest of your discussion of the problem doesn't make much sense to
me, but this is how you copy images in pygame. Hope it helps. As RB
said, if you just want the same image to be blit in different
locations, a copy is not needed at all, you can blit the same image to
different locations.

Re: [pygame] Python IDE for windoz

[Patrick Mullen]

Well, it's far too late to solve the OP's problem, but I am going to
double vote my choices of SciTE (when I need an editor for a file
fast, or just don't want to deal with an IDE, which is actually pretty
often) and netbeans which has some really killer tools. (The test
coverage and mercurial integration are pretty slick)

On Wed, Oct 7, 2009 at 4:27 PM, Jake b ninmonk...@gmail.com wrote:
 I like geany and / or scite. [ Scite's not an IDE, but worth mentioning. ]

 On Tue, Oct 6, 2009 at 7:04 PM, pierrelafran...@sympatico.ca
 pierrelafran...@sympatico.ca wrote:

 Hi
 I have administrator rights on a computor in a lab at work, until
 tomorrow.  I would like install IDE for Python. What do you suggest me ?

 I know, I may not write this question in the good room, but I just learn
 this news, and after tomorrow, it will be too late to install Python.

 Thanks
 --
 Pierre



 --
 Jake

Re: [pygame] ANNOUNCE: pygame 1.9.1 released.

[Patrick Mullen]

I think it's the ascii art at the top!

On Fri, Aug 7, 2009 at 10:43 PM, René Dudfieldren...@gmail.com wrote:


 On Sat, Aug 8, 2009 at 6:56 AM, Ian Mallett geometr...@gmail.com wrote:

 Hi,
 I've been getting this issue too--I meant to tell René when I got a
 chance.  It's only a problem with these release announcements.  Are these
 automatically generated/sent from a different address?
 Ian

 Maybe it's because there's lots of links and html in the email.  Also the
 email was similar for each of the rc releases... so maybe gmail saw that
 too.

 oh well.

Re: [pygame] Midterm report for Movie Module

[Patrick Mullen]

Sounds great Tyler, it looks like it's about equal to the current
version, plus the support for more than just mpeg, which is good
enough for my purposes.  Seeking and subtitles would really put it
ahead of anything else.  Thanks so much for taking this project on!

On Fri, Jul 17, 2009 at 7:48 AM, Tyler Laingtrinio...@gmail.com wrote:
 Hi everybody,

 What the movie module is capable of doing right now is:
 -Video
 -Audio
 -resize the screen
 -pause, unpause
 -stop
 -play, with a loops argument that works just like the one in mixer
 -get, set, surface support


 So we have basic functionality so far for it. There is also a vlc
 backend, that refuses to work properly, except once in a blue moon...

 There are some issues, effectively unsolvable with it right now. If
 you use a surface to blit the frames to, and try to resize smaller,
 you end up with visible corruption. Very, very rarely does the sync
 between video and audio not quite work. There are also some formats on
 some computers that will cause crashes, but on others, they will work
 fine. I have no idea what makes a difference on different computers,
 but I suspect slightly different ffmpeg libraries.

 My plan for the future is to:
 -support the location of later ffmpeg libraries, which were changed
 after v0.5 to go into ffmpeg/lib*
 -seeking
 -subtitle support(this is nearly done... I just need to take the text
 packets and figure out how to display them on overlays. For surfaces,
 its easy, just use sdl_ttf, so if anyone has any ideas, let me know!)
 -add filepath expansion
 -callback for returning an image buffer
 -callback for returning a sound  buffer
 -document code further
 -add mplayer backend

 Thank you guys for this opportunity, it has been a fun couple of months so 
 far!

 -Tyler
 --
 Visit my blog at http://oddco.ca/zeroth/zblog

Re: [pygame] Pygame and mp3 files

[Patrick Mullen]

Couldn't ffmpeg be used for the mp3 support, at least on systems where
ffmpeg supports mp3's?

On Tue, May 19, 2009 at 2:51 PM, Lenard Lindstrom le...@telus.net wrote:

 Hi Yanom,

 Actually on Unix it will be optional. If the smpeg package is installed
 Pygame will have limited mp3 support, though with the possibility of
 crashing. mp3 is also supported in the official Windows distributions. And
 it doesn't crash. But mp3 support on Windows means building and including
 smpeg with Pygame. Since smpeg is slow to change and the DLLs are already
 built it will costs nothing to keep them in the distribution. Just don't
 expect an up-to-date smpeg version.

 Lenard


 Yanom Mobis wrote:

 it could be an optional part of pygame, so you would have to:

 sudo python setup.py --with-mp3 install
 --- On *Mon, 5/18/09, Lenard Lindstrom /le...@telus.net/* wrote:


From: Lenard Lindstrom le...@telus.net
Subject: [pygame] Pygame and mp3 files
To: Pgame Mail List pygame-users@seul.org
Date: Monday, May 18, 2009, 3:56 PM

Hi,

Since switching to Debian Linux to develop Pygame for Python 3
I've found the mixer_music_test.py unit test fails with a memory
access violation. Something about the house_lo.mp3 file included
in the examples, maybe the 11025 Hz sample rate, causes smpeg to
misbehave. smpeg will happily play other mp3 files, but not this
one. The problem I am running into is that mp3 is a proprietary
format. None of the tools readily available to me will write an
mp3 file. And I am not inclined to custom build tools with mp3
support just to chase down this problem.

So this brings me to the point of this post, to propose
deprecating mp3 support in Pygame starting with Python 1.9.0.
ogg-vorbis support is widely available, and FLAC support should
become more wide spread (the Windows build already has it). This
is not to suggest mp3 support should be immediately cut off. But
with a new ffmpeg based movie module in the works there is little
other reason to keep smpeg as a dependency. Without an mp3
requirement smpeg can be turfed once and for all, since the
existing movie module was never reliable anyway. Of course mp3
support will not completely go away. For systems where SDL and
other dependencies are provided as separate packages smpeg can
always be included. But for Windows, were custom built
dependencies are used, it would be omitted.

Any thoughts.

Lenard

Re: [pygame] Networking library

[Patrick Mullen]

Python2.6 comes with json.  Other than that, it is a small thing to include.

The library seems to be built around json, so removing it as a
dependency doesn't make much sense.

I took a look at this library when you announced it and thought it
looks good, but I haven't had a chance to really try it out.

The whiteboard example is very impressive!  It looks a lot easier to
start working with than twisted.

Re: [pygame] A* module using surfaces for walkability data

[Patrick Mullen]

This seems to be only usable in specific situations - can only be used
in a 2d euclidean map.  A* is usable in so many other ways I would
want a module within pygame to be more general and able to be
configured to work in many very different situations.  On the other
hand, it sounds like it is well optimized, and having an a* module is
better than not having one.  Perhaps a general version could use this
for situations where it makes sense, and fall back to something else
for other situations?

A* is not hard to write for each game, but it can be annoying, and in
pure python can be pretty slow, so an optimized version available for
all games that need it would be great!

 On Sat, Mar 28, 2009 at 12:07 AM, Yanom Mobis ya...@rocketmail.com wrote:
 building it in to pygame wouldn't be a good idea- it would take up space
 even if you didn't use it. After all, modularity is the soul of python.


I almost never need cdrom, or cursors, or many of the other pygame
modules, but it is nice that they are there.  AI is a little bit new
for pygame, being outside of the scope of input/output, but there has
been talk about a possible ai module for a long tme.  A* should be the
first thing there, since it is the most solved ai problem, and one of
the most commonly needed modules.

On Mon, Mar 30, 2009 at 3:49 AM, Frozenball orkkiole...@gmail.com wrote:
 I doubt text (code) will take much space?


It seems pretty small at that.

Re: [pygame] how to bind surface rects without subsurface (need help with bug)

[Patrick Mullen]

On Mon, Mar 9, 2009 at 10:31 PM, Michael Fiano michael.fi...@gmail.com wrote:
 I realize my code isn't the best code there is, but it's also my first
 programming project and I've been teaching myself all sorts of things
 as I go. But, could someone please take a look at code and
 tell me why the foreground isn't aligned when scrolling? To reproduce,
 you'll have to move the player toward the right side of the screen
 until it scrolls the map, and while it does pay attention to the huge
 trees and other foreground objects such as the tall grass.

Sure.  I love looking at other peoples code for problems.  (Honestly,
it's a lot more fun than trying to find problems in code I wrote)

This was hard, because while your code is not bad per say, there is a
lot of indirection, and much overengineering going on.  There are too
many strong connections between classes (like the player having to
know about the background and the foreground), and this coupling makes
it very inflexible.

In this case, the problem is simply a matter of ordering.  The
background is updated, then the player, then the foreground.  When you
start scrolling the screen (from the player update), the background
has already run it's update for that frame, while the foreground gets
to run its update with the move command.  So it is a frame ahead of
the background.

In scene.py, if you change the order that objects are updated:

self.render.add(self.map.background)
self.render.add(self.map.foreground)
self.render.add(self.player)

Then the player will set up the scrolling for the next frame, which
fixes the problem.  A better way to do cameras, instead of having it
happening in the player movement function, is to have a separate
camera update that scrolls the right direction at a maximum speed
until whatever it is focused on is within some region of the screen.
That way if you start the player offscreen, the camera will still be
able to find him.  Also, for cutscenes, you can have the camera focus
on a different character than the player fairly easily.

Another thing that bugged me: It seems weird that you have limited
yourself to only two layers in the code, when any number of layers
would actually be easier.  A map.move() function, which moves all of
its layers by a set amount, means one less line all of the places you
have to write background.move... foreground.move, and would also
solve the above problem (because the movement happens instantly
instead of waiting for some update).  And in the map, instead of
having background, and foreground, you could simply have layers[].  In
the future, when you want to add a paralax treeshadow layer to display
on top of the player and npc's, you will be hitting yourself at all of
the places you will have to add the new layer.

Good luck with the game, the sprites/tiles look really nice, and the
code isn't all bad :)

Re: [pygame] how to bind surface rects without subsurface (need help with bug)

[Patrick Mullen]

Yep, changing the layer order is just a quick fix, not a real
solution.  You can keep the layer order you had before, and add a
move_layers function to the map.  Give the player a reference to the
map instead of the two layers, and call move_layers in the spots you
are setting the background.move and foreground.move.  Map.move_layers
would look something like this:

def move_layers(self, amount):
for layer in [self.background, self.foreground]:
layer.dirty = 1
layer.rect.move_ip(amount)

Actually, it might be even better to just make move a function instead
of an attribute on TileLayer.  You will have to change less code (but
will still have the ugly bg/fg references in player).

class TileLayer(pygame.sprite.DirtySprite):
def __init__(self, screen, layer, w, numx, h, numy):
self.screen = screen
pygame.sprite.DirtySprite.__init__(self)
if layer == 'fg':
self.image = pygame.Surface((w*numx,h*numy), SRCALPHA, 
32).convert_alpha()
else:
self.image = pygame.Surface((w*numx,h*numy)).convert()
self.rect = self.image.get_rect()

def move(self):
self.dirty = 1
self.rect.move_ip(self.move)

Then in player you would say:
self.background.move([self.movement, 0])
self.foreground.move([self.movement, 0])

etc.  Instead of assigning to those values.

The real problem is that you are delaying an action until the update
functions when it is really (in this case) an in-place action.

Re: [pygame] Fade to black question...

[Patrick Mullen]

On Tue, Mar 10, 2009 at 8:32 AM, Ty ... ty.sql...@gmail.com wrote:
 I'm trying to get a fade to black working, to that end I've written a
 simple program just to try it out... the (partial) code looks like
 this:

 self.screen.fill(white)
 self.screen.blit(self.image, self.size, self.size)
 print self.screen.get_at((4,4));
 self.screen.fill((2,2,2), None, BLEND_SUB)
 print self.screen.get_at((4,4));
 self.screen.fill((2,2,2), None, BLEND_SUB)
 print self.screen.get_at((4,4));
 self.screen.fill((2,2,2), None, BLEND_SUB)
 print self.screen.get_at((4,4));
 sys.exit()

I think maybe you want BLEND_MULT instead of BLEND_SUB?  I don't know,
I rarely use flags.  What I would do for fade to black is create a
black surface, and call set_alpha() on the surface with an increasing
alpha value on each frame, and blit it.

Re: [pygame] Bliting clip semantics

[Patrick Mullen]

Arguably, the best solution for laaarge numbers of sprites is to use
some kind of space partitioning scheme to keep the checking code fast
and also not force sdl to try to render everything either.  Once you
get to this level of optimization, things can get a little hard to
deal with.

In the original case, checking before blitting is probably overkill,
and slower to boot.

On Wed, Feb 18, 2009 at 4:52 PM, Zack Schilling
zack.schill...@gmail.com wrote:
 I found that for a large number (100+) of small sprites, blitting everything
 and letting the blit function figure out if things are onscreen is much
 faster than coding up checks in python, especially if the checks go down to
 the pixel level for sprites partially offscreen.

 -Zack


 On Feb 17, 2009, at 10:49 PM, Hugo Arts wrote:

 you can blit something that is not on the screen or even half on the
 screen without problems. It will work as expected

 On Tue, Feb 17, 2009 at 8:55 AM, Daniel Mateos dan...@mateos.cc wrote:

 Hey All,

 I was just wondering if i can count on Surface.blit dealing with stuff i
 pass it that has co-ords greater than its drawable area like say i pass
 a rect of [200, 195, 10, 10] to a surface of size [200, 200].

 I ask because i notice it is working right now as expected with a
 function i use that only roughly checks if something is on the screen or
 not before it is blited and im not sure if i should bother to make it
 more accurate.

 Daniel

Re: [pygame] Re: Python path problem in vista?

[Patrick Mullen]

I get that error if I run from IDLE... But if I run it any other way
there is no problem.  IDLE is screwing up the __file__.  Don't know
why IDLE thinks it's OK to do that, but there it is.

On Tue, Feb 10, 2009 at 2:48 AM, Thiago Chaves shundr...@gmail.com wrote:
 Can anyone in the list also reply if they do NOT get problems running
 programs with skellington-compliant structure on Vista? So far I've
 got only one person informing of problems executing the program and
 I'd like to hear if that's widespread or not.

 -Thiago

 On Sun, Feb 8, 2009 at 10:02 PM, Thiago Chaves shundr...@gmail.com wrote:
 Hi,

 recently I was informed that my most recent project is not running
 properly in Vista. I'm using the skellington structure suggested by
 Pyweek administration and I'm wondering if that's somehow related.

 File structure for the project (as far as it is relevant to this post):
 ssof/run_game.py
 ssof/lib/main.py

 run_game.py's contents:

 
 #! /usr/bin/env python

 import sys
 import os


 try:
__file__
 except NameError:
pass
 else:
libdir = os.path.abspath(os.path.join(os.path.dirname(__file__), 'lib'))
sys.path.insert(0, libdir)

 import main
 main.main()
 ___

 User feedback:

 Alright then,
 Open fully-updated Windows Vista. Open IDLE. Python version number is
 2.5.2. Open run_game.py. Hit F5 (runs the script).
 Traceback (most recent call last):
 File C:\Users\Andy
 Hanson\Desktop\ssof-2009-01-31-fixed\ssof_alpha4\run_game.py, line
 15, in module
 import main
 ImportError: No module named main

 This is certainly a very simple problem!

 

 Any thoughts? What am I doing wrong here?

 (I'm attaching run_game.py just in case the formatting gets messed up)

 -Thiago

Re: [pygame] Pathfinding

[Patrick Mullen]

On Wed, Jan 28, 2009 at 4:09 PM, Yanom Mobis ya...@rocketmail.com wrote:
 ...
 I'm just going to make my game tile-based, I guess.


Just a tip: you can have tile-based pathfinding without tile based
graphics.  And the tiles don't necessarily have to be the same size as
you might think of when you think tile.

It depends on how tightly your game is packed, but if it is mostly
wide open spaces, you could have large tiles for pathfinding


| |   RR |
| n  |  RR  |
| |RR|

| | |
| | |
| | |


If the n needs to go somewhere in the lower right, he can't go through
the tile with the big rock.

If you have very tightly packed levels, you need finer tiles.  If you
have a mix, the tiles could be hierarchial, where pathfinding from far
distances first use the larger tiled map, but pathfinding within one
of those large tiles uses a higher resolution tilemap.

You can also have normal sized tiles for pathfinding.  But the method
used for pathfinding does not need to correspond with the method you
use for graphics.

Brian, I really like that method based on vision tests!  I'm going to
try it out next time I have a game that needs something like that.

Re: [pygame] unit and doc testing questions

[Patrick Mullen]

On Wed, Jan 14, 2009 at 10:57 AM, Jake b ninmonk...@gmail.com wrote:

  2) Do you have two seperate unittests ? (A) One is ran every time source
  files are compiled, and a second, (B) slower one is ran at a longer
  interval
  for slow tests ?

 Such separation is rarely necessary.

 Something I started on, requires rendering. It's not a huge delay, but I
 don't want it happening every time I hit f5, while the other tests are fast
 that they can every time.

 I'm not totally sure how I'm going to handle this. For now I'm manually
 running the slow one, but.

In my system, all of my tests are categorized, and I have a flag in
the run tests script
that determines which categorys I want.  While debugging, I only run new
tests (any tests I am working on or recently added, I tag as new).  Before
I check into version control, I make sure to run all of the tests
first, but setting
the flag in the run tests script to all categories.  Running all of the tests
does take a while (more than a minute), but the slow tests don't delay
my debugging/coding.

Another option, which might have merit, is to completely separate rendering
tests and other unit tests.  You can have one runner that runs the rendering
tests, and another runner for everything else.  I think rendering is a bit
fuzzy as a unit test.  You should prefer tests that don't have to
render to those
that do, and structure code in such a way that you can test as many things
without rendering as possible.  For instance, animation code doesn't need to
render to check and make sure self.frame is incrementing properly.

But, there are certainly cases where rendering needs to be tested.  Just make
sure to only test it when necessary.  Example (semi-real): I have
20ish tests for positioning an
object.  If I were to draw the object in each test, it would be very
slow.  Instead,
the 20 tests check the result of a get_screen_pos() rather than render
the object
outright.  Most of the logic that used to be in the object.draw()
method is refactored
to the get_screen_pos method.  That way I can get by with just a few tests of
object.draw() itself, and know that since it uses get_screen_pos
(which is fully covered
by the other tests), that draw() is well covered as well.

Any of your tests or test files that import the module are pretty much
inherently
checking for compiler errors, so there is no need to test for the compiler
explicitly.  That cookbook example sounds like it is less about
compiling, and more
of a way to implicitly run tests when the application runs.

Re: [pygame] Working on Retro 80s Game SDK, Looking for general support

[Patrick Mullen]

On Wed, Jan 7, 2009 at 3:51 PM, Jake b ninmonk...@gmail.com wrote:
 On Wed, Jan 7, 2009 at 2:00 AM, Patrick Mullen saluk64...@gmail.com wrote:

 On Tue, Jan 6, 2009 at 10:59 PM, Jake b ninmonk...@gmail.com wrote:
 through, I use the assert statement to make sure that the frame counter
 is no
 longer progressing.  Later, if I change some of the animation code
 somewhere that
 might mess up the play_3_times behavior, when i run the tests that
 test will error,
 and I'll know I broke something.

 Do you use the assert statement, or do you have a function like this?
 def _assert(exp, msg=):
 An assert() function.
 source: http://www.gamedev.net/community/forums/topic.asp?topic_id=496793;
 if __debug__ and not exp:
 import pdb
 print \n_assert failed:\n\t%s\n % msg # or: simple: print _assert failed:
 , msg
 pdb.set_trace()
 --
 Jake


Yeah, I just use assert statements for the most part.  I don't touch
debuggers, not that they wouldn't help, I am just so used to
sprinkling print statements everywhere that I don't think of it.  The
important thing is that the tests are separate from the rest of the
code.  Most of them generally look like this:

def test_something():
   o = create_object_somehow()
   o.do_something()
   assert o.state == something

Then I have a file that imports the files with the tests and runs all
of the functions.  If a function errors, I catch the exception and
print it, but continue to the next test.  That way I can see a
pattern. If I have 10 tests that all fail with the same exception, it
becomes pretty clear what I did that screwed it up.

This isn't any different from what UnitTest or doctest (or py.test, or
nose, or ...) do.  Some of the test suites I've seen use asserts
like me, others have their own equality-checking functions.  I do have
a special function for comparing images, but that's a special case.

I would say my test code is roughly 3 times longer than my actual
code.  Currently I have about 170 tests, so it's getting to be a bit
scary, but I think it's the right way to go.  I feel a bit more secure
than I did before, but it could be a false sense of security.  We'll
see when I release it how the bug reports go, versus the last version
I released.  Coding speed seems roughly equivalent to before when I
wasn't doing tests.  Most of the time I spend writing tests now I
would have done before in writing comments or just planning things
out.

If you want to get into unit testing and test-driven development, I
recommend doing some research on it, it's not a skill that comes
naturally.  I was indoctrinated in school (and they are always going
on about it on blogs and such), but it still took me a while to
actually apply it to a personal project.

By the way, do you have your code in a repo somewhere?  I'd be
interested in checking it out.

Re: [pygame] Working on Retro 80s Game SDK, Looking for general support

[Patrick Mullen]

On Tue, Jan 6, 2009 at 10:59 PM, Jake b ninmonk...@gmail.com wrote:
 @OP: for file saving, have you messed with pickle?

 On Tue, Jan 6, 2009 at 6:10 PM, Patrick Mullen saluk64...@gmail.com wrote:

 Also, automated testing is really important when building a framework.
  I had to throw
 out my own framework and start over because the code was bad enough it
 would
 have taken too much time to fix all of the problems, and I had no
 tests to verify
 that my changes weren't breaking things.  Every fix I did broke
 something else that I
 didn't know about.  Now that I have a huge test suite, I am more
 flexible in adding
 new features or subtly changing the code.


 Do you mean using: doctests and Unittests ? [
 http://docs.python.org/library/doctest.html,
 http://docs.python.org/library/unittest.html ]

 Or do you do more? I'd like to know more information.

 --
 Jake

Yeah, I'm talking about unit tests basically.

Well, I use my own testing suite I wrote, because I didn't feel like learning
the others.  It somewhat resembles unittest though, and that's probably
a good thing to learn.  Doc tests might be worth looking into as well.
I actually wrote the tests first.  For instance, one of my tests
creates an animation
object, with a play_3_times behavior.  Then, I continually call
next_frame() on the
animation, to tell it to go to the next frame.  After what should have
been 3 times
through, I use the assert statement to make sure that the frame counter is no
longer progressing.  Later, if I change some of the animation code
somewhere that
might mess up the play_3_times behavior, when i run the tests that
test will error,
and I'll know I broke something.

Much more could be said about tests, look for test-first development,
which is basically
what I am experimenting with.  After a history of numerous codebases
that are very
difficult for me to work on due to not knowing what might break if I
change or add
anything, I decided to try something different.  It's difficult to
know what to test and how
to test, but I think it pays off.

Oh, one thing that was VERY difficult was how to test any of the
drawing code.  I found
a program called perceptualdiff which can compare images even if the
colors or filetypes
or bytes differ, but from a human perspective they look the same.  So
I have a reference
image and the test produces a secondary image to compare with the
reference.  It's
far from ideal, but it's the best I could find.  My engine supports
software or opengl
backends, so checking the drawing was a pretty high priority.  Doing
ad-hoc tests (where
you run some toy program and fiddle with it to check that its working,
like I used to do) was
a nightmare because I always forgot to go back and check the other display mode.

TheMusicGuy wrote:
 Generally, though, I am trying to make sure that the engine works in a
 way that will allow XML to work. With that much settled, the editors
 shouldn't be too difficult. As soon as I finish the menu module I can
 begin work on the image/animation editor, then I'll be able to make
 better judgments.

Sounds like you are thinking about these issues, so that's good.  I was thinking
more of the logic editor than the image editor, but maybe you are not that
ambitious for that :)

 Well...three things:

The problem with draw speed comes more from the fact that software drawing is
slow at higher resolutions.  Since you are focusing on 8/16bit, this
isn't so bad,
but if you want anything better than that, you really want to talk to
the graphics
card's powerful rendering hardware.  Most of which is not used in 2d drawing.
If graphics are a bottleneck, and with the exception of collision
detection usually
are the primary bottleneck, switching to opengl is a much greater gain than
converting code to C.  Since you have already abstracted away surfaces, you can
add in an opengl draw model at a later time if it is needed, so that's
good.  I have
had good results doing a similar thing in my engine.

You may not need it though.  Don't rewrite anything in C unless you know where
the slowdown is coming from :)

Event manager - doubtful to need any optimization
Physics - yeah, this probably needs it, depending on how complex it
is.  Might be
better, since there are so many of them out there, to find an existing
one.  Last Summer
of Code a pygame physics engine was started, I don't know if it was
completed.  This
adds a dependancy, but better than trying to tackle such a difficult
subject when you
have so many other things.

 Thanks. I was afraid people were going to tell me not to bother with
 something like this since there are already several projects that
 resemble this one. I just hope I can take it to the next level before
 school starts up again--only two short weeks left!

As many frameworks as we can get in my opinion!  Plus, if it's
fun/educational for you, why not.

Re: [pygame] Working on Retro 80s Game SDK, Looking for general support

[Patrick Mullen]

On Tue, Jan 6, 2009 at 3:39 PM, Casey Duncan ca...@pandora.com wrote:
 On piece of advice I have is to create actual games with the system as early
 as possible, especially before the apis and features have completely
 solidified. It's very helpful to point out awkward or missing parts of the
 system.

 -Casey

Seconded!  You should develop 2 or 3 test games (each test game should have some
variety to each other) as you develop the system.  When you get stuck
on a test game,
you know what needs to be added, and because you have the other test
games you have
an idea of how to add the new feature without breaking them.

Also, automated testing is really important when building a framework.
 I had to throw
out my own framework and start over because the code was bad enough it would
have taken too much time to fix all of the problems, and I had no
tests to verify
that my changes weren't breaking things.  Every fix I did broke
something else that I
didn't know about.  Now that I have a huge test suite, I am more
flexible in adding
new features or subtly changing the code.

Your library sounds like a great idea, and seems fairly complete so
far.  The hard
things are to come though.  Editors and online especially are quite
difficult if they
haven't been a part of your design already.  Editors tend to need the
engine to be
structured a certain way, unless you want to work hard at making the editor very
smart.  Although you might have already been structuring things with
this in mind.
The same goes for multiplayer.  It's very difficult to convert a
system where everything
knows about everything and stays in sync for free, to a multiple machine
syncronizable simulation.  Come to think of it, that is difficult even
if you start from there :)

By the way:
 * Support for tracked music in formats like
pygame already supports tracked formats.  I can't remember which
exactly, but I'm pretty sure xm,
it, and mod work.
 * Implementation of critical modules in C to improve speed.
Probably won't be necessary.  Best way to speed up a pygame game is to
use pyopengl, which
kind of throws your design for a loop.  No pygame.draw or surfaces for
one thing.

Good luck, I love projects like this.  I'd help if I wasn't bogged
down with my own :)

Re: [pygame] Re: PixelArray versus Surfarray + Numeric/NumPy

[Patrick Mullen]

On Mon, Jan 5, 2009 at 10:02 AM, Jordan Applewhite
jordan.applewh...@gmail.com wrote:
 Hello again.  I may have posted prematurely.  It seems that the easiest
 thing for me to do is to just set up a Python2.4 + Numeric dev environment
 and wait for the incompatibilities to sort themselves out.  I still welcome
 any of your suggestions too my previous questions.

 Thanks again.

By the way, you do mean python2.5 right?  Python 2.6 and 3.0 are not
widely supported yet, but 2.5 is.

Re: [pygame] Do we still need Python 2.3 support from Pygame?

[Patrick Mullen]

On Fri, Dec 12, 2008 at 1:23 AM, Casey Duncan ca...@pandora.com wrote:
 On Dec 11, 2008, at 8:48 PM, Brian Fisher wrote:
 [..]

 ...In fact, I think a reasonable thing for pygame to do is say you want
 support for 2.3? then here's an installer for 1.8.1, we kept it around just
 for you.

 I think this is the right way to approach this. You need to use an old
 version of python, then use an old version of pygame. I couldn't care less
 if folks are lazy, what matters is that the pygame developers lives aren't
 complicated by supporting ancient versions of the interpreter. Removing
 complexity from the development process is a very good thing.

I agree.  If you are limited to py2.3, you are limited to pygame1.8.  1.8 is
pretty good as is.  But it's not really about lazy, it's about portability.  The
reason I stick with pygame instead of pyglet, is because pygame runs
damn near ANYWHERE.  From the oldest system imaginable, to
the newest.  I don't have any users stuck on python 2.3 fortunately, but
I do have users stuck on windows 98.

 Opposition to requiring 2.6 has been voiced, and I'd have to agree that at
 this time there is little to be gained moving that far. Seems to me that
 making the next version of pygame require 2.5 is reasonable.

 -Casey



Yeah I don't think 2.6 should be required for at least a year or two.
As mentioned
above, I cut out a significant portion of users with 2.6.  It stinks, because I
want to upgrade, but there we go.  I could just stick with pygame 1.8 though.
So even still, I wouldn't argue too loudly if things went in this
direction.  Not to
mention, I could probably use one version of pygame/python for these users
specifically, and let everyone else upgrade.

PyObjC has been the most difficult issue for my mac users, so I would
give a cheer if that dependency were removed.

Re: [pygame] Shader Demo

[Patrick Mullen]

Hi Ian.  It doesn't work for me.  A window opens with nothing in it
(clear) and then I get this output:

Error!  See index 0!
Error!  See index 1!
Error!  See index 2!
Error!  See index 3!
Error!  See index 4!
Error!  See index 5!
Error!  See index 6!
Error!  See index 7!
Error!  See index 8!
Error!  See index 9!
Error!  See index 10!
Error!  See index 11!
Error!  See index 12!
Error!  See index 13!
Error!  See index 14!
Error!  See index 15!
Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.

I have an ATI 2600 HD.  I've tried with and without glutInit

Re: [pygame] Shader Demo

[Patrick Mullen]

0 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
1 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
2 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
3 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
4 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
5 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
6 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
7 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
8 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
9 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
10 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
11 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
12 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
13 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
14 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
15 Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.
Fragment shader(s) were not successfully compiled before
glLinkProgram() was called.  Link failed.

Doesn't give much more to go on :P

I wonder what is wrong with the shaders/my system that they aren't compiling?

Here is the first generated shader:

varying vec3 normal,lightdir,lightposnormalized,halfvector,lightVec;
varying vec3 blah;
varying float dist;
uniform sampler2D tex1,tex2,tex3,tex4,tex5,tex6,tex7;
uniform sampler2D normalmap;
uniform sampler2DShadow
shadtex1,shadtex2,shadtex3,shadtex4,shadtex5,shadtex6;


vec4 fog(vec4 color)
{
float z = gl_FragCoord.z / gl_FragCoord.w;
z = clamp((z-2.0)/5.0,0.0,1.0);
float oneminusz = 1.0 - z;
color =
vec4((color[0]*oneminusz)+(1.0*z),(color[1]*oneminusz)+(1.0*z),(color[2]*oneminusz)+(1.0*z),1.0);
return color;
}
vec4 cartoon(vec4 color, int steps)
{
float grey = (color.r+color.g+color.g)/3.0;
float steps2 = float(steps);
float intensity = float(floor(grey*steps2))/steps2;
color = vec4(intensity*color.rgb,color.a);
return color;
}
vec4 outline(in vec4 color, in float threshhold, in vec4
setcolor, in float normz)
{
if (normz  threshhold) {
return setcolor;
}
return color;
}
vec4 tex(sampler2D texture, vec2 uv=gl_TexCoord[0].st)
{
return texture2D(texture,uv);
}

void main()
{
vec3 n = normalize(normal);

//color
vec4 color = vec4(0.0,0.0,0.0,1.0);

//clamp color
color = clamp(color,0.0,1.0);

//set color
gl_FragColor = color;
}

It's all greek to me, I don't see anything obviously wrong.  It could
be a problem with the pyopengl binding on my system, that's my guess.
I can play the latest of the latest games so I definitely have shader
support.

Re: [pygame] sprite groups and tilesheets

[Patrick Mullen]

On Sat, Nov 15, 2008 at 3:27 PM, Greg Ewing [EMAIL PROTECTED] wrote:
 Michael Fiano wrote:

 i want to have a faster
 framerate when there is no scrolling by only updating the player and the
 background and foreground contained in it's rect area.

Generally in a scrolling game, depending on how you deal with the
camera, the player is scrolling more often than not.  In this case
there is no gain for a faster framerate when not scrolling.  In any
case, if there is important gameplay that occurs while the screen may
be scrolling, such as dodging an enemy, then you have to make sure
everything works at that slower framerate.  If it's more like zelda
(the first one), where you get a non-scrolling screen and then there
is a short scrolling transition when you move off the screen, then
your case would make sense.

A good thing to do in a tile based game, is to blit all of the tiles
to a single surface, so you aren't doing a bunch of blits every frame,
and then just redraw the whole screen each frame using the rendered
map.  If you have animated tiles of course, depending on how many
tiles on screen are likely to be animated, this optimization will not
be helpful.

Re: [pygame] sprite groups and tilesheets

[Patrick Mullen]

On Wed, Nov 19, 2008 at 7:59 PM, Charlie Nolan [EMAIL PROTECTED] wrote:
 A good thing to do in a tile based game, is to blit all of the tiles
 to a single surface, so you aren't doing a bunch of blits every frame,
 and then just redraw the whole screen each frame using the rendered
 map.  If you have animated tiles of course, depending on how many
 tiles on screen are likely to be animated, this optimization will not
 be helpful.

 It's also not going to be helpful if your map is large.  Assuming SDL
 is willing to create a big enough surface (I've hit the limit with a
 few bugs), you'll be using a ton of memory.

 -FM


In this case I hope you aren't drawing all of the tiles at once either
:)  Either way you will have to set up a region, but setting up a
region will of course be much simpler with raw tiles.

Off topic, what's with SDL surface sizes being so restrictive?  That
has bitten me in the past with loading animation strips.  It's not
just a memory limit, but a dimensions limit.  I had to convert my
animations to grids to get around it, even though the amount of memory
for the load is the same.  I feel like I should be able to load the
maximum sized image that will fit in available memory.

Re: [pygame] Pygame and windows managers

[Patrick Mullen]

It looks like your eee pc is using directfb or some sort rather than
standard x11.  fbcon = framebuffer console maybe?  Not sure.

I did some googling and found some reports of people having trouble in
this regard, with other reports of it working.

By the way, have you tried skipping the display.info and just trying
to use pygame anyway?  Also an actual error log might be helpful.

Re: [pygame] my rpg game (so far)

[Patrick Mullen]

On Tue, Nov 4, 2008 at 11:58 PM, Michael Fiano [EMAIL PROTECTED] wrote:
 On Sat, 1 Nov 2008 05:06:08 -0400
 Michael Fiano [EMAIL PROTECTED] wrote:

 I am stuck. I realized I need to blit the player the the map surface
 instead of the screen so that I can position the player at a given map
 position. The problem is if i change line 66 of player.py from:

 self.screen.blit(self.playerimgs[self.frame], (self.x,self.y))

 to:

 self.background.blit(self.playerimgs[self.frame], (self.x,self.y))

 The map (also on the background surface) does not get repainted
 properly. The player leaves trails when he moves. I'm not sure how to
 fix this, or why it even occurs. Somebody enlighten me?


No need to place him on the map itself, as long as you position the
player so that he is aligned with the background.  I assume you are
doing scrolling?  If you are scrolling by moving, the background, blit
the player this way:
self.screen.blit(self.playerimgs[self.frame],
(self.x+backgroundx,self.y+backgroundy))

Your way would work if you create a new copy each time:
this_frame_bg = self.background.copy()
this_frame_bg.blit(self.playerimgs[self.frame], (self.x,self.y))
But it is probably slower to copy a whole surface like this.

Re: [pygame] Linux binaries

[Patrick Mullen]

On Tue, Nov 4, 2008 at 12:55 AM, Greg Ewing [EMAIL PROTECTED] wrote:

 The only way to improve speed is to re-code the cpu-intensive
 parts using something more efficent, such as C or Pyrex.

 --
 Greg



Or, of course, write better python code if possible in those parts.

Re: [pygame] help

[Patrick Mullen]

On Thu, Oct 30, 2008 at 10:55 PM, Matt Pearson [EMAIL PROTECTED] wrote:
 how do you get the Win32 console window from popping up when running a
 script?

If you name your file .pyw it will assume you are handling the
windowing yourself and will not open a console.

Re: [pygame] Saving Alpha Channels

[Patrick Mullen]

Ian Mallet:
 I'm running into random troubles with PyOpenGL transparency again, and the 
 simplest solution is just to make the textures have
 transparency.  Normally, I would just add the transparency in an image 
 editor, but unfortunately I have ~250 images.  My solution is
 programming!  I wrote a script which should convert all the images to be ~50% 
 transparent:

Well, here is how you can fill a surface with alpha values in pygame:

import pygame
screen = pygame.display.set_mode([400,400])
img = pygame.Surface([400,400]).convert_alpha()
img.fill([255,255,255])
array = pygame.surfarray.pixels_alpha(img)
array[:,:] = 50
del array
pygame.image.save(img,test.png)

surface.set_alpha does NOT fill the surface with alpha values, all it
does is tell the rendering system to mix the colors when it blits the
surface.  This is why it won't save those values.


But what trouble are you having with transparency in pyopengl?  If you
use glColor to set an alpha value, you should get the same effect.
And it will be more flexible too, such as allowing you to handle
things fading in etc.  Although I don't know what your problem space
is.  But if you are having issues such as objects that should be in
front displaying behind etc, I don't think making the textures have
alpha is going to fix the problem.  I think we should look at the
original problem instead of trying to work around it.

Re: [pygame] recommendation for a good n00b IDE

[Patrick Mullen]

On Sun, Oct 5, 2008 at 9:48 AM, yanom @linuxmail.org
[EMAIL PROTECTED] wrote:
 both scite and geany are terrible for python, in my opinion.

I keep coming back to SciTE myself after trying just about everything
else.  I use vim occasionally, but SciTE tends to get out of my way
the most.  How is it terrible for python exactly?  Or do you just
think it's terrible period?  That would make a little more sense.  One
thing that has saved me numerous times for instance, is convert to
tabs.  I get something that uses indentation of 2, which doesn't fit
my preferred indentation of 4, I tabify it, and indentify it in two
clicks.  It has the same basic folding, paren and quote matching etc
that everything else has.  It has autocomplete if you want it
(although I can't stand autocomplete).  It runs the program in a
separate process, and any freeze can be killed (emergency break you
mentioned).  It's NOT an ide, it lacks debugging (although there might
be some extensions for that) and project management features (probably
an extension for that too) but as an editor it works really well.

I suppose if you HAVE to have an ide, it won't work for you.  But
terrible?  That's a bit far.

Anyway, I haven't seen any mention of Editra.  It's pretty new, but
seems like it stands toe to toe pretty well with other ides.  It even
has a vi mode which is pretty cool.

Re: Re: [pygame] PyGameDB coming along well

[Patrick Mullen]

Hypernucleus has too many syllables in my opinion.  But if it's too
late, that's OK I guess.  I would go with a shorter hyperNuke.  Less
of a spelling problem as well.  But if it's already hypernucleus,
that's fine :)

I also think it would be cool if it could use pypi or even pygame.org
as a backend.  Maybe not at first, but more backends would mean that
people don't have to worry about submitting to hypernuke, or
resubmitting if their game already exists somewhere else.  The problem
with pygame.org is that the fetch mechanism is pretty loose - some
people put a source, some put exe, some just link to their website
where you have to find a download.  So that would need to be sorted
out.  At this point though, I do like browsing the games at pygame.org
a lot.  But having one click to download and play would be a big added
benefit.

Re: [pygame] PyGameDB coming along well

[Patrick Mullen]

I would suggexst monoxide, but that kind of makes it sound like it uses mono.

How about snake oil?  That's pretty catchy.

Re: [pygame] The Giant - 'cool project I'm working on now' - thread.

[Patrick Mullen]

René, you start a thread like this and don't post your cool project?
Let's hear it!

Nirav, very interesting, in a somewhat maniacal way.  I'll be looking
out for the youtube.

I have some big projects for sure.  I am still working on Crescent
Dawn Online, my attempt at an mmo.  Not as cool as Champions (how is
that going Noah, by the way?) but it's cool enough to me :)  At this
point I did some redesign (I should say design as what was there
before was pretty much what would happen if we try this) and am busy
implementing everything to spec and trying to get a small but workable
economy going.  Also my artist is on hiatus, which is making for fun
times for me to practice my 3d skillz.

My other cool project is PyWright, an engine/scripting language to
make Phoenix Wright games.  It is currently in competition with 4
similar tools written in various other languages, which is a lot of
fun :)  By my judgement it is in 2nd place, I don't think it will take
the crown anytime soon, but I keep adding features hoping to make some
more ground.

Re: [pygame] phpbb forum missing at pygame.org website

[Patrick Mullen]

 Apart from the features, I think nowadays people are more comfortable
 joining a forum than subscribing to a mailing list.
 --
 Nathan Whitehead


And then you have the other class of people who prefer to manage their own
moderation, get all of their communication in one place, have an easy way to
search through all communication regarding several projects, and not have to
remember the links to half a dozen forums.

And then there's me who will subscribe to all of the mailing lists and put
the forum in a permanent tab on firefox :)

But it's true - there may be a potential audience that we are not hearing
because they don't follow mailing lists.

Re: [pygame] Moving to SDL 1.2.10

[Patrick Mullen]

March forward the stampede of progress I say.

Personally I don't use SDL for anything except pygame, so it doesn't affect
me.  I'm sure it may affect someone though.  Everything does.

Re: [pygame] Dirty Rect updating

[Patrick Mullen]

Sounds like you are never updating the entire screen.  If you NEVER update
the entire screen, then the area outside where the sprites rect is will
never be displayed with the background (and stay black).  The background is
a dirty rect too :)

But without the real code you are using, it's not possible to tell if that's
truly the problem.  In the future please try to post the actual code that
doesn't work, it helps to troubleshoot a lot.

Re: [pygame] Framerate Normalizer

[Patrick Mullen]

Yeah, fixed-time physics is the way to go.  How you get that fixed time is
up to you, but it's a much better way than trying to put time into all of
your code.  It is more stable, and easier to program as well.  Since you are
thinking about lower end computers, you may have to rebalance everything for
a lower fixed-time update.  (i.e, right now it runs good at 190 fps, but
that's probably not a good interval for a slower computer that can only run
60 fps).  I think most professional games run at around 30 hz or so.  I know
Doom3 did anyway, and that's the last I read about any game's update
function.  Less than 30 though is probably not so good.  On a really slow
computer, things will slow down, but you wouldn't want to skip too many
frames in that case anyway.  If I can only run at 10fps, I would prefer the
game to update a little slower (slow motion) to having objects be warping
around.

Re: [pygame] starting sound playback at offset

[Patrick Mullen]

On Thu, May 8, 2008 at 8:09 PM, Ian Mallett [EMAIL PROTECTED] wrote:

 I suppose it is possible to play the sound at zero volume until the
 starting point, then pause, and restart when you need to start.  This seems
 to me to be a decidedly low-tech solution though.
 Ian


Although getting the timing right on this would be difficult - you would
have to queue up a sound ahead of time at the low volume.  Another low tech
solution I can think of would be to chop up your music into set time
intervals and only fade between them at an interval.  A more high tech
solution may be to use a sndarray, but I am completely unfamiliar with how
these array objects can be used exactly.  but it may be that you can make an
array, and then slive it from where you want to start, and it will modify
the sound such as to start from where you want.

There are no high-level interfaces for seeking through a sound though.  More
sound control in pygame would be great.

If you do figure out how to seek using a sndarray let me know, I'd be
interested in such a thing as well.

Re: win9x testers wanted. Re: [pygame] C file pointers and file loading

[Patrick Mullen]

It is worth noting that win9x is one of the platforms specifically
unsupported by python 2.6:
http://www.python.org/dev/peps/pep-0011/

It looks like this is planned deprecation.

...

Lame, but somewhat understandable.  I haven't seen a live win9x machine in
quite a while.  Even my grandparents have moved on :)

Still lame though.

Re: [pygame] Re:[pygame] networking example

[Patrick Mullen]

Found you an exe and an egg:
http://www.zope.org/Members/saffe/zope_interface/folder_contents

Really annoying when binaries stop being updated.

You could also just use sockets of course, they aren't that difficult
really.

Also, raknet uses udp, but it has built-in workarounds for all of udp's
problerms.  It can send both reliable packets, and break through NAT's,
which are the two most difficult issues with using UDP.  Messaging is
actually easier with UDP because you send datagrams (messages) instead of a
constant stream of bits.

Good luck!

Re: [pygame] networking example

[Patrick Mullen]

Well yes, LAN makes this easier, because you can pick a latency to
work with and it will be fairly consistent.  With a consistent
latency, you can send a message like: bullet will be here by the time
you get this message and it should be fairly accurate.  Unfortunately
there is currently no networking built into pygame, and yes I think
there were some people working on such a thing.  I think your best bet
at this point is to use something like twisted or raknet and build
your own scheme that fits your game.

Re: [pygame] Python and Speed

[Patrick Mullen]

In that specific case, no matter which programming language you use,
your code will not be very fast.  Do you think programmers write
unoptomized code in c, and get speedy execution every time?  Have you
not ever used a program or played a game which ran slower than it
should, which was actually programmed in a fast language?  Optiomizing
code and improving algorithms have been around far longer than python,
and are an important part of programming in general.  As has been
mentioned before, there have been many attempts to optimize core
python, which have resulted in some improvements.  Python2.5 is
considerably faster than python1.0.  However, due to the nature of the
language it can only be optimized so much.  The best bet really, is to
write code in c that needs to be fast, and call that code from python,
using python as a glue language.  This can be accomplished using
implementations that already exist (pyode, numpy) or writing a new
implementation and exposing it with pyrex or other linking programs.

There is no magic bullet that will make python faster, and it's not
for lack of trying.  Even at it's most optimized that could
theoretically be done, I don't think pure python will ever be as fast
as c.  I do hope it gets close, but even if this were to be the case,
your collision detection code will still be slow as heck.  Culling
algorithms for this purpose were invented to speed up applications
written in C after all :)

Re: [pygame] award winning pygames.

[Patrick Mullen]

In my opinion, pygame is fairly easy to learn/use.  This is a double
edged sword when it comes to how it looks from the outside.  Tools
that are hard to use generally require very dedicated people to be
able to be productive with them at all.  By the time a developer has
jumped through the hurdles to get started, assuming that development
does get easier as time goes on, said developer might be more likely
to have the dedication required to finish a game.  On the other hand,
with something like python/pygame, getting started might be so easy as
to delude someone into thinking that finishing a game will now
magically be easy because the tool was so easy to learn.  I have
seen this same problem with other tools that are easy to learn.
Getting started may be shorter, but finishing is just as hard as
finishing ALWAYS is.

Pyweek is a good example of this.  Maybe half of the games in each
competition I would say have the potential to be somewhat successful,
at least as successful as other indie games could be.  But very very
few of these games ever get developed further after pyweek.  Actually
developing one of those games into a full commercial or popular game
could take many more months of development even if it seems complete
after that week.

To sum up, even finishing a game, especially when working alone as
most pygame developers do, requires a huge amount of patience and
dedication, even though the tool is very good and makes many things
easy.  The tool is only half the battle in making a good game.  My
problem is that I basically only work on games with the kind of
dedication required during pyweeks, after which I am very lazy and
never manage to finish anything.  Plus most of my game development
energy is put into my mmorpg which is such a huge project I don't know
when I will ever finish.  If I could spend a few months with the
energy I put into each pyweek on a single game, I think I could pump
out many at least able to be successful games each year.  Lord knows
I have enough ideas.  I just don't have that kind of energy or I use
it up in other places.  I think many others in the community could do
the same.  Unfortunately most of us are doing this as a hobby, and
we're a small community besides, hence the small amount of
successful games.  However you measure success.

Re: [pygame]

[Patrick Mullen]

This makes me sad.

Re: [pygame] hi, what is it? oh pygame 1.8 is released.

[Patrick Mullen]

Great job!  Wow, this is going to make the choice of pyglet or pygame
for pyweek that much more interesting ;)

Re: [pygame] Does PyGame support Ogg Vorbis OOTB?

[Patrick Mullen]

Don't know anything about the osx or debian problems (with OSX I
expect the issue may be with whatever python version the user has by
default, and which pygame packages are available), but ogg vorbis is
definitely supported.  Mp3 support is a bit off, so you should always
use ogg vorbis instead.  How do you have extras installed?  AFAIK
there is only pygame.

Good luck with the tutorial.

Re: [pygame] scaling the entire screen

[Patrick Mullen]

On Wed, Mar 19, 2008 at 10:01 AM, Ian Mallett [EMAIL PROTECTED] wrote:
 --But, if the graphics are always going to be at a set resolution, then it
 is more correct to keep your images in a lower (or higher) resolution to
 begin with.


The OP was asking for the option to let users choose the resolution,
so this isn't an option.  I would say to target the smallest
resolution, and at that level have no scaling.  The point of the low
resolution is for the fastest framerate.  For higher resolutions
either scale your images up beforehand, or scale them right after
pygame.image.load().  In drawing code, make sure you abstract the
resolution out of it.  You could scale all x,y values by same amount,
where the lowest resolution would have a scale of 1.0.  There are
probably other options as well.

Or switch to opengl, where the problem vanishes :)

Re: [pygame] my first game (so far)

[Patrick Mullen]

From: Devon Scott-Tunkin
 anyone else try this in
 vista?

I'm running it in vista, and I did notice the character stop moving a
few times - usually after pressing another key (shift etc).  I was
trying to find the run key, hehe - Character moves a bit slow.  There
may be something wrong in the event handler where it loses the event,
which happens more often on your computer than on mine.

Re: [pygame] my first game (so far)

[Patrick Mullen]

On Mon, Mar 17, 2008 at 6:50 PM, Lenard Lindstrom [EMAIL PROTECTED] wrote:
  problems with the arrow keys that I could find. The only thing I
  wondered about is that changing the direction the sprite faces also
  makes it moving ahead one square.

Most rpgs I know of work this way, so Michael is working within the
standard.  Although maybe the standard is not so good :)

To Michael, I think you are making a great start with this, and the
code looks very clean and well designed.  Scrolling the screen can be
tricky if you have never done it before, but it is not too
complicated.  The biggest loss with screen scrolling is that (at least
if you are smooth scrolling) dirty rects basically go out the window -
the entire screen becomes the dirty rect when it is scrolling.

The main idea, is to have a camera offset value, and then every time
you draw you subtract that value from the x and y of what you are
drawing.  This way, most of your code doesn't have to be changed, as
you are working with the same coordinates for everything.  The only
code that has to change are the blits.

screen.blit(image,[x,y])
becomes
screen.blit(image,[x-cam_x,y-cam_y])

Test this step of the code, before you worry about scrolling, by
setting the cam_x and cam_y to different values.

Once you have this, you can detect where the player is going to be
drawn (player pos minus camera offset) to determine if the screen
should be scrolled.

Here's some pseudo code for that:
screen_x = player_x - cam_x
screen_y = player_y - cam_y
screen.blit(player,[screen_x,screen_y]
if screen_x(screen_width-100):
   cam_x+=scroll_speed
if screen_x100:
   cam_x-=scroll_speed
if screen_y(screen_height-100):
   cam_y+=scroll_speed
if screen_y100:
   cam_y-=scroll_speed

Then, the camera will scroll when the player is 100 pixels from any screen edge.

This is of course not directly applied to your project, but you should
be able to figure it out.

I hope to see more of this project in the future.  The world can never
have too many rpgs :)

Re: [pygame] scaling the entire screen

[Patrick Mullen]

This is very easy to do, thanks to the structure of pygame, blits and
surfaces.  Here is a simple (untested) example:

Old way:
resolution = [320,240]
screen = pygame.display.set_mode(resolution)

while 1:
   screen.blit(sprite,[5,5])
   pygame.display.flip()

New way:
resolution = [640,480]
real_res = [320,240]
_screen = pygame.display.set_mode(resolution)

while 1:
   screen.blit(sprite,[5,5])
   #other plits
   surf = pygame.transform.scale2x(screen)
   _screen.blit(surf,[0,0])
   pygame.display.flip()

And you have a nice doubly scaled screen.  It will probably be slower
than just writing the game for the higher resolution though.

Re: [pygame] get_wm_info on linux

[Patrick Mullen]

On Wed, Mar 5, 2008 at 9:47 PM, René Dudfield [EMAIL PROTECTED] wrote:
 Is window as an int in there?

  Have a look at src/display.c  There you'll see the X11 properties put in 
 there.

  Is this what you're after?
info = pygame.display.get_wm_info()
windowid = info.get(window)
print The window ID is, hex(windowid)


  display is a pointer on X11.

Right, display is what I am after.  I can get the windowid, but not
the display.  I guess what I am trying to do is impossible?  It's
weird because ogre is expecting a string like this: display
*:screenid,windowid, and I'm not sure how you would put a display *
as a string.  Is it the memory location?

I guess I can ask the ogre guys, although maybe I'll play around with
display.c for a bit - thanks for pointing that out!

Re: [pygame] get_wm_info on linux

[Patrick Mullen]

Well here's the documentation for ogre:


RenderWindow * createRenderWindow (const String name, unsigned int
width, unsigned int height, bool fullScreen, const NameValuePairList
*miscParams=0)
...
miscParams  A NameValuePairList describing the other parameters for
the new rendering window. Options are case sensitive. Unrecognised
parameters will be ignored silently. These values might be platform
dependent, but these are present for all platorms unless indicated
otherwise:
...
Key: externalWindowHandle [API specific] Description: External
window handle, for embedding the OGRE context Values: positive integer
for W32 (HWND handle) poslong:posint:poslong
(display*:screen:windowHandle) or poslong:posint:poslong:poslong
(display*:screen:windowHandle:XVisualInfo*) for GLX Default: 0 (None)

NameValuePairList only accepts strings.

It works on windows just fine as such:
set[externalWindowHandle] = str(info[window])

But yeah, the glx portion doesn't really make any sense to me.

I guess this is more a python-ogre/ogre issue than a pygame issue though.

Re: [pygame] get_wm_info on linux

[Patrick Mullen]

Well, I managed to get it to work by hacking pygame src/display.c :)
It is actually a string it is looking for, and I'm not totally sure
how the conversion works (not totally clear on what a void * really is
etc), but here is my addition to display.c that made the value usable:

get_wm_info (PyObject_* self )
{
//In the glx section

tmp = PyInt_FromLong (info.info.x11.display);
PyDict_SetItemString (dict, a_of_display, tmp);
Py_DECREF (tmp);

}

So now the info dictionary has a new value, a_of_display which I
assume is some kind of address.

In my python-ogre code, I call it like so:

self.screen = pygame.display.set_mode([opts[width],opts[height]])
settings = ogre.NameValuePairList()
inf = pygame.display.get_wm_info()
d1 = inf['a_of_display']
w2 = inf['window']
settings[parentWindowHandle]=str(d1)+:0:+str(w2)
self.renderWindow = self.root.createRenderWindow(
   name,opts[width],opts[height],opts[fs],settings)

Surprisingly it works.  It seems like it should be possible to get the
long from the PyCObject (info['display']) just as well as it was done
from the c code (PyInt_FromLong) but what do I know.  At least I have
it working.  Thanks for pointing out that file Rene.

[pygame] get_wm_info on linux

[Patrick Mullen]

I am embedding ogre in a pygame window, which is working fine on
windows, but on linux ogre needs not only the window handle, but also
a display pointer and screen id.  Fortunately,
pygame.display.get_wm_info() returns a display field, and the screen
id I assume is just zero.  Unfortunately, the display field in the
dictionary is of type PyObject, and has absolutely no accessible
properties.  Is there any way to get access to this information or am
I just stuck?

Re: [pygame] Animated Gifs again :)

[Patrick Mullen]

In my case, all of the graphics (pre-existing) I wanted to use for a
project were in animated gif format, so I had no choice but to use it.
 I couldn't get PIL's gif animation to work either, so instead I wrote
a converter to convert gif animations into framestrips, using gifsicle
(http://www.lcdf.org/gifsicle/).  This could be rigged up to convert
and load frames in semi-realtime, but conversion is probably the best
bet.

I was getting strange grey colorshifts, like negatives, after seeking
with PIL, so it sounds like the problem your having as well.

Re: [pygame] New GUI

[Patrick Mullen]

 Show me a GUI builder that in fact produces clean, non-overloaded code,
 that does not break, if I manually change, add or remove stuff and so
 effectively eases development. I am not aware of any. If they do not
 match these criteria, but I am instead forced to stick with them (like
 e.g. VS.NET), they are useless.

Gui builders really ought to store the gui structure and then let the
coder write all the functionality hooks.  Like, oh, I don't know,
writing html.

Oh wait, even html designers get it wrong.  Oh well :)

Yeah, gui builders aren't all they are cracked up to be.  I am using
CEGUI for my project, and I used the gui builder for a while, until I
discovered that it randomly chose whether positions were stored as
percent of screen size or pixel size, and I had to redo the whole
thing manually.

Don't criticize Marcus for not talking to other gui developers about
their gui's problems, as far as I know, he was the first :)

For me, I probably wouldn't purchase a gui toolkit.  I have written
some in the past, and find writing guis rather enjoyable.  If I want
to actually work on a game rather than a gui, I will look at what's
out there and use it if I feel like it.  Both PGU and ocemp really
look like they control how I would write the game, which I think is
fine in PGU's case, it's meant to be sort of a quickstart, not a last
minute plugin.  CEGUI definitely has influenced how I have programmed
my game, but it has also saved me some time.

If I couldn't find a suitable free library though, I would probably
write my own toolkit as you have just done.  Trolltech has succeeded
with QT because is is usable in so many places for many different
operations, and is also used in one of the two most popular linux
desktops: KDE.  If it weren't for their liscensing though, I can't
help but think that GTK would not have done as well as it has.

For a toolkit that can only be used in pygame, ignoring things like
pyopengl, python-ogre, etc, such limited use I don't see as being very
marketable.  If it was generalized, and pluginable to almost any
python program, that starts to have some real value.

Re: [pygame] Help: improve new module documentation. Read this, and give me comments.

[Patrick Mullen]

Yeah I have generated my own masks in pure python for per pixel or
special effects, and it is super slow.  I have to precalculate all the
masks or there is nothing doing.  This module sounds great!

The only point of confusion is the point of intersection.  Very rarely
is only one point intersecting.  Which point exactly is the
intersecting point?  With rects you could say its the corner, or you
could have a vector that determines how far out to move it, based on
the center of the rect, so it's not intersecting etc, but with a mask
there is no corner, and likely not a center either.

On Jan 22, 2008 1:55 PM, Ian Mallett [EMAIL PROTECTED] wrote:
 Sorry, don't have time to give a good answer about the documentation,
 but a pixel perfect collision detector is great!  The one I wrote for
 a game a while ago works, but is not to portable...
 I

Re: [pygame] Tactics Game Demo

[Patrick Mullen]

Pretty cool.  I love this sort of game.  My first pyweek entry was a
fire emblem clone: http://www.spinheaddev.com/downloads/mechrev.zip

Several things brought it down though.  The interface had too much
clicking, the strategy was unsound, and my a* was much too slow.  Take
a look at the source if you like, maybe you can find something useful
in there.  Although I doubt it.  One of the best games I've made, and
probably some of the worst code I've seen in my life :)

Your tactics demo seems pretty hard to win, have to make better use of
those healers I guess!

Re: [pygame] On the Posting of Projects

[Patrick Mullen]

Good advice, however I feel that the people who would most benefit
from it may not be listening here.  Also, even though it's linked on
the front page, I always seem to forget about the cookbook.  Thanks
for the reminder.  The next time I do something I feel is
clever/useful, maybe I'll put it there, since an actual distributable
project is so rare!

I would also like to add that people who have nothing yet to show of
their project has no business posting.  It's called a release, maybe
if there were a pre-release section it would be different.  If you cry
wolf by announcing a release, people may skip over the next release
which actually has something to say.

Are there any moderator abilities to go through and remove some of the
spam?  Possibly with a warning first?

On an unrelated website note, I would like to be able to remain logged
in to the web site.  It didn't used to be a problem when I would only
log in every month or so, but lately I have wanted to comment more
often.  Could this be added Phil Hassey?

Re: [pygame] Why does my ball vibrate?

[Patrick Mullen]

On Dec 5, 2007 9:59 AM, Ian Mallett [EMAIL PROTECTED] wrote:
 On 12/4/07, Greg Ewing [EMAIL PROTECTED] wrote:
  That's true. Probably not something you need to take into
  account in a Pong game, but if you're simulating space
  flight or something like that, you certainly do!
 I always wondered how the ball in Pong could bounce indefinitely, and
 not accelerate when traveling downwards.


Well pong is viewed from above, so downward acceleration makes no
sense.  (ping pong)  As for bouncing indefinitely, pong takes place in
a magical universe where no energy is ever lost :)  It's funny how you
don't ever have to worry about going over the net.  Why they didn't
just name it hock (air hockey) we'll never know.

Fwd: [pygame] Problems with py2exe and Pygame

[Patrick Mullen]

Yes my setup script uses py2exe on windows and cx_freeze on linux,
while keeping the data movement code generally shared for either
system.  So it is all in one nice, portable setup file.  Of course, I
really am a loser.  Instead of using shutil, I wrote all of my own
shell functions :)

To answer the actual question...
We really need to see what code is breaking to know what is wrong
here.  I think you may need to specify an actual named font rather
than relying on the default one, in order to pick up the ttf in the
exe directory.  Uh, one more thing.  Try manually putting the font
into library.zip.

You'll be safest to manually load the font yourself though, with the
pygame.Font function.

On Dec 4, 2007 1:57 PM, Casey Duncan [EMAIL PROTECTED] wrote:


 On Dec 4, 2007, at 1:19 PM, Joe Johnston wrote:

  hwg wrote:
  I'm trying to make an exe of a simple Pygame program.
   Here's the setup.py http://setup.py/:
   from distutils.core import setup
  import py2exe, pygame
  import glob, shutil
  setup(windows=[lunarlander.py http://lunarlander.py/])
  shutil.copyfile('moonsurface.png', 'dist/moonsurface.png')
  shutil.copyfile('lunarlander2.png', 'dist/lunarlander2.png')
  shutil.copyfile('C:/Python25/Lib/site-packages/pygame/
  freesansbold.ttf',
  'dist/freesansbold.ttf')
 
  Maybe I'm a loser, but I generally keep the setup.py script short.
  If I've got to move files, I do that from a bat script which can
  call my Windows installer compiler too (inno, my case).

 A good reason to keep this stuff in python (regardless of whether it
 is in setup.py or not) is portability. bat files only work on
 Windows. But then again, absolute paths (especially ones that use
 drive letters) are highly non-portable anyhow no matter what language
 they're in (even on different machines that are running Windows).

 -Casey

Re: [pygame] Bouncing ball - separating the physics from the frame rate

[Patrick Mullen]

 1. Have the physics and graphics running in separate threads. I don't have a
 clue how to implement this!
This is a very experimental technique.  I think there may be a few
games that do this, but the majority do not.


 2. Call a function from the main loop every time it passes which does the
 physics calculations based on a clock independent of the frame rate but which
 pauses when the simulation is paused (window not in focus?) Is there a 
 function
 in the sys module that I can use to test for a pause?

If your framerate is fairly constant, i.e. it doesn't ever go slower
than what you place inside the clock.tick() call, than you should be
able to get away with simply calling the physics once per frame
without using time_passed as part of the calculation.  (Substituting
some fixed time, like 0.02 as needed).  The only downside to this
method, is if the framerate goes down, the physics will slow down
along with it - but this may be preferable to jerkiness anyway.  What
you won't have is a bad framerate that causes the physics to go out of
sync or go haywire.  And the pausing problem won't matter.

To handle slower framerates, you could detect if time_passed is above
some threshold, and call the physics function twice if the time is too
large.  But it's better to keep the framerate up, no?

clock.tick(60) should guarantee that the framerate is a steady 60 fps
unless things slow down.

So here's my untested example, factoring out time_passed, and making
physics a function:

#physics
def run_physics(ob):
time_passed = 0.02   #.02 is a decent time interval for 60 fps,
adjust as needed.  (1/60.0 is more accurate)
# The physics
# Reverse velocity taking into account bounciness if we hit the ground
if ob.ypos = 384 and ob.velocity  0:
# Avoid the ball sinking into the ground
ob.ypos = 384
ob.velocity = -ob.velocity * ob.bounce

newvelocity = ob.velocity + (ob.gravity * time_passed)
# Use the average velocity over the period of the frame to change position
ob.ypos = ob.ypos + int(((ob.velocity + newvelocity) / 2) *
time_passed * 160)
ob.velocity = newvelocity

# The main loop
while True:

# Test for exit
for event in pygame.event.get():
if event.type == pygame.QUIT:
exit()

clock.tick(60) / 1000.0

run_physics(ball)   #Make global variables attributes of ball

# Update the screen
screen.fill((0, 0, 0))
screen.blit(ball, (xpos, ypos))
pygame.display.update()

Re: [pygame] Why does my ball vibrate?

[Patrick Mullen]

On Dec 2, 2007 7:00 PM, David Gowers [EMAIL PROTECTED] wrote:
 I believe this is the most reliable solution.
 (AFAIK there is no upward force though; it's more to do with the
 pressure the object exerts being insufficient to penetrate the ground.
 So for a simple physics simulation, this solution is also more
 correct.)

But there IS an upward force, at least as far as my memory of the
physics I learned.  The whole every action has a reaction business.
If the ground were mobile, that gravity force down would cause the
earth to move down with that same force.  Since the earth can't move,
it pushes back with the force of gravity.

It has been quite a while since I was in physics, but that's how I remember it.


 Matt: I assume you didn't mean to use a suggestive subject line, Every
 time I look at my mail I see this conversation, read the subject line
 rather differently than you intended, and delete it. And then someone
 posts another reply, so it appears again.. ._.


I never once read the subject line in that way, but now I can't help
it.  Thanks a lot.

LOL

Re: [pygame] Why does my ball vibrate?

[Patrick Mullen]

When I click and hold on the window of the demo, the simulation
pauses.  This accounts for the ball bouncing high into the sky.
Since the game has paused for a while, the framerate has gone wy
down, resulting in a very large time_passed amount.  When put into the
rest of the system, this very large time_passed makes the new velocity
very large, resulting in it shooting high above.  A better method of
handling physics, is to run a certain number of physics steps
depending on how much time has passed, so that variable time doesn't
cause issues such as this.  So it would be like:

def physics_step(blah):
Physics to be run for 1/30th of a second
update_velocity()
collision_detection()

As to the bouncy problem, you see this happen in even established
physics engines such as ODE.  What you have to do is have some sort of
threshold in which to stop the physics and freeze the moving
objects, when they collide with something at some small amount of
speed.  The inaccuracies have to do with floating point math, which is
never going to be exactly 0, in addition to your allowance of the ball
falling through the floor before calculating the velocity.  Here's my
quick and dirty modification:

# The physics
# Reverse velocity taking into account bounciness if we hit the ground
newvelocity = velocity + (gravity * time_passed)
# Use the average velocity over the period of the frame to change position
ypos = ypos + (((velocity + newvelocity) / 2) * time_passed * 160)
if ypos = 384:
ypos = 384
newvelocity = -newvelocity * bounce
if velocity  1:   #Alter this value for the freeze to
happen at different speeds
ypos = 384
newvelocity = 0
# Prevent the ball from sinking into the ground
velocity = newvelocity

On Nov 28, 2007 12:26 PM, Matt Smith [EMAIL PROTECTED] wrote:
 Hi,

 I am beginning to learn Pygame and I have written a short program to
 simulate a bouncing ball. The motion of the ball is pretty realistic
 until it has almost come to rest. The ball continues to vibrate long
 after you would have expected it to come to a complete rest (or be
 moving less than 1 pile each time as it will never stop moving 100%).
 Also, the ball can start to bounce higher again if I click somewhere
 else on the desktop. I can't work out why this happens so can anyone
 shed some light on it and suggest how I can prevent it.Here's my code:

 #! /usr/bin/python

 import sys, pygame
 pygame.init()

 xpos = 92
 ypos = 0
 gravity = 9.8
 velocity = 0
 # How much of the velocity of the ball is retained on a bounce
 bounce = 0.8

 screen = pygame.display.set_mode((200, 400), 0, 32)
 # The ball is a 16px sprite
 ball = pygame.image.load('ball.png')
 clock = pygame.time.Clock()

 # The main loop
 while True:

  # Test for exit
  for event in pygame.event.get():
  if event.type == pygame.QUIT:
  exit()

  # The physics
  # Reverse velocity taking into account bounciness if we hit the ground
  if ypos == 384 and velocity  0:
  velocity = -velocity * bounce
  time_passed = clock.tick(60) / 1000.0
  newvelocity = velocity + (gravity * time_passed)
  # Use the average velocity over the period of the frame to change
 position
  ypos = ypos + (((velocity + newvelocity) / 2) * time_passed * 160)
  # Prevent the ball from sinking into the ground
  if ypos = 384:
  ypos = 384
  velocity = newvelocity

  # Update the screen
  screen.fill((0, 0, 0))
  screen.blit(ball, (xpos, ypos))
  pygame.display.update()

 Thanks for looking.

 Matt

Re: [pygame] global class instances?

[Patrick Mullen]

pygame.fps = FPS()

import pygame
print pygame.fps

It's somewhat hacky but it works, because the import statement uses
the already imported module if it exists.

I tend to have one entry point that I pass to all constructors, as in
the displaymanager example.  Sometimes I'll make it a part of the
class instead:

class DisplayManager:
def test(self):
print I am the root object

class ObjectInstance:
def test(self):
self.root.test()

#initialization code at end of main.py
root = DisplayManager()
ObjectInstance.root = root

a = ObjectInstance()
a.test()

On Nov 24, 2007 12:48 PM, Ghislain Leveque [EMAIL PROTECTED] wrote:
 2007/11/24, Jake b [EMAIL PROTECTED]:
  (2) I'm going to be creating a sprite group: bullet_sprites. Do you
  think my sprite groups should be global? Because I need to spawn
  bullets from within Player().

 I don't know for your other question but may be really interested by
 the answers.

 For this point, here is what I do :
 - have a class named DisplayManager and instantiate it
 - this instance sould be global or passed to every object in the
 constructor (as you do now)
 - this class has a method create_bullet that creates the bullet with
 the right sprite group. This will also be the class that handle the
 draw method and holds the sprites group, the pygame.display...

 hope that helps

 --
 Ghislain Lévêque

Re: [pygame] Split screen question (newbie)

[Patrick Mullen]

If you have any more questions on the rest of it we are here :)  If
you get stuck and feel like you are in too deep you can always start
another project.

On second thought, that's what I do, and it's left me with 1000's of
failures.  Maybe sticking to it would have been a better idea...

One of these days I'll have a success.

We R all Noobs of something :)

BTW that subsurface trick was awesome Casey.

Good luck mundial!

On Nov 22, 2007 12:32 AM, Mundial 82 [EMAIL PROTECTED] wrote:
 Hi all,

 First, thanks a lot for all the help!
 Ups, now I feel some performance anxiety :) As soon as my little
 artsy fartsy experiment is ready, I will share it for feedback. But,
 since I am a noob and this is my first original IP ;) it may take a
 while to figure out the implementation of the basic mechanics.
 As for the subsurfaces explanation - thanks a lot! that makes a lot
 of sense :)

 cheers

 Naranjito



 On Nov 22, 2007, at 3:28 AM, Casey Duncan wrote:

  On Nov 21, 2007, at 5:57 PM, Kris Schnee wrote:
  [..]
  With subsurfaces, eh? I was thinking more like:
  code
  w,h = SCREEN_SIZE ## eg. (800,600)
  top_screen = pygame.surface.Surface((w,h/2))
  bot_screen = pygame.surface.Surface((w,h/2))
 
  def Draw():
  DrawPlayerOneScreen(top_screen) ## Draw game stuff onto these
  surfaces
  DrawPlayerTwoScreen(bot_screen)
  screen.blit(top_screen,(0,0))
  screen.blit(top_screen,(0,h/2))
  pygame.display.update()
  /code
 
  What's the purpose of using subsurfaces? I don't understand those.
 
  If you use subsurfaces, you don't need these lines at all:
 
  screen.blit(top_screen,(0,0))
  screen.blit(top_screen,(0,h/2))
 
  Because when you blit to the subsurfaces, you are also blitting to
  the screen (because subsurfaces share pixel data with their
  parent). It means the system does less work and you use less
  memory, but the effect is the same.
 
  -Casey
 

Re: [pygame] Networking?

[Patrick Mullen]

I tried the twisted as separate process thing for a while when i was
working with Blender's game engine.  At the time it was the only way I
knew how to do it, but it was very unwieldy to work with and deploy,
just not a good system at all.  You are already introducing issues
with network communication, why introduce issues with local
communication as well.

Currently I am using sockets with threads, it works pretty well I
think.  It seems extremely stable, and fast enough, if I could get my
higher level constructs in order.  The hard part with network
programming in my opinion is the higher level stuff rather than the
protocol.  How to serialize the data, what data to send, and how to
interpret it, is very difficult if you want a smooth game.  No
networking library I have seen handles this for you.  I'd like to see
someone write a game network library that handles things like moving
characters around and sending chat messages - 95% of networked games
need these two things.  But most games are so specialized and
integrated that it's hard to modularize this functionality to make it
general enough for a library.  If I ever completely solve my netcode,
I don't see myself being up to that task.

I used to really like twisted, but it's sort of a hard nut to crack
sometimes.  When using basically the raw tcp or udp protocols, twisted
seems like massive overkill to me, and none of it's constructs seem
all that well tailored to games.  That might have changed in the few
years I've been away though.  What things like raknet, hawkNL, etc
give you, is the ability for reliable udp sockets, which does make
some things a bit easier and smoother.

But really, the socket module IS everything you need.  It's just a lot
of work to set up and learn to use it.

On Nov 20, 2007 12:49 PM, Richard Jones [EMAIL PROTECTED] wrote:
 On Wed, 21 Nov 2007, David wrote:
  1)  Use Twisted with reactor.iterate

 I found that this approach has quite a high impact (ie. takes a considerable
 amount of time to run, even when there's no network events).


  2) Use the Twisted reactor *as* your main loop, and implement all game
  logic as call-backs from there. This is the approach that the Twisted
  people will recommend.

 This is also useless for highly interactive games.


   3) Run the Twisted reactor in its own thread

 This is probably the only reasonable approach for games.


  5)  Run the Twisted reactor in its own process, and use pipes or sockets to
  pass data between
  it and the main loop/process.  This has the merit of using the OS's CPU
  allocation management
  rather than that of Python's thread manager.

 Quite difficult to manage on Windows.


  Richard

Re: [pygame] dynamic pygame programming

[Patrick Mullen]

The best situation for this would be to program things very
functional.  That way you can keep most of the program in an easily
reloadable module for when the game is paused.  So instead of:

class man:
   def update(self):
  if not self.touchground():
 fall
  if self.walking():
 move

You would have something more like this:

class man:
def update(self):
functions.manUpdate(self)

#in module functions
def manUpdate(self):


Then when you unpause the game:
reload(functions)


-

Rebinding functions to existing instances is not pretty :)

Another more complex solution, one which I have not personally tried,
would be to make everything inherit from one level above where you
normally would inherit from.  That way you can reload the parent class
and all of the methods at least would be reloaded as well:

--superclasses.py--
class man:
   def update(self):
  if not self.touchground():
 fall
  if self.walking():
 move
--game.py--
import superclasses
class manInstance(superclasses.man):
pass

Then I think when you reload superclasses, the methods on manInstance
will be delegated to the updated superclasses.man class.

I'm not so sure about that method.

-
Also you could use exec to run all of your code.  But that is very bad
and insecure, and doesn't necessarily solve the problem of instances.

On Nov 7, 2007 9:46 AM, Casey Duncan [EMAIL PROTECTED] wrote:

 On Nov 7, 2007, at 5:28 AM, Lionel Barret De Nazaris wrote:

  Hi all,
  I am considering using pygame for a new prototype and I wonder if
  any of
  you has any experience with what I call dynamic programming.
 
  Basically, I want to launch  Ipython,  import the main module of the
  program, run it , then, pause it, modify any module and having them
  reloaded and relinked.
  All this without restarting the program.
 
  Would that be possible ? if so how ?
 
  It's very smalltalkish, but i wonder if it is possible in Python
 
  Lionel

 Yes, absolutely yes. Just please don't ask me to debug it ;^)

 -Casey

Re: [pygame] image.load() -- array?

[Patrick Mullen]

I've known people who could detect the difference between 100 and 80
fps, so it's possible.  12 fps may be where we decide that we are
seeing movement rather than a cycle of still images, but that doesn't
mean there is no difference beyond that.  If you draw enough stuff,
your framerate will drop like a rock with sdl, no matter how optomized
your algorithm.  You still have to take into consideration other
programming routines that occur besides just drawing.  I am looking
forward to the gl backend for sdl, that should help level the playing
field.  Although opengl isn't really that difficult to learn.

The main problem is that modern video cards aren't designed for 2d
rendering, so the increase in capability doesn't fit that domain.
Standard resolutions have grown well beyond 320x240, but 2d drawing
routines haven't increased nearly as fast.  And every time the
resolution doubles, the amount of the screen being drawn quadruples.

You could always write a game for gameboy, where the tile engine is
built right in to the hardware :)  Although even then I think you have
to fight the framerate eventually.

On 10/25/07, Ian Mallett [EMAIL PROTECTED] wrote:
 Of course it's pointless to draw nothing.  The framerates are still
 respectable when drawing stuff.  SDL drops to about 40 or 50, OpenGL to
 60-120 depending on the render method.

 One's eyes refresh at about 12 fps, so anything faster than that looks
 fluid.  The amount of smoothness, of course, is dependent on the framerate
 of the screen.  12fps vs. 40fps is a big difference.  After about 60, most
 people can't tell any increase.  I don't care if I can't see it.  It is
 still cool to know that your computer is doing that.

 Ian

Re: [pygame] .png saving

[Patrick Mullen]

I just checked, I do actually have libpng in my pygame folder.  So if
you could bypass SDL_Image and go straight to libpng for saving png
files, it would be extremely useful.  Png has become the standard
format for me, because of the good lossless compression and the alpha
channel support.  By the way, in case you didn't know, PNG is also a
lossless format.

Re: [pygame] Code: Center of Triangle

[Patrick Mullen]

Yeah, shouldn't it be math.sqrt(dist)?

Although you might want to just return the distance^2 so the user can decide
whether a sqrt is necessary or not.

Re: [pygame] time progression independent of game ticks

[Patrick Mullen]

Yeah, a time queue is the way to go, don't bother with threads.  On each
update, you can get the current time (pygame.time, or pygame.clock), and
pass that into your time queue.  The time queue, will look something like
this:

[(5.0,eat,fish1),(6.5,eat,fish2)]

At each iteration, you continue to pop() the list, calling each function
(eat) with the argument (fish1, fish2), until the item on the list has a
time that is greater than the current time.  If you spread out your
scheduling, so there aren't too many fish doing the same thing at the exact
same time, this will scale really well and be a good way to handle timed
events.

As for tracking time, I use pygame.time as well.  I've found pygame.clock to
be inaccurate in some cases, and of course it's not usable in situations
where you don't want to use pygame (server).

I store lasttime = pygame.time.time() at the start of the simulation, then
on each iteration I calculate dt = pygame.time.time()-lasttime;.  Then if I
have some sort of game timer (like your 15 minutes = 1 year) I add the
dt(real time difference) times a modifier (to get game time difference) to
the game time variable.

Re: [pygame] Using PyOpenGL for 2D graphics

[Patrick Mullen]

[EMAIL PROTECTED]:

I use python-ogre, which is a more recent much better version of pyogre by a
different team.  Cegui works with it and is pretty nice, although feels like
overkill for most things.  I have never really looked at sprites or any kind
of 2d stuff with it though, our game is completely 3d.  As a robust 3d
rendering engine, nothing else I know of comes close, at least out of things
usable from python.  It surely has a learning curve though, and its quite
big (which can be a positive and a negative).

Fonts in opengl aren't too difficult, neither is rendering an interface.
You will want to render the interface AFTER you render all the 3d elements,
and turn off the depth buffer before you render it so it is rendered on top
of everything.  There are numerous font systems around, I use some code
treeform gave me on irc which I modified for pygame.  I attached it for
you.  Openglcontext which is somewhat of an addon for pyopengl also has font
code.  Lastly, I once programmed my own font system using the NeHe tutorial
as a guide - it was confusing because there is so much windows api specific
code in that tutorial, but the basic idea is the same - load each letter of
the font as a texture and draw quads with the proper texture.

I attached this code as well, although this is not as well tested or clear.
import pygame
pygame.font.init()
from OpenGL.GL import *
from OpenGL.GLU import *
#from mygl.texture.material import *

def nextPowerOf2 (num):
 If num isn't a power of 2, will return the next higher power of two 
rval = 1
while (rvalnum):
rval = 1
return rval

def setupMatrix():
 sets up the matrix for font drawing 
glPushAttrib(GL_TRANSFORM_BIT)
viewport = glGetIntegerv(GL_VIEWPORT)
glMatrixMode(GL_PROJECTION)
glPushMatrix()
glLoadIdentity()
gluOrtho2D(viewport[0],viewport[2],viewport[1],viewport[3])
glPopAttrib()


def taredownMatrix():
 returns the matrix to the state before setupMatrix 
glPushAttrib(GL_TRANSFORM_BIT)
glMatrixMode(GL_PROJECTION)
glPopMatrix()
glPopAttrib()


class Font:
 very nice font class 

def __init__ (self, name, height=10,antialias=True):
 make a font with font name and font hight 
self.m_allocated = True
self.height = height
self.name = name
self.antialias = antialias
self.sizes = {}
ft = pygame.font.Font(name,height)
self._listStart = glGenLists (128)
self.fontTextures = [None] * 128
for i in xrange (128):
self._makeList (ft, i, self._listStart, self.fontTextures);
ft = None

def setup(self):
glPushMatrix()
glPushAttrib(GL_LIST_BIT | GL_CURRENT_BIT  | GL_ENABLE_BIT | GL_TRANSFORM_BIT)
glMatrixMode(GL_MODELVIEW)
glDisable(GL_LIGHTING)
glEnable(GL_TEXTURE_2D)
glDisable(GL_DEPTH_TEST)
glEnable(GL_BLEND)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)

def tairdown(self):
glPopAttrib()
glPopMatrix()

def printChar(self,character):
glCallList(character+self._listStart)

def flatPrint (self,  string):
 the normal print of a font 
if (string == None or string ==  ):
return
glPushMatrix()
glPushAttrib(GL_LIST_BIT | GL_CURRENT_BIT  | GL_ENABLE_BIT | GL_TRANSFORM_BIT)
glMatrixMode(GL_MODELVIEW)
glDisable(GL_LIGHTING)
glEnable(GL_TEXTURE_2D)
glDisable(GL_DEPTH_TEST)
glEnable(GL_BLEND)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
#glListBase(self._listStart)
glPushMatrix ()
#glCallLists (string)
for char in string:
glCallList(self._listStart+ord(char))
glPopMatrix()
glPopAttrib()
glPopMatrix()

def wrapPrint(self , string, size=(0,0) ):
 prints text in the sized window 
lines = string.split ( \n )
glPushMatrix()
glPushAttrib(GL_LIST_BIT | GL_CURRENT_BIT  | GL_ENABLE_BIT | GL_TRANSFORM_BIT)
glMatrixMode(GL_MODELVIEW)
glDisable(GL_LIGHTING)
glEnable(GL_TEXTURE_2D)
glDisable(GL_DEPTH_TEST)
glEnable(GL_BLEND)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
#glListBase(self._listStart)
h = self.sizes[A][1]
print self._listStart
for i in xrange (len (lines)):
line = lines [i]
if self.getTextSize(line)[0]  size:
width = 0
liner = 
for c in line:
if width + self.sizes[c][0]  size:
 liner += c
 width += self.sizes[c][0]
else:
glPushMatrix ()
#glCallLists(liner) # hope this gets fixed
for character in liner:
  

Re: [pygame] Using PyOpenGL for 2D graphics

[Patrick Mullen]

Yes, there are a lot of things in ogre that are somewhat considered add-ons,
that python-ogre doesnt yet wrap, unfortunately.  You can use pygame to
handle windowing, just like you would in an opengl app, and it works the
same way.  Opengl is given direct access to the contents of the window, so
you wont be drawing typical sdl stuff to the screen like you would like.

It does wrap an impressive amount of code though, quite often I see someone
suggest another thing that needs to be wrapped on the message board, and the
next week the code is there, so the team behind it is really great.  The
future looks very bright, but even as is it feels very complete and
professional to me.

Re: [pygame] Using PyOpenGL for 2D graphics

[Patrick Mullen]

Opengl will be slower than sdl on computers with either bad graphics cards
or bad graphics drivers, but in general it is much much faster.  On the
order of 10 times faster or more for some things.  But you have to code the
opengl way, and not the sdl way.

Directly modifying pixels in a texture is going to be slower than blitting
pixels to the screen, so you will want to use another interface to draw
pixels to a texture and then replace the texture for it to be update on the
screen.  If you can find a way to accomplish what you want without changing
or editing textures, it will probably work a bit better.  On more advanced
cards you can use pixel rendering functions to offset this issue, but that
is less portable.

Another common slowdown with using opengl for 2d is badly sized textures.
Most cards will either have graphical errors or run slowly if any texture is
not a power of 2 in size (256x256, 512x512 etc).  This is not much of a
problem, since you can use scaling of polygons rather than scaling of a
textures pixels in order to make anything look the right size on screen.

Finally, polygon count does matter.  If you use tiles and make a giant map,
say, 10,000 x 10,000, and then blit that whole map to the screen, it will
run incredibly slow.  You have to be just as careful in opengl on how much
data you pass to the renderer as you would have to watch the number and size
of your blits in sdl.

Lastly, display lists or other batch techniques to limit the amount of
functions python has to call are a must.  Python function calls are slow, so
if you are telling opengl to draw each vertex of the entire scene every
frame, it could possibly be slower than the blits would just due to the
python overhead.

I'd like to see what your test was that ran slower in opengl than sdl.
Everything I've done has ran 100-300 fps in opengl versus 40-60fps being
about the max  I've EVER seen SDL run anything.

Re: [pygame] Dirty Rect Animation

[Patrick Mullen]

I'm fairly certain that update does NOT merge incoming rects or do any other
optomization  on input.  It iterates through all of the rects in the list
and updates that portion of the screen.  So you can optimize it
considerably by merging rects where it makes sense, rather than sending a
rect for each of your 1000 sprites you want to draw :)

You could also check out DR0ID's optimized drawing routine and see what he
does.  If I recall, it handles dirty rects.

Re: [pygame] Shining Sea source code

[Patrick Mullen]

My entry for pyweek was similar in idea to your missions game, but everyone
hated the grating marching sound effect...  I suppose the base stuff is also
more sim* than civilization as well though.  We also failed in that you
never got a report of what happened on the mission, you just see how many of
the team members come back (if at all!).  But I've wanted games around this
mechanic for a while.

You can check it out here:
http://media.pyweek.org/dl/4/cent_of_fb/cent_of_fb_0.99.zip
It's very alpha and needs some work to be a real game :(  A week limit and
all...

As for shining sea, it's a nice little demo!  The music is fun, but looks
like it's been stolen :)  The island is a bit big and empty,  and the
objects are not sorted correctly.  You need to sort the onscreen objects
based on y-value so that when the character is in front or behind something
it displays right.  I like where your going with this though, I like any
game that requires eating, ha ha.  Also, as far as I can tell without
looking at code, you are generating the tilemap from the minimap, which is
very cool.

Re: [pygame] Mouse Speed

[Patrick Mullen]

You could try mouse.set_pos, reading the relative movements and then set it
to the center of the screen.  Of course this is extremely annoying for the
user in windows mode, but you would probably only do this in fullscreen
anyway.

Re: [pygame] Path finding demo, now with more fugu

[Patrick Mullen]

As someone who runs a slower-than-average computer, I very much appreciate
games that let me run at 10-15 fps, rather than slowing the game down to
boring speeds or telling me I can't play.  Telling me I can't at least TRY
to play the game with some screen updates missing feels really snobby to
me.  Sure, I'd rather have it run at 30 fps, but at least I can for the most
part enjoy the game at a lower fps.  Games really don't become unplayable
until they are under about 12 fps, so if you say that I have to run it at 30
fps or nothing, that's really cutting off a group of players who could enjoy
the game (nearly) as it was intended.

Yes, games should give at least some cpu time back, and only hog as much cpu
as they need :)  Some games need to hog a lot of it though.

Re: [pygame] Python bots in Galcon (or your game!) safe_eval

[Patrick Mullen]

Yeah I read that warning in the source :)  This is a difficult issue that
many have tried to conquer and failed before, but it's worth looking at
again I think.  I'll try to integrate your script in my silly hacking game
and produce some working scripts for you, although the way I load the
scripts wont be so useful for data.  But scripts that should work aren't as
useful as scripts that shouldn't and those are harder to come up with.

I've started integrating and am running into little problems here and
there.  I'll get back to you this weekend when I've got more time to look at
it.

I'll help with this in any way I can though.

Re: [pygame] PyWeek #4 in April!

[Patrick Mullen]

The problem with this, and it has been discussed before, is that those who
have extensive (internal, or even external but not well documented or
supported) libraries start off with a huge advantage over those who come
into it fresh.  There are quite a few pretty extensive libraries that are in
fact allowed, and you can use your own library as well if you document it,
release it well in advance of the contest, and get it approved.  I've been
working on a massively multiplayer game for a year and a half.  Now I'm
going to take that, put in some models that fit the theme, and call it a
day.  Not so good...

The idea of the contest is sort of to put everyone on a level playing field,
and allow freedom of experimentation.  I don't know about some people, but
when I am limited on time I tend to come up with very unique code design
that I don't often use in my full projects, sometimes I even learn something
from it besides just having a good time :)

A week really is enough time to accomplish some great things or at least a
great start to a new project.  More time than that and it's too easy to put
things off or have feature creep really set in, less time is just too
rushed; although that's an experience in itself.

Re: [pygame] PyWeek #4 in April!

[Patrick Mullen]

Pyweek is a competition, is it not?  An exhibition would be something
entirely different, and allowing more time or loose inclusion of any
libraries would be orthoganal to what pyweek currently is.  A different
thing, that was an exhibition and allowed you to build off of existing code,
would be something completely different.  Which isn't to say that something
like that shouldn't exist :)

I don't think you'd get nearly as many entrants as you do with pyweek, it
would be more of people just showing off what they are working on, which
people can already do anyway (on the pygame.org page, or through various
standard channels).

The competition element of pyweek is part of the creative drive that makes
it work for people, at least for me.  The chance to not worry about
remembring which of my 10,000 functions do what I want, start from scratch,
work on a brand new game with a friend or friends (who i don't have to
teach, except the extreme python basics) is a great opportunity.

I don't look at the from-scratch angle as a burden (oh no, I don't want to
have to code this function AGAIN) but as an opportunity (instead of doing it
like this, since I always do it that way, lets try something different).

And if you have a nice boiler plate library that accomplishes all of the
annoying set up that you don't want to write again, publish it and use it in
the contest :)  Just give others the opportunity to use it as well.

Heh, my online game was a bad example.  It's sort of closed source for the
time being, and not working very well at the moment to boot.  I can
definately see the value in a non-from scratch competition, expo, etc.
Pyweek is so infrequent I would love more opportunities to get ideas and
make cool stuff.  Start something new :)

Re: [pygame] PyWeek #4 in April!

[Patrick Mullen]

Richard wrote:

I should nit-pick here. I'm very careful to call it a challenge and not
a competition. There are no prizes, except kudos. I like it that way 'cos
it means I can enter without fear of being charged with cheating to gain
prizes :)

Yeah this is important.  Prizes would probably mess the whole thing up.  I
don't feel so bad if I miss a compo or if I lose, if there were prizes it
would be more frustrating.  Still, we do vote on winners, so there is a
competitive element.  For me, it's this more than the deadline that gives me
inspiration.  Thanks by the way for running this Richard.  I've only
competed once, but it was a blast.  I'm planning on entering this time
though, I think the timing is actually going to work out.

Greg Ewing wrote:

If the PyGame site isn't suitable, are there any other
sites for Python-based games that would be more
appropriate?


This is a very good point.  Other than pygame.org, I can't think of any
good, standard showcase sites for python games.  Pygame is the most common
library, but there are quite a few others, and more coming down the pike
(pyglet etc).  More than any other kind of project, games are meant to be
shown off.  When I am looking for games to play, pygame is usually the only
place I look, before going to non python places such as happypenguin or
gametunnel.  Perhaps the community should be decentralized a bit from the
libraries.  Although these kinds of developments can often split a community
instead of bringing it together.  Maybe pyweek could be involved?  It
already has a good infrastructure set up, and some good documents covering a
lot of the libraries available.  A standard site for python game development
might not be such a bad idea.

--
If there were to be an exposition type thing, how long would it last?  Same
length of time or more?  Would there be themes as well (but maybe more of a
guideline than a requirement).  Releasing the source would be required of
course.  Maybe instead of running it like a competition, there could be some
sort of awards type thing once a year (pygame oscars!).  They do those game
of the month top ten articles on gametunnel that are always interesting and
help point out independent games that you might not hear about.  Maybe
pygame needs something like that?

Just some ideas to think about.

Can't wait for pyweek to start!

Re: [pygame] Python bots in Galcon (or your game!) safe_eval

[Patrick Mullen]

Sounds cool, and this is an important problem domain for python, even beyond
gaming.  I've been needing this for similar reasons, and the hacks I've been
using are pretty flimsy.

re.sub(script,'import','_no_imports_') FTW