[r141] animation problem

Bugs will be moved here once resolved.

Post » Fri Aug 16, 2013 1:59 pm

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!):
http://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: https://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]
    
B
29
S
9
Posts: 356
Reputation: 2,938

Post » Fri Aug 16, 2013 6:38 pm

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.

naelian2013-08-16 18:40:33
B
18
S
5
G
3
Posts: 298
Reputation: 5,332

Post » Fri Aug 16, 2013 10:44 pm

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?
B
29
S
9
Posts: 356
Reputation: 2,938

Post » Fri Aug 16, 2013 11:32 pm

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
B
18
S
5
G
3
Posts: 298
Reputation: 5,332

Post » Sat Aug 17, 2013 12:27 am

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
B
55
S
29
G
19
Posts: 1,520
Reputation: 25,630

Post » Sat Aug 17, 2013 2:28 am

Thanks Ramones this is THE answer ! ... can i call you "Master" ?

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* !naelian2013-08-17 02:57:46
B
18
S
5
G
3
Posts: 298
Reputation: 5,332

Post » Sat Aug 17, 2013 12:13 pm

*** 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!!mercy2013-08-17 12:17:16
B
29
S
5
G
5
Posts: 139
Reputation: 5,820

Post » Sat Aug 17, 2013 1:35 pm

This change in r141 is to blame:

[quote][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.[/quote]

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.
Scirra Founder
B
387
S
230
G
88
Posts: 24,251
Reputation: 192,464

Post » Sat Aug 17, 2013 2:01 pm

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
B
29
S
9
Posts: 356
Reputation: 2,938


Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 1 guest