Ashley's Forum Posts

  • Closing as not a bug: the 'move to layer' action moves the object to the top of the given layer regardless of its old Z order. Add a 'move to bottom' action to get the effect you want.

  • Thanks, should be fixed in next build.

  • I think given my comment from the linked bug report, this should not be fixed otherwise we will create another infinite-loop bug. Based on that, closing as won't fix.

  • Closing as won't fix; it's just a deprecation warning from a feature removed since Windows 8.0, no functionality is impacted. We will keep this feature in place to preserve backwards compatibility with Windows 8.0 for the time being.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 'Left' and 'Right' were never built-in attributes, so you'd have to ask Yann.

  • Attributes were moved to behaviors in Construct 2. Notice the Solid attribute is now a behavior, for example.

  • Well, I think HTML5 gaming is viable on mid to low end devices. I just also think if you have a phone which is about as powerful as a mid-range desktop, which is the state of the latest top-end phones, it would be nice to take full advantage of that - just like with a top end gaming PC you want to be able to run Crysis at 60 FPS, not locked to 30 FPS because the game designer wanted to try to improve the experience on weaker machines.

  • It sounds exactly like a graphics card driver bug, which is more likely to occur when updating the OS.

  • Aren't you worried about people with expensive, high-end phones getting an unnecessarily degraded experience?

  • Can't reproduce on Windows 8 with Chrome. Check your graphics card drivers are up to date.

  • It's not currently supported but is on the todo list. The only workaround is to either play lots of sounds with one tag, or add the effect to multiple tags (but be aware if you add the effect to N tags it will use N times as much CPU time to process).

  • Have you tried using a folder-based project and directly pasting over the animation frame image files? If you have Construct 2 closed when you do this, then re-open the project in C2 after replacing the files, all the objects should still be in the same position/angle.

  • Just thinking I could experiment with a non-adaptive half-vsync rate mode that's only supported with high-resolution timers in the next beta. Perhaps it could be split in to off / mobile only / all devices, so you can leave it uncapped on desktop... but IMO it'd still be annoying to have a really powerful phone like the Nexus 5 (which can outperform some of the desktop machines in our office!) and have the game capped at 30 FPS to ensure a better experience on weaker devices... if I had a phone like that I'd want it to be on 60 FPS!

  • Why not just minimise it so it's gone completely?

  • I didn't say we would never support it. IMO It's a trickier subject than most people are giving it credit for.

    Issues with dt at low framerates are a different problem. If the framerate is low enough to cause problems with gameplay, usually it is much lower than 30 FPS, so a framerate cap does not fix that. It's a separate problem.

    Adjusting the framerate cap at runtime is a pretty difficult problem and hard to get reliably right. You'd want to figure that out on startup, but Javascript optimisation and garbage collection tends to make things a bit choppy on startup, so any measurements would be unreliable. Even so later on there might just be a single momentary blip below 60 FPS, and you probably don't want that to trip it down to 30 FPS. So then you have to draw a line somewhere, and wherever you draw the line, sometimes you'll choose 60 FPS when it should have been 30 and 30 FPS when it would have been better to choose 60. I'm not at all confident the engine would be able to choose correctly most of the time.

    Other game creation tools might provide a framerate setting, but I don't think that makes it a good idea!

    A screen with a refresh rate like 72 Hz doesn't play the game at 60 FPS - it plays it at 72 FPS (if the system is fast enough). A framerate independent game adapts to this seamlessly, ensuring best quality display. To be more correct, instead of talking about 60 FPS and 30 FPS we should say "vsync rate" and "half vsync rate". The engine could support a "half vsync rate" mode, but then you can't easily tell the display refresh rate in Javascript, so you have to go off some adaptive system again, which is unreliable and might pick wrong, and then you have a choppy framerate again. Also that kind of thing needs reliable high-precision timers, which aren't available everywhere.

    Consoles are a different case: the hardware is known in detail in advance, so you may be able to say confidently that a game you have absolutely cannot run at vsync rate. However C2 games run everywhere from powerful desktops to weak phones. IMO a game running at half-vsync on a powerful desktop PC is both annoying and an inferior experience to a vsync-rate game. I didn't spend all that money on a ridiculous graphics card for 30 FPS :)

    In short my opinion is that if a system can run a game at vsync rate, we should let it. Since there's probably not a really reliable way to detect the need for half-vsync rate and then accurately hit that, the best way to try and let it is to leave the framerate uncapped.