Why do you need so much RAM?
I haven't investigated much, but I believe it has to do with the way resources are handled. They're all pre-loaded, and then they end up getting duplicated as a result of speed optimizations. (For instance, every level contains a couple tile layers, which become one giant image each.)
It runs so slow because of the RAM? That doesn't make much sense for such a game tbh.
No, it crashes because of the RAM. Or, if you have swap turned on, then yes, it runs slow because of it.
Wow, that seems to be REALLY unoptimized.
I'd say that's a relatively accurate statement.
As to why the SGE is that slow, it's complicated, but basically, Pygame being fast depends on optimizations that are very low-level and game-specific; the SGE can't take advantage of any of those because it's much more advanced. For example, Pygame does nothing to handle collision detection, so that means you can devise your checks for collisions to exactly fit the needs of your game. But the SGE has a built-in method and built-in events for collision detection, so this type of laziness is more difficult.
You could actually try to help make it run better if you want, since the SGE is already publicly released; there is a Pong example you can use as a reference point, as well as Pacewar, which is also developed with the SGE:
http://stellarengine.nongnu.org
http://pacewar.nongnu.org
So something sounds really wrong here, have you ever tried profiling the code to find out what the issues are?
Yes, several times, actually. It actually used to be much worse.
The problem with profiling at this point is no single thing in the Pygame SGE left is particularly slowing the games down. It's all down to really tiny things all over the place that build up. In fact, these things are so tiny that the last time I profiled the Pygame SGE, the buggest thing that was eating time was actually a property that did nothing more than return the value of a name-mangled variable. The only possible way to substantially optimize it further is to reduce numbers of function calls, and how to do this isn't always obvious. You have to figure out special tricks.
But generally, the problem is in the amount of looping, and that is generally caused by having too many objects the SGE has to deal with at once. For instance, one recent thing I did was to substantially reduce the number of objects produced by loading TMX maps, by combining all tiles into one image. Before this change, level 2 of reTux was too large to run very well; it lagged the game to about 10 FPS, I think. Of course, this came at a substantial RAM cost, but RAM is a generally plentiful, growing resource; CPU time is not.
