@oscar: Well that's very cool - I like the svg loading. Thanks for the heads-up.
On Apr 21, 1:51 pm, oscar <[email protected]> wrote: > Hi Jonathan. > > I'm working on a thrust-like game with a friend. You can get it at > github. If you like it, please fork it and we'll pull your > improvements. > > It is using pyglet and box2d. We're using inkscape svgs for content. > Currently one can play a level at a time. > > http://github.com/brasse/force-pylots-of-gravitaar > > On 21 Apr, 10:33, Jonathan Hartley <[email protected]> wrote: > > > Thanks for that stampson! > > > Wow - so quickly did I skim through the pyglet programmer's guide > > section on sprites that that I didn't know they could be rotated. > > > I'm actually using Pymunk too. (Intention is for something like 'Oids' > > or 'Thrust' with rigid-body physics.) There's a small degree of camera > > zooming in and out going on, but even so, this might be a handy idea, > > especially for the sorts of 'special effects' like smoke that I > > mention above. > > > On Apr 20, 3:39 pm, stampson <[email protected]> wrote: > > > > Last year I did a lot of experimenting with pymunk (ctypes bindings > > > for chipmunk physics) and pyglet. I was doing little demos with > > > randomly spawned shapes - circles, triangles, rectangles, 'sticks', > > > various regular polys. I hit upon the idea of rendering the shapes to > > > textures, and animating them as sprites rather than redrawing them. > > > If you're not morphing the geometries, just drawing them in different > > > colors, orientations, positions, and scale this works well. I was > > > able to greatly increase the number of shapes (now sprites) on the > > > screen at once. > > > > Then, I realized a lot of time was being wasted in multiple calls to > > > the sprite module - if you are updating sprites position, scale, and > > > orientation every frame, you can save a lot of time by making a new > > > sprite function to update all three at once. This second change more > > > than doubled the number of shapes I could draw while maintaining > > > target fps. > > > > So there might be a simple way to take advantage of sprite batches, > > > even if you're working with geometries . > > > > -price > > > > On 19 apr, 12:54, Jonathan Hartley <[email protected]> wrote: > > > > > Hi all, > > > > > I've just started reading through the Orange OpenGL Shader book, and > > > > thought I'd post my thoughts here so people can correct or confirm for > > > > me, thanks! > > > > > I'd avoided shaders until now, thinking they would be an *extra* layer > > > > of complexity that I didn't need while I was still getting to grips > > > > with OpenGL. I think they might solve a lot the problems I've been > > > > happily wrestling with for a while now. So now I wish I'd read the > > > > book and got to grips with shaders ages ago. > > > > > It seems that the traditional OpenGL API I've been using is a bit of > > > > an anti-pattern these days - especially calling it from Python. If you > > > > have many independently positioned and oriented meshes, then you have > > > > to render each one with a separate glDrawArrays (or whatever) call, > > > > and change the model-view matrix between each call. Making these > > > > multiple function calls, passing through ctypes parameter wrangling > > > > each time, then changing opengl state, seem to form a significant > > > > performance overhead. > > > > > As I understand it, using pyglet batches takes a *lot* of the headache > > > > out of this, but it still requires me to make these modelview changes > > > > between each batch - under the scenes is it doing the same thing as > > > > above? I think so but obviously would love to hear if I'm wrong. > > > > > Plus, it seems, support for the traditional API is often implemented > > > > as a shader on modern graphics hardware, and these shaders have to > > > > handle *all* the byzantine features of OpenGL, regardless of whether > > > > you're actually using those features, so these shaders used for the > > > > traditional API are quite large and inefficient. > > > > > My use case is this: I have a bunch of simple 2D geometries (~20 to > > > > 100 verts each) and I want to render a lot of them all over the place > > > > at various positions, sizes, orientations. I'm not using textures, and > > > > I'm not using lighting. It's all very simple. > > > > > Upon reading about shaders, it seems a good idea to me to create a > > > > single large vertex array containing modelspace co-ords for every > > > > entity that I want to render, and add a custom vertex attribute which > > > > is an index into a second array of model transformations. My vertex > > > > shader would retrieve the desired model transformation by indexing > > > > into this second array (maybe as a matrix, maybe simply as a 2D offset > > > > and rotation) apply the transform to generate the gl_Position output. > > > > It could do this on every vertex in my scene in a single call to > > > > glDrawArrays(), thus circumventing the function-call overhead I incur > > > > using the traditional API. > > > > > I still have to update the values in the second 'transforms' array. If > > > > every mesh in my scene was moving all the time, and I had to update > > > > each transform individually, going through ctypes every time, then I > > > > might just be right back where I started. But if only a few of my > > > > meshes are moving around at once (many in-game objects were just > > > > resting on the ground where they lay), or if I can update the whole > > > > transform matrix as a single update (maybe as the output from some > > > > numpy wrangling) then this might not be so bad. > > > > > Do people think this is a useful idea, or am I misunderstanding how > > > > things work? > > > > > Thanks for any comments, rock on everybody. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
