Some questions on performance, box2D and usability
Monkey Forums/Monkey Beginners/Some questions on performance, box2D and usability
| ||
| Hello there, I just finished a game in Unity and I was somewhat disappointed by the performance on low-end android devices... it's a rather simple 2D shooter and I would like it to run on Galaxy Pockets and alikes, but that was not possible... when the game is simple, the overhead of Unity becomes significant. So, since I'm not actually planning to go 3D anytime soon, I started looking for alternatives, I've used blitzmax in the past and I really loved it, so I'm considering Monkey since it's the new thing from the same guys. The other two 'competitors' are Haxe (OpenFL) and LidGDX (although I don't know Java). I've downloaded the free version of Monkey, the Box2D module and modded the box stacks demo, to create lots of smaller boxes instead, however, when I try to create 600 boxes, the memory goes up to 2GB and then goes down to about 130MB, when I try to create 1200 boxes, the thing crashes. I don't know if that's expected, perhaps some GC peak or something... but in any case, I'd like to know how Monkey compares, in terms of performance (sprite rendering and physics2d performance) to the other competitors like Haxe (optionally Nape for physics) and LibGDX for 'native' target, be it desktop or mobile. Is it possible to batch draw calls in Monkey? Do you have to do that manually? Also, I'd like to know how is the usability compared to something line Unity... I don't actually need the GameObject+Component architecture, but I would like to know if there are easy ways to edit the levels and stuff. Perhaps some external tools or something. Thank you in advance. |
| ||
| When using the Desktop target, the GC executes once per frame. If you're creating lots of garbage on.a single frame, it could have issues. To fix this, you only need to enable the generational GC using a compiler directive. I'm not at my computer now, so I can't tell the directive name. However, testing your app on HTML5 should not show this issue, and the same goes for Android. It's something speciffic to the C++ collector. Setting it to generational collection, will solve it too. |
| ||
| Hello there. HTML5 is just too slow for that... I'm sure it's possible to make it work though... I'm mostly interested on this because I read somewhere that the Box2D port is not that slower than the LibGDX wrapper, which is basically plain C++ because the JNI overhead is very minimal. Any rough numbers on graphics performance is appreciated also, specially comparing these 3 alternatives. Of course I expect LibGDX to be the faster one, but I'd like to have an idea on how slower Monkey is (2x, 5x, 10x, etc). Thanks. |
| ||
| Hey Szabo, welcome to the forums. You might want to check out Ignition along with the RUBE module and editor. http://www.playniax.com/index.html |
| ||
| The Monkey Box2D Module is a port of the Flash version IIRC.... <goes to look> Here we go: https://code.google.com/p/monkeybox2d/ This is a port of Box2D by Erin Catto (http://www.box2d.org) to the Monkey language (http://www.monkeycoder.co.nz). The port is directly translated from the Box2DFlash 2.1a code (http://www.box2dflash.org), with credits to BorisTheBrave, Matthew Bush and John Nesky for their work on that project. I would also take a look at this thread and start reading at post #38 as that's where performance starts to get discussed. |
| ||
| Is it possible to batch draw calls in Monkey? Do you have to do that manually? Batching is done automatically. (edited) Monkey can automatically batch drawings into the same draw call if they share the same image and blending. Do: Don't: |
| ||
| ... modded the box stacks demo, to create lots of smaller boxes instead, however, when I try to create 600 boxes, the memory goes up to 2GB and then goes down to about 130MB, when I try to create 1200 boxes, the thing crashes. Did you build and run it in "release" mode? |
| ||
| DrawImage(image1, ...) DrawImage(image1, ...) Is this automatically batched if instead you draw two images that are grabbed from image1? [Actually, this might explain why grabbing is not recursive, as somebody noticed recently...] |
| ||
| (I edited the previous post and example) Is this automatically batched if instead you draw two images that are grabbed from image1? Yes. Monkey can automatically batch drawings into the same draw call if they share the same image and blending. |
| ||
| Monkey's version of box2d is a "naive" (read: mostly machine-converted) port of the version of box2d used in ActionScript games. It will be slower than a native port of box2d. I don't know if haxe uses native box2d or one in its own language, but if it uses the C version then it will be faster. The maintainer of the box2d port (whose name escapes me right now) is decent at fixing problems with it if you can report the bug and track down the problem with a profiler, but it will probably always be slower on some platforms compared to native. This means Android, mainly. I've had a project that used box2d extensively for its engine running at about 28fps on Android on my old Nexus S phone. There were approximately 100 active objects in the simulation being polled for at any one time. Depending on your game, you can deep freeze objects in and out of the simulation to increase the framerate for objects that are out of range, off-screen, or whatever. There shouldn't be any serious bottlenecks unless you're making some kind of danmaku game which requires full collision mechanics. (And if you're making one of those, usually you'd be writing your own collision code and foregoing most physics simulations entirely) |
| ||
| I use Monkey's version of box2D in my project. It runs really great, although I do not have too many bodies in my game. The most extensive level is Level 12 and has over dynamic 100 box2D bodies. Everything runs nice and smooth on my Android tablet, Android phone, HTML5, and GLFW builds. The game is here on the Monkey site if you are interested in trying the HTML build. http://www.monkey-x.com/Community/posts.php?topic=8722&app_id=321 |
| ||
| Thank you guys. Sorry for the bad formatting. I'm typing this in a phone... @why0why: thanks for the recommendation. @programmer: yes I'm building a release version. I'm not building anything massive ATM but I'd like the game to run in as many devices as possible, so I'd like it to be as efficient as possible. Is it possible to have a wrapper for native box 2d in monkey? (Or perhaps chipmunk). |
| ||
| I did a quick test of Box2D via Haxe using the Android NDK build earlier in the year and it was actually slower than the Monkey Java output. Joshua Granick puts it down to their version of Box2D being poorly optimised so maybe it has or will improve. Last time I tested performance on LibGDX it had <20% speed improvement over the Monkey output on Android. As with everything your mileage will vary depending on your particular use case and the version of Android/hardware you're running on. As you haven't provided your test case I can't say what's going on with your memory usage/crashing. It's fair to say that 600-1200 dynamic boxes is a lot for most Android devices to handle though. Perhaps you should try your test case in LibGDX and see how that goes for you before planning a project that needs that sort of scenario. The domino stack test only involves a couple of hundred blocks and LibGDX can only manage around 13 simulation frames (no rendering) per second on my, admittedly old and weedy, Android phone. Is it possible to have a wrapper for native box 2d in monkey? Sure, let us know how you get on writing it. :) Monkey's version of box2d is a "naive" (read: mostly machine-converted) port While about 90% of the initial code was produced by automated conversion this description is quite off the mark. It's certainly inaccurate when discussing Android performance where significant effort has been made to optimise for that platform's particular issues. |
| ||
| @muddy_shoes: thank you. I know box2d sucks for haxe, that's why I mentioned nape because it seems to be way better than the other options and comes closer to native box 2d performance. Libdgx is practically the same as native performance, at least on desktop. I don't know how it performs on mobile. Besides the advantage of speed, libgdx also has 3d and uses java which is somewhat valuable knowledge. I still didn't decide though... In fact I'm noticing that even for simpler 2d games, these options can't really be compared to unity... I'd like something higher-level, I mean, a fully featured engine with a solid workflow including appropriate graphical tools for the different tasks. |
   |