[r141] animation problem

Alright so I've been able to strip the game down to it's bare minimum while also triggering the bug. The capx is still fairly huge, clocking in at approx. 100 mb

Link to .capx file (required!):

https//dl.dropboxusercontent.com/u/5323353/Klang%20animation%20bug.capx

Steps to reproduce:

1. Leave event 107 and 108 on at event sheet "tutorial level" , and 82 and 83 at "tutorial level 2". Turning these off makes the game runs smooth again. Proving that it's this event that's the source.

2. Boot up the game

3. Press any direction with the arrow keys

4. Witness the lagspike

Observed result:

The player performs a meele strike using the arrow keys, which triggers a set amount of animations within the environment. This makes construct 2 freeze for 1-3 seconds at a time consistently.

Expected result:

The parry and animations should feel fluent and snappy, even when spammed in every direction. This has always worked as intended until [r141], and this code hasn't been touched for months!

For a demonstration on how it really is suppose to look like. The last stable node webkit build can be found here: dl.dropboxusercontent.com/u/5323353/Klang12_8.zip

Browsers affected:

Chrome: YES

Webkit (target platform): YES

Operating system & service pack:

Windows 7 SP1

Construct 2 version:

[r141]

event 108 is good, event 107 is probably not good now because "on animation" finished retrieve pillars one by one and not all instances.

change 107 like this this :

(If) On animation "pulse" finished and VisualFeedback not = -1

(Do) => set VisualFeedback to -1

(add a new event)

(If) VisualFeedback = -1

(Do) => set VisualFeedback to -2 and (all your set animation to "default")

As all "default" animation will send at the same time the problem will be solved.

Thanks for the feedback. I'll check it out when I have the time. Even though I'm still concerned that it worked as intended right before the update but not after I updated to r141?

It's perhaps not really a R141 bug but a new different behaviour in "on animation finished" creating a lag bug in your game (impressive game) ... clean code with checking variables still the best way to avoid unwanted results in time.

Scirra team will probably explain us asap if there is really a bug or not, but sure my coding avoid it ;p

There was a change in r141 to the way strings are compared.

Like naelian says, you're running the actions in event 107 way more times then necessary. In tutorial level when the 'Pulse' animation finishes, event 107 runs 26 times. That's 26 * 13 objects * however many instances of each that need to have their animation set. The animation name is "Default" and you're setting it to "default" (lower-case 'd').

The code that compares strings to see if "default" == "Default" needs to be called hundreds of times in 1 tick. In r139 it was fast so you didn't notice it. In r141 it was changed and it freezes up (in Chrome only?). You'll see if you set the animation to "Default" instead of "default" there's no freeze.

Here's a simplified capx that highlights the problem: setAnimationCases.capx

Thanks Ramones this is THE answer ! ... can i call you "Master" ? <img src="smileys/smiley1.gif" border="0" align="middle" />

Doing so 107 is still triggered 26 times but with no more lags ... perhaps merging this "Default" animation + my code will provided even better speed because 107 will be triggered only once ! ... *need to be tested* !

*** THIS IS A NODE-WEBKIT EXPORTER BUG / or CHANGE in r141!! ***

Exported to r141 Node Webkit and there is a GIANT LAG in Klang%20animation%20bug.capx when attacking and also in SetAnimationCases.capx when pressing the Right Button.

Exported to Chrome from r141 both run smooth on my 5 year old dualcore 3.17Ghz, GTX280, 4GB RAM, WinXPSP3.

In Chrome (r141) it may be few frames slower than in the R139 Node-Webkit compilation, because in the slower Chrome I could finish the Klang-level, where projectiles are coming from four directions, whereas with the r139 Node Webkit build I couldn't: it run at too high FPS, too fast for my below mediocre platform-gaming skills.

Dear developers, please review r141 beta and hopefully come up with a solution.

Thank You all!!

This change in r141 is to blame:

CHANGE] The way the engine does case-insensitive string comparisons (which it does in many places) has been altered to try to create less garbage. Watch out for any issues that this might introduce.

It turns out the function we used performs truly appallingly in Chrome. I had no idea it could possibly this slow, but it is. Anyway, I've reverted it and it runs fine now. No other browsers should be affected even in r141; note your bug report is missing a report for other browsers - you should always include this information since it can help us track down the problem more quickly.

Thanks a ton everyone. What would I do without you guys? <3 It works now. I'll take the optimization advice into account as well.

-Tom