pygame-users archive @ ASPN

Re: [pygame] pass by reference

On Jun 21, 2006, at 7:38 PM, spotter . wrote:

> I am trying to optimise on loading images and I was wondering if
> images as passed by reference or if a new copy is made.

*Everything* in Python is passed by reference (a PyObject* from C).  
The "value types" are still by reference (int, float, str, tuple,  
bool, etc.) but are immutable.

-bob

Re: [pygame] pass by reference

Thanks for all your replies, and for
clearing that up!

spot.

On 6/21/06, Rene Dudfield  Yeah, surfaces don't get copied unless you do it specifically with the
> surf.copy() method.
>
>
> def load_into_cache(fname):
>     if not cache.has_key(fname):
>	  cache[fname] = pygame.image.load(fname)
>     return cache[fname]
>
> Yes, update can take a list of rectangles.
>

On 6/22/06, Luke Paireepinart  spotter . wrote:
> > Hey everybody,
> >
> > I am trying to optimise on loading images and I was wondering if
> > images as passed by reference or if a new copy is made.
> >
> > I want to load one image and use that as the image many instances of a
> > class.
> >
> > Right now, my code looks like this:
> >
> > def __init__(self):
> >   self.image, self.rect = loadimage.load_image("enemy.png", -1)
> >
> > This obviously loads the image for every instance of the class.
> >
> > I was reading this webpage:
> >
http://www.learningpython.com/2006/03/19/creating-a-game-in-python-using-pygame-part-two-cr
eating-a-level/
> >
> > and the code in there loads all the images in a function and passes it
> > off to each class.
> >
> > I just wanted to know if it passed by reference or not, if not there
> > would be no point in changing the code since there is no real
> > advantage to doing it the other way.
> >
> > Also I had a question about pygame.display.update(), Do I pass it the
> > rectangles that I want to update? Can I give it a list of rectangles?
> >
> > Thanks for all your help and patience,
> > spot.
> >
> Even if surfaces were not pass-by-reference, the way you're doing it,
> the file has to be reopened x number of times,
> where x = the number of class instances that use it.
> However, if you passed a surface copy (which is not what is happening)
> then the file wouldn't have to be loaded from disk
> but just copied within RAM, which should be faster.
> Either way, as Rene said, they're pass by reference.
> -Luke
>

Re: [pygame] How to make a (fast) smooth movement on 30 frames

Hi,

On 6/22/06, Richard Jones  On Thursday 22 June 2006 18:29, Sami Hangaslammi wrote:
> > Even if you only have two static sprites, I'm presuming you are
> > re-painting the whole screen. For software surfaces, this is done
> > entirely by the CPU.

Yes, but that's not the reason. See below.


> Also, and this is an FAQ I guess, if you're asking clock.tick() for a frame
> rate of > 40 or so then tick() will busy-loop to get the timing right.

Yeah, that's it. Thanks. I thought the reason was my ugly
update-handling but the cpu usage of 100%
occures even when I draw nothing to the screen:

import pygame
from pygame.locals import *

pygame.init()
screen = pygame.display.set_mode((800,600))
clock = pygame.time.Clock()

while 1:
    for event in pygame.event.get():
	if event.type == KEYDOWN:
	    if event.key == K_ESCAPE:
		sys.exit()

    clock.tick(60)

Causes ~98% cpu usage.


>     Richard

Thanks to all of you. :-)

Re: [pygame] How to make a (fast) smooth movement on 30 frames

On Thursday 22 June 2006 18:29, Sami
Hangaslammi wrote:
> On 6/22/06, Kai Kuehne  > Thanks for the explanation.
> > I'm just wondering *what* causes the nearly 100% cpu time.
> > Currently, there's only the player-ship and one enemy on the screen.
> > And they don't move. ;-)
>
> Even if you only have two static sprites, I'm presuming you are
> re-painting the whole screen. For software surfaces, this is done
> entirely by the CPU.

Also, and this is an FAQ I guess, if you're asking clock.tick() for a frame 
rate of > 40 or so then tick() will busy-loop to get the timing right.


    Richard

