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.
