performance issue solved yet?

http://parthdalal.com/c2performance/

Welcome to HTML5. If you absolutely want flawless performance on Mobile Devices, no questions asked. Then you should probably learn how to code.

Construct 2 is a impressive program for non-coders and the performance I get with on Mobile devices is actually impressive to me.

parthdalal.com/c2performance

try ejecta with the same example ....

I think this is to do with the browser frame scheduling and v-sync. This is already perfect in IE11, which proves HTML5 can be equally good as a native app for that. I think Chrome is working on improving their frame scheduling at the moment and it should be a lot better when the current Canary gets down to stable. This disproportionately affects C2 games since we rely on Chromium as the engine for Chrome, NW.js and Crosswalk, which covers a lot of platforms.

it was a very great problem not so long ago on chrome, but it seems to be fixed "mostly"

vsync will improve in browsers, its also getting more awareness by sites like these

http://www.vsynctester.com/

http://www.testufo.com/browser.html

kudos to them

some thing i also found there is that vsync doesn't work well on second screen or is not reliable

so testing on second screen can also give janky results sometime

i may just move to unity and learn c# or programming languages needed to build mobile games

Welcome to HTML5. If you absolutely want flawless performance on Mobile Devices, no questions asked. Then you should probably learn how to code.

Construct 2 is a impressive program for non-coders and the performance I get with on Mobile devices is actually impressive to me.

I gave C2 a try before, the performance wasn't my issue because I was just trying to make a simple test game.

The thing that I didn't like is how it handles events; the Event System was a big turn off for me, it isn't a DRY solution but a WET one, a real WET mess that's much messier than a WET programming code. That's maybe another reason, why the performance is slow.

I once tried to work my way around this:

scirra . com /forum/how-do-i-create-an-array-for-sprites_p890045?#p890045

Reference of DRY & WET principle: http://en.wikipedia.org/wiki/Don't_repeat_yourself

There's also some important things that C2 is NOT covering in their manuals and I feel like they intend to hide this crucial element.

See this: scirra . com /forum/what-are-all-the-event-conditions-that-uses-fake-triggers_t124875

I have an off-topic question, can someone answer.

Does having the C2 License will force you to have the badge at the side of your avatar that says, "[user] owns a Construct 2 License! Hats off!", or is it something just optional to have when you got your C2 License?

Edit: Fixed URL cuz' of fancy forum rules.

Mabaet

Yours is a very salient insight; I hadn't heard of WET/DRY before, but I understand the concept perfectly.

IMO, the tendency of most C2 users is to adopt a WET approach by merely copy/pasting events to replicate logic in different contexts. It's a lot faster than modularizing into a function, and it's acceptable for a prototype, but breaks down for projects exceeding a few hundred events.

However, you can often fend off this kind of design with a good use of families and functions. My rule is this: never copy/paste logic if you are using it it more than one place; it will always come back and bite you later on. Turns out this has been codified into a rule of thumb as well:

http://en.wikipedia.org/wiki/Rule_of_th ... ramming%29

One of the places where I still run into trouble, though, is in cases where I want to pick objects of different types in one go. For example: we can't go "pick all objects where X > foo" if some of those objects are sprites, some are spritefonts, some are TiledBG, etc. Even if we just want to pick all sprites where X > foo, we still have to add every sprite in the game to a family, then refer to that.

It would be great to be able to have a pick function that could cross object type lines and pick thru every object that shared the same kind of parameter (X, Y, Opacity, etc).

BTW, that example you link to: what, exactly, is the advantage of such an approach to multiple objects added to a family? The problem I see, in a real world scenario, is that every animation frame for every troop would be loaded with that object, which would take up a lot of unnecessary memory on layouts where you would only be spawning certain types. And...what if you had multiple animations for a given troop?

Here's a version implemented with families; if anything, I think this approach is more elegant, as adding new enemy types only requires adding a couple new actions, and all stats can be set in one go thru the enemies family:

https://www.dropbox.com/s/jychw2ppib7en ... .capx?dl=0

Mobiles still stutter, its not resolved due to reliance on Chromium which Google messed up and haven't fully fixed yet.

On PC, it's still the same, we have to use a very old version of NodeWebkit with an old Chromium without this problem. But at least there's that option.

Steam API integration is wonky and that should be the priority to fix.

IMO, the tendency of most C2 users is to adopt a WET approach by merely copy/pasting events to replicate logic in different contexts. It's a lot faster than modularizing into a function, and it's acceptable for a prototype, but breaks down for projects exceeding a few hundred events.

However, you can often fend off this kind of design with a good use of families and functions. My rule is this: never copy/paste logic if you are using it it more than one place; it will always come back and bite you later on. Turns out this has been codified into a rule of thumb as well:

http://en.wikipedia.org/wiki/Rule_of_th ... ramming%29

One of the places where I still run into trouble, though, is in cases where I want to pick objects of different types in one go. For example: we can't go "pick all objects where X > foo" if some of those objects are sprites, some are spritefonts, some are TiledBG, etc. Even if we just want to pick all sprites where X > foo, we still have to add every sprite in the game to a family, then refer to that.

