Perhaps you should reconsider your decision not to use a simple
colliderect. It'd be much more efficient (as the general case is
certainly not a high number of entities on the edge of the screen) to
.colliderect() with the edges of the map, and process those specially.
Also beware drawing very large amounts that you do not need to.
Blit()ing onto a large surface, which you then display, will draw all
the pixels each frame even if they are not visible. blit() accepts a
rect argument to limit drawing, which you can take advantage of. You can
also get away with not drawing a very large amount of pixels each frame
by "erasing" underneath moving sprites.
I would also second the request for you to profile. Often, performance
bottlenecks in python are nonobvious. Lots of code that might look
expensive is fast because it operates in optimized C, and code that
looks innocent is actually slow because it is doing something behind the
scenes that you do not expect.
Wall collision code is often complicated and suspect.
On 3/1/22 15:02, Irv Kalb wrote:
> I am developing a game but I'm running into some cases where the game slows down too much. A few details ...
>
> The game lives in a world whose size is much larger than what the user can see in the window. (For now, the world is 3000 x 3000, but the window is 640 x 640 - I could decide to change these later). There is a central player who is controlled by arrow keys. When the user presses a key or keys to move in a direction, the player is an animation that looks like its walking, but always stays in the center of the screen - the view in the window scrolls in the opposite direction. There are "enemies" that live in this world, new ones are generated all the time, and each moves semi-randomly in every frame. There are also a number of additional elements that must be drawn every frame (e.g., walls in a maze and more).
>
> The game is complicated by the fact that the world wraps around both horizontally and vertically. If you move off the top, you show up at the bottom, go off the left and you appear on the right, etc. In my current version, in every frame I iterate through all drawable elements, and go through some coordinate checking code to determine if the element is visible within the window. This code is more complicated than a simple "colliderect()" because I have to account for the potential wrapping in all directions. If the element is within the viewable screen area, I draw it (blit), otherwise, I don't do the draw. I thought this would be a great optimization. But, I'm finding that as the number of enemies grows, the overall game slows down. I'm sure this has to do with the fact that in every frame I check their movement (they cannot go through walls), move each to a new location, and then decide whether to draw them or not.
>
> I'm wondering if my code to check if an element is within the viewable area, is actually doing more work than not bothering to check at all. My question is really about the efficiency of a call to blit in pygame when the thing being drawn is outside the viewable area. I actually have done some minor tests, and the game seems to work a little better without doing the checking, but I want to get opinions from anyone who might really know.
>
> I will probably wind up limiting the number of enemies, but it would be good to know about how efficiently pygame deals with potentially drawing outside the window.
>
> Thanks in advance,
>
> Irv
>
>
>