[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] OpenGL stretch of a pygame.Surface



vertpingouin,

If you are doing that every frame as part of the sprite's .draw or .update method , it's still possible the transform is what is taking up CPU time. ÂYou may want to use something like this instead:

class MySpriteThing( pygame.sprite.Sprite):
  image = None
  def __init___( self ):

    .....
    if MySpriteThing.image is None:
      MySpriteThing.image = pygame.image.load( "foo.png" )
      size = MySpriteThing.image.get_size()
      new_width = size[0] * X_SCALE # where X_SCALE is the ratio between RESOLUTION_X (the big resolution) and GRAPHICS_X (the resolution the images were made at) ; ( 1920 / 640 )
      new_height = size[1] * Y_SCALE
      MySpriteThing..image = pygame.transform.scale( self.image, ( new_width, new_height ) )Â

    self.image = MySpriteThing.image

........

# then, in your main loop, blit the sprite's .image attribute to your display surface

mySpriteGroup.draw( screen )

pygame.display.update()



On Mon, Jul 28, 2014 at 4:41 PM, vertpingouin <sylvain.boussekey@xxxxxxxxxxxxxxx> wrote:
to Sam :
I'm using HWSURFACE flag but I got exatly the same framerate. The ideal
would be to rewrite everything in openGL but I don't know it well...
yet.

to Noel:
On the topic of performing transform one time only, I'm not sure what
mean here. If I scale my surface one time, it gets, say, 1920x1080, but
then blitting is done only of a 640x480 part of the surface... So maybe
I misunderstood something here.

I'm using this to transform :

pygame.transform.scale(self.native, (SCREENWIDTH, SCREENHEIGHT),
self.screen)

where native is the little one and screen the big one. I assume that
self.native is scaled then blit onto self.screen...

I think this is the blitting that is slow because if I use a lesser
resolution for self.screen, I almost get back my precious frames per
second.

It will be really cool to send my little native surface to my graphic
card, then let it scale by itself. Don't know if it's even possible.


Le lundi 28 juillet 2014 Ã 11:50 -0400, Noel Garwick a Ãcrit :
> Right now you are blitting tiles to a 640x480 surface, and then
> performing a transform on the whole surface and then blitting it to
> the display?
>
>
> If this is the case, then try to only perform the scale operation when
> the resolution is changed (instead of once each frame) and see how
> that works. ÂI know you mentioned that the full screen blit operation
> seems to be the main bottleneck, but this should help too.
>
>
>
>
>
>
>
> On Mon, Jul 28, 2014 at 7:32 AM, Sam Bull <sam.hacking@xxxxxxxx>
> wrote:
> Â Â Â Â On lun, 2014-07-28 at 06:54 +0200, VertPingouin wrote:
> Â Â Â Â > So I came up with the idea of an hardware opengl texture
> Â Â Â Â stretching
> Â Â Â Â > instead of a dumb blit but I don't know how to achieve it.
> Â Â Â Â >
> Â Â Â Â > Anyone has already done this ?
> Â Â Â Â >
>
>
> Â Â Â Â You would just need to code the graphics in OpenGL without
> Â Â Â Â using
> Â Â Â Â pygame.Surface and pygame.draw. First though, check you are
> Â Â Â Â using the
> Â Â Â Â HWSURFACE flag, if you are running fullscreen, it's possible
> Â Â Â Â this might
> Â Â Â Â provide the necessary speedup without going to OpenGL.
>
> Â Â Â Â http://www.pygame.org/docs/ref/display.html#pygame.display.set_mode
>
>