On Sep 9, 4:31 pm, stampson <[EMAIL PROTECTED]> wrote:
> I did a test, filling the screen with animated sprites. It does slow
> down a lot, although this machine was still able to maintain 30fps.
then i must've done something terribly wrong - i get only below 1fps
with this code: http://phpfi.com/351779 (there are 12 water tiles with
32x32px) the tile count in the nested loops matches for fullscreen
with my resolution.
>
> Based on my reading of the sprite class, it looks like using sprites
> for tiling is perhaps not ideal - even less so with animated
> textures. Because the sprite class allows for animations of variable
> dimensions per frame, and different sprites sharing the same animated
> texture are not necessarily in sync, every time the animation changes
> the sprite has to recalculate several things.
so i should take the sprite code of pyglet and write my own with
removing unnecessary things?
>
> If you are willing to go with the following restrictions, and write
> some code for tile layers, I think you could get excellent
> performance:
>
> - all tiles oriented the same, all the same size
> - all animated tiles animate in sync
> - all frames of animation the same size
well in the end there will be more than water as terrain (but it is
the only animated terrain tile) - there will also be some objects on
the map from which some are also animated - these would be some more
layers above the terrain.
but yes for the terrain all tiles are 32x32 and water tiles are all
oriented the same and animate in sync
map objects will vary in size (width height being 32, 64, 96 or 128px)
and only sometimes be animated
>
> With the above restrictions, it should be possible to avoid most of
> the recalculations which occur per animation frame when using
> sprites. And each layer can be translated/scaled/rotated. If the
> animations are in sync, the texture can be changed once per group,
> regardless of whether the tile is animated or not.
>
> So you would have a tile layer group, then a group for each texture
> (animated or not). Each layer would be a static mesh of textured
> quads, with a state change per base tile. Your performance would
> depend more on the number of different textures, rather than the
> quantity of tiles. Unless your levels are very large, you should not
> have to worry about paging the tiles in/out, but doing so would not be
> terribly hard.
>
> -price
thx for all the info! i still have to learn a lot on this topic - you
guys are very helpful in getting me started! :)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
