Pygame Performance Issues

[j0n]

Hi,


I just recently got my pandora (last week) and I said I would have a look at the pygame performance issues people are having, and the feasibility of using HWSURFACE on the pandora.


What I need is some examples of code people think run "too slowly". Examples from games you're working on are fine, as long as you don't mind sharing the code.


I will then test these and try and get an idea of what the bottlenecks in pygame are.


I will also look at whether we can use HWSURFACE in pygame or not.


Thanks,


j0n.

 

[clop]

Hi,


Check this:


http://bugs.openpandora.org/index.php?do=details&task_id=121


There is an example in the comment.

 

[Tempel]

Robo Hell, by richiz (on repo, and source code)


BubbMan2, by pymike, packaged by me (on repo, and source code). The latest version of the source removes the alpha channel from all images, but I'm told that didn't really affect performance. Therefore, the PND contains slightly older code that still uses alpha.


Good luck, and thanks!

 

[j0n]

Thanks for the replies, I've been working on this for the past couple of days a little bit each day.


So this problem can be reduced to getting HWSURFACEs to work in SDL, then seeing how this can be done in pygame.


This is the test script I have been using:

import pygame


pygame.init()


# HWSURFACE and FULLSCREEN

pygame.display.set_mode((0,0),pygame.HWSURFACE | pygame.FULLSCREEN)

info = pygame.display.Info()

print(info)

import pygame


pygame.init()


# HWSURFACE and FULLSCREEN

screen = pygame.display.set_mode((0,0),pygame.HWSURFACE | pygame.FULLSCREEN)

info = pygame.display.Info()

print(info)

print "HWSURFACE:"

print screen.get_flags() & 0x00000001

print "HWACCEL:"

print screen.get_flags() & 0x00000100

which gives output:

[j0n@myhost pygame_perf]$ ./test.py 

<VideoInfo(hw = 0, wm = 1,video_mem = 0

	     blit_hw = 0, blit_hw_CC = 0, blit_hw_A = 0,

	     blit_sw = 0, blit_sw_CC = 0, blit_sw_A = 0,

	     bitsize  = 32, bytesize = 4,

	     masks =  (16711680, 65280, 255, 0),

	     shifts = (16, 8, 0, 0),

	     losses =  (0, 0, 0, 8),

	     current_w = 1920, current_h = 1080

>


HWSURFACE:

0

HWACCEL:

0

so basically I want the blit_hw flags and every other HW related entry to go to 1.



Found a couple of useful references:

http://linuxdevcenter.com/pub/a/linux/2003/08/07/sdl_anim.html

This basically says that on linux you need to set the environment variable :

SDL_VIDEODRIVER=dga

which unfortunantly ends up with :

[j0n@myhost pygame_perf]$ SDL_VIDEODRIVER=dga ./test.py 

Traceback (most recent call last):

  File "./test.py", line 20, in <module>

    pygame.display.set_mode((0,0),pygame.HWSURFACE | pygame.FULLSCREEN | pygame.OPENGL)

pygame.error: No available video device

Not fun. If anyone is an expert on using the dga modules, that would be awesome.


Otherwise I'm going to hack away at this and see what I can do. I think the problem is that dga needs to be enabled in xorg.conf, but I can't find any examples of how to do this online, I've tried including it as a new module but that didn't do anything.

 

[darfgarf]

if you're testing sdl you should probably use C, at least then you can easily debug it to find exactly what sdl is doing (once you compile a debug version that is


python is nice and all, but debugging it is a right pain

 

[j0n]

Hi Sorry for the lack of replies, I am still working on this, wondering if anyone knows if there are any examples of C++ SDL using something HW_SURFACE intensive, something where there is a significant speedup.


I can't really think of any at the moment. Maybe rendering lots of triangles at once and seeing how fast I can refresh?

 

[Farox]

Maybe is not what you are searching for...but i have compiled for Pandora a version of the GPMark (code by Optimus) a little benchmark for the GPH console GP2X/Wiz and Caanoo .


It use SW_SURFACE but maybe with little code changes it will be usefull for you.


link at gp32x.de forum http://www.gp32x.de...post__p__945172


Here a summary of the result:

Pandora 320*240 windowed


My results


Blitting Test: 783.3


Plasma: 427.5


Rotozoomer: 365.0


Rotozoomer Near: 446.9


Rotozoomer Far: 245.8


Radial Blur: 69.7


3D Bunny: 11.1


**********************


Pandora 640*480 windowed


My results


Blitting Test: 226.2


Plasma: 116.0


Rotozoomer: 93.2


Rotozoomer Near: 123.9


Rotozoomer Far: 64.8


Radial Blur: 15.6


3D Bunny: 10.5


***********************


and


GP2X version under GINGE


My results


Blitting Test: 960.3


Plasma: 517.5


Rotozoomer: 401.1


Rotozoomer Near: 513.3


Rotozoomer Far: 248.5


Radial Blur: 66.4


3D Bunny: 9.9

 

[relliker]

If this thread is still relevant, I found that the greatest speed increase I have gotten so far in python/pygame was when I initialised the screen surface without specifying the colour depth (bitplanes) and letting pygame decide the best option for my hardware.

 

[diligentcircle]

If this thread is still relevant, I found that the greatest speed increase I have gotten so far in python/pygame was when I initialised the screen surface without specifying the colour depth (bitplanes) and letting pygame decide the best option for my hardware.

This is something the Pygame docs specifically recommend, so I'd see it as common sense, to be honest.

 

[relliker]

This is something the Pygame docs specifically recommend, so I'd see it as common sense, to be honest.

Agreed, but I only found this out when running the same program for the first time on the Pandora and got terrible performance there. I did most of the development on a win PC and did not read up on any optimisation methods before that as there were never any issues. I read (past tense) the documentation mostly as a syntax/parameter reference so the effect on performance escaped me at first. Maybe this could serve as a heads-up for others just starting in python/pygame (like me, after all)!