It would be great to be able to have a pick function that could cross object type lines and pick thru every object that shared the same kind of parameter (X, Y, Opacity, etc).

BTW, that example you link to: what, exactly, is the advantage of such an approach to multiple objects added to a family? The problem I see, in a real world scenario, is that every animation frame for every troop would be loaded with that object, which would take up a lot of unnecessary memory on layouts where you would only be spawning certain types. And...what if you had multiple animations for a given troop?

Here's a version implemented with families; if anything, I think this approach is more elegant, as adding new enemy types only requires adding a couple new actions, and all stats can be set in one go thru the enemies family:

https://www.dropbox.com/s/jychw2ppib7en ... .capx?dl=0

Completely agree with this! However, there are many cases I've run into where copying and pasting events was the only bug-free way to make things happen (else statements, or statements, and for loops all seem to get buggy in sub-events and sub-groups, etc).

So, it's a lose-lose situation where relying on things that *should* work but *don't* is bad, and you also do still get bit by the copy paste method later on. It's hard to isolate individual examples of this though, as our game was already a huge number of events (many types of enemies, different playable characters with different movement types, etc). The general experience is that anything deeper than one layer of subevents breaks.

TiAm

IMO, the tendency of most C2 users is to adopt a WET approach by merely copy/pasting events to replicate logic in different contexts. It's a lot faster than modularizing into a function, and it's acceptable for a prototype, but breaks down for projects exceeding a few hundred events.

And that makes it hard to maintain. If I change 1 little thing from something, I would have to find every many other lines that has something to do with that 1 little change which can take up to hundreds, and that is a pain to manage. It works, but to me isn't practical.

//======

However, you can often fend off this kind of design with a good use of families and functions.

Yes, the family and functions. The function is fine, but the family I can't say for sure as I can't play around with this. Reading some guides about the Family and how it works, I think it's still limited. I'm not suppose to say that it should cover everything, but the thing is that there are still simple things that the Family feature should be doing but isn't.

//======

One of the places where I still run into trouble, though, is in cases where I want to pick objects of different types in one go. For example: we can't go "pick all objects where X > foo" if some of those objects are sprites, some are spritefonts, some are TiledBG, etc. Even if we just want to pick all sprites where X > foo, we still have to add every sprite in the game to a family, then refer to that.

It would be great to be able to have a pick function that could cross object type lines and pick thru every object that shared the same kind of parameter (X, Y, Opacity, etc).

The first time I played with how the event pick its objects had me down. The picking system is a huge role and needs to be smarter. It's a pain to deal with.

//======

BTW, that example you link to: what, exactly, is the advantage of such an approach to multiple objects added to a family? The problem I see, in a real world scenario, is that every animation frame for every troop would be loaded with that object, which would take up a lot of unnecessary memory on layouts where you would only be spawning certain types.

This isn't the general idea of what I'm trying to show there. It's still all in the Event Sheet, how it should be easily managed.

//======

And...what if you had multiple animations for a given troop?

Can get around with Animation's folders and tabs but gets complex. But like I said, this isn't the general idea of what I'm trying to show there.

//======

Here's a version implemented with families; if anything, I think this approach is more elegant, as adding new enemy types only requires adding a couple new actions, and all stats can be set in one go thru the enemies family:

I can't test that as I don't have a C2 License; Family feature requires C2 License. And this is why I demonstrated my logic using the Animation. But if what you say is what it is, then great. But I know that you know that the Family needs more work.

//======

Jayjay

there are many cases I've run into where copying and pasting events was the only bug-free way to make things happen (else statements, or statements, and for loops all seem to get buggy in sub-events and sub-groups, etc).

So, it's a lose-lose situation where relying on things that *should* work but *don't* is bad, and you also do still get bit by the copy paste method later on. It's hard to isolate individual examples of this though, as our game was already a huge number of events (many types of enemies, different playable characters with different movement types, etc). The general experience is that anything deeper than one layer of subevents breaks.

Speaks for itself. The C2 Event system wants to be easy to understand but done in an unproductive way. And that's pretty much about it, C2 wants you to work like a factory, it works but is a pain to manage. All in all, it all boils down to user preference; Well of course, this is completely fine to users who are cool with that. And I think isn't much of a big deal to those who make small mobile games like a Flappy Bird rip-off.

//======

Can you please answer my question:

Does having the C2 License will force you to have the badge at the side of your avatar that says, "[user] owns a Construct 2 License! Hats off!", or is it something just optional to have when you got your C2 License?

Construct 2 provides several tools so users can avoid repetition: event sheet includes, functions, families, global layers, and more. I think the tendency of C2 users to repeat things is more to do with their inexperience since we cater to a non-technical audience. I think C2 helps them realise that repeating stuff is unmaintainable and to learn to use tools to implement DRY. We're wandering a little off-topic though!

Back on performance another big issue IMO is non-technical users are oblivious to hardware limitations and throw in tons of CPU and GPU intensive stuff assuming the device can handle it. Experienced programmers use very clever designs to look good while staying efficient, and non-technical users picking up C2 need to learn those kinds of tricks too - such as memory management.