gles.js - a lightweight WebGL renderer for Android

If its C2, then its fixable, provided it can be identified.

If its Chrome, not so much.

Of course the big problem is that Chrome kinda covers both pc, and mobile.

We need alternatives to it, that I will agree on.

Otherwise you're looking at Cocoon and stripped down features, that only works for mobiles.

Jayjay (not a real solution, but if you're still having problems with skipped collisions like I had: I replaced every single one in Penelope with "is overlapping object - trigger once", it does the trick pretty well even at low framerates)

Aurel Thanks! We actually did do that but found we also needed to have the "on collision" events left in as it didn't work on platforms. There's so much stuff I'd love to test more if I had the time to make more comparison/example capx and cap's, as CC tends to run much smoother than C2 at any framerate.

I think, while there still is space for improvements in the C2 engine and also in the runtime enviroment (Chrome, NW), many problems are (from example capx i saw from others) user-made or because the lack of hardware support.

The biggest problems from user side are:

• overuse and misuse of Physics (really, many things you can easy code in 2 or 3 lines, but some developers use physics for everything / also mixing incompatible moving (like 8-direction) with physics) Advice: only use physics if there is really no way you can get the behavior you want in code.
• overuse of WebGl effects (effects are very heavy, try avoid them as much as possible, most things can be baked in the sprites/background images already)
• overuse of Particles (not much to say here, but keep in mind: a bad game doesn't get better because you use explosions with thousands of particles...)
• using way too big image resolutions (i remember this now, when reading another post) Always use images in the smallest size possible, specially for mobile games, because many small devices still have memory & gpu power problems with over-sized images. You really need a 2048x2048 background picture for your 2d retro platform game? I think not...
• logic errors/coding errors (like for example putting stuff in the system.every tick that doesn't belong there)

I don't say that everybody here makes this mistakes and that there aren't problems with the construct engine itself, but from what i experienced around 80 % to 90% of the users that have problems with their games, have them because of misusing the engine like i show above. The biggest selling point of C2, it's easy way to use and make games, is also the biggest problem of it, because many people without knowledge of the underlying technology or even coding are attracted and if something doesn't work like they want, for sure they blame the engine first.

There is another issue from the hardware side and this is lack of WebGl support from drivers (video cards)

Your shit little 80's arcarde game doesn't run well on your big pc or on your mobile, if your gpu doesn't support WebGl at all or good enough, and there is not much Scirra can do about. Because of this we have this big difference between all the devices we are testing our game. But because all GPUs made in present time support (hopefully) WebGl, this issue will vanish.

— Games (not sure the alert works with the space)

There are indeed lack of web tech support (like webGL not being availiable), and user mistakes, I do wonder though how to make them less problematic.

I mean for the web tech, there are not a lot we can do (unless someone here can contribute to the development of browsers and wrappers).

But for user mistakes and issues, maybe there are ways to make them less easy to do, as it has been said, it is easy to use wasteful ressources in C2, or to add behaviors that are not made to be compatible between them, etc..

All of this makes me believe that, while C2 is not a direct culprit, the user does not feel he is doing something wrong, meanwhile, sometimes weird uses can feel wrong but are actually correct (like not using behaviors at all).

— Games

Agreed, there are limits to the amount of heavy-hitter stuff that can be used, and that will apply in any engine, but we also have taken them into account and avoided using them for the majority of cases, especially physics which does not get used at all.

I like that you blame user code, both of us devs on our game ( which isn't little <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink"> http://store.steampowered.com/app/334190/ ) are coders outside of C2. In fact, that reminds me that nesting is completely broken in C2 and most code that we would do in programming has to be extremely dumbed down and expanded into more events/conditions. That's a nice "gotcha!" to run into <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

I'm not crazy enough to expect C2 to even be able to run the title screen on mobile, just desktop performance is what I want <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> Mobile is a whole different beast to tame and cram stuff into.

I'd be interested to know how nesting is broke. I know some things are all chicken, and egg as far as who made who goes.

Also Aurel's workaround with is overlapping sounds interesting, but I think there should be some other way to do that.

You have to keep in mind that that is one of the "gotcha's" of frame rate independance.

Is overlapping is bound to be more expensive, I will say that much. Plus trigger once is a little iffy, a better solution may be an instance variable.

are coders outside of C2. In fact, that reminds me that nesting is completely broken in C2 and most code that we would do in programming has to be extremely dumbed down and expanded into more events/conditions. That's a nice "gotcha!" to run into

I'd love to hear an example of that, since I've only ever used the Scirra/Clickteam style of coding.

newt The overlapping work around does indeed work for the most part. I've had to do it for most of the game to rectify the lesser lurching. Bullets not making contact etc. Platforming however was a different beast. I got around that too. The worst offender was the vertically moving platform vs player gravity which I fixed by pushing the player back out of the moving object with something like if sprite is overlapping at y + (number) then set sprite y - (correct distance to top of sprite etc.).

It does work and since it's doubling the detection code, I'm sure it's taxing.

I think I remember something about getting some expressions for line intersections, no idea if that's still in the works. It might help, but probably only if it can work with collision cells.

There are other methods as well like a percent to hit.

newt It's mostly when you want to prevent duplicating conditions/events by using sub-events, and then also using loops/for loops within those sub-events, hard to say an exact case from memory but I might be able to make one in future.

Also, I wonder if non-circle and non-box type collision/overlapping (so, convex shapes) is currently done by using a method like this : http://www.dyn4j.org/2010/01/sat/

(also another example here: http://www.metanetsoftware.com/technique/tutorialA.html )

— Sure, I'll update this post when I get some time with examples, hopefully by the weekend.

It would be nice to know what methods C2 uses, and perhaps see if there isn't something better.

It claims to use the latest tech, might as well keep the the insides updated as well.

C2 uses SAT and convex decomposition for it's collisions. There's not really anything better for 2D, i don't feel like GJK would offer any performance gains in a 2D environment. What perplexes me is the lack of more primitives, especially circles, since these would be the fastest and most general collision bodies to have, as well as dead simply to implement.

I was pretty sure SAT isn't used in C2. Just checked and no it's not. It does the collision detection with either bounding box overlap tests, which are very fast or "line intersection" and "point in polygon" tests for polygons. Collisions are resolved in most (all except physics) behaviors using the runtime's pushout functions which basically are loops that check for an overlap, move a bit and check again until not overlapping. The function used to push out in the nearest direction uses a spiral scan pattern to find a free space.

I understand your logic perfectly. To me though the problem is not that there's a thrid party involved, which in unavoidable, rather the fact that the main focus of the third party is not gaming performance, cause let's face it, google or apple don't care if there a bit of jank every 30 secs on a web site/page, but for a game that is a totally different story.

> Ashley: I know you're probably sick of me pointing to this, but I would really love for you to read these two articles and then tell me if this is not a technology worth considering

>

Given the number of people here criticising us for "depending on third parties too much", I am extremely wary of adding any additional technology dependencies in to the C2 workflow. Even if Haxe works pretty well, we could still get shafted by compiler bugs, missing features and unoptimised parts that kill the performance. In particular I think Stencyl got burned by some of these types of issues. I'd rather stick with HTML5 - it may not be perfect, but it's improving fast and has some huge players backing it, such as Microsoft and Google.