Ashley's Forum Posts

  • Can you post a .capx? Scroll To just scrolls to the object so are you sure your object is in the right place?

  • What exact warning did you get hungry4donuts?

    Also you can do all the multiple screen size support on the Construct 2 side, there's no need for PhoneGap to handle that. See Supporting multiple screen sizes.

  • You're right, the Object(index) syntax skips the picked objects and uses the full instance list. This was done because it turned out the feature wasn't actually useful if it stuck to the picked objects - there were lots of other cases it worked better using the full instance list. Basically it's best to stick to UIDs.

    I wonder if another feature would be more helpful here - perhaps Object[UID].Expression, like a UID version of the current expression indexing...

  • Well the main issue with different instances of an array is it can be confusing. For example, the way event picking works is if you pick more than one array instance it will be writing to two arrays at the same time. And this all happens "invisibly" - it's hard to check which arrays are being written to and what their content is.

    It's clearer to think about if you only have one instance of an array. If you need multiple 2D arrays, use one 3D array instead, or different array objects if possible. On the other hand, if you know what you're getting in to, I guess you can go ahead and use multiple array instances!

  • This doesn't work because subevents carry on picking where the parent left off.

    The event runs like this:

    1. First array instance created. The 'create' action picks it.

    2. Its UID is saved.

    3. Second array instance created. The 'create' action picks it. This is now the only picked array! The other array instance is no longer picked!

    4. Enter the subevent. The subevent inherits the parent event's picked objects, i.e. *only* the second created instance.

    5. Conditions only ever run on the picked instances. So "pick by UID..." in that subevent will only pick from the second created instance, which does not have the UID you want, so the event can never run!

    There's no bug here, it's just Construct 2 working normally.

    There are three possible solutions:

    1) Use system 'Pick all BaseArray' before the 'Pick by UID' to go back to both arrays picked rather than just the second array picked.

    2) Make a new start of layout event and move the pick by UID to there.

    3) Don't use multiple instances of array - it's much better to use two different array object types than two instances of the same array (i.e., insert a new array in to the layout again and use that).

  • Objects don't move smoothly, they actually move in little jumps every frame. Also, one object can be at X = 100, and another can be at X = 100.000000001, and those are not equal, so the chances the event is true is almost impossible.

    You probably want an event something like

    + Sprite2.X < Sprite1.X ("sprite2 is to left of sprite1")

    + Trigger once ("only do this once")

    -> Spawn sprite3

  • What is more cpu-intensive: 100 objects with 4 polygon points, or one object with 400 points?

    It's probably more CPU intensive to use one object with 400 points. It's best to use more objects with fewer collision points.

    If an object is overlapping an object with 400 collision points, it will probably check all 400 collision points in that object. If it is overlapping an object with 4 collision points, it will check just those 4 collision points (100 times less!) and it will skip checking any of the other objects.

    Of course using more objects has its own performance impact, but using lots of collision points isn't very efficient in the engine at the moment, so it's probably better to avoid that. This can probably be optimised in future, but this is how it is at the moment.

  • You can click the dropdown next to the undo button which lists everything that's in the undo queue. Does that help?

  • I can't think of any reason re-picking the same events would fix anything. When you click export, if it's the same events, you should get exactly the same output. Are you sure you did not change anything else?

    Also, if you can reproduce this in a new project could you post it to the bugs forum?

  • Looks fine here. This is almost certainly a graphics card driver issue. We have had this issue reported several times before and every time it was fixed by updating the graphics card driver. What graphics card do you have? The About screen should tell you.

  • Thanks for jumping in appMobiSam!

    Our engine is canvas-only, it doesn't do anything visual with the DOM apart from draw to the canvas so reflows shouldn't be a problem.

    Also, surely the overhead of stringifying from the webview to native isn't more than the overhead of stringifying to the other context then calling eval()? Do you have performance figures comparing the two? I didn't think there would be much difference between them, but then again WebGLGap didn't work out so well :) Anyway, that's why I've been thinking a single context approach makes much more sense, but that's just from our point of view.

    Most of the difficulty of porting comes from lots of little things, really. There are already a lot of games in Construct 2 and even dropping little features breaks some people's games. For everything to work the game needs to know the image dimensions, but only the directcanvas layer needs the actual image. My first naive port of everything-in-directcanvas didn't work, presumably because there are a few DOM references that throw it off. Besides, the three input plugins assume a full DOM is there, Browser and Webstorage assume they're in a real browser, and Button and TextBox are real DOM elements too. DirectCanvas didn't look like it had anything to draw text with, which is no worry - we already overlay a 2D canvas for text rendering in WebGL mode - but then our renderer has to be half-and-half DirectCanvas and WebView. If DirectCanvas doesn't support patterns or texture co-ordinates we have to do something different for tiled background. etc. etc. We'd love to get it working but it seemed to be a lot of work (I never thought I'd have to munge some of the engine in to another context) and we're already knee deep in other projects so I was trying to persuade you guys to do a single-context version! :)

    FYI our next release (in about a week) has some minimal tweaks to export an AppMobi-aware game, but it's probably not much different to what you've already done in testing.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • ian - we still don't support DirectCanvas because of the complication of the second context in our engine. I didn't mean to imply AppMobi is slow, it's just a possible reason a user may have seen a slight performance improvement over PhoneGap when both are using a non-accelerated canvas.

    I really don't understand why you have two javascript contexts to use this. Are you guys planning on making a single context version? It would be far, far easier for us to implement and that's really important to us when we're a tiny two-man company already working round the clock. For example, when writing WebGLGap all the WebGL calls are made from one context, which means existing code can be used virtually unmodified. The WebGL calls are just saved and passed to a separate rendering thread so rendering doesn't hold up the game code either. I thought this design would be sensible for DirectCanvas to maintain high compatibility with existing code while still minimizing performance overheads.

  • That's odd, the arcade pages all include a tag to force IE in to the proper standards mode. Any ideas Tom?

  • You do not have permission to view this post

  • The reason is actually different for Text in WebGL and form controls - form controls are always on top even in Canvas 2D mode, because they're not in the canvas, they're additional elements in the HTML page laid on top of the canvas. I don't think there's any way around it though, form controls always have to float on top.