If the ennemies are generated randomly, and if you are sure they are the bottleneck of the FPS, you could generate them dynamically as the character progresses through the world.
Otherwise, you can divide your world in multiples rects the size of the screen, and link each ennemy to the "screen" to which it belongs. Ennemies are then woke up when the actual screen approaches the rect of the ennemy, allowing you to double-loop over a domain with side size 600 times smaller approximately. (well I wrote "ennemies" but of course this applies to any element that is more or less static with respect to the map) ________________________________ De : owner-pygame-us...@seul.org <owner-pygame-us...@seul.org> de la part de Rick van der Meiden <rickvandermei...@gmail.com> Envoyé : mercredi, 2 mars 2022 08:42 À : pygame-users@seul.org Objet : Re: [pygame] Drawing efficiency question 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<mailto: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
