On iOS, cocoonjs' JavaScript performance, last I checked, was less than safari's. I hope they can improve it, but apple doesn't allow as many technologies on iOS (which is why chrome and Firefox aren't really on iOS - Firefox is a no show and chrome is just a reskin of the web view).

C2 may make game dev easier, but it is inherently a complex subject, and learning how to optimize for mobile is something you shouldn't expect to not have to learn. C2 cannot know when you're trying to do something in code that a target device can't handle. Are you targeting powerful or low-end devices? Or both? There's no way for C2 to know.

> I've been logged off three times now, even though I've set it to keep me logged in.

>

Dont tell me you got posting errors and the posts vanished xD

noooooooooooooooooooooo !!!

Been online for couple hours and have not experienced that.

No posting errors - I think it has something to do with the fact that I've got the unread posts page bookmarked. I switched my bookmark to the main index instead to see if that fixes it.

I've been logged off three times now, even though I've set it to keep me logged in.

Chrome 32 and node webkit currently have a performance problem, chrome/chromium 33 fixes it.

Also, I don't know if it's possible, but two things I liked about the old forum were:

• being able to click on the 'x new posts' to go immediately to the newest post (Edit: nm, there is a link, it's just so small I didn't notice it)

• having the posts in the new posts section be sorted by forum (the way it's set up now I have to check each thread for if it's in the right forum area, rather than knowing that all threads in a section are in that current forum area)

Being able to set all threads to 'read' status would be helpful as well. (Edit: oh, you can, but the link is only on the board index. It seems like it should also be on the pages showing the unread topics and new posts)

I'm not finding any way to get to a user's profile other than typing the address manually.

It's lookin' good! Thanks for all the work, Tom!

Aside from what you've mentioned:

• the font size button doesn't remember the setting and has to be reset on every page
• on my ipad, the forum doesn't take up the whole screen - there's a white vertical stripe on the right side of the screen
• I think the content column (with the avatars and post text) should be wider. It seems a bit narrow.

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.

A sega mega drive is a highly optimized, non variable target platform. Games could be coded to the metal. You can't do that on PC, there are too many layers of abstraction getting in the way. Apis like direct x make it easier to do things, at the cost of raw speed, but developers use it because it would be an utter nightmare trying to support all the different configurations of hardware otherwise.

On a mega drive you don't have all the other bazillion parts of the os and background programs competing for resources. You don't have to worry about buggy unsupported drivers. You know exactly what you're working with.

No one's claiming JavaScript is as fast as native - it's not. In my tests (done a whole ago, things might be different now) I recall CC was about 1.5-3 times faster than c2 in event execution speed, and c2 was actually faster at rendering. My computer isn't that fast either, an AMD 4400+ with an Nvidia 9800gt, what I would call probably a low-end computer if it were new, and yet most of my stuff runs fine.

As I said before, performance is a complex matter. Even c++ games have performance problems with the os and abstraction layers getting in the way, which is why ati's mantle API was created to try to improve that.

nimos100 - I checked your performance test.

I made a small program here, that basically doesn't do anything except moving some small sprites around. You get a massive performance hit.

Your capx is far away from just moving some sprites around. It's moving 650 sprites around and doing 422,500 collision checks every tick.

Which is caused by "on collision", there are added nothing to it. And you are not able to change the way this event works as its part of C2. Now in the program I have added that it should only trigger this if the speed of the sprite is above 0. Which ofc shouldn't make any difference to whether it should check for collisions or not, so removing it, makes no difference. And since the event doesn't actually do anything, it doesn't matter anyway in this test.

The event most certainly does something - the collision condition is what's slamming the CPU. Conditions take CPU time, too, and in this case it's a lot of it.

You also set up the event wrong. You have:

On sprite collision with sprite

Sprite bullet speed is > 0

This means c2 misses out on all the performance benefits because it does all the collision checks first, which is the more intensive task. The filtering happens top to bottom, so what you should have done was:

Sprite bullet speed is > 0

If sprite is overlapping sprite

Doing that gets 60 fps on my computer. Checking the bullet speed is a far, far faster operation than the collision checks, so by filtering them out first, c2 doesn't have to do any collision checks at all.

On my computer the moment I spawn 350 objects, the fps drop between 20-25 instantly. Even though these objects do absolutely nothing, except being on the screen.

I want to make sure you understand that just because the object don't appear to be doing anything, doesn't mean you're not slamming the CPU. The act of checking for collisions on them all every tick is intensive, even though there is no visible result.

So even though the computer also plays a part, the C2 engine or what to call it, will be the first thing to kill performance. Im pretty sure my computer can handle rendering 650 sprites :D

Again, this example is CPU bound, not GPU.

In order to improve performance when handling lost of objects, you would need to be able to control when and under what conditions for instant collision testing should even take place.

Which you can. You can set conditions, but they need to be BEFORE the collision check. That's why you use 'is overlapping' rather than 'on collision' so you can put conditions before it (trigger conditions have to be at the top of the condition list).

Chrome 32 has a performance problem that's fixed in the next version. It affects node webkit as well.

On my computer, an AMD 4400+ and Nvidia 9800gt, it runs at 60 fps in Firefox, 67 fps in IE (odd...) and 60 fps in cocoonjs on both an ipad 3 and iPhone 4S.

Not sure why your laptop is having a hard time with it, but laptops are generally a lot weaker than desktops. Thoughts about what could be causing the issue: sometimes performance on laptops is reduced by having them unplugged, you could have an 'abandoned' card that isn't getting updates for its drivers anymore, if you're not using aero you're not getting hardware acceleration for the window manager, your card could be blacklisted.

Aside from that, I'm not sure. Performance is a frustrating topic sometimes, as it seems it should be simple, but isn't. :/

nimos100 - checking 500 objects against 500 others is 250,000 collision checks per tick. That's a lot. There are ways you can cycle through them and only check them in batches, and a lot of what's going on in that video with the moving objects doesn't actually require collisions at all.

You can set it to run with the 'use driver blacklist' flag disabled by default, I think in the manifest file, though you'll need to package it yourself that way with node webkit instead of using C2's nw export.