[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[pygame] Pygame Scene System



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