I'm crowdfunding my newest game: reTux (new Mario-inspired platformer)


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.
 
"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).
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.
When I see "hobby quality", I think of something like Barbie Seahorse Adventures.
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. 
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.
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 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.
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?
 
There is the medusa python to dart compiler. Dart ist quite fast, not sure if it will run the pandora.
 
I didn't not create a Vimeo account because of "hassle". It's entirely because of ethical grounds. Obviously, IndieGoGo requires proprietary JavaScript too, but I used IndieGoGo because I couldn't find any more ethical alternative currently available for these kinds of projects. For video sharing, there's MediaGoblin (where the videos are hosted; you guys are acting like videos don't exist at all), and there's also imgrush.com. Never mind my personal desire not to run Vimeo's and YouTube's proprietary JavaScript, steering people toward watching a video on Vimeo (which is, incidentally, the one major video sharing site whose videos I do not know of a reliable way to watch without its JavaScript code) when it is completely unnecessary is absolutely not something I want to do. That's why rather than recording a campaign video (which was my initial plan), I opted to instead center the campaign pitch around text and use a gameplay video (then another one which I added later) to supplement it. Was that a wise decision? I don't know, maybe not. But please understand that my reason for making this decision was not laziness.

You might want to contemplate porting parts of your SGE Engine to C depending on where you lose most performance according to the profiler.
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.
 
Last edited by a moderator:
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.
Off-Topic:

I just tried out Haxeflixel with Self-written, Quick and Dirty Pong. On my Laptop(Core 2 Duo@1.6Ghz) I get 30% to 40% CPU usage while Playing and ~14% while Im in the Menu.


To defend the 30% to 40% CPU usage while Playing: I did not use the Sprite functions at all. For those, who are Interested here the Source Code:



package;

import flixel.FlxG;
import flixel.FlxSprite;
import flixel.FlxState;
import flixel.text.FlxText;
import flixel.ui.FlxButton;
import flixel.util.FlxMath;
using flixel.util.FlxSpriteUtil;
import flixel.util.FlxColor;
/**
 * A FlxState which can be used for the actual gameplay.
 */
class PlayState extends FlxState
{       private var canvas:FlxSprite;
        private var ballspdx:Int;
        private var ballspdy:Int;
        private var ballx:Int;
        private var bally:Int;
        private var paddlex:Int;
        private static var fillStyle = { color: FlxColor.BLACK, alpha: 1.0 };
/**
         * Function that is called up when to state is created to set it up.
         */
        override public function create():Void
        {
                ballx=50;
                bally=50;
                paddlex=50;
                ballspdx=-2;
                ballspdy=-2;
                super.create();
                canvas = new FlxSprite();
                canvas.makeGraphic(FlxG.width, FlxG.height, FlxColor.TRANSPARENT, true);
                add(canvas);
        }

        /**
         * Function that is called when this state is destroyed - you might want to
         * consider setting all objects this state uses to null to help garbage collection.
         */
        override public function destroy():Void
        {
                super.destroy();
        }

        /**
         * Function that is called once every frame.
         */
        override public function update():Void
        {
                super.update();

                ballx += ballspdx;
                bally += ballspdy;
                canvas.drawRect(0, 0, FlxG.width, FlxG.height, FlxColor.BLACK, { color: FlxColor.BLACK, thickness: 0 }, fillStyle);

                if (FlxG.keys.pressed.LEFT && (paddlex >= 0))
                {
                paddlex += -5;
                }
                if (FlxG.keys.pressed.RIGHT && (paddlex+20 <= FlxG.width))
                {
                paddlex += 5;
                }
#if desktop
                if (FlxG.mouse.pressed && (FlxG.mouse.x > FlxG.width/2) && (paddlex+20 <= FlxG.width))
                {
                paddlex += 5;
                }
                if (FlxG.mouse.pressed && (FlxG.mouse.x < FlxG.width/2) && (paddlex >= 0))
                {
                paddlex += -5;
                }

#end
#if mobile


                for (touch in FlxG.touches.list)
                {
                if (touch.pressed && (touch.x > FlxG.width/2) && (paddlex+20 <= FlxG.width))
                {
                paddlex += 5;
                }
                if (touch.pressed && (touch.x < FlxG.width/2) && (paddlex >= 0))
                {
                paddlex += -5;
                }
                }
#end
                canvas.drawRect(paddlex, FlxG.height - 2, 20, 2, FlxColor.WHITE, { color: FlxColor.WHITE, thickness: 0 }, fillStyle);
                if (bally <= 0)
                {
                ballspdy *= -1;
                }
                if (ballx <= 5 || ballx >= FlxG.width-5)
                {
                ballspdx *= -1;  
                }
                if(bally >= FlxG.height - 2 && ballx >= paddlex && ballx <= paddlex+20)
                {
                ballspdy *= -1;
                }
                if(bally >= FlxG.width){FlxG.switchState(new MenuState());}
                canvas.drawRect(ballx, bally, 2, 2, FlxColor.WHITE, { color: FlxColor.WHITE, thickness: 0 }, fillStyle);
        }
}

(As you can see, I used an Sprite as canvas)

But the ~14% In the Menu are a bit Concerning, and there I did nothing wrong, because I just Draw a Button there, and let Haxeflixel do the Event Handling. So here the Menu Source Code:

package;

import flixel.FlxG;
import flixel.FlxSprite;
import flixel.FlxState;
import flixel.text.FlxText;
import flixel.ui.FlxButton;
import flixel.util.FlxMath;

/**
 * A FlxState which can be used for the game's menu.
 */
class MenuState extends FlxState
{
        /**
         * Function that is called up when to state is created to set it up.
         */
        override public function create():Void
        {

                FlxG.mouse.useSystemCursor = true;
                add(new FlxButton(50, 50, "PLAY!!", PlayButton));
                super.create();
        }

        /**
         * Function that is called when this state is destroyed - you might want to
         * consider setting all objects this state uses to null to help garbage collection.
         */
        override public function destroy():Void
        {
                super.destroy();
        }

        /**
         * Function that is called once every frame.
         */
        override public function update():Void
        {
                super.update();
        }
        private function PlayButton():Void
        {
        FlxG.switchState(new PlayState());
        }
}

Also here some Data from my Android Phone(1Ghz single Core):

Screenshot_2015-08-16-15-21-10.png

Screenshot_2015-08-16-15-23-35.png

Porting to Android was VERY easy(It took me half an hour, to write the Code for PC and then just 15 minutes, to Port the thing to Android), but i noticed slowdowns, while Playing.

Very Off-Topic:

I wonder, why Android Has a load-average of 8.0 while I'm on the Home Screen. That would mean, that the CPU is 8 times to slow.....
 
Last edited by a moderator:
@lukey: Could you stop proposing your Haxeflixel thingi? onpon4 is obviously not interested.
 
I didn't not create a Vimeo account because of "hassle". It's entirely because of ethical grounds...
Ah, that's way more dogmatic on the Free/Libre dimension than I am myself, but I respect your point of view.
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.
Cool. Be aware the PyPy and pygame are not compatible (according to 1, 2) since Pygame runs mostly in C anyway.
 
Out of curiosity, I added a feature to show FPS to reTux, and checked what it is on the Pandora. It's actually about 3 FPS. This is about 1/10 the speed it runs on my laptop, which has an Intel Core i3-3217U CPU.


That's on SuperZaxxon with no changes to the OS, at 600 MHz. Overclocking to 800 MHz at OPP5 raises it to 4 FPS. So I guess an overclocked 1GHz model would be able to achieve around 6 FPS.


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. :)
 
