Ashley's Forum Posts

  • Closing as not a bug: as GenkiGenga says, you allow acceleration when the speed is exactly equal to 200, allowing it to accelerate slightly beyond. Even with that though, you should not expect the speed to exactly equal 200. See "Expecting math calculations to be exact" in common mis-used events and gotchas.

  • All I can see is a .capx file that has no image files in it. You can rename it to .zip and see the Animations and Textures folders are missing. It's too late to do anything for that .capx, and I still have no idea what causes this - I really need steps to reproduce the problem in the first place (i.e. how to get from a working project to a broken one). Otherwise all that can be done is maybe try and recover the file.

  • Thanks, fixed for the next build. I think it originally pointed at loading-logo.png (which was renamed from logo.png), but it probably makes more sense to point it at icon-128.png, so that's what I've done.

  • Closing, please follow the bug report guidelines.

  • Thanks, should be fixed in the next build.

  • You can also click "Reset dialogs" in Preferences.

    Since you did not include the steps to reproduce the problem there is nothing we can do to investigate, so closing.

  • Does your server support CORS? By default if your server is not sending Access-Control-Allow-Origin HTTP headers, cross-origin requests are blocked.

    Your workaround basically involves disabling that entire security measure, and I don't want to do that if it's just a CORS issue with your own server.

  • Here is your project exported with minification enabled and running on the Scirra server: http://www.scirra.com/labs/testexport/

    It works fine here, no errors. Closing as can't reproduce.

  • Closing as not a bug: your JSON string has the incorrect size in it (the width and height properties are 10 and 11). If I save TilesJSON again it has the correct size of 53x30. Some previous releases had bugs with saving the wrong JSON data, which should be fixed now, I think this is just a consequence of that.

  • The reason it's like that is if you have a game time scale of 0, you can still set some objects to be moving at a normal rate. If it was relative to the game time scale, setting a time scale of 0 (commonly used for pausing) makes all object time scales useless. Also making this kind of change causes serious backwards compatibility problems. If we did it, cue the forums flooding with "my game is broken in the latest release, Construct sucks!".

    Changing an object timescale is just like updating a variable, there shouldn't be any problem with setting it to timescale * objecttimescale every tick if that's what you are after.

  • Your test includes things like comparing adding 1 to a variable to adding 1 to a variable in a function. That's exactly the kind of a test that basically just measures the overhead of a function. Functions already pretty much do the minimum work they can do, I'm not sure there's any obivous way to speed them up, but that's not to say they're slow. But I guess you might want to avoid them in long loops and such.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Wow, 800mb compressed? I was going to suggest that you were just running out of memory... but if disabling the icon cache fixes it, that's the Windows limit of 10,000 graphics objects per process

  • Construct 3 will have better support for high-DPI displays.

  • Can you share a .capx that crashes when loading?

    Are your graphics drivers up to date?

  • There are two sides to the GPU performance:

    1) reading from the source textures. Larger images involve more data to read so can be slower.

    2) writing pixels to the screen. A higher resolution involves writing more pixels. The rate the GPU can write pixels at is called the fillrate.

    Usually from what I've seen the bottleneck is 2). As in, the size of your source artwork doesn't matter that much, it's mostly about how much content is drawn. If you have a large source image and render it to a small, low-resolution display, you don't use much fillrate, because there weren't so many pixels written to, even if the source image is large. On the other hand, even a small source image drawn at a large size on a high-resolution display will use a lot of fillrate, since it has to fill a lot of pixels. So generally I focus on the fillrate side of performance.

    Look up mipmaps on wikipedia to learn more about them, but they also help make 1) less of a performance issue. The GPU stores images at 1/2 size, 1/4 size, 1/8 size etc. down to a single pixel with high-quality resizing. If you render a large source image at half the size, it will render from the 1/2 size source image that it automatically generated, which means there's even less concern about the size of the source image. The main reason to reduce the size of your source images is basically to reduce the overall memory usage.

    If you have any performance questions involving specific cases, it's best to measure them yourself.