Re: Surfarray

Re: Surfarray

yes Numpy and Numeric will be supported with pygame in the future.

cu.

On Feb 1, 2008 11:05 AM, Ian Mallett <geometrian@...> wrote:
> On Jan 31, 2008 12:12 PM, Lenard Lindstrom <len-l@...> wrote:
>
> > Just dropping in Numpy for Numeric will not always work. And NumArray is
> even less compatible.
> >
> That explains why Numpy didn't work for me.  But I thought Numeric was
> older!  Will the next Pygame support Numpy completely?
>

Re: Drawing/Surface performance

I simplified my create_surface... by keeping copies of the indexed
(greyscale) image and it's palette; but still slow...
I'm wondering -
  Would locking surfaces help
  Is the pygame 1.8 buffer object relevant here?
  Would surarray be quicker?
  The palette manipulation seems like it could def be quicker; but my
python knowledge isn't good enough here.

For performance reference I'm using a 1.5ghz centrino core 2 thingy.

Simplified create_surface:

    def create_surface(self, colour):
        # Check cache
        #p_colour = utils.pack_colour(colour)
        #if p_colour in Block.surface_cache:
        #    return Block.surface_cache[p_colour]

        pal_image = Block.indexed_image.copy()
        # Manipulate the palette
        pal_image.set_palette(self.colourise_palette(Block.indexed_palette,
colour))

        image = pygame.Surface((Block.width, Block.height), pygame.SRCALPHA, 32)
        image.blit(pal_image, (0, 0), image.get_rect())

        # Apply the alpha to our newly colourised image
        pygame.surfarray.pixels_alpha(image)[...] = Block.alpha_channel

        # Add to cache; eviction policy might be nice ;)
        #Block.surface_cache[p_colour] = image

        return image

On 31/01/2008, Stuart Axon <stu.axon+pygame@...> wrote:
> Hello,
>   I'm combining a paletted surface and an alpha surface so I can
> manipulate the colours. As I'm quite new to python + pygame so
> slowness is probably down to me :)
>
> At the moment I cache the surfaces, but if it was realtime it would be
> simpler and not use shedloads of memory.
>
> Both methods seem too slow - especially the palette manipulation
> (commenting that out speeds things up quite a bit).  The rest of the
> code still seems to be slower than I'd expect without the palette code
> enabled; I thought pygame 1.8 might hardware accelerate this, but it
> doesn't seem to make a difference (so I'm using 1.7.1 as 1.8 isn't
> finished).
>
> The game (in progress):                                  (python ballbreaker.py)
> stuartaxon.com/ballbreaker/pygame.zip          - shows the performance
> stuartaxon.com/ballbreaker                             - build with caching
>
>
> Cheers :)
>
> ---------------------------------------------------------------
> These are the relevant two methods from block.py
>
>     ##
>     # Return a surface to represent the block
>     #
>     def create_surface(self, colour):
>         # Check cache
>         #p_colour = utils.pack_colour(colour)
>         #if p_colour in Block.surface_cache:
>         #    return Block.surface_cache[p_colour]
>
>         # Create 8 bit surface and copy our image there
>         pal_image = pygame.Surface((Block.width, Block.height), 0, 8)
>         pal_image.set_palette(Block.indexed_image.get_palette())
>         pal_image.blit(Block.indexed_image, (0, 0))
>
>         palette = Block.indexed_image.get_palette()
>
>         # Manipulate the palette
>         pal_image.set_palette(self.colourise_palette(palette, colour))
>
>         # Create our image palette
>         image = pygame.Surface((Block.width, Block.height), pygame.SRCALPHA, 32)
>         image.blit(pal_image, (0, 0), image.get_rect())
>
>         # Get the alpha channel from our alpha image
>         alpha_channel = pygame.surfarray.array_alpha(Block.alpha_image)
>
>         # Apply the alpha to our newly colourised image
>         pygame.surfarray.pixels_alpha(image)[...] = alpha_channel
>
>         # Add to cache; eviction policy might be nice ;)
>         # Block.surface_cache[p_colour] = image
>
>         return image
>
>     def colourise_palette(self, palette, colour):
>         hls_colour = colorsys.rgb_to_hls(*utils.normalize_colour(colour))
>
>         ##
>         # Function for actually altering the colour
>         def alter_colour(colour):
>             h, l, s = colorsys.rgb_to_hls(*utils.normalize_colour(colour))
>             h = hls_colour[0]
>             l = (hls_colour[1] + l) / 2.0
>             s = 0.95
>             return utils.reformat_colour( colorsys.hls_to_rgb(h, l, s) )
>
>         return map(alter_colour, palette)
>

Re: Re: Drawing/Surface performance

what os?

Have you tried using convert() and convert_alpha() on the surfaces?

