On Fri, Sep 26, 2008 at 3:37 AM, Alex Holkner <[EMAIL PROTECTED]> wrote: > > On 9/26/08, Ragzouken <[EMAIL PROTECTED]> wrote: >> >> Is it any more efficient to change only the y coords of a vertex >> list's texture coords rather than both x and y if you know that frames >> of the same animation are vertically aligned? > > In general, yes; though the logic in iterating past every second (or > third) float in a vertex list may outweigh the benefit. Note that > using a slice with a step effectively implements the same operation, > though pyglet handles the iteration for you (probably slower than you > could have done, due to generality).
I don't know if this was suggested before (I skimmed the thread and didn't see mention), but it is possible to animate the vertex coordinate without changing the vertex list itself by using a shader. A possible method would be to store the tile type for each vertex as an additional vertex attribute and pass a varying "time" value from your application to the shader program to control the animation. The shader would then alter the texture coordinates (perhaps shifting them along the Y or Z for a 3D texture) according to the vertex attribute (for instance leaving the coords alone for non-animated tiles) and the time value. The major downside to this approach is it requires opengl 2.0, which may be a non-starter. The upside is zero CPU cost for shaders running in the hardware. Alternately, you could divide your vertex list into animated and non-animated tiles and draw them separately. In one pass you could lay down the non-animated tiles, and in a second the animated ones. So long as the latter does not overdraw the non-animated tiles, it will look the same and allow you to have the non-animated tiles have a static vertex list. Thus you update a significantly smaller vertex list to animate. This assumes that a large fraction of the tiles are not animated, however. Yet another approach would be to switch the base texture rather than the texture coordinates. Rather than putting every possible tile type over time in a single texture, only put ones that will be shown at the same time. Then switch which texture is active to animate. If many or most tiles are not animated, you can combine this idea with the above and keep the non-animated texture completely separate, thus removing redundant tile textures to save space. The downside to this is that all animated textures would have to operate in lock-step (have the same texture at the same time), which may not look as good. But you could get around this by having multiple water types at the cost of larger textures. Still another approach would be to abandon updating the vertex list in python (assuming doing that is the bottleneck) and write some C code to generate it on the fly. You'll probably find yourself limited by transfer bandwidth to the video card with this approach, In native-code you can build a very large vertex array in short order. The shader solution is probably the most ideal. I would probably go for that and either disable animations when shaders are not available or fallback to one of the other compromise solutions above. hth, -Casey --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
