Hello, As no one responded to me taking up improving the sprite and scene system for pygame, I am going to take that as no one has any objections and start working on it. Hopefully, somewhere along the way someone will mentor me.
The first thing I want to do is the scene system. Here, I am treating scenes as a logical area where a set of related sprites live. The way I propose to do this is as follows: This contains two main components; the View class and the Subspace class. The subspace class represents a logical area, for example the game area or the sidebar for GUI elements. The View class is used to display a portion of a subspace onto the screen itself (or any other surface). I will implement the entire thing as the following pipeline: - The list of views will be taken. - From here, we will get the subspace to be drawn as they are members of the view. - From the subspaces, we shall get all of the objects that can be drawn. - This will be filtered down into the objects that are in the relevant View. - From the position of the view in the subspace, the position of the object in the subspace and the offset of the view on the screen, the position where the object is to be drawn will be calculated (pos=offset+object.rect.topleft-view.rect.topleft) - The objects will then be drawn. I plan on using a LayeredUpdates instance for every surface, passing all of the objects to be drawn and their positions, and then drawing them all. - pygame.display.update - All of the ones drawn to the screen will then be cleared.from the screen using the background image of their subspace. Implementing this in the above manner makes it very easy to have a logical object area larger than the available display area, and to then have the display area move about to show different segments of the logical area. It also makes it easy to place sidebars, and partition different parts of the screen for different purposes. I will also implement a class which acts as both a view and subsurface for the common case of where the logical area is smaller than or equal to the display area available and so there is no moving view. I have the following questions about implementing this: - When looking through the source code, I saw that the draw is done as surface_blit(spr.image, spr.rect) with surface_blit being surface.blit referenced locally (for speed, I am assuming). What I would like to do is instead have a draw function in the sprite itself of the form Sprite.draw(self, surface, pos), which will be called in the above pipeline, so as to easily allow the user to tailor the way he wants the object to be drawn. This can also store the position drawn, making it easier to clear the sprite later. - Secondly, when I look through the code, in every function I see attribute accesses being referenced locally for speed (eg; surface_blit=surface.blit, spritedict=self.spritedict). When writing, should I adopt the same style? Or can I program directly, which I feel is more readable? - In a related point, instead of using hasattr, can I use try ... except, or in the case of _spritegroup isinstance? I am sorry that this post is a bit on the long side, and thank you for reading the entire thing. I would really appreciate any suggestions or comments you have to offer. Nikhil Murthy