Re: [pygame] How to make a (fast) smooth movement on 30 frames

On 6/22/06, Kai Kuehne  Thanks for the explanation.
> I'm just wondering *what* causes the nearly 100% cpu time.
> Currently, there's only the player-ship and one enemy on the screen.
> And they don't move. ;-)

Even if you only have two static sprites, I'm presuming you are
re-painting the whole screen. For software surfaces, this is done
entirely by the CPU.

-- 
Sami Hangaslammi

Re: [pygame] How to make a (fast) smooth movement on 30 frames

Hi Patrick,

On 6/22/06, Patrick Mullen  [Explaining when to use dirty rects...]

Thanks for the explanation.
I'm just wondering *what* causes the nearly 100% cpu time.
Currently, there's only the player-ship and one enemy on the screen.
And they don't move. ;-)

I know.. the glass spheres are expensive at this time.
Maybe I could post a piece of code, so you can look at it.

Kai

Re: [pygame] How to make a (fast) smooth movement on 30 frames

Depends on how many dirty rects you have
versus how many pixels you really
need to update.  Even with a starfield, there will be many pixels which stay
black from frame to frame.  In my experience, dirty rects almost always
helps, unless the dirty rects would take up 80% of the screen.	You can
always code it to work with dirty rects, and then it's very easy to test
which method is faster by not passing the rects to the update function.  You
could even have it use rects until a certain amount of objects are onscreen
and then switch methods.  In my shooter test, I am using dirty rects
combined with moving objects for the background (instead of a full scrolling
background) to keep the framerate up.  Feel like I should really be using
opengl though, lol.

Re: [pygame] How to make a (fast) smooth movement on 30 frames

Hey guys,
I've tested the game under linux and there it simply doesn't run. =)
I blit each object at each frame to the screen. This cannot be good.

But... it is efficient to use dirty rects in a space shooter? Everything
is moving and floating around... especially if there is a moving starfield.

Thanks
Kai

Re: [pygame] pass by reference

spotter . wrote:
> Hey everybody,
>
> I am trying to optimise on loading images and I was wondering if
> images as passed by reference or if a new copy is made.
>
> I want to load one image and use that as the image many instances of a 
> class.
>
> Right now, my code looks like this:
>
> def __init__(self):
>   self.image, self.rect = loadimage.load_image("enemy.png", -1)
>
> This obviously loads the image for every instance of the class.
>
> I was reading this webpage:
>
http://www.learningpython.com/2006/03/19/creating-a-game-in-python-using-pygame-part-two-cr
eating-a-level/ 
>
> and the code in there loads all the images in a function and passes it
> off to each class.
>
> I just wanted to know if it passed by reference or not, if not there
> would be no point in changing the code since there is no real
> advantage to doing it the other way.
>
> Also I had a question about pygame.display.update(), Do I pass it the
> rectangles that I want to update? Can I give it a list of rectangles?
>
> Thanks for all your help and patience,
> spot.
>
Even if surfaces were not pass-by-reference, the way you're doing it, 
the file has to be reopened x number of times,
where x = the number of class instances that use it.
However, if you passed a surface copy (which is not what is happening) 
then the file wouldn't have to be loaded from disk
but just copied within RAM, which should be faster.
Either way, as Rene said, they're pass by reference.
-Luke

Re: [pygame] How to make a (fast) smooth movement on 30 frames

, but I guess what you'd do is save the
previous frame (using Pygame's existing double-buffering ability?) and
for moving objects, blit it beneath the current frame with high alpha,
leaving a ghost of it on the screen.
>
>
>
Oddworld Abe's Oddysee and Exodus both used a similar method.  The moving
sprites had shadow versions of themselves at a lower z-plane.  These shadow
versions were all black, at increasing alphas.	There were about 4-6 for
Abe.  They sort of trailed behind Abe by few milliseconds.  The net effect
was that the sprites appeared to animate more smoothly and seemed to have
more depth.

-- 
Andrew Ulysses Baker
"failrate"