About C++ performance. Box2D. Performance worse than Flash.

[Beliar]

Hello there. I'm looking for a modern and high-performance cross-platform solution to program 2D games initially for the desktop operating systems (Win/Mac/Linux) but I also plan to go commercial and release paid versions of some of my games for iPhone/iPad/Android, as well as ad-supported Flash versions.

However, the most important thing at the moment is the ability to deploy native applications (full-performance and without virtual machine) for the standard computers.

I'm playing with NME and It seems good, I don't understand some concepts, but overall, the entire thing flows smoothly (I'm using FlashDevelop). The only fallback is that I measured the performance of the box2d library (installed with haxelib) and when compiled to native code (cpp), the performance isn't good at all, I made a simple benchmark using the Date.now().getTime() (I think it's suitable) and the C++ version is only 23% faster than the Flash version (maths only), when the rendering comes into account (box2d debug rendering) the performance is actually much worse, I think it's due opengl problems, but it's not only worse in speed but also the Flash version is fully antialiased and pleasant to the eye.

I don't know if this bad performance is normal, because it's 34 times slower than the pure-C++ version, and I was expecting it to be at least 2-3 times slower.

When it comes to simple mathematics, a C++ version can outperform the Flash version by 10,000 times, I think it's due compiler optimizations. 

So, is it possible to achieve a good performance for native C++ binaries, or should I look for another solution?

Thank you.

[Joshua Granick]

I am working on native bindings for the original Box2D C++ library.

One concern with the Haxe version of Box2D (which was ported from the
Flash version) is that there are no stack variables. Box2D uses a
tremendous amount of B2Vec2 values which are allocated on the stack, and
cleared at a later point. Haxe is handling them all on the heap and
garbage collecting. Pooling instances or some other optimization technique
could make some good headway.

Using the Date class is also a slow way to get timestamps in C++. Try
"haxe.Timer.stamp ()" instead.

Lastly, you might actually see better performance by using "cacheAsBitmap"
on the debug draw. That toggles whether the objects are drawn in hardware
or software. For real applications, bitmaps (handled in hardware) perform
much better than primitives, overall.

[Hugh]

Hi,

NME is not optimized for drawing lines - solids work much better, and tiles/bitmaps work even better still. eg, an "angry birds" style game would render much much faster than a "debug line" style game.

"When it comes to simple mathematics, a C++ version can outperform the Flash version by 10,000 times"

This is simply not true for as3 and modern flash player.  The flash player can use "jit" to compile the code into something like native code, and for the case where you perform some calculations on local variables, it can be 100% as efficient, although typically I would expect 2x to 5x slower.  The main differences come with object-access patterns.  C++ code can avoid "allocs" by putting stuff on the stack, but flash (and hxcpp) can't.  So it is the object creation stuff that is slower, not really the numerical stuff.

I would generally hope that the hxcpp version would be about 2x faster for the physics calculations.  For lines, I would say it would be slower to render.  For bitmaps, I would say faster to render.

Only being 23% faster would indicate that there might be some optimizations that can be done.  Another possibility is that the current port is over-optimized for flash and is using some constructs that are hurting the hxcpp code.  So infact, the performance by be improved by removing the "optimisations".

Hugh

[Beliar]

Good to know you're working on Box2D because it's the most important thing for 2d games nowadays after input, video and sound (imho). :).

That's true, but I'm not sure if these optimizations would make such a brutal difference. There's another code-once-deploy-everywhere language around (a commercial one) and the guys ported the Box2D from AS and the thing performed well after converting to C++ (less than 4 times slower than native C++), and outstandingly when converted back to AS (almost the same performance). However, the difference between AS and C++ was huge.

The drawing is not the issue actually. I'm sure this is not a real problem, and as you said, maybe it's just a problem when using the debug draw.

I though haxe would be able to convert the code to all targets while maintaining a consistent performance according to the target language inherent performance. I'm not talking about rendering here.

Thank you.

[repga...@gmail.com]

The drawing performance is not the actual issue.

Hey! I'm not a liar! :). That's why I said I think it's due compiler stuff. For example, when you have:
while(x<y){x++;}
The compiler just do something that returns x=y in 0 millisecs, doesn't matter what number y is, and on flash, if y is too big it just crashes the plugin.

I was expecting the hxcpp version to be something like 20 times faster than Flash, about 2 times slower than native Box2D.

Look, you can't really compare Flash to native. For example, if you use high-performance and newer stuff, like, let's say, Box2D and SFML, you end up with a performance that i'm 100% sure in real-world applications Flash can't come close, not even closer than 20 times slower I should say. The problems here is that in Flash you take (I'm not a Flash dev) one day to program something you would take a week (program and debug) in C++. That's why I want to avoid going pure-C++, it's a pain. Java and Mono have silly VMs, other languages have interpreters and are stupidly slow for a game... I can't see a good alternative. Now I understand why so much game studios are still using C++.

Thank you.

[Robert Carcasses Quevedo]

Hi Beliar, 

I personally have used Box2d to build as3 games in the past, and honestly I didn't like it very much. More recently I have discovered a haxe library: nape, which I believe is the best choice out there to build games with physic engine. Nape haxe library is a version of a popular c++ one, I'm personally a physicist, and have play around with several libraries and I have found nape much more fast and pleasant to work than Box2d. I'm not sure, but I guess the current haxe version in haxelib should work well in all platforms, and at least faster than Box2d. If you decide to change I could give you a hand, I hope the information worth something for you.

Kind Regards,

Robert

[Luca]

Nape isn't based on any C++ library :P It's original version was 'inspired' by physaxe, glaze, and box2d, though the new api is novel and has some novel features (more in development).

I've not worked with haxe box2d, but comparing native C box2d, to nape running on hxcpp I get roughly about a 2x speed difference (on desktop)

This was a test with a stable 820 box pyramid which gives roughly:

35fps in release flash player (nape)
95fps in hxcpp (nape)
180fps in c (box2d)

One of the things I've asked in the past is whether we can get hxcpp to use Float instead of Double which might give some better performance when it comes to cache use since box2d uses floats not doubles.

[Luca]

+ chipmunk

[repga...@gmail.com]

Wow! Am i dreaming? :) Nape is fantastic! It has all the features I need plus a lot of cool stuff!
Unless Box2D performs better than Nape in AS3, I don't see any point in porting it while we have this amazing piece of software already. (sorry Mr. Granick :D ).
Man! If it's true it is only 2x slower than Box2D (C vs hxcpp), then it's perfect for me! :).

