Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Code exceptionally slow - is this just Python's limit?

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 The Communist Duck   Members   -  Reputation: 154


Posted 18 April 2011 - 02:35 AM

I don't mean to start a flame war, and I am pretty sure it is fault of mine not of Python for being a high level language.

I am making a tile based RPG. Needless to say, I have tiles.
For display, I have a 2D list of 60*40 pyglet sprites. Each frame (currently I'm running on a wait-for-user-input system, simply to try and get it working) I will iterate through a list of tiles that I can see, and set each tile on the screen to the same type. Obviously this is going to be slow.

I can't think of a better way. Here is some code:

 def Update(self):
    	for t, x, y in self.camera.GetView(self.width, self.height):
        	t = tile.DebugTile1() if random.randint(0,1) == 1 else tile.DebugTile2() #this is just so I can see the results.
        	self.window.SetTile(x, y, t)

 def SetTile(self, x, y, tile):
    	self.spriteList[y][x].image = self.GetTileTexture(tile) #spritelist is a list of sprites, and GetTileTexture is a caching function that stores tile textures

I also tried just changing the sprite texture instead of the whole sprite, but that was actually slower.

Here are the important parts of the profiling:
15085326 function calls (15085306 primitive calls) in 32.166 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000   32.168   32.168 <string>:1(<module>)

       99    0.743    0.008   20.531    0.207 engine.py:58(Update)

   237600    0.796    0.000   11.995    0.000 sprite.py:349(_set_texture)
   120121    0.677    0.000    9.062    0.000 sprite.py:365(_create_vertex_list)
   357721    1.487    0.000    3.478    0.000 sprite.py:377(_update_position)

   420767    0.786    0.000    2.054    0.000 vertexbuffer.py:421(get_region)
   715442    0.859    0.000    1.280    0.000 vertexbuffer.py:467(invalidate)

        1    9.674    9.674   32.168   32.168 win32.py:46(run)
      180    0.007    0.000    1.771    0.010 win32.py:83(_timer_func)

   237600    0.416    0.000   17.069    0.000 window.py:60(SetTile)
   237600    0.646    0.000    2.174    0.000 window.py:72(GetTileTexture)
I am no good at reading these, but it seems a lot of time was spent in the update loop - so I doubt it's a drawing issue. To get these, I just hit the keyboard somewhat to force it to update, so there are times of idle and times of quick updating.

Almost all the time in Update was in SetTile, so I assume my method of keeping things on the screen was a bad idea. I doubt blitting images is going to be any faster than a sprite batch.

Any ideas? (Python/pyglet, I do not want to go to Pygame)


#2 Hodgman   Moderators   -  Reputation: 35086


Posted 18 April 2011 - 07:02 AM

It looks like assigning a new image to a tile is quite slow - is there any way you can reduce the number of times that you do that? Perhaps you can check if blah.image is already correct before performing the assignment, or some such. Or instead of swapping out images, can you show/hide different sets of sprites?

Pyglet isn't the most high-performance library - it was designed to be written in pure python, rather than dropping down to C for performance critical parts. FWIW it was written by a charlatan academic who's highest achievement in the industry is an iPhone game (not made in python).

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.