Actually .. I've noticed pyglet (1.1.1) has serious issues as far as framerate limiting/counting.
It's basically not possible to have it be consistent. If you use clock.set_fps_limit() .. the FPS will go far above this when for example moving the mouse around in the window. Also, A simple clock.get_fps() usually returns something considerably different than whet was specified with clock.set_fps_limit() As far as Alex's official response to screen resolution changing ... I _really_ think these capabilities are within pyglet's scope. Pyglet is not a pure OpenGL wrapper (as PyOpenGL aims to be). Pyglet is A full ``cross-platform windowing and multimedia library for Python''. Pyglet has windowing capabilities. Pyglet has screen capabilities. It even has multi-monitor capabilities! Stating that monitor resolution changing is out of the scope of Pyglet just seems a bit ridiculous to me. The ``issue'' with sound looping/seeking (not really an issue so much as the code simply not existing in v1.1.1) is obviously known and addressed because I see new code which seems to slowly be adding functionality in newer svn revisions > v1.1.1. I just think it's 'interesting' how the documentation 'acts as if'/'pretends' that code actually exists and is functional. Maybe I'm not comprehending the documentation revision process and it's actually based on 'greater than current release' code, which may or may not be available in SVN. Nevertheless, I think it's generally A good idea for whatever's found at pyglet.org/doc to be up-to-date with the latest -release- and let never documentation reside in the SVN. And to this same topic it's interesting to note Alex's response at the following page: http://groups.google.com/group/pyglet-users/browse_thread/thread/641516ebc0ec7736 Drew complains about on_eos() not working (as it shouldn't because the code is skeleton in v1.1.1)... but Alex responds as if it should be working, querying about 'platform / audio environment'. Maybe he forgot that Drew is probably not working with the up-to-the-minute codebase found on Alex's hard drive, or maybe he's polling for information to take into account for continued development. Either way it's interesting. And finially .. the problem with texture-to-texture blitting not preserving alpha [blit_into()]. I've actually contacted Alex directly about this and what he had to say was: <<< "In short, blit_into doesn't have this functionality, as it's not exposed by the OpenGL API for image transfer." "Also, would it not be smart to have a future version of blit_into() have alpha functioning?" >>> "No." "Why not just have it exposed to OpenGL API for image transferring?" >>> "I didn't write the OpenGL API, I only make use of it for pyglet ;-)" I don't understand this logic. I understand his explanation as far is blit() invoking GL rendering and blit_into() _not_ doing it.. But this is just inconsistent API. Again, Pyglet is ``a cross-platform windowing and multimedia library for Python''. Python is a high-level language and I'm somewhat presuming that Pyglet aim at bringing this access down to uses/ developers of Pyglet. Otherwise, why not just have the would-be users/ developers of Pyglet write their own OpenGL ctypes interface or use PyOpenGL, instead? texture.blit() invokes GL rendering which preserves alpha, but texture.blit_into() does not. That's just seriously in-consistent. If not have blit_into() invoke the GL renderer to preserve alpha, then at least have it preserve alpha some other way. Personally I think that would just be sane overall design. If texture.blit() preserves alpha, texture.blit_into() should as well. Anyway I just feel really strongly about these issues because I believe Pyglet's has a lot of potential going for it. I was a little pretentious about judging Pyglet since I'm used to pygame which _does_ all of these things and I'm aiming at eventually comprising something that can be considered a 'large' game project.. Which means that if such core issue's aren't address (ESPECIALLY inconsistent FPS) then pyglet will simply not be a candidate for further development. My game logic code is hardly advanced at all but it's much easier to build this down the line when it's set on a strong +stable core rendering framework. Thank you Richard Jones. Thank you Alex Holkner. I hope no one is upset by my sometimes-hash-seeming constructive criticism. ;) Good health to you. On Sep 7, 2:29 am, Richard Jones <[EMAIL PROTECTED]> wrote: > On Sun, 7 Sep 2008, 3TATUK wrote: > > ps. pyglet still needs working sound loops, alpha-aware blit_into(), > > and monitor resolution changing ! > > http://groups.google.com/group/pyglet-users/web/faq --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
