In terms of scope and complexity. It is easily a one-man effort. I.e. if someone were to develop any non-trivial game as a hobby, this is the kind of game he/she would tackle. Furthermore, there are many non-libre games of comparable or better quality."Hobby quality" in what way? The only libre platformer which is finished that I would say is at the same quality level as reTux is Alex the Allegator 4. That's a great game, but it's a different one (and it's nowhere near as advanced, mind).
From what I've seen of your game and Barbie Seahorse Adventures, I would say they are in the same category. Barbie Seahorse Adventures looks more original though.When I see "hobby quality", I think of something like Barbie Seahorse Adventures.
These kind of statements make you lose your credibility really quickly. You are asking people for their money, yet you refuse to spend a couple of minutes to setup a free account to upload videos advertising your effort. If that is too much of a hassle, why would I believe that you will spend effort on developing the game.I wanted to, but I can't. IndieGoGo only supports linking to YouTube and Vimeo videos, for some reason. I don't have an account on either of those sites.
Although it's design is much cleaner, Python is more multi-paradigm than C++. That said, most of pygame is C-code I think. You might want to contemplate porting parts of your SGE Engine to C depending on where you lose most performance according to the profiler.I don't like C++ in general. I think it's an unholy mess of different programming paradigms. If I wanted to go as low-level as that for a new project built from scratch, I'd be more in favor of C.
Have you considered learning D?I don't like C++ in general. I think it's an unholy mess of different programming paradigms. If I wanted to go as low-level as that for a new project built from scratch, I'd be more in favor of C.
That's one possibility I've considered. But developing an implementation that works with PyPy (and is pure-Python) is something I want to do first, before trying that.You might want to contemplate porting parts of your SGE Engine to C depending on where you lose most performance according to the profiler.
Off-Topic:Hmm, interesting, but I remain unimpressed. Computer translated C++ from a high level language tends to be as slow and clunky as the source language was at best. The problem tends to be the flexibility of high level languages limiting what you can optimise away.
Ah, that's way more dogmatic on the Free/Libre dimension than I am myself, but I respect your point of view.I didn't not create a Vimeo account because of "hassle". It's entirely because of ethical grounds...
Cool. Be aware the PyPy and pygame are not compatible (according to 1, 2) since Pygame runs mostly in C anyway.That's one possibility I've considered. But developing an implementation that works with PyPy (and is pure-Python) is something I want to do first, before trying that.
It runs so slow because of the RAM? That doesn't make much sense for such a game tbh.Anyway, as I said before, it's a near certainty that reTux will never run decently on the Pandora, mostly because of the very limited RAM. This is just for anyone curious about reTux's CPU requirements and how far the Pandora is from meeting them.
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.)Why do you need so much RAM?
No, it crashes because of the RAM. Or, if you have swap turned on, then yes, it runs slow because of it.It runs so slow because of the RAM? That doesn't make much sense for such a game tbh.
I'd say that's a relatively accurate statement.Wow, that seems to be REALLY unoptimized.
Yes, several times, actually. It actually used to be much worse.So something sounds really wrong here, have you ever tried profiling the code to find out what the issues are?
This seem to be right. Games which scale with the amount of pixels (like Puzzletube) ran only a BIT faster on the pandora than on the gp2x and the pandora has five times more pixels than the gp2x.Wow, that seems to be REALLY unoptimized.
SuperTux even runs fullspeed on a GP2X, which is... don't know, 5 times slower (or more?) than the Pandora?
Sorry, but a platform game should not need so much RAM that it needs swap space.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.)Why do you need so much RAM?
No, it crashes because of the RAM. Or, if you have swap turned on, then yes, it runs slow because of it.It runs so slow because of the RAM? That doesn't make much sense for such a game tbh.
I don't get this, maybe I am too native. Why and how does SGE prevent pygame using it's optimizations? I never worked with pygame, but always thought about it like SDL or sparrow3d: Window management, events, blitting pictures, drawing simple primitives. And why is your collision check so complex? Do you do pixel based collision checks? Otherwise it should be quite fast - especially in a jump and run.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.