Fengist's Forum Posts

  • Problem Description

    If a touch event is released over a text box, it will continue to detect Touch movements. Unfocusing the textbox has no effect.

    Attach a Capx

    w*w*w.datainterlock.com/ConstructBugs/Focusbug.capx

    Description of Capx

    A text box, a button and the Touch plugin. While touch-dragging or mouse-dragging the textbox.text will change to reflect the general direction using touch acceleration.

    Steps to Reproduce Bug

    • 1. Touch and drag across the top of the app. The textbox.text shows the direction.
    • 1a. Release the touch while outside the textbox and move the mouse. The textbox stops showing direction.
    • 2. Touch and drag from the top of the app into the textbox. The textbox.text shows direction.
    • 2a. Release the touch while inside the textbox. The textbox.text continues to show direction.
    • 3. Touch and drag while inside the textbox. The textbox.text shows the direction.
    • 3a. Release the touch while outside the textbox and move the mouse. The textbox stops showing direction.

    Observed Result

    Touch is not releasing when the event ends inside a textbox.

    Expected Result

    The textbox should not continue to show touch movements when the mouse button/touch has been released.

    Affected Browsers

    • Chrome: (YES)
    • Edge: (YES)
    • Internet Explorer: (YES)

    Operating System and Service Pack

    Windows 10 64x

    Construct 2 Version ID

    r216 / 64

    Notes

    This is essentially a reopening of this closed bug from 163-177. It appears to still not be fixed: w*w*w*.scirra.com/forum/textbox-will-not-unfocus-if-using-touch-object_t97848

    I've also tried to switch focus to another object on the canvas and touch still detects movement.

    Since there is no user options for Touch, there's not even a way to disable/enable touch to reset it. I've tried some textbox plugins and they all seem to suffer this same bug. I'm still very seriously considering purchasing Construct but I keep running into snags. If there's a workaround, I haven't found it and would appreciate any advice.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks RoJo, I'll give that a try. It actually sounds like a much better idea as it won't tax the physics engine as much . And you may be right, it may be that the animation physics calculations are causing the issue. But I just ran this with just the two sprites on the screen, one animated and one not, went and took a nap and when I came back, it had crashed.

    I'll do some testing with animations turned off and see if that makes a difference. Thanks for the ideas.

    *edit*

    I dropped 100 animated sprites on a layout, I turned animation looping off so it did run once. I did a foreach every second and applied a random physics force at a random angle. And it doesn't seem to crash. If I turn the animation loop on... it crashes. I also tested 100 sprites as bullets with the animation on, no crash. And, as you suggested, I pinned the animated sprite to an invisible non-animated sprite with physics and... no crash.

    So, it seems you are correct. It's the combination of physics and an animated sprite that runs into the memory limitations. Your method seems to be a great workaround. But I certainly wouldn't have guessed it.

    Thanks again.

  • Ok, I did some more testing.

    First, instead of creating the sprites every few seconds, I created 100 of them in a for loop in the On Start of layout event. It loaded them up fine and they started animating. After about 30 seconds, it crashed. So, creating them with a timer or all at once isn't a factor. But I thought it odd that it was able to create all of them and to run for 30 seconds before crashing. It 'feels' like a memory leak.

    So, I wondered what the minimum was I could create and have it crash. While I haven't tested any lower than this, I changed the for loop to create just 5 of the Sprite3. Without applying any force, not moving the mouse, nothing... it took about 10 minutes but it crashed. So, a total of 6 sprites with the physics behavior enabled caused the JS to crash.

    While, as I mentioned, this sounds like a bad memory leak, if this is a result of the memory limitation that Ashely increased, and if just 6 physics sprites reaches that limitation, then that's REALLY limiting what this game engine can do. And crashing is a really, really bad way of letting the developer know they've reached that limit.

    I do hope this isn't working as intended. I have high hopes of purchasing this engine and putting it to good use.

  • While the number of sprites does have an effect, I'm pretty sure it's where I'm applying the physics every 3 seconds. Usually for me, about the time it's hitting 50 is when it crashes. But, if you set the number to 20 and let it keep running, it'll still crash, just takes longer. Setting the event timer to something like 1 second may make it crash sooner.

  • Thanks zenox, I just thought of that myself and changed those objects to bullets. The good news, it hasn't crashed yet. But in my ignorance though, they don't seem to bounce off each other or the boundary walls and they pass right through the one physics object I left. Plus, random motion looks pretty stiff.

    If this is the route I'm going to have to go it looks like I'm going to have to create a lot more events to handle collisions and 'simulate' physics.

  • There is no specified point. I let it run for about a minute or two and it crashes.

    I found this post with a response from Ashley: w*w*w*.scirra.com/forum/viewtopic.php?f=151&t=148526

    which is a link from this post: w*w*w*.scirra.com/forum/physics-behavior-js-app-crash_t148047

    which produces the same error I'm having. Apparently me creating objects and changing physics on the fly is causing the crash. Unfortunately, I've had it crash with as few as 20 objects.

    While I program in several languages, I'm a complete noob at Construct. But that seems like a huge limitation. And right now, I'm not sure what a workaround would be. What I was planning on was 20-50 physics objects floating around that randomly change directions, bounce off each other, etc.

  • And it cut out my url:

    w*w*w.datainterlock.com/Construct/Javabug.capx

    And here's the java console output.

    Uncaught abort() at Error
    at Error (native)
    at fb (http://localhost:50000/Physics_behavior.js:31:26)
    at ua (http://localhost:50000/Physics_behavior.js:417:61)
    at Function.h.o [as W] (http://localhost:50000/Physics_behavior.js:17:91)
    at nc (http://localhost:50000/Physics_behavior.js:167:483)
    at NB (http://localhost:50000/Physics_behavior.js:196:40914)
    at mo (http://localhost:50000/Physics_behavior.js:184:88231)
    at j.O (http://localhost:50000/Physics_behavior.js:734:21)
    at createPolygonShape (http://localhost:50000/Physics_behavior.js:818:17)
    at behinstProto.createBody (http://localhost:50000/Physics_behavior.js:1734:24)
If this abort() is unexpected, build with -s ASSERTIONS=1 which can give more information.c @ Physics_behavior.js:7ua @ Physics_behavior.js:417h.o @ Physics_behavior.js:17nc @ Physics_behavior.js:167NB @ Physics_behavior.js:196mo @ Physics_behavior.js:184O @ Physics_behavior.js:734createPolygonShape @ Physics_behavior.js:818behinstProto.createBody @ Physics_behavior.js:1734behinstProto.tick @ Physics_behavior.js:1888Runtime.logic @ preview.js:2573Runtime.tick @ preview.js:2322tickFunc @ preview.js:649
Physics_behavior.js:10 Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 33554432, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.
Physics_behavior.js:10 Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 33554432, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.
[/code:12uiesqc]

  • Problem Description

    ____ A concise description of your problem here ____

    Simply running this layout causes a Javascript abort at an uncaught error. The layout attempts to create 50 sprites. Within 1 minute, it usually will crash. No user interaction required.

    Attach a Capx

    ____ Upload a Capx to this post ____

    Description of Capx

    ____ Concise description of what this CapX does ____

    Very simple 8 event capx. First, creates a procedural background from a sprite animation and an array (from a tutorial on this website). Second, creates a parallax background in the same manner. It starts with one 'user' sprite that's mouse controlled. Every 3 seconds, it creates a new 'sprite3' (up to a maximum of 50) and then applies a random physics force to all 'sprite3'.

    Steps to Reproduce Bug

    • Step 1 Run the layout.
    • Step 2 Wait.

    Observed Result

    ____ What happens? ____

    A popup notifiying the user of a 'Javascript Abort ()' error.

    Expected Result

    ____ What do you expect to happen? ____

    To not crash???

    Affected Browsers

    • Chrome: (YES)
    • Internet Explorer: (YES)
    • Edge (YES)

    Operating System and Service Pack

    ____ Your operating system and service pack ____

    Windows 10

    Construct 2 Version ID

    ____ Exact version ID of Construct 2 you're using ____

    Release 216 64 Bit

    Sorry if this has been reported before or if I'm somehow doing something wrong. I've only been using Construct 2 for 2 days.