Ashley's Forum Posts

  • Are you running Construct 2 as administrator for preview-over-wifi? That might explain it. If not, I don't see why Photoshop would need admin permission to write to a temp file. Maybe something specific to your system?

  • I can reproduce in Chrome 39, but it works correctly in Chrome 41 Canary. So I'm guessing it's a Chrome bug that's already been fixed and should come around soon.

  • Should be fixed in the next build.

  • Thanks, should be fixed in the next build.

  • Closing as not a bug. A quirk of the Timer behavior is 'On timer' can run with multiple instances picked (all the instances that fire the timer at the same time). So 'On timer onUpdateScore' fires with the entire 'Teams' family picked, because all their timers fire at the same time.

    Then "Ball team = Teams.team" becomes ambiguous since you are comparing 11 balls against the 3 instances in the Teams family. I think the C2 engine attempts pairing when you do this, and will try to match the first 3 balls with the first 3 Teams, then the next 3 balls with the first 3 Teams, and so on, which I think is how it comes up with the somewhat non-intuitive number 4.

    The solution is just to add "For each Teams" under the "On timer" event. Then it handles each instance separately and it works correctly.

  • It doesn't appear to be to do with families, since if you replace Family1 in the events with Sprite then it works the same. There is a fundamental conflict in the events here: Sprite, Sprite2 and Sprite3 are all in a container, so will always pick together. If Sprite collides with a Sprite2 from a different container, as per the normal working of events, both instances involved in the collision are picked, and therefore due to containers all six objects are picked. Now your "Pin to Sprite3" action is ambiguous, since there are two Sprite3 instances picked, so it's going to (arbitrarily) go with one of them.

    I don't see evidence of a bug here. I think you just want to avoid using containers, since in this example they seem to be working against you.

  • 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

  • Poor performance with such a small number of sprites almost always comes down to one of two causes:

    1. Extremely inefficient game design, often in direct and extreme contravention of our guidelines as performance tips

    2. GPU blacklisting due to poor quality graphics driver (common on old Android devices), so it reverts to software rendering. (Nothing we or any HTML5 developer can do about that - if the browser enabled GPU acceleration, the buggy driver could crash the whole system.)

    If you have any examples of poor performance that are not either of those causes, I'd definitely be interested to take a look. I very rarely see any such examples.

  • There is no such limit. It will only make the download size bigger.

  • From http://nintendo.wikia.com/wiki/Nintendo_Entertainment_System:

    [quote:id3nxi9j]The NES had 48 color pallets available and five different shades of grey. Twenty five different colors could be used on a single scanline. At one moment sixty four sprites can be shown on screen (each sprite must be 8x8 (minimum) pixels or 8x16 pixels (maximum)). A maximum of eight sprites can be placed on a scanline at once. ... The picture resolution for the NES is 256 x 240.

    The genius of games on the NES was that they were fun and looked reasonable despite those stringent technical limitations. The games were probably extremely difficult to write, and probably involved hand-written assembly taking in to account the specific CPU and GPU architecture in use on the NES. It was also mains-powered (so no constraint on designing low-power chips) and 256x240 is only 61440 pixels (at 8 bits per pixel I think, so ~60kb).

    A modern phone might be running at 1920x1080 in 32 bit color with arbitrary scaling and rotation - none of those limitations on colors or scan lines. That's about 8.2mb of pixels (135x as many as the NES). They run on very low power chips to save battery (and have to support a wide range of hardware), and Javascript has some overhead (although modern JITs are good at compiling the important bits to machine code). And despite all that, I can still get 20,000 sprites on-screen at 30 FPS on a modern phone, which is quite a lot more than the NES's maximum of 64! So I think there's been far more progress than you imagine.

  • Probably not, but as with any performance question, you can check yourself by making performance measurements both ways and seeing if there's a measurable difference. If not, then it doesn't matter.

  • The main problem on Android is GPU blacklisting due to buggy drivers. Visit chrome://gpu in Chrome for Android and it should tell you more.

  • Closing as this is posted in the Bugs forum not following the guidelines, so there is nothing we can do to investigate.

    r187 is an old build, the latest is r193. Try testing that since we may have already fixed the problem.

  • jqquick223 - it's already fixed in the latest betas; when the next stable update comes around then everyone will get the fix.

  • It does one update and draw per tick, with dt being the time since the last frame as measured by the high-resolution timer API where available (instead of Date.getTime() which does not have sub-millisecond precision). There is also no assumption that the display will be running at 60 FPS, since displays which run at different refresh rates exist.

    The way I see it multiple updates per draw is just a good way to burn CPU time for little benefit. If there are fast moving objects you want to collision test more accurately or something like that, then a specific feature to handle that case is far more efficient than running the entire game's logic repeatedly.