I think some OS's are emulating palette changes slowly these days.
Well at least some X11 implementations.

On Feb 1, 2008 12:22 PM, Stuart Axon <stu.axon+pygame@...> wrote:
> I simplified my create_surface... by keeping copies of the indexed
> (greyscale) image and it's palette; but still slow...
> I'm wondering -
>   Would locking surfaces help
>   Is the pygame 1.8 buffer object relevant here?
>   Would surarray be quicker?
>   The palette manipulation seems like it could def be quicker; but my
> python knowledge isn't good enough here.
>
> For performance reference I'm using a 1.5ghz centrino core 2 thingy.
>
> Simplified create_surface:
>
>     def create_surface(self, colour):
>         # Check cache
>         #p_colour = utils.pack_colour(colour)
>         #if p_colour in Block.surface_cache:
>         #    return Block.surface_cache[p_colour]
>
>         pal_image = Block.indexed_image.copy()
>         # Manipulate the palette
>         pal_image.set_palette(self.colourise_palette(Block.indexed_palette,
> colour))
>
>         image = pygame.Surface((Block.width, Block.height), pygame.SRCALPHA, 32)
>         image.blit(pal_image, (0, 0), image.get_rect())
>
>         # Apply the alpha to our newly colourised image
>         pygame.surfarray.pixels_alpha(image)[...] = Block.alpha_channel
>
>         # Add to cache; eviction policy might be nice ;)
>         #Block.surface_cache[p_colour] = image
>
>         return image
>
>
> On 31/01/2008, Stuart Axon <stu.axon+pygame@...> wrote:
> > Hello,
> >   I'm combining a paletted surface and an alpha surface so I can
> > manipulate the colours. As I'm quite new to python + pygame so
> > slowness is probably down to me :)
> >
> > At the moment I cache the surfaces, but if it was realtime it would be
> > simpler and not use shedloads of memory.
> >
> > Both methods seem too slow - especially the palette manipulation
> > (commenting that out speeds things up quite a bit).  The rest of the
> > code still seems to be slower than I'd expect without the palette code
> > enabled; I thought pygame 1.8 might hardware accelerate this, but it
> > doesn't seem to make a difference (so I'm using 1.7.1 as 1.8 isn't
> > finished).
> >
> > The game (in progress):                                  (python ballbreaker.py)
> > stuartaxon.com/ballbreaker/pygame.zip          - shows the performance
> > stuartaxon.com/ballbreaker                             - build with caching
> >
> >
> > Cheers :)
> >
> > ---------------------------------------------------------------
> > These are the relevant two methods from block.py
> >
> >     ##
> >     # Return a surface to represent the block
> >     #
> >     def create_surface(self, colour):
> >         # Check cache
> >         #p_colour = utils.pack_colour(colour)
> >         #if p_colour in Block.surface_cache:
> >         #    return Block.surface_cache[p_colour]
> >
> >         # Create 8 bit surface and copy our image there
> >         pal_image = pygame.Surface((Block.width, Block.height), 0, 8)
> >         pal_image.set_palette(Block.indexed_image.get_palette())
> >         pal_image.blit(Block.indexed_image, (0, 0))
> >
> >         palette = Block.indexed_image.get_palette()
> >
> >         # Manipulate the palette
> >         pal_image.set_palette(self.colourise_palette(palette, colour))
> >
> >         # Create our image palette
> >         image = pygame.Surface((Block.width, Block.height), pygame.SRCALPHA, 32)
> >         image.blit(pal_image, (0, 0), image.get_rect())
> >
> >         # Get the alpha channel from our alpha image
> >         alpha_channel = pygame.surfarray.array_alpha(Block.alpha_image)
> >
> >         # Apply the alpha to our newly colourised image
> >         pygame.surfarray.pixels_alpha(image)[...] = alpha_channel
> >
> >         # Add to cache; eviction policy might be nice ;)
> >         # Block.surface_cache[p_colour] = image
> >
> >         return image
> >
> >     def colourise_palette(self, palette, colour):
> >         hls_colour = colorsys.rgb_to_hls(*utils.normalize_colour(colour))
> >
> >         ##
> >         # Function for actually altering the colour
> >         def alter_colour(colour):
> >             h, l, s = colorsys.rgb_to_hls(*utils.normalize_colour(colour))
> >             h = hls_colour[0]
> >             l = (hls_colour[1] + l) / 2.0
> >             s = 0.95
> >             return utils.reformat_colour( colorsys.hls_to_rgb(h, l, s) )
> >
> >         return map(alter_colour, palette)
> >
>

Re: Re: Drawing/Surface performance

Re: Re: Drawing/Surface performance

Could you cache an image with each of the different palettes set, then
instead of set_palette do copy(), then blit?  I'm not sure if that'd
be faster.

Have you timed each part of your function to make sure that's the slow part?

If on linux/osx use time.time otherwise time.clock on windows.

t0 = time.time()
# part 1
t1 = time.time()
# part 2
t2 = time.time()
# part 3
t3 = time.time()

cu.

On Feb 1, 2008 12:35 PM, René Dudfield <renesd@...> wrote:
> what os?
>
> Have you tried using convert() and convert_alpha() on the surfaces?
>
> I think some OS's are emulating palette changes slowly these days.
> Well at least some X11 implementations.
>
>
>
>
> On Feb 1, 2008 12:22 PM, Stuart Axon <stu.axon+pygame@...> wrote:
> > I simplified my create_surface... by keeping copies of the indexed
> > (greyscale) image and it's palette; but still slow...
> > I'm wondering -
> >   Would locking surfaces help
> >   Is the pygame 1.8 buffer object relevant here?
> >   Would surarray be quicker?
> >   The palette manipulation seems like it could def be quicker; but my
> > python knowledge isn't good enough here.
> >
> > For performance reference I'm using a 1.5ghz centrino core 2 thingy.
> >
> > Simplified create_surface:
> >
> >     def create_surface(self, colour):
> >         # Check cache
> >         #p_colour = utils.pack_colour(colour)
> >         #if p_colour in Block.surface_cache:
> >         #    return Block.surface_cache[p_colour]
> >
> >         pal_image = Block.indexed_image.copy()
> >         # Manipulate the palette
> >         pal_image.set_palette(self.colourise_palette(Block.indexed_palette,
> > colour))
> >
> >         image = pygame.Surface((Block.width, Block.height), pygame.SRCALPHA, 32)
> >         image.blit(pal_image, (0, 0), image.get_rect())
> >
> >         # Apply the alpha to our newly colourised image
> >         pygame.surfarray.pixels_alpha(image)[...] = Block.alpha_channel
> >
> >         # Add to cache; eviction policy might be nice ;)
> >         #Block.surface_cache[p_colour] = image
> >
> >         return image
> >
> >
> > On 31/01/2008, Stuart Axon <stu.axon+pygame@...> wrote:
> > > Hello,
> > >   I'm combining a paletted surface and an alpha surface so I can
> > > manipulate the colours. As I'm quite new to python + pygame so
> > > slowness is probably down to me :)
> > >
> > > At the moment I cache the surfaces, but if it was realtime it would be
> > > simpler and not use shedloads of memory.
> > >
> > > Both methods seem too slow - especially the palette manipulation
> > > (commenting that out speeds things up quite a bit).  The rest of the
> > > code still seems to be slower than I'd expect without the palette code
> > > enabled; I thought pygame 1.8 might hardware accelerate this, but it
> > > doesn't seem to make a difference (so I'm using 1.7.1 as 1.8 isn't
> > > finished).
> > >
> > > The game (in progress):                                  (python ballbreaker.py)
> > > stuartaxon.com/ballbreaker/pygame.zip          - shows the performance
> > > stuartaxon.com/ballbreaker                             - build with caching
> > >
> > >
> > > Cheers :)
> > >
> > > ---------------------------------------------------------------
> > > These are the relevant two methods from block.py
> > >
> > >     ##
> > >     # Return a surface to represent the block
> > >     #
> > >     def create_surface(self, colour):
> > >         # Check cache
> > >         #p_colour = utils.pack_colour(colour)
> > >         #if p_colour in Block.surface_cache:
> > >         #    return Block.surface_cache[p_colour]
> > >
> > >         # Create 8 bit surface and copy our image there
> > >         pal_image = pygame.Surface((Block.width, Block.height), 0, 8)
> > >         pal_image.set_palette(Block.indexed_image.get_palette())
> > >         pal_image.blit(Block.indexed_image, (0, 0))
> > >
> > >         palette = Block.indexed_image.get_palette()
> > >
> > >         # Manipulate the palette
> > >         pal_image.set_palette(self.colourise_palette(palette, colour))
> > >
> > >         # Create our image palette
> > >         image = pygame.Surface((Block.width, Block.height), pygame.SRCALPHA, 32)
> > >         image.blit(pal_image, (0, 0), image.get_rect())
> > >
> > >         # Get the alpha channel from our alpha image
> > >         alpha_channel = pygame.surfarray.array_alpha(Block.alpha_image)
> > >
> > >         # Apply the alpha to our newly colourised image
> > >         pygame.surfarray.pixels_alpha(image)[...] = alpha_channel
> > >
> > >         # Add to cache; eviction policy might be nice ;)
> > >         # Block.surface_cache[p_colour] = image
> > >
> > >         return image
> > >
> > >     def colourise_palette(self, palette, colour):
> > >         hls_colour = colorsys.rgb_to_hls(*utils.normalize_colour(colour))
> > >
> > >         ##
> > >         # Function for actually altering the colour
> > >         def alter_colour(colour):
> > >             h, l, s = colorsys.rgb_to_hls(*utils.normalize_colour(colour))
> > >             h = hls_colour[0]
> > >             l = (hls_colour[1] + l) / 2.0
> > >             s = 0.95
> > >             return utils.reformat_colour( colorsys.hls_to_rgb(h, l, s) )
> > >
> > >         return map(alter_colour, palette)
> > >
> >
>

