Ashley's Forum Posts

  • Does it mean every dev is on their own with q/a process from steam when there are hiccups like this where we use construct2 tool to make game for hundreds of hours and then we get stuck because there is needed some general knowledge that goes beyond creating game logic but goes deeper in territory of handling installers?

    Would you consider helping us out? I'm very glad dev did manage to figure this out but it doesn't help me or others at all.

    AFAIK the problem in that thread was to do with Steam uninstall scripts, which I have zero experience with (C2 doesn't use one in the Steam build), so I'm just not actually a helpful person in that situation. It would be better to get in touch with Valve's support. Yes, you may need to learn and use some other technologies to publish your game, I think that is pretty reasonable.

  • Ashley

    Isn't free edition limited to 100 events?

    Yes, and there are other limitations too besides that.

    [quote:1t0sv5wr]Could you help out with issue that was brought up here with nwjs and steam:

    Which, specifically? The thread is mainly about writing a cleanup script for Steam, which doesn't seem to be that specific to NW.js, and AFAIK was resolved by the developer. There's also no reason to think Electron would be different in that regard.

  • So, are you saying that Scirra won't allow armaldio to publish the Electron plugin? Or I misunderstood something?

    Why would we allow people to advertise ways to circumvent the free edition restrictions? That breaks our whole business model.

  • Do you have autobackup set to run every 1 minute or something? I can't think of anything else that it would start doing after 60 seconds that could go wrong.

  • The runtime is architected so that with "render cells" enabled, an offscreen sprite with no animations or events has a zero performance overhead. (Animated objects have to tick their animation and events still check against all the objects in the layout.)

    This means that if you create even a gigantic layout which consists solely of static objects (no animations or events), it should run perfectly no matter the size of the layout.

    The performance problems tend to stem from running events against a large number of "live" objects in the layout. You may need some techniques to avoid having too many of them at once, possibly by dividing the layout in to certain segments and destroying all the objects outside of the segment, but as far as the static objects go you should be able to create as many as you want (providing render cells is on).

  • Please note that NW.js is only available with a license and any discussion of ways to circumvent the license restriction is not allowed, even if it is possible.

    I cannot think of any technical reason Electron would perform better or worse than NW.js - they are based on the same Chromium browser engine, so are running pretty much the same code. The screenshots of performance results look close enough to be within the margin of error, or deriving from window size differences or the Chromium version used. Realistically I don't think anything would be much different if we supported Electron, and it could be a lot of work.

    NW.js is regularly updated and AFAIK is robust enough for several games to have been published to Steam with it. As far as I am aware the new versions tend to work better than the old versions, not worse, especially since they come with the feature, performance and memory improvements of the newer Chromium versions. If you run in to problems please do file bugs for any issues you have so we are aware of them.

    The "relying on browsers" argument has been done to death a bunch of times already and I'm really sick of it - you can't avoid relying on third parties in software. If we went native then we would be hosed by crappy graphics drivers instead, and there wouldn't be anything we could do about it. So I know it's frustrating when there are problems caused by other software projects, but there is no reason to think that changing which software we depend on would fundamentally resolve that.

  • Isn't this an Intel XDK bug? Or is that happening even if you don't open the XDK?

  • Ashley has now stoop so low as to use other people accounts to defend himself and Tom. Ashley uses a 2 year old account to defend himself look

    This plus other complaints earns you a temp ban. See if you've cooled off in 7 days.

  • What kind of device is it?

    The most common mobile performance problem is that the graphics driver is buggy on Android devices so the browser disables the GPU. You can check for this in chrome://gpu in the Chrome browser.

    Other than that you'd have to share your .capx so we can take a look.

  • Closing, please see the bug report requirements. If you just need help with making your project, post in the "How do I" forum.

  • Closing as not a bug: you're just seeing the effect of linear sampling over sub-pixel positions. This is a normal result in computer graphics.

    For pixel-perfect display, use the project settings 'Letterbox integer scale', Pixel rounding on, and 'Point' sampling.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yes, like most actions it only affects the picked instances.

  • COGames - that will also break your app if it tries to run in WKWebView mode.

  • This is deliberately not supported because it is a brittle architecture to depend specifically on plugins or behaviors that may not be there and cannot be interchanged with any other features.

    Just find a way to let the user tell your plugin that expression, e.g. through an action.

  • We'll keep these ideas in mind for Construct 3.

    However I have to say 60FPS+ animations doesn't sound like a good idea - it will use absolutely loads of memory and be wasteful if it's not even showing every frame. If you want super-smooth animations a tool like Spriter is a better idea.