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.
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.
Richard
On 26 July 2013 15:35, Fred <[email protected]> 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].
> 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].
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.
