Ashley's Forum Posts

  • You can disable c2 collisions for a performance boost

    This will have no effect if you don't test for collisions in events. If you make no collision tests yourself, then the C2 engine doesn't make any collision tests either, so it's irrelevant whether the object has collisions enabled or disabled.

    I don't think there's any way around having the two collision tests - not all games use a Physics engine, so C2 needs its own engine. But as I say if you don't use collision events on an object then it will only use the Box2D collision engine.

  • This doesn't make sense to me, I don't see how an issue can "propogated throughout all previous versions" since we haven't changed any older versions.

    Please follow the bug report guidelines and comprehensively describe the problem with complete steps to reproduce it.

  • The physics engine is difficult. I want to go with only the asm.js physics engine, but at the time the asm.js version was built it lacked the ability to disable collisions. That's pretty much the only reason it's not the default, since right now any project using that feature will be broken by switching across to asm.js.

    Adding that feature to the asm.js build has become very complicated since Emscripten subsequently got a bunch of updates and broke backwards compatibility. So despite the asm.js physics being open source, it's no longer useful since it does not build with Emscripten any more. I contacted the original developer on a couple of occasions, and they say they are too busy to update it. Besides people are now asking for features like certain types of joints that aren't supported by the (now fairly old) version of box2d that the asm.js version was built against. So to get that one last feature for asm.js and make it the default, the entire asm.js port of box2d needs to basically be rewritten from scratch. That is a pretty complicated project, and the end result may not even be backwards compatible with what we have now either (even just a slight change in the way floating point calculations are rounded can have a cascade effect with results like a tower of objects falling in a different direction with significant change to the gameplay).

    Since as ever we get a constant stream of feature requests and we could never have time to deal with them all, we prioritise the easy ones, or the really important ones. This is not easy, and I see the existing situation as acceptable (there is the high-performance option with a single missing feature, or the slower box2dweb which has collision disabling). So weighing it up with the amount of work vs. benefit to be gained, I see it as not ranking very high. That doesn't mean we won't do it, it's just more likely to fall behind other things (like the requests we get for the image editor, and 'open external editor' is a good example of something easy which can bring a lot of benefit).

    Box2d and Emscripten are both free open source projects, so in theory anyone could come along and do this work, and then we should easily be able to integrate it back in to the behavior. But with all the other demands other customers are making it's hard to justify ourselves doing that. So if you know how to do it yourself or have any other developers handy, building the latest Box2D with Emscripten and writing the bindings is 90% of the job.

    I don't know what tests you guys are running but asm.js typically comes out 3-4x faster than box2dweb for me. I just ran another stress test to confirm: 2700 objects at 30 FPS with asm.js, and 850 at 30 FPS with box2dweb, making asm.js over 3x faster, and that's in Chrome which doesn't yet specifically compile asm.js code like Firefox does.

  • It's intended that you publish with the PhoneGap Build, Intel XDK or Ludei Webview services. You can also try the PhoneGap CLI, but we do not document that ourselves (they provide their own documentation and it is for technical users anyway, whereas most C2 users are non-technical). A UIWebView is pretty barebones by itself and Cordova provides some useful additions to make it work more usefully, so you will probably want to start with a PhoneGap project in Xcode as opposed to a new empty app.

  • Thanks, should be fixed in the next build.

  • Closing as this is not something the Browser object controls - it looks like the Android OS is bringing back the status bar at the top. You could work around it by showing an in-game message instead.

  • Closing, please follow the bug report guidelines and provide a .capx.

    I would strongly recommend you use a different image hosting service since the one you linked to is NSFW.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Perhaps if the save mechanism changed... for example, instead of trying to save an auto-backup file as the >same< name... you save it as backup2, and if that succeeds... then replace backup1?

    It already basically does that. I've reviewed the code and I can't see why it would hang. It first saves to a .capx.backup1.tmp file, and only after a successful save, it deletes the existing .capx.backup1 file then renames the .capx.backup1.tmp file to .capx.backup1. So it's not even directly writing to the file. Even if the file is locked, then the delete will fail, then the rename will fail, and then it finishes the backup routine. That's what I see happening when I test it. It shouldn't hang, because AFAIK the delete and rename operations should fail instead of wait if it can't access the file. Perhaps there is some other software installed that is conflicting with this.

  • There is one last quirk that can make WebGL slower: on some platforms, updating a large Text object every tick can hit the framerate. Otherwise in pretty much every other case it's faster. So I'd guess that's what you're doing.

  • That's what node-webkit is for, why do you still need to run it in a browser but offline?

  • That's what the Cordova export does.

  • Javascript is garbage collected so increasing memory usage is expected until the next garbage collection event, which may not happen predictably. Can you provide a .capx (as per the guidelines - your description does not use an unmodified example file) which does this automatically and clearly proves that the memory is not collected?

  • Closing, please follow the bug report guidelines. Try turning off all your browser addons as well in case they are breaking it.

  • Reproduce the problem in a new .capx that you can share, otherwise all I can do is speculate that WebGL shaders caused the performance problem, and turning off WebGL also turns off the shaders.

  • Not with the SDK, no.