I have observed similar issues with the framerate and clock and have posted under issues no. 314 but I am not sure if pygame is any better. It has the worst performance on my systems (Mac OS X) and also a very large preinstallation hit of ~60MB for users on that platform. Before the current release of pygame it was years without any released on my platform. Current pygame release has it's own issues to deal with. I'm still focusing on pyglet+rabbyt myself until I can get a chance to play with pyglet 1.2 to test performance on.
Cheers, PN On 08/09/2008, 3TATUK <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