Last edited by a moderator:
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. :)
It runs so slow because of the RAM? That doesn't make much sense for such a game tbh.
 
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?

Additionally, Barbie Seahorse Adventure is also written in Python / PyGame and also runs fullspeed on the Pandora.

So something sounds really wrong here, have you ever tried profiling the code to find out what the issues are?

I guess so far the game doesn't look impressive as it uses the graphics and music from SuperTux but runs a lot slower.

I know you added a lot more features, but most people who only take a glance and know SuperTux will probably complain about it.

Then again, with IndieGoGo, you can keep every cent you got, even if you miss the goal... :)
 
Not exactly so, if you do go the "flexible-funding" route, indiegogo gets more of all funds if you don't meet your goal.

I don't want to give 7% to a closed source funding platform, when all it does is promote non-free services and payment methods, given the idea is to support FOSS.
 
Last edited by a moderator:
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.
 
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?
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. :)
 
Huh, interestingly, disabling backgrounds increases the frame rate from around 33 FPS to around 40 FPS. Since I was disabling backgrounds on the Pandora (necessary because of the RAM limitation), that means the speed on the Pandora is closer to 1/13 the speed on my laptop than 1/10.
 
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.
Sorry, but a platform game should not need so much RAM that it needs swap space.

The Pandora has 512MB RAM. That is enough to store 349 full screens (800x480) worth of pixels stored in 32 bit RGBA. It should not be a limiting factor at all, unless you're doing something quite horribly wrong from efficiency point of view.
 
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.
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.
 
Back
Top