Ashley's Recent Forum Activity

  • From ***MUST READ FIRST!*** Bug report requirements:

    [quote:2kh0zkm3]Why haven't you responded to my bug report yet?

    We do look at every report, but developer and release schedules mean we may not get round to it immediately. Please allow a few weeks for it to be investigated. If you are waiting, you can improve the chance it is resolved when a developer does get round to it by carefully reviewing these guidelines and providing as much useful information about the problem as possible. If you are missing anything, you may end up waiting a few weeks for a reply simply asking for the missing information, and then you're waiting again.

    Emphasis added. Please be patient. Two or three working days is not a reasonable amount of time to expect a bug report to be investigated.

  • Events are always evaluated sequentially. The only way you can run an event outside of top-to-bottom order is with a trigger (such as a function call). Within each event, the conditions are tested from top to bottom. If they are all true, and only after all conditions have been tested, the actions are then run top to bottom. It's pretty simple, it all runs in order!

  • If you need real-world examples of why and how this would be useful, just say the word.

    I always need that. That is mandatory. I have no evidence that the sampling mode impacts performance in any meaningful way. Can you provide data that backs up this assumption/assertion?

  • paradine - it sounds like most of your criticism is centered exclusively on Crosswalk. It had a bug recently which could reduce performance, but it should be improved in Crosswalk 14. There's no reason Crosswalk can't be as fast as the browser (it is a browser), so it should be able to produce identical results to your HTML export which appears to have excellent performance, so if it can be that fast, what do we need a native exporter for? We're not going to work on a 12-18month project just to work around a passing bug in Crosswalk.

  • Well, most games that use physics, particles and pathfinding are CPU-bottlenecked.

    If you're using asm.js physics, there's not much more that can be done to make it faster - it should already be about as fast as physics in a native engine. Pathfinding runs in a web worker in parallel to the game so even if it's slow (and generally it's still reasonably fast) it should have no impact on the framerate. Particles are already highly optimised and even very large effects should run well (this demo runs nicely on many of the mobile devices we have in our office, with ~800 particles).

  • There is a bug in Safari that it cannot load sound from the offline cache. There is no way to get sounds to play offline: either you disable the offline cache so sounds can play but it won't work offline, or you enable the offline cache so it works offline but sounds might not play.

    It is however already fixed in the latest iOS 9 betas, so it should be fixed from iOS 9.

  • The engine doesn't know ahead of time what kind of scaling or zooming will be used. If they are only ever used small, it will waste memory preloading images which are too large, and if they are always scaled up a lot, they will still appear pixellated. Also any kind of image processing on startup could make the loading take far longer.

  • A PNG file is just a PNG file. There are no "fast" or "slow" PNG files. They are all the same. The software you use to create PNG files doesn't matter.

  • There are a few problems with SVG support in C2:

    • as people have mentioned, it can seriously degrade performance. Textured sprites are super fast to draw. Normal sprites are always a box with 4 vertices. A single SVG object could involve hundreds of vertices, having an equivalent performance impact as hundreds of sprites.
    • there are not currently any good libraries for drawing SVG in WebGL, the main renderer for C2 games. Even browsers themselves have patchy support for rendering all the many features of SVG in web pages. Writing such a library when none exists is a significant project, and it's hard to justify it when it could take a great deal of work and end up slowing down games.

    I think it's possible to render SVGs at a fixed size and then just use them as a WebGL texture, but this could still be slow when scaling objects gradually (every size change requires re-rendering the SVG then uploading a new WebGL texture to the GPU), and it would still use lots of memory (the same as if you just used a normal texture in the first place). I'm not sure that really has any benefits.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • We do not ourselves impose any restrictions on the type of content you publish with Construct 2. It is a tool, and it is up to you what you use that tool for. However some content may be illegal to publish, and other content may have restrictions and regulations around how and where you can publish it, but that is a problem for you at the time you decide to publish.

  • It should be a simple matter of setting it to the middle of the viewport as the posts in this thread already suggest. Check the origin is in the middle. If it doesn't work please post a minimal .capx with nothing else in it other than the object, with 50 events and lots of objects it's hard to prove it's not something else you've done that is breaking it.

  • See Construct 2's export-time optimisations. It's by design that Construct 2 imports everything in your project as PNG, and recompresses it when exporting. This makes it pointless to do any compression yourself before importing. If you want to set an image to JPEG, choose the JPEG option in the Image Format dialog in the Image Editor, and the image will be recompressed to JPEG on export.

Ashley's avatar

Ashley

Online Now
Early Adopter

Member since 21 May, 2007
Last online 27 Oct, 2026

Twitter
Ashley has 1,833,914 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
  • x6
    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
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs