Construct 3 - many questions (native exporterts)

—, I must confess that I don't see how your example shows a more efficient alternative. I don't know how those events would be rewritten in JavaScript, but the inclusion of a function that way would surely result in a few more lines of exported code where the function is declared and referenced. More lines of code equals more for the CPU to do....

This is the recommended way of eventing by a professional C2 user, however that was just an example. (Link to the post is HERE)

To be honest Colludium, I don't think that Ashley will have the time to look through thousands of games and optimize them the way they should be.

This debugger system would do the work for him, that was my main idea behind that.

Ashley: ARRRRGGHH!!!!! I Think you life sometimes in your own fantasyworld!!!!! BoyHK say it right: Construct is now from 2011 round 5 years old. In the advert-video it suggerest me and all the other users its absolute easy to make mobile-games! but the problem is: they running bad! In the last 12 months there was a minimum better now. But sorry, we cant wait a lot of years when you clear this problem!

We have spend a lot of money to you and your company and you will tell us in all this long time there you can not delete this problem?????? Its equal for me how you change it. When the solution is an another as an native exporter its ok for me! But make what..... what ever that the games are running! At the first time i have worked with c1/c2 it was a wonderful time..... then cames the problems with the mobile......

paradine - please, link me to every example of CPU-bottlenecked games you can find. I want to investigate them but am so far unaware of most of them. I assure you I do not intend to ignore them, but with hundreds of posts made to the forum every day it's very easy to miss posts.

I am also skeptical of polls for features in general. We did feature polls that showed the vast majority of users out of hundreds of voters said they wanted multiplayer. I was concerned that even with C2 doing much of the heavily lifting and hard work, networking is still a difficult subject to work with in general, so it would probably still be hard to use. Even when I specifically described how it would likely be difficult to use, still people voted for it in huge numbers. Then when we released it, very few people actually used it. As far as I can tell it's because... it's a difficult subject to work with in general!

To me this proves large numbers of users will vote for features based purely on hype. They imagine that everything will be perfect and brilliant and there will be no shortcomings or tradeoffs and it will be super effective and easy to use. Of course reality rarely ever lives up to that.

So I don't really care if a million people vote for native exporters. I regularly see that people blame HTML5 for performance issues when really it's a hardware bottleneck. I can see that people think "just make a native exporter, it's not that hard right?", whereas I can see it's a colossal project with severe ongoing impact on the product development. So even if everyone voted for it, I am not persuaded they have a proper understanding of what they are voting for, as happened with the multiplayer polls.

when we say make a native exporter we actually mean change the whole engine (you have to change it for native exports)

and also i didn't know you dont care about your users

thanks for that !

and also see this :

Ashley

intel XDK and crosswalk 11 - it runs 40-45 fps on my mobile device.

The newest Intel XDK and the newest Crosswalk - it runs 45-46 fps on my mobile device.

Native APK - it runs 57-58 fps on my mobile device.

Thanks for the link, — That tutorial is referring to efficiencies gained in your event sheet structure by calling a function for actions that will be called in different places in the event sheet. It had nothing to do with making the events run faster, and it only removed repetition so and edits only have to be done once.

There are some good techniques for making event sheets efficient, but I don't think that's one of them! I suggest this: don't waste your time would be the best start.

Thanks for the link, — That tutorial is referring to efficiencies gained in your event sheet structure by calling a function for actions that will be called in different places in the event sheet. It had nothing to do with making the events run faster, and it only removed repetition so and edits only have to be done once.

There are some good techniques for making event sheets efficient, but I don't think that's one of them! I suggest this: don't waste your time would be the best start.

Just a bad example I guess, but you get the idea.

I want to help out with new ideas for C2, instead of native exporting which is a thing for quite a while now.

when i make a simple Capx with 15 small objects on layer and the framerate is going down

It sounds like it's simple enough to reproduce easily ; please submit a sample .capx for the interested parties to investigate ! I too would like to know how it's possible to bring the framerate down with only a handful of objects (unless they're all supermassive blended textures on a very old device, which would kill the fillrate and pixel units anyway, regardless of the technology)

> when i make a simple Capx with 15 small objects on layer and the framerate is going down

>

It sounds like it's simple enough to reproduce easily ; please submit a sample .capx for the interested parties to investigate ! I too would like to know how it's possible to bring the framerate down with only a handful of objects (unless they're all supermassive blended textures on a very old device, which would kill the fillrate and pixel units anyway, regardless of the technology)

And what brings? Nothing! I have upload my complete capx (pinball-game) for weeks here. many other examples/videos i have watched here in this forum the last months. And when you tell you angryness comes everytime the same s**t: "load it up please" "its your mistake". Funny community...... very funny Why you make it not self? 10 stapled objects (with physics) and a ball crashed inside! Its with IntelXDK 15 minutes of work! Now we going in the year 2016 an we talking about a 2d engine that can it not run smoothie and thats with a payment over 300 €uro. its a shame!

This is all still going on??

Ashley

BasicTribe : yeah well, sorry for not knowing all the posts from all the users from the past months... Only trying to help ; I'm not wasting time re-creating a project for a problem I'm not facing.

This thread has gone full circles too many times ; I'm done for now on this one.

Ashley

Subscribe to Construct videos now

your video is from:

Published on Mar 15, 2013

you could make the same example and try today with better hw, and when c2 has made loads of changes to physics, and not using anymore box2d slow physics.

also why are people using box2d physics which is slow when you got chipmunk that works fast? and many more factors... but i guess you will whine it's about a native exporter <.<

you could make the same example and try today with better hw, and when c2 has made loads of changes to physics, and not using anymore box2d slow physics.

also why are people using box2d physics which is slow when you got chipmunk that works fast? and many more factors... but i guess you will whine it's about a native exporter <.<

You have to prove that C2 has better physics now - create the same test with modern C2's physics.

well do it. i don't use physics nor do i have to prove to myself anything.

well do it. i don't use physics nor do i have to prove to myself anything.

Lol.

Why are you talking about physics improvement if you don't use it

Repeat three times "I will not post anything about things that I do not understand"

Ashley

Please, give me a sign if you have seen this information:

intel XDK and crosswalk 11 - it runs 40-45 fps on my mobile device.

The newest Intel XDK and the newest Crosswalk - it runs 45-46 fps on my mobile device.

Native APK - it runs 57-58 fps on my mobile device.