C2 Performance, let's be honest...

Uh, as far as I'm aware C++ is compiled to native code (unless you use an interpreter for some reason) which is processor instructions, and is no different from C in that regard, as opposed to being the language the operating system was coded in, which I don't think is relevant. Those languages become compiled to the instruction set of the processor on the system. Javascript is interpreted by some other program at run-time and is far slower as a result. I think with modern engines there's some sort of just-in-time compilation for javascript which means that when you run the program it is compiled to machine code at the time you run it, or part of the program is anyway.

HTML5 is javascript , and it gets interpreted (converted) into native code ( I think , correct me if I'm wrong ) in the browser , WHILE running the application , that's called an JIT compiler (Just In Time) , and that's why it's slower than native C , aka NodeWebkit ...

I hope this shed a bit of light on Javascript manners

Moreso , if you want to go more into details ,

Subscribe to Construct videos now

Almost correct, interpreting it would mean running the JS without compiling it into native code this is the more traditional slower "web" method of running JS.

The V8 engine (Chrome) actually compiles the JS to native machine code X86-64, ARM etc which has a number of advantages eg it can be further optimised at runtime, be cached etc etc It's almost as fast as native because it is ultimately native there's a loss of time in the initial conversion one must assume. Thing is although its been out in the wild a few years now the V8 engine is imo very much a work in progress I expect to see further significant improvements in time.

pixel perfick :

C2 has it's quirks, but on desktop platforms at least, it can generally hold it's own. I'm working on a bullet hell shooter now that can have 1000-2000 moving sprites on screen at times, checking cols against a few hundred enemies, all per tick(yes, cols too).

Plus particles effects, rotating enemies, multiple layer, parallax, etc.

I'm getting 60fps solid, with only occasional dips in debugger. Cpu usage maxes around 75, averages about 20-40, and that's also in the debugger, which adds a good bit of overhead, especially when you have a lot of moving objects. Now, I have a pretty fast processor (i5, 3570k), but I'm using it's integrated graphics.

This has been said before, but javascript has improved dramatically, and continues to improve in speed and performance. As other's have said, 90 percent of modern games don't code to the metal to begin with, because: a. too slow and difficult, b. OS in the way, and c. no way of knowing what metal is going to be there.

The key is this: javascript has a way to go to compete with C/C++...but there are no set-in-stone barriers to getting there.

tgeorgemihai, lennaert :

I kind of reject the idea that Visual/WYSIWYG editors will never be able to compete favorably with hand coded games. Obviously, hand coded will always be faster (IF they are coded well...and that's a big if). But, in most cases, it's not going to be the massive difference that it was in the past.

If you doubt this, take a look at the original Construct Classic. It's easily as fast as many custom coded pc games...and in many cases faster. And keep in mind that it would probably be even faster by now had the Scirra Bro's kept on developing it.

Of course, you still have to understand the basic logic that goes into making things work, still have to refine your approach, but at this point in time, most of the lower level muckity-muck is best left to the computer itself.

I wish I had the skill, dedication, time, and talent to build my games from scratch, to work exactly how I want them to.

But...I'd rather actually make them...with C2.

The technical performance differences between compiled JavaScript and languages like c is even more complicated. It's not a matter of 'JavaScript is x amount slower across the board.' Certain specific operations are different speeds depending on the language and the compiler.

Also, how the JavaScript is written makes a big difference - as an example, physics uses either the normal box2d web or asm.js. Asm.js is still JavaScript, but written differently. But even that isn't the whole story. A recent improvement was made to asm.js that speeds it up by about 50% when using that optimization.

Regardless, currently, even when compiled, javascript generally is not as fast as other languages, but it's not all that far behind and there is continual work being done that is improving it.

TiAm

This is what I want to see ,a game that pushes the C2 envelope, would like to see that running sometime...You need testers?   <img src="smileys/smiley2.gif" border="0" align="middle" />

Thanks for your refreshing post...

pixel perfick

TiAm

For 120$ you get an easy to use (almost no programming skills needed) game maker that export HTML5 (even without the "exporters", the index.html file can still can be tweaked to run on any device that supports HTML5). Of course that it has some issues like the TileMap scaling that makes it unusable on variable resolutions or the overall performance could be better... etc

The performance is not that great compared to native games, but it comes really close. We are talking about average casual gamer, the one that plays Angry Birds, not the one that plays Battlefield 4 at Ultra-Quality and expects no less then 60 fps... Any constant fps higher than 30 would do fine for average casual gamer.

Also HTML5 is not complete, still evoluates as we speak and Scirra team upgrades Construct 2 very often, for example:

• WebGL increased significantly the performance/speed
• asm.js powered physics
• bug fixes

Just to make a quick comparison with another few engines I tested until I decided to go with Construct:

Unity

Great engine, free for Indie Devs until they reach 100.000$ , great tools and support, and also exports native games on different platforms (including consoles) and decently easy to use.

The bad: You need to know programming, spend more time, need 3D models if you decide to make a 3D game and does not export HTML5. You can skip some programming if you buy a 100$ plugin named PlayMaker that gives a Construct-like interface, but also buy other plugins like IAP, Social (even PlayMaker have different plugins depending on platform, each variate from 10$ to 25$)... or you can code them yourself.

Game Maker: Studio

Costs 200$ to get the HTML5 exporter and the performance is not that good even if makes native games (Try Street Fighter X Mega Man to see the minimum requirements for a 8bit-like game)... For "better" performance you can buy the Yoyo-Compiler for just another 300$ or the whole package and exporters for 800$. On top of that you get to work with a very outdated layout editor and need to learn a proprietary programming language. Quite the deal.

Also has a great community and the support team answers to all questions you have about bugs and features. /sarcasm

The good part is that exports directly to other platforms without the need of 3rd party wrapper.

... and a few others engines

Long story -> Short:

You get what you pay for. But yes, I dislike the fact that I need to relay on 3rd party wrappers in order to export my game on different platforms. Also, from here on, HTML5 is just getting better and better.

tgeorgemihai

Thanks,

That's a good rundown of comparable game engines pro's and cons, as I have said more than once, I think C2 is great and would recommend it to anyone...

All I am asking is for us as developers to be honest about the performance of the games we are creating on C2, it's really easy to be consumed by the creative bubble, making us biased and zealously defensive of criticisms...

pixel perfick :

Will hopefully be done within the week. Kind of just a quicky experiment, mod of built in shooter. A lot of stuff I ripped from a more ambitious game I'm working on. Here's a screen though...(60fps, and 0.214 is cpu usage, so, about 21 percent)

TiAm

Good job. I like it. I found C2 weakness really isn't it's graphical render. it's the fact that it's really easy to make poor and slow event coding.

jayderyu

Thanks. I'm still learning my way around it myself.

One of the things I'm trying to do now is figure out how to break up collision tests across a few ticks, instead of testing all at once. With the addition of col cells, col checks don't make sense anywhere but the top level now.

So, the only way I've been able to figure to do it -- and I haven't even tried this yet, but in theory it should work -- is to create a family containing as many duplicate object as I have steps (so, if I want to test every second tick, two duplicates, every third tick, three duplicates, etc), then when I'm spawning these objects, call on the family to generate a random instance. I should end up with about an equal number of each.

Then, I can have a separate col test for each duplicate object type, and use a timer to loop thru them, only doing one per tick.

The advantage -- again, in theory -- is that the load on the engine should be more balanced. Lets say col check are taking 60 percent of the cpu when run. If I test every third tick:

test all every third tick, cpu:

10,10,70,10,10,70, etc...

So my average would be okay, but a high hit every third which could cause stuttering on a weaker system. OR...

test a third of objects(aprox), cycle every three ticks, cpu:

30,30,30,30,30,30, etc...

Anyway, all pontificating at this point...hope that all makes sense...anyone every tried this themselves?

A year ago, for the help cocoonJS I installed my apk games for sony xperia S then I had 30 fps.

Today I built a this same application by cocoonJS after installing I see only 5 fps!

Ashley

ludei

or someone can explain me whats really going on?