Re: Surfarray

And the release order of the various array modules from oldest to newest 
was Numeric, NumArray, Numpy. Only Numpy is actively supported.

Lenard

René Dudfield wrote:
> yes Numpy and Numeric will be supported with pygame in the future.
>
>
> cu.
>
> On Feb 1, 2008 11:05 AM, Ian Mallett <geometrian@...> wrote:
>   
>> On Jan 31, 2008 12:12 PM, Lenard Lindstrom <len-l@...> wrote:
>>
>>     
>>> Just dropping in Numpy for Numeric will not always work. And NumArray is
>>>       
>> even less compatible.
>>     
>> That explains why Numpy didn't work for me.  But I thought Numeric was
>> older!  Will the next Pygame support Numpy completely?
>>
>>     

Re: wxPython Message Window returns in Pygame

Re: LAN vs Internet

Thanks to all for your input.   I have tentatively decided to skip all
the local discovery stuff and just rely on an internet server being
accessible.  A simple LAN-scope server may happen later.

I did look at the 'rendezvous' type libraries, and they would be
attractive for a LAN-only game, but trying to share peer listings
between the 'rendezvous' source and internet server source seemed to
reintroduce the complexity.

David

On 1/31/08, Marius Gedminas <mgedmin@...> wrote:
> On Thu, Jan 31, 2008 at 12:43:45PM -0500, David wrote:
> > I have been making gentle progress towards a networking module for my
> > game, but have doubts about the value of my approach.
> >
> > I have been working toward the goal of having a module that will find
> > peers on a LAN, via a UDP discovery process, or on an internet server.
> > The game is basically a one-on-one contest, so the player-finding
> > process is just to setup matches, and not as a many-playered universe.
> >
> > The UDP discovery process makes the whole module much more complex,
> > and I am wondering whether it has any real value.
>
> Perhaps you could make it simpler by reusing an existing implementation
> of Zeroconf, e.g. Avahi:
> http://en.wikipedia.org/wiki/Avahi_(software)
>
> It's LGPL, so no licence taint.  It's also cross-platform.  And it has
> Python bindings.  OTOH it might make the distribution of the game
> somewhat more complicated (another library to install).
>
> > Do any of you play network games on a LAN that is *not* internet
> > connected?  How common is that usage case?
>
> I don't play multiplayer games much.
>
> > I ask, because if LANs are generally internet connected, the game can
> > just use an internet server to find competitors, including those
> > within that LAN.
>
> That would require the server to proxy all communications between
> players, to work with NATed LANs.  Is the latency decrease worth
> maintaining complex code?  You decide.
>
> Marius Gedminas
> --
> Never assume the reader has read the subject line.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHoh+dkVdEXeem148RAujaAJ9CHgooCDhjy4VCGwd6N2GmQfe9zQCeP9d6
> 58Faz3jAF38yAAuyE9notM4=
> =7ax6
> -----END PGP SIGNATURE-----
>
>

--

-- 
dkeeney@...
Pitcher's Duel -> pitchersduel.python-hosting.com

layers and/or tiles?

Please excuse the beginner type questions and I will gladly accept
redirection/pointers/link to documentation that will assist.

I would like to create an interface for a game that will run on a
limited size display 800x480 (ie Nokia tablet N800).  In order to be
able to have access to a lot of different information, I would like to
be able to put some information on a tile/layer/window that would slide
out from the side of the display.  Then when done viewing it, tap it
(ie, the tablet doesn't use a mouse) and it slide back to the left.
Actually, I would like to have several of these sliding windows come
from the left of the display and one or two from the right.  These
windows would come out about 1/4 of the display when "pulled out".  The
game is a card game, so the main display would show one players hand.
Then with a tap from the top of the screen, there would be another
sliding window that would come over the main players display and show
the other players hand.  There would be a graphic "knob" to tap to pull
out that appropriate window.

Obviously, I am not experienced with pygame, but the question, is there
something like this concept already built into pygame. Would this be
accomplished by a tile? Or, is there some other concept of a rectangular
area that can be defined that can have various graphical images and
fonts drawn on it, that can be animated to appear to slide out from the
side and over top the bottom screen (hence my thought of layers).

Any pointers would be welcome.
Gregg