You mean that if two sprites share the same texture (which will happen often), it won't be copied twice ? If so, the memory usage will be that of the textures atlas,
I'll try, we'll see if my computer will burn :) Le vendredi 26 juillet 2013 12:24:55 UTC+2, Richard Jones a écrit : > > That ain't how OpenGL works. The total memory usage would be significantly > less than that. By an order of about 8196x at a rough guess. > > Sent from my mobile - please excuse any brevity. > On 26 Jul 2013 18:34, "Fred" <[email protected] <javascript:>> wrote: > >> >> >> 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]> 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<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 pyglet-users...@googlegroups.**com. >>> >> > To post to this group, send email to [email protected]. >>> >> > Visit this group at >>> >> > http://groups.google.com/**group/pyglet-users<http://groups.google.com/group/pyglet-users>. >>> >> > >>> >>> >> > For more options, visit >>> >> > https://groups.google.com/**groups/opt_out<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 pyglet-users...@**googlegroups.com. >>> > To post to this group, send email to [email protected]. >>> > Visit this group at >>> > http://groups.google.com/**group/pyglet-users<http://groups.google.com/group/pyglet-users>. >>> > >>> >>> > For more options, visit >>> > https://groups.google.com/**groups/opt_out<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.
