On, Thu Feb 12, 2009, Pete Shinners wrote: > > > I think we should wait until after pygame 1.9 is released before > > > moving it over to use SDL_pyg? Was that your idea too? Or start > > > > Absolutely not. The C library is a simple spin-off of > > pygame/pgreloaded. Why would we want to add some more run-time > > overhead to pygame? Just to use the C library? > > I was expecting the main use of this library would be to move the heavy > computation out of Pygame. I expect it would be useful for bindings to > other languages, as well as standalone game projects. If the heavy computation is within pygame or not, does not matter that much, because it would be C code in both cases, thus having approximately the same speed (except for the linked call overhead). > Moving this to an external C library would add no overhead to Pygame. We > already have so many; SDL, SDL_image, SDL_mixer, etc. It will create > more work for compiling and configuring, but that will be minor. Looking at it from that position, you are right. That however was not exactly what I meant :-). > There will be issues in keeping it synced with Pygame. But I have a > feeling it will be easy to keep a stable API and ABI. And we would be bound to a more strict release policy in order to keep the releases in sync. We could not do a quick release with API enhancements or changes, if both do not share the same interface and ABI system. Somewhat risky, I guess. Keeping both in sync on the SVN level only and copy the files here and there would also allow us to let them get out of sync a bit without breaking any compatibility. Another thing are the supportive flags. Let's say the HAVE_JPEG switch spreads a bit more around (except for just the surface.save() call), users would become easily confused. The compiled pygame with HAVE_JPEG, but forgot to compile SDL_pgame (or SDL_pygame) with HAVE_JPEG. The user would become easily confused by that behaviour. Anyhow, we can move anything out of pygame/pgreloaded, which fits into the SDL library and add it as dependency. We just have to make sure, that certain things do not cause a misbehavioural effect for the user (e.g. avoid feature switch confusion) and that the release cycles, especially regarding the API compatiblity, are synchronised very well. Regards Marcus
Attachment:
pgpJlRNwjO5g8.pgp
Description: PGP signature