Javascript Uncaught Abort Crash Physics_behaviour.js

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.

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]

Fengist

I'm on Windows 7 and I've tested this in FireFox 42.0, IE11 and NW.js and it works on all 3.

At what point is it meant to crash?

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.

The bullet behavior might be an alternative option to try while waiting for a response. It has a property that allows it to bounce of other objects.

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.

Tried again and left for a while - also ran in debug - and it does throw the error. It's interesting to watch the number of sprite3 creations as, for me, it created more than 50 before crashing. Changing from the variable check to sprite3.count seems to stop it going over 50, but it still crashes.

It's going to need a more qualified eye than mine, I think.

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.

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.

Fengist

It doesn't crash for me either, and I'm not sure why you'd be running into a memory limit with asm.js in your capx.

One thing that does stand out is sprite3 is animated. The physics engine has to re-calculate the collision polygon every time the frame changes, which I guess may be using up memory. Often what I do is create an invisible second object with one frame to handle the physics, and then remove physics from the animated object and pin it to the other object.

Also you can avoid the memory limit entirely by changing "project properties"->"Physics engine" from "asm.js box2d" to "box2d web". The only difference is the performance may not be as good.

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.

.capx link returns "that page can't be found", so closing.