Le vendredi 26 juillet 2013 07:53:08 UTC+2, Richard Jones a écrit :
>
> Yep, so every time update is called you loop over the entire tile map 
> to see which tiles might need to be drawn. A reasonable optimisation 
> would replace that with an explicit calculation of the range of tiles 
> to be displayed. It probably won't have that huge an impact on your 
> speed though. 
>

I'll do that, but without big expectations :) 

>
> Another alternative - assuming your tilemap isn't *huge* - is to just 
> create all the sprites and don't worry about culling the off-screen 
> ones. The culling can be handled by OpenGL which is probably going to 
> be much faster at doing so. 
>
> Thats (one of) the problem(s) : the biggest map is 180 x 120 tiles big, 
and made of 10 layers. Each layer would be 180 x 120 x 32 x 32 x 4 bytes, 
that is 84 Mb, so in total 840 Mb. That seems a lot :) (furthermore, it's 
indeed toric, so I'd need to add some tiles on the four edges)  

I've managed to replace all pyglet.sprites by rabbyt ones, but it still has 
exactly the same fps (around 4). I more or less copied/pasted (and adapted) 
code from articpaint tutorial #1. I need to find how to optimize my code 
(with numpy.arrays rather than python lists ?)
 

>     Richard 
>
> On 26 July 2013 15:35, Fred <[email protected] <javascript:>> wrote: 
> > Yes, it is. 
> > 
> > But unless I'm mistaken, most of the time it does nothing (only when 
> tiles 
> > row/column disappear / appear) 
> > 
> > Le vendredi 26 juillet 2013 03:11:42 UTC+2, Richard Jones a écrit : 
> >> 
> >> Just a thought - is the update() method you show below being called 
> every 
> >> frame? 
> >> 
> >> 
> >>      Richard 
> >> 
> >> On 21 July 2013 08:35, Fred <[email protected]> wrote: 
> >> > Thanks for your answer. I studied the code. 
> >> > 
> >> > On Saturday, July 20, 2013 9:49:30 AM UTC+2, Juan J. Martínez wrote: 
> >> >> 
> >> >> On 20/07/13 00:07, Fred wrote: 
> >> >> > [...] 
> >> >> > 
> >> >> > Am I doing it the wrong way (and if so, could you please point me 
> >> >> > better 
> >> >> > ideas) or is my goal clearly unreachable using Python + pyglet, 
> and 
> >> >> > would require C++/OpenGL code ? 
> >> >> 
> >> >> You can do it with Python and Pyglet, you just need to use OpenGL: 
> >> >> 
> >> >> http://los-cocos.googlecode.com/svn/trunk/cocos/tiles.py 
> >> >> 
> >> >> See MapLayer._update_sprite_set and base class 
> >> >> layer.ScrollableLayer.draw. Basically if keeps en memory a list of 
> >> >> visible sprites and uses OpenGL's glTranslate for scrolling. 
> >> >> 
> >> > 
> >> > From what I've understood, I use the same scheme. For example, my 
> >> > equivalent 
> >> > of MapLayer._update_sprite is : 
> >> > 
> >> >     def update(self): 
> >> >         t_left, t_right = GfxBase.screen_left / 32 - 1, 
> >> > (GfxBase.screen_left 
> >> > + GfxBase.screen_width) / 32 + 1 
> >> >         t_top, t_bottom = -(GfxBase.screen_bottom + 
> >> > GfxBase.screen_height)/32 - 1, -GfxBase.screen_bottom/32 + 1 
> >> > 
> >> >         for j in xrange(self.th): 
> >> >             for i in xrange(self.tw): 
> >> >                 if t_left <= i < t_right and t_top <= j < t_bottom: 
> >> > #                    print (i, j), ':', self.sprite_array[j][i] 
> >> >                     if not self.sprite_array[j][i] and 
> >> > self.array[j][i][0] > 
> >> > 0: 
> >> >                         _sprites_added += 1 
> >> >                         image_id, transfo = self.array[j][i] 
> >> >                         image = self.sheet[image_id] 
> >> >                         image.anchor_x = image.anchor_y = 16 
> >> >                         if transfo & 0x40: 
> >> >                             image = image.get_transform(flip_y = 
> True) 
> >> >                         elif transfo & 0x80: 
> >> >                             image = image.get_transform(flip_x = 
> True) 
> >> >                         sprite = pyglet.sprite.Sprite(image, 
> >> >                                                       x = i * 32 + 
> 16, 
> >> >                                                       y = -j * 32 - 
> 16, 
> >> >                                                       blend_src = 
> >> > self.blend_src, 
> >> >                                                       blend_dest = 
> >> > self.blend_dest, 
> >> >                                                       batch = 
> >> > self.batch, 
> >> >                                                       group = 
> >> > self.group, 
> >> >                                                       usage = 
> 'static') 
> >> >                         sprite.opacity = self.alpha 
> >> >                         self.sprite_array[j][i] = sprite 
> >> > #                        print 'sprite drawn at 
> >> > ',(self.sprite_array[j][i].x, self.sprite_array[j][i].y), '#', 
> >> > self.array[j][i], 'batch=', self.batch 
> >> >                 elif self.sprite_array[j][i]: 
> >> >                     _sprites_removed += 1 
> >> >                     self.sprite_array[j][i] = None 
> >> > 
> >> > I can explain the code more if needed but the difference with cocos' 
> >> > code is 
> >> > that I use a 2D array to store the sprites, where cocos uses a dict 
> >> > whose 
> >> > keys are tuples ? 
> >> > Also, I use an OrderedGroup for each layer (in order to draw them in 
> the 
> >> > right order), whereas I didn't find how cocos achieves that (a Batch 
> per 
> >> > layer ?). I was wondering if it wouldn't be more efficient to set a 
> >> > z-value 
> >> > to every sprites in a layer (rather than a group), but pyglet sprites 
> >> > don't 
> >> > have a z attribute (I suppose it wouldn't be too hard to implement 
> >> > though, 
> >> > but I don't know if it has an impact on performances). I suspect this 
> >> > group 
> >> > drawing procedure to be one of the bottleneck of my program. 
> >> > 
> >> > As to the draw method, mine is simply : 
> >> > 
> >> >             pyglet.gl.glLoadIdentity() 
> >> >             self.window.clear() 
> >> >             pyglet.gl.glTranslatef(-GfxBase.screen_left, 
> >> > -GfxBase.screen_bottom, 0) 
> >> >             self.batch.draw() 
> >> > 
> >> > 
> >> >> 
> >> >> Cocos2D code is a great example. I know it can be hard to read if 
> >> >> you're 
> >> >> not used to OOP (too many layers!), but I think it will help you 
> with 
> >> >> your problem. 
> >> >> 
> >> > In fact, I knew about Cocos2D, and studied its TMX loader before. I 
> >> > agree 
> >> > that's a great library. Ressources on the net about it should be more 
> >> > numerous. 
> >> >> 
> >> >> Regards, 
> >> >> 
> >> >> Juan 
> >> >> 
> >> >> -- 
> >> >> jjm's home: http://www.usebox.net/jjm/ 
> >> >> blackshell: http://blackshell.usebox.net/ 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> > Groups 
> >> > "pyglet-users" group. 
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send 
> >> > an 
> >> > email to [email protected]. 
> >> > To post to this group, send email to [email protected]. 
> >> > Visit this group at http://groups.google.com/group/pyglet-users. 
> >> > For more options, visit https://groups.google.com/groups/opt_out. 
> >> > 
> >> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "pyglet-users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to [email protected] <javascript:>. 
> > To post to this group, send email to 
> > [email protected]<javascript:>. 
>
> > Visit this group at http://groups.google.com/group/pyglet-users. 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to