Ashley's Forum Posts

  • Rolling back to an older version after saving your project is never officially supported. If you are editing the project files directly to allow C2 to open it, then you are risking exactly this kind of issue. Condition 18 in the Browser object is the new 'Supports requesting fullscreen' condition, so presumably you added it in r191, saved, then tried to open in r190 where the condition does not exist. This is nothing to do with this bug report here.

  • Closing, the .capx is mandatory, it is never needless.

  • You don't need render cells for any of these, you can already do them with collision cells by testing for overlaps with rectangular objects to mark out an area.

  • Closing as won't fix: we just deprecated support for Ejecta, in part because of all the bugs (like this) that we end up dealing with because it's not a real browser engine.

    If you still want to see it fixed, consider filing the bug directly with the Ejecta project.

  • Closing as not a bug: 'pixel rounding' has no effect on this, since it does not affect the actual object co-ordinates, only the position when rendering the object image.

    See 'Expecting math calculations to be exact' in the blog post common mis-used events and gotchas. This is a normal floating-point precision issue. If you add and subtract the X and Y co-ordinates directly, you will preserve perfect accuracy. However since you use the 'Move at angle' action, which can take any angle at all, it calculates:

    x offset = cos(angle) * move distance

    y offset = sin(angle) * move distance

    Trigonometric functions can only return approximate results, and work with radians, so there is opportunity for rounding error in both the degrees-to-radians conversion and the calculation of a trigonometric function.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • jayderyu - it's a good idea, but it's probably going to be slow or flakey - either you write the entire storage on every change, which if you make 100 changes in a row with 1mb of local storage means you immediately run 100mb of writes, or you batch them up on a timer or some such, and then you simply lose data if the user quits before the writes happen. There could be an action to flush WebStorage, but then it only exists for a single platform and does nothing else anywhere, and you still have a new porting barrier since to make an existing project work on the CWS you need to go through adding "flush storage" actions in the right places.

    I really don't like the fact the Chrome team are willing to turn off random web platform features, since it bodes very badly for portability of existing web content, so I don't think it's even in their interest to do it! I don't want to encourage them to do it again, so I'd rather fight this case and get it put back than find a workaround.

  • dankhan - have you made measurements that identify it as exactly a factor of 10 difference?

  • I think the savegame system will still work, because internally it uses IndexedDB first if it's supported, and I think Chrome apps still support that. Unfortunately if Chrome don't support localStorage again then the WebStorage object will do nothing in Chrome apps (writes will be ignored and reads will return empty).

  • I'm not sure there's anything we can do about this from the C2 engine, the WKWebView still looks just like a browser. I think it's up to whoever provides the build system that uses WKWebView. I'm assuming it has some kind of API to mark files as permanent? Or if not maybe Apple need to add support for that - I've read WKWebView has a few bugs and missing features compared to the old web view.

  • Yes, it works on all platforms.

  • I haven't got round to the "recreate zone" action yet, but the last few releases have included bits and pieces to try and improve it whichever way you want to design your game. Also I think render cells are applicable to a wide range of game genres so are a more useful general-purpose tool to have. "Reset persisted objects" wasn't aimed at your request at all, it was for an unrelated request IIRC.

    I think jank will be a problem if you create and destroy large numbers of objects at once, and it is difficult to see how that can be worked around. (It's not at all straightforward - you can try and spread out the creations, but then if the game keeps running you may run in to issues where you reach the new area before it's finished creating all its objects, and stuff randomly pops in to existence.) So one of the useful things about render cells is you can use them to avoid having to create and destroy any of your static scenery objects. They can exist over the entire layout and render cells allows the far away ones to have zero performance impact.

    So then once we get 'recreate zone' you don't need to use that for any static scenery, just the changing things like enemies and powerups. Ideally that reduces the number of objects to create/destroy at a time to a small enough number as to make the jank unimportant.

    Destroying large numbers of objects at once used to be particularly slow, but another recent release made that a lot faster. So I think we're getting there.

  • If you use an uncommon font with the Text object, it won't show the same for anyone who doesn't have the same font installed.

    Web Fonts or SpriteFonts don't have this problem and will show the same for everyone.

  • PhoneGap is largely the same as a browser, so you can use the normal form controls like Text Box. (Form controls were one of the casualties of non-browser engines so those custom ways to bring up the keyboard were hacks to work around normal text boxes didn't work)

  • You do not have permission to view this post

  • I don't have any plans to implement this - we're making a game engine, and I don't think games ought to stay active in the background, it will waste a lot of battery.