As your world gets bigger and has more objects, your game will slow down even more. (Even if you directly use openGL, I suspect, although I haven't used it myself). You will need a spatial index. I have some code that i'm willing to share, if you're interested (or anyone else here, drop me a line). You can probably find some other code on the web or you can code your own spatial index, it's not that hard and it's a good exercise.
Rick. On Wed, 2 Mar 2022, 00:10 Irv Kalb, <i...@furrypants.com> 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 > > > >
