I did. Just not the atlas/grid as I don't even know how to use it for that (sorry) -- I had assumed it was good for accessing a texture in a tiled manner but not for drawing objects.
In my case, either doing it individually or batching my drawing of 120 sprites of 15x15 pixels slows everything to 43 fps...and that's all I'm drawing, no character sprites or anything else. I can run Mass Effect 2 on the highest settings but Pyglet still kills my system :( . Go figure. I used PIL to assemble a huge image object that then I feed to pyglet through the buffer. Then I can choose to focus on drawing a smaller region of it so I don't have to draw that big bastard every frame, my reduced region is going at a maximum of 256x224 which is the old NES resolution and so far nothing is exploding. But my issue is that I do not know which is more efficient; using PIL, or the Pygle buffer to assemble an image object to be stored in the buffer. On 3 mayo, 09:20, veers <[email protected]> wrote: > Why do you want to render the tile map to a buffer? Did you try to use > pyglets sprites with a batch and a texture atlas/grid? > I would expect that to be at least as fast as drawing the one big > prerendered texture. > > Cheers, > Jonas > > On May 1, 8:42 pm, Alejandro Castellanos > > > > > > > > <[email protected]> wrote: > > I'm wondering because I'm kinda curious about working with the image > > buffer. I'm working on a tile engine where I assemble an image from > > many smaller images so that pyglet only has to draw a single thing > > instead of a buttload of small sprites that slow everything to a > > crawl. > > > At the moment I'm using PIL to assemble my image by using a grid, from > > there I can either save it to a file or keep it in memory (the buffer > > of sorts) where I can work over it and then feed it to Pyglet. So far > > everything seems to be working fine, but it means I do have to depend > > on something other than good ol' Pyglet. The advantages are that it is > > a very straight forward process and I can easily modify small regions > > of the larger image on the fly if I so wish, with relative ease. Yet I > > still have to keep making the conversions between the PIL buffer and > > the Pyglet one. > > > But just a few moments ago I started playing aorund with the whole > > 'pyglet image texture' stuff where, if I understand correctly, I can > > create textures and then either blit some stuff onto them, or blit the > > textures directly to the screen, and I'm assuming I may be able to get > > something similar working using just the actual pyglet buffer, just > > slightly less straight forward (than what I'm used to). > > > My issue is in discerning what should be better, to keep using PIL, > > which is a graphics library in itself, or substitute it for a full-on > > pyglet application. Any thoughts? -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
