It works ! I don't reach the 60 fps, I must be around 50, but it's already nice.
I use rabbyt render and I don't think it uses batches ; I wonder if using pyglet batches and groups could give some more fps. Map loading takes much more time obviously, I'll make it load partially and complete loading while displaying the first frames. Thanks for the advice. You are right, I don't really know how OpenGL works. I imagined a huge bitmap stored in GPU RAM (as I used to do using SDL or Allegro in the old days). That's the problem with high-level interface such as pyglet : you end with little understanding of the machinery :) Le vendredi 26 juillet 2013 12:50:08 UTC+2, Fred a écrit : > > 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]> 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]. >>> 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.
