No it does not, but i'm trying to make my engine be able to handle as many gameobjects per scene it can, without lagging. This is my objective.

Well, if you want to render as much sprites as possible then you could look into rendering using OpenGL or Direct3D. For fast collision you could try a Python port of Box2D or maybe somebody has made a different physics package for Python.

But I'm wondering, you are going to use this engine to create a game with right? So wouldn't you rather focus on what that game needs?

Actually i'm trying to make something like Unity 3D but for 2D games with python :p Of course not too powerfull, just a start.

As you can see only six images are rendered to the screen (the other 14996 are off the screen).

Since you count these off screen ones does that mean you don't cull them?

rendering 15000 sprite objects.

15000 * 2 = 30000 triangles = half a mesh buffer worth of triangles; so you don't batch your meshes.

Learn batching, it is a process where you merge a lot of sprites into one as a way of saving performance.

If you did use batching you could get 64 000 triangles per mesh = 32 000 sprites per mesh = 32 000 * 300 (Mid range graphics card) = 96 000 00 static sprites. On a brand new graphics card you will get millions of static sprites.

You can start here: https://www.gamedev.net/resources/_/technical/opengl/opengl-batch-rendering-r3900

You could also search on the web, someone should have done it us

So the basic idea is, instead of saying "Ok draw me 15000 rectangles", group pictures together to create one large image and draw this one on the screen? Like for example, 15000 / 50 = 300, so create 300 "big" images and draw these instead.

Also the method blit of pygame is not using graphics accelarator hardware.

But still, i don't think that this is the problem, because in this example ONLY six images are being rendered on the screen the rest 14996 are just skipped because of the if statement:

def render(self, screen):

    if self.onScreen(screen) and self.image != None:
        screen.blit( self.image, self.pos )

OK! So i asked pygame developpers about the blitting method and they answered me:

Also the method blit of pygame is not using graphics accelarator hardware.

Yup, which means it'll never be as fast as using a sprite renderer that uses OpenGL or Direct3D.

But still, i don't think that this is the problem, because in this example ONLY six images are being rendered on the screen the rest 14996 are just skipped because of the if statement:

Why don't you profile your code using the script I provided? Then you'll know for sure if it's the sprite blitting that's slow or the onScreen check or something else.

I tried but it shows me so many other methods that python runs and its a mess. Isn't there any way to tell the profiler "ok, show me only my methods"?

Someone else mentioned the word "culling" which is a key part of the equation here. This is related to those for loops.

If 15,000 objects aren't on your screen, there's no need to loop over them when drawing. You already have a quad tree for physics so you've got the basics of the solution in place already: use a scene partitioning system to efficiently find the subset of objects that are actually visible. If 6 sprites are visible and 15,000 are not, your rendering code should only even try to draw those 6 sprites and entirely ignore the other 15,000. A good scene graph (or even just a quad-tree) helps here a massive amount. You can hypothetically reduce your O(N) rendering to O(log(N)) or less which is a huge win.

One of your for loops then basically goes away. You never need to iterate over the static objects. Never. Both graphics and physics should be using an efficient graph of some kind to find relevant objects. (Note that physics and graphics might use _different_ graphs, because what makes the most sense for physics isn't necessarily true for graphics.)

You can then also heavily reduce the load on your dynamic objects for loop. After all, collision detection is already using an efficient data structure and you'll be changing your graphics to also use a tree of some kind, so the only work for dynamic objects that remains is to apply velocity. Luckily, that work only needs to be done on objects that _have_ a non-zero velocity. You can thus split your dynamic objects into two sets: active and inactive objects. The active objects are the ones that are currently moving.

After that split, you might notice that there's no longer any practical difference between static and dynamic objects, so you can perhaps remove that entire concept from the code. Objects with velocity (or some other forces) are put into the active set and are removed from the active set when they stop moving.

The physics code need only loop over the active objects to apply velocity and forces. The collision system uses an efficient graph. Rendering uses an efficient graph. Unless you (foolishly) make all 15,000 objects active at the same time, you never need to loop over all your objects even once, much less twice.

The next big step then is the batching improvements others have recommended.

The third big step I'd recommend is to use an accelerator like PyPy or whatever's in vogue today. Remember that even the simplest operation like adding two small integers should just be a single ADD instruction on the CPU, but in plain ol' CPython that same operation can take hundreds of CPU instructions, branches, memory accesses, and so on. Python does not translate to CPU code very well and requires a sophisticated JIT engine to do even marginally well in terms of performance, and Python does not include such a JIT engine out of the box like JavaScript engines do, so you have to use an add-on/replacement like PyPy.

The time is in seconds?