4: What do you mean by "aggravation factor"?

Thanks for you opinion glerikud. One of my fears, since I can't test it in the free version, was that getting apps out the door and onto Google Play, Facebook, etc. was going to be something akin to a nightmare. I'm reading all sorts of scary wordings that require plugins or other programs with inherent bugs just to get published. While I do program in several languages, java is not one of them. I've been concerned after browsing the forums that I was going to have to start debugging someone else's code (which I loathe doing) in order to get published.

And I suppose that relates to the aggravation factor as well. Recently I've been working with Unity and scripting in C# (modding for another game) and while I've been at it for several months, trying to comprehend some of the really obscure ways Unity works is... well... aggravating (like a quaternion and vector math and the Unity API in general not to mention it's mind boggling interface.) So I guess my ultimate question here is: from creating a new project to seeing the first $1 come in, how many times am I going to facedesk?

While my experience with C2 is extremely limited I can say this. One of my first experiments was creating a 5,148 element array (72x72), filling that array with random numbers (1-5), reading back that array and assigning sprites to the background based on the random number, refilling the array with random numbers and then using a different sprite to create a parallax background and... it was fast.

Arrays are old programming structures. They've been around for years so the code to work with any array in any language is pretty well optimized. But, with any programming, it depends on how large the array is, how often you access it and whether you're reading through the entire array or accessing one cell.

The problem you're going to have with an array is defining the size of the array at the start and then tracking which cells you've updated and what to do when you reach the end of the array (I don't think C2 has dynamic arrays where you can change the size, I may be wrong)

This thought keeps gnawing at me...can I build a business this way? Too often in these forums the answer is "use cranberry's plugin". I commend Sang Ki Kwon for the work he has done, but should I build a game/app that depends on a 1-man company who develops plugins in his spare time? I am relatively new to this aspect of the build process, but I am finding this part of the process much more difficult than the actual building of the game. (Example: I was trying to get the admob plugin working and now the game is locked in portrait mode even though every setting in the game and XDK is set to landscape. I cannot get it in landscape mode. haha) Not trying to sound like the voice of doom, but I really think C2/3 needs to make the process to iOS and Android builds a singular path for its customers. Until then, I just cannot see this as a tool you can use to build a mobile game business. (I feel obligated to say I love C2 as a game-making tool!)

Currently sitting on the fence trying to decide if I should purchase Construct 2 and like you, considering building a 1-man business around it, I think you just answered one of my major questions. It would appear that building an app with Construct 2 is the easy part. Getting it out the door seems to be an exhausting aggravation.

First of all, let me say that I'm finding Construct 2 to be pretty amazing. Even with the free version I've developed an app in a matter of days that would have taken me months in the other programming languages I know. Secondly, the help and support on the forums has been great. Within hours of posting, I'm getting my problems fixed.

But now, the time has come to make a decision. I've reached the 100 event limit and have to decide if it's time to purchase or look elsewhere. So here's the questions in my head that I don't have answers for and maybe you can help me decide.

1. I'm looking to make apps, not necessarily games. And I'm finding that pretty easy going. So, the question is, how easy is it to take a Construct 2 app and port it over to say Android and iOS. I have no experience with that and looking at things like XDK confuse me.

2. I understand Construct 3 is in the works. If I purchase now, am I going to have to purchase again when 3 comes out. I've got shafted before buying an IDE and a month later a new version came out with gobs of new features and I got no free upgrade. *Edit* I just found the post where it said there would be a discount to upgrade but it was from back in January. So I'm wondering now if the 'long way off' for Construct 3 is still a long way off.

3. I understand some publishers refuse apps made with Construct. While I don't at present plan on going through them, it would be nice to know if I get hard up for cash that I can create a game quickly and sell it. Is it common for publishers to refuse Construct apps and why? Is their reasoning something I need to be aware of when independently releasing my own apps?

4. Doing my homework, I've looked at a few other app IDE's like GDevelop. While it's amazingly similar to Construct, I like the workflow in Construct much better. It makes sense. But, the price tag of GDevelop is much more appealing. I've also looked at some of the negative reviews of Construct to see where the 'aggravation' factor comes in. My question therefore is, from those of you who have been using Construct for some time, rate the amount of aggravation you experience with Construct and if you can, compare that to other IDE's.

Those are the questions right off the top of my head. I'll probably have more.

That works, thanks but it seems to me that it should have the drag & drop plugin on the textbox before it sets it as a target, which is what it's appearing to do. And I just discovered that listboxes are affected by this as well.

Anyway, thanks to the support for the two bugs I have reported, I'm ready to purchase... When does it go on sale next? Ok, not a good place for that question. Nevermind.

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.

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]