Ashley's Recent Forum Activity

  • When you import images of any format Construct 2 re-saves it as a PNG using a default stock encoder which doesn't do many optimisations, because it's not as important for your project to be small, only the final exported project needs to be as small as possible. Also if you change an image at all in the editor (e.g. flip or mirror or any tools when we add them) then it can't re-use the original image anyway, so it would be very brittle to try and make Construct 2 always use the exact imported file.

    Instead everything's run through image recompression on export to squeeze files down to the minimum size. I would be surprised if, on export, you could beat the compression done by Construct 2 - we've paid to license some specialist tools for the process, and it will do things like count the colors and switch to PNG-8 for 256 color images, and then try multiple PNG compression strategies and pick the best one.

    However, if you can beat it, you can safely paste over the exported image files.

  • qster: Firefox 11 supports looping, out in a few weeks.

  • Hi all,

    I've found a slightly updated version of Box2D that ought to be faster and reduce the garbage collection overhead. This should help reduce pauses or stuttering in complex physics-based games. I've done some of my own customisations and the final script after export should come out smaller too.

    However since it's modified it might not work exactly the same as it used to. If you could give it a spin and give me any feedback on performance, GC pauses and functionality, that would be great... it worked fine with all the Physics demos I've made, but I don't want to slip a big change like this straight in to a new build in case it breaks lots of games.

    Here it is - back up your old runtime.js for the Physics behavior then try pasting this one in:

    http://dl.dropbox.com/u/15217362/physics-refactored2.zip

  • Oops... you can work around this by adding the following javascript to the exported HTML:

    function log(str) {}

    ...or just go back to r80.2 for the time being.

  • Probably this bug

  • The plugin-making language is javascript!

    With all plugins written in such language, even if it were to be a custom language developed by Scirra, a tool could be created to convert said plugins to the native language of the exporter, maintaining the plugins compatible across runtimes.

    All official plugins and behaviors are written in Javascript, just like all the third party ones, using exactly the same SDK. This means we could in theory port them with the V8 javascript engine - but that doesn't run standalone on some platforms like iOS, where the only way to run javascript is in a browser. On top of that V8 is a "pure" javascript engine with no features like rendering, audio, HTML, form controls etc. and many existing plugins and behaviors have dependencies on there being an actual browser there with those features. So it would still be difficult to port.

    Doubtless browsers will get better on all platforms over time, and the situation will get better.

    TBH rewriting everything to another language in any capacity is off the cards - for the time being at least - there's no way we could possibly pull it off. However, there are lots of other good ideas here like a central plugin service which we've also been thinking about ourselves. Hopefully we can come up with things like that in feature to resolve some of the other pain points.

  • From reading their forums, GameSalad are currently undergoing a major effort to remove all Lua from their engine, because it's far too slow.

    Isn't Javascript that "agnostic solution" anyway?

  • Closing as not a bug.

  • Both run 60 fps here.

    My best guess is:

    1) all your 'for each' conditions are redundant except the one in 'on start of layout'. Events naturally run for-each instance, so you only need that condition in corner cases where the event system's default behavior is not enough. Adding 'for each' to an event where you don't need it can cause slowdowns because it forces Construct 2 to repeat the event 250 times with one instance each time, rather than handling all 250 instances in one go. I had to create 5000 stars to get the fps to drop on my computer (!), and the fps nearly doubled when I took out the redundant 'for each's!

    2) I can't see the GameMaker project, but I assume you just painted stars directly using some draw function. This is more efficient than Construct 2's sprite object and is one of the areas scripting can get ahead of events. Despite spending a lot of time ensuring sprites are as optimised as possible, they still carry a lot of "weight" like instance variables, collision polygons, and the event system which has to do extra processing compared to what a script would do. (GameMaker's Sprite is not really directly comparable since it represents an image only, its Object is a more appropriate comparison.) In most cases I would think the same thing in both would run about the same speed, but this is one of those specifically-designed cases where a difference can be seen. Not totally sure here, but it's my best guess.

  • Ah, thanks for the report, should be fixed in the next build.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You do not have permission to view this post

  • If you already know the necessary server-side coding, there are just a few really important points you need to know:

    • run the game in an iframe on a different domain to your website. We run the games off static1-4.scirra.net, and the parent frame is scirra.com. These count as different domains, and the browser blocks the iframe accessing anything in a different domain, meaning the website's info is safe from the game. (This is the same principle that stops any website AJAX'ing Facebook in the background to get your personal info.) You can also try sandbox="allow-scripts" on the iframe for extra security.
    • have a whitelist of allowed file extensions or filenames - do *not* allow anyone to upload any .aspx, .php files etc! Just have a whitelist of files that are allowed e.g. index.html, *.js, *.png, and reject anything else.
    • it's best to manually verify all entries to ensure there's nothing obviously malicious going through.

    Our arcade actually has extra steps to ensure double security: the Arcade export format is data-only, so the user does not actually upload any javascript code at all. This means the games only ever use our official runtime code and previously approved plugins. However this is technically complex to set up - you should be OK with the above steps only.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,773,986 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs