[Sugar-devel] Testing the activity bundle of my activity before submitting it to ASLO.
James Cameron
quozl at laptop.org
Mon Sep 30 18:25:26 EDT 2013
On Sat, Sep 28, 2013 at 01:42:50PM +0200, laurent bernabe wrote:
> But as the computer where I inserted the key was a very old one (it
> has an old AMD processor and it seems to me it has just 1GB of RAM),
> the animation where too slow : very slower than the result I got on
> my laptop (which has two processor at 2.19 Ghz).
>
> Apart this, it works, and I should submit the bundle to ASLO soon.
I suggest fixing performance soon.
On Sat, Sep 28, 2013 at 05:54:30PM +0200, laurent bernabe wrote:
> As my computer has 2*2.16Ghz processor, is it possible to configure
> sugar-build so that the speed is "locked" under 433 Mhz ?
No.
You raise an important issue though. You must tune your activity so
that it works on the slowest hardware you support. The CPU clock
isn't the only cause of slowness.
Looking at your:
git://git.sugarlabs.org/hittheballs/hittheballs
in particular at hash 4533d1f2be64ef74d34129cf388919cfa36c8e91
In main_game.py you have chosen 40 frames per second for self._FPS.
This is a very high rate for an OLPC XO-1. You should lower this
number as much as possible until just before the game is unpleasant
for a new user.
The reason this number is important is that it determines the CPU
processing required for display update between each opportunity to
respond to input.
The display update pipe is a work queue. If the update rate is too
high, then the main_game.py will _pause_ briefly on line 223, and this
pause will prevent main_game.py from responding quickly to keyboard or
mouse events.
Also, you must add a call to self._clock.tick(self._FPS) when
game_state is not NORMAL, and while in show_menu, otherwise the
display update pipe will be flooded, and you _will_ have delays and
massive power use, shorter battery time.
If after doing the above the performance is still too slow, then a
more advanced display update method is required. I use this method in
the Netrek game client Gytha. The method is to maintain a list of
rectangles that have been dirtied, and only update those rectangles
instead of the whole canvas.
(by the way, you should rename gpl-3.0.txt to COPYING, because that is
the conventional name)
Below is a patch showing some of the performance changes mentioned
above:
diff --git a/main_game.py b/main_game.py
index 110ebf3..0e23fd9 100644
--- a/main_game.py
+++ b/main_game.py
@@ -60,7 +60,7 @@ class Game:
return
pygame.init()
self._LEFT_BUTTON = 1
- self._FPS = 40
+ self._FPS = 10
self._MENU_LEVELS_RECTS_Y_GAP = 30
self._MENU_LEVELS_RECTS_WIDTH = 345
self._MENU_LEVELS_RECTS_HEIGHT = 60
@@ -220,6 +220,8 @@ class Game:
pygame.time.set_timer(USEREVENT + 2, 1000)
while True:
+ while Gtk.events_pending():
+ Gtk.main_iteration()
pygame.display.update()
self._screen.fill(self._GAME_BACKGROUND)
paint_result_bar(result_bar, self._screen)
@@ -228,9 +230,6 @@ class Game:
for ball in the_balls:
paint_ball(ball, self._screen)
- while Gtk.events_pending():
- Gtk.main_iteration()
-
for event in pygame.event.get():
if event.type == QUIT:
pygame.quit()
@@ -253,7 +252,6 @@ class Game:
game_state = GameState.WON
else:
game_state = GameState.LOST
- self._clock.tick(self._FPS)
for ball in the_balls:
ball.move()
balls_collision.manage_colliding_balls(the_balls)
@@ -270,9 +268,6 @@ class Game:
self._RED)
self._screen.blit(end_txt_surface, self._END_TXT_POS)
- while Gtk.events_pending():
- Gtk.main_iteration()
-
for event in pygame.event.get():
if event.type == QUIT:
pygame.quit()
@@ -282,6 +277,7 @@ class Game:
elif event.type == MOUSEBUTTONUP:
if event.button == self._LEFT_BUTTON:
return
+ self._clock.tick(self._FPS)
def show_menu(self):
"""
@@ -324,3 +320,4 @@ class Game:
self._play_game(
30,
self._levels[selected_level_index])
+ self._clock.tick(self._FPS)
--
James Cameron
http://quozl.linux.org.au/
More information about the Sugar-devel
mailing list