Ashley's Forum Posts

  • Closing as duplicate of https://www.scirra.com/forum/r192-bumpmap-shader-on-tiled-background-goes-nuts_t122118 which appears to provide a clearer repro so favouring that issue over this one.

  • Thanks, should be fixed in the next build.

  • Also the project has a huge number of seemingly totally redundant objects - for example Sprite1 through Sprite40 appear to all be identical images of a star, and this means the editor has to create 40 icons from the limited budget where you only need 1 object. There appear to be many other objects redundantly repeated over and over again. This is extremely inefficient and is probably the main reason you're running in to this limit. Why does your project do this? Can't you remove all the redundant objects?

  • ilimi - please report any issues you have with the Intel XDK so we can fix them, it is definitely the better approach since it is based on a real browser engine and so shouldn't run in to problems like you have here.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Can't reproduce, works fine here - and if this really was a C2 issue with every project, I think we would be inundated with reports but we haven't, so this strongly suggests an issue with your specific system. I think the "error linking shader program" in D3D strongly suggests a graphics driver bug. Try checking your graphics drivers are up to date, and if you have a dual-GPU system, that both drivers are up to date.

  • ilimi - I think this is because Construct 2 is running in to a limit in the Windows OS. Windows only lets you create ~10000 icons before it starts running out of memory, and with 2000+ objects and the C2 editor creating icons in a variety of sizes, it can end up running in to that limit. It's very difficult to do anything about this since it's not really C2's fault, it's a limitation in Windows. That checkbox in Preferences was added as a workaround to this very issue. Is it plausible to keep working with that setting?

  • For the next build I added a 'Call expression' action to the Function object which should be more convenient for long parameter lists. Closing as that's probably a better solution than using the UI.

  • Should be fixed in the next build.

  • Closing as Ejecta is no longer officially supported as of r191, and the corresponding Ejecta issue was closed due to lack of information.

  • It's not supported because it's a terrible idea: it will rapidly drain the user's battery. Imagine if all the apps on your phone did that.

    Instead when the app resumes, measure how long it was suspended, and then advance the counter according to how much time had passed.

  • The problem is the event runs with two instances of 'Sprite' picked. Then you spawn 'Sprite3' from 'Sprite', which creates two 'Sprite3' instances. Then the actions that follow apply to both 'Sprite3' instances. In particular 'Pin to Sprite' takes an object parameter, and the way the C2 engine works this does not pair up instances, it will just find one 'Sprite' and use that for both actions on 'Sprite3'. If you add a 'for each' condition it then properly runs the actions once per instance, spawning one object at a time and applying the actions for just that one spawned instance. As far as I can see this entirely fixes the problem in general, there should not be any other problems from doing that.

  • Have you tried the 'Visual Studio 2012 Dark' style?

  • Honestly I'm a really scared that an auto updating webview, more than nodewebkit, could break a perfectly working game without any action from the user (or even knowing it really).

    Google already manage to do this without breaking the entire Internet, so I'm sure apps will be fine too.

  • Is it possible to obtain expression for specific UID or currently picked instance just like IID does(Sprite(0).X)? I would like to use them.

    IIRC, back in the early days, Sprite(N).X would actually look up the Sprite with the UID N and return its X position, but it got changed to index because it was more useful. I can't recollect the exact rationale now, it was too long ago, but just thinking about it now it does seem more straightforward since Sprite(0) always returns the first picked instance, Sprite(1) the second picked, etc. without needing to know any UIDs.

    If you want to get expressions from an object with a specific UID you can already use 'Pick by UID', and put 'Pick all' before it if you want to also be able to pick objects which don't match the parent events.

  • You do not have permission to view this post