Ashley's Forum Posts

  • webglstats won't give you data about the canvas2d renderer, which is still about 10% of systems and correlates with older hardware with lower limits that doesn't support WebGL, so I'd still stick to 2048 as the lower limit for the time being. To be honest, if you need 2048-sized images or larger, you are probably designing your game inefficiently and are likely to run in to severe memory usage problems - see remember not to waste your memory.

    As ever, NW.js (formerly node-webkit) is just a standalone version of Chrome, so you can pretty much think of it as identical to Chrome for all intents and purposes.

  • I'm sure some people actually need it the way it currently works, and they're not here on the bug report forum because it works. So I don't want to change or remove what is already there for starters.

    Secondly there are much more subtle hangs by trying to clean up created objects when the layout ends: object A could create B which creates C which creates D which creates A. Alternatively A could create B which is in a container with C and therefore creates that as well, and destroying C creates D which is in a container with E, which when destroyed will randomly create an A. Then your game randomly hangs when changing layout, instead of every time, which is even more annoying since it's that much harder to pin down.

    Also the engine is actually doing the same thing as the Destroy action when the layout ends or is restarted, so it is logical that it also fires 'On destroy' as well.

    The workaround is pretty simple too - if it comes to it just put all your 'On destroy' in a group and disable the group before restarting/changing layout.

  • Put them in a family and put the expression in a "pick random" event.

  • I don't know, it definitely did not do this previously and we haven't made any changes to the Cordova exporter lately, so it seems the most likely cause is a change in the PhoneGap build system and that thread seemed to make it sound like it was a known/recurring issue too. Not sure what can be done since it already doesn't ask for location permission!

    Does removing the Touch object prevent the prompt? I'm just wondering if it thinks the device orientation counts as location...

  • I think this is a bug in PhoneGap Build. The export from Construct 2 clearly specifies in config.xml:

    <preference name="permissions" value="none"/>

    However if you build the .ipa, rename to .zip, open and extract, the bundled config.xml file is a "hello world" style default which says nothing much about permissions, so I guess it might default to asking for location.

    According to this thread: http://community.phonegap.com/nitobi/topics/how-to-i-turn-off-geolocation-when-using-phonegap-build - it sounds like it's been a problem before:

    [quote:3oquyyrs]That's a good idea. My guess is, that PGB never built with your config.xml and took a default config instead. That has been reported several times before.

    I'd report this to the PhoneGap Build service, I don't think it's related to Construct 2 at all, our export is trying to say that it does not require any permissions. Geolocation calls are made strictly only from the Geolocation object, so if that is not in your project, the C2 engine is not making any location requests.

  • Thanks, should be fixed in the next build.

  • Closing as by design: restarting a layout first destroys everything on the layout, and naturally that creates anything you create in "On destroyed". What should happen if you create an object half way through destroying everything because the layout is ending is a question with no clear answer in IMO, and the C2 engine happens to leave them there for the next layout which I think is reasonable. If it went back and destroyed the newly created objects too, it could easily end up hanging, because it could get stuck in an infinite loop as the new objects are destroyed, which creates new objects, which are destroyed, which creates new objects...

    Workaround: set a "don't create objects" flag just before restarting the layout, and don't create anything if that flag is set.

  • Closing as won't fix. I can reproduce, but what is happening is you are creating one-shot particles that effectively are never destroyed. The size of the particles object is a box bounding all the particles, and as particles wander off in all directions, the box gets bigger and bigger. The engine uses collision cells as an essential optimisation to keep collision testing fast, but one thing it has to do for that is update which cells an object is in, and a huge and continually expanding object requires an increasing burden of collision cell updating, which is what happening. Also significantly you have set a gravity, so it's not just a linear rate the object expands: it's accelerating.

    I can't imagine why it's useful to do this anyway: either you want the particles to disappear after a while, in which case you should let them be destroyed, or you want to keep the particles on-screen, in which case you should make them continuous and have a timeout, or just use sprites which wrap to the layout.

  • I can't reproduce in r204.2. The problem you describe and screenshots seem to indicate it's a graphics driver bug. I'm testing on a nVidia GeForce GTX 660 and I can move around all three objects a lot just fine. What is the graphics hardware of the systems you can reproduce on and do they all have up-to-date graphics drivers?

  • I can't reproduce, it seems to keep playing indefinitely just fine here in Chrome. Perhaps try it in Chrome Canary in case it's a Chrome bug that has already been fixed?

  • Well I can't reproduce, zooming does and always has work fine for me, and as far as I can tell the vast majority of users since we would be getting a lot more reports if C2 really was broken. So this suggests an issue specific to your system.

    GPU driver bugs (and the latest drivers can still be buggy) are one of the top causes of crashes in C2, so I still strongly suspect that. Most vendors write terrible quality drivers. If you're using the Steam version, perhaps you could try downloading the version direct from our site instead and running it after closing Steam, in case it's Steam itself that is breaking C2?

  • I can reproduce, and it happens in browsers too: http://www.scirra.com/labs/bugs/overlaytest/

    (Please always test everywhere you can, this is important information for bug reports)

    This could be tricky to fix, I guess it relates to how the spritesheeting on exports interacts with background-blending WebGL shaders. I'll investigate, but may postpone this to the next beta cycle (I want to have a stable update out soon).

  • It appears correctly here in all of Chrome, IE and Firefox on an nVidia GeForce GTX 660.

    Inside shaders, color values are normalised to a float in the range [0, 1]. So the color values you are entering are really divided by 255 and rounded to a low-precision float to conserve memory bandwidth. My best guess is a driver, OS or browser component changed recently, and now something is rounding in a different direction, so it amounts to a rounding error. The workaround should be simple: just increase the tolerance to say 2 or 3, and it will still include close colors that have a small rounding error compared to what you are testing for.

  • 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

  • I think there's too much on the parent page that could conflict with the C2 engine or its canvas tag, preventing it being able to easily integrate to existing pages. Embedding games with an iframe is the recommended way of integrating a C2 game in to an existing page.