Thank you guys!

On Wednesday, May 16, 2012 1:24:52 PM UTC-3, Luca wrote:

+ chipmunk

[Hugh]

Hi,

You can try -D HXCPP_FLOAT32 in the latest release.

It's not fully tested, but give it a shot and let me know how you go.

Hugh

[Robert Carcasses Quevedo]

Thanks Luca for the explanation, about the performance in as3 of both libraries, still nape goes beyond box2d, even to the version compiled with alchemy. Box2d is even hard to work with, very messy to assign graphics to bodies, etc. I personally think there is no reason for use box2d in any haxe project while having this piece of art named nape. One warn: if you compile nape from haxe sources to swc and use it in a pure as3 code, you may have problem with some NaN definitions that can make your life miserable, I don't remember where but look for NaN definitions and replace it for huge numbers.

El martes, 15 de mayo de 2012 23:31:30 UTC-3, Beliar escribió:

[Luca]

I have it documented how nape has to be compiled to .swc; it needs to be done with additional flags -D swc and -D flib, and then passed through my 'flib' tool on github which does some magic so that the AS3 swc has the same API as the haxe lib.

[Luca]

I will try as soon as my exams are over :)

[Robert Carcasses Quevedo]

Thanks again Luca, and on behalf of this I would like to congratulate you for the amazing work done with nape. I didn't know about the additional compiler options, when I use nape with as3 I usually do all the physic logic in haxe, and that's why  I don't use the SWC provided with the library but compile my own with additional code. After a lot of debugging I realized that there was a problem how haxe translate some constants to the AVM2. Replacing:

public static inline var POSINF  = Math.POSITIVE_INFINITY;

by

public static inline var POSINF  = 1e+99;

at nape.Const.hx, solved all the unexpected issued. Sorry for being a little off topic, but I think this is something could really help people who reads this post.

[Luca]

source already has: 

	#if flash
		//cannot use POSITIVE_INFINITY due to haxe bug
		//cannot use untyped __global__["Number"].POSITIVE_INFINITY due to some strange memory consumption.
		public static inline var POSINF =  1.79e+308;
		public static inline var NEGINF = -1.79e+308;
	#else

		public static inline var POSINF = Math.POSITIVE_INFINITY;

		public static inline var NEGINF = Math.NEGATIVE_INFINITY;
	#end

[Robert Carcasses Quevedo]

great then :)

[whitetigle]

Hi hugh,
you mean in official 2.09 ?

Cheers.
François

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

-- 
http://whitetigle.tumblr.com/

[Hugh]

Yes, the one on haxelib.

Hugh

[ex]

Nape looks good indeed,
but the problem for me it's the BSD license,
I'd prefer MIT licenses for commercial work.

[Luca]

What's the problem with BSD for commercial work? The only 'restriction' is including a copy of the licence with the work?

[ex]

It's related to work for hire projects,
in order to fulfill the license the client of our project must make available a copy of the license in their web page in some place.
most of the companies we work for (I think all) don't want to add any additional link in his frontal web page.
"Distribute the license in the documentation for binary distribution" how affects this web deploy?
I'm not sure but my interpretation is that if you use Haxe or Nape for doing even a banner in order to really fulfill the license your client need to agree with this license if they are going to use your work in his web site. This is not a problem with pure Flash tools.
With MIT licenses there is no problem because there is no obligation to do this.
If it were my personal project of course there is no problem to add an about box with some links, I don't have to ask for permission to bureaucratic hierarchies :D

[Tarwin Stroh-Spijer]

I'm not sure if this is really what "should" be done, but having a list of the work you've done, with links to what technologies and associated licenses on it, would at least be "nice" to the authors. Not sure if it goes far enough, but at least you're not pretending you did it all yourself then.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
cell: +1 650 842 0920
_______________________

--

[ex]

Yes, I understand it's a nice thing to do, indeed it would be the correct thing to do,
The problem is that sometimes it's not easily done. Changing the way how my client works?
I think that is not going to happen, we are a small fish in big pong.
so sadly we must avoid any license that give us additional administrative work or is plain impossible.

[Tarwin Stroh-Spijer]

I'm not talking about on the site itself, but on your own site. I find sometimes it is not possible (and sorry to anyone for whom I have not strictly followed their license) and simply list the technologies etc on one's own personal site / portfolio is at least trying to do the right thing.

Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
cell: +1 650 842 0920
_______________________

[ex]

Oh that could be ok.

However some of our projects are under no disclosure provider, so we are not allowed to talk about them,
It's true, and no, we don't work for NASA or the CIA, but some companies ask for this, even if you don't believe me.
Saying no to those contracts is not possible if you want to work with them.
That is making a bit harder for us to decide to go with even with Haxe,
Haxe has also the BSD license in the standard libraries that is used everywhere.
I know the Haxe authors are ok with we posting credits in *our* site, they even talk about switching licenses to MIT soon,
I 'm not sure if other BSD project authors are ok with their credit not showing in the *deploy* site.

Thanks, and sorry about the off-topic.

[Luca]

Actually, does BSD even require license to be distributed with derived work?

The license states distribution of the work in binary form must carry the license, which to me would mean that if you distribute a .swc of nape, or a compiled library which uses nape, then that library has to carry the license. But say, compiling a project which 'uses' nape but which doesn't empower the user to make use the library (so it's not really a distribution of the work at all) then the license doesn't need to be included?

[Luca]

By that I mean say, distributino of a game which makes 'use' of nape, doesn't need to carry nape's licence. 

Distribution of say, a game maker which lets you build games that use nape, would need the licence or something like that :P