Drawing 450 triangles should definitely not drop to 43 fps, especially not at 256x224. Can you give me a code sample to reproduce your problem?
Cheers, Jonas On May 3, 9:02 pm, Alejandro Castellanos <[email protected]> wrote: > 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.
