Fri 07 Sep 2007 12:51:17 PM UTC, comment #12:
It turns out this was related to action execution order.
At least latest commit to fix execution order fixed this, it seems.
|
Tue 04 Sep 2007 08:18:13 PM UTC, comment #11:
I'm not sure this bug is related to action order, that one is "race condition playing copter.swf", which I have fixed locally, by pushing all actions to the global list. This bug still remains though.
|
Mon 03 Sep 2007 03:09:19 AM UTC, comment #10:
I'd like to finish the wiki page for actions order first .
Copter.swf is apparently too big and complex for deduction.
About actions order, if any questions or any thing you think important and related or any thing haven't been covered, please add to the wiki page for a discussion.
|
Sun 19 Aug 2007 11:29:53 PM UTC, comment #9:
Attached a farther reduction. The problem is definitely in ActionScript.
A quick fix for the version I'm attaching is NOT popping the value from the stack on BranchIfTrue, but that in turn breaks 3 tests from swfdec testsuite (and who knows what else..)
Reducing farther...
(file #13733)
|
Sun 19 Aug 2007 09:22:10 PM UTC, comment #8:
Decompiling the resulting SWF using 'flasm', adding a final 'label4' and reassembling results in a valid SWF... which still shows the problem. Further reducing ...
|
Sun 19 Aug 2007 09:18:55 PM UTC, comment #7:
Attaching a further reduced input.
It seems the bug is related to duplicateMovieClip and _x.
(file #13732)
|
Sun 19 Aug 2007 11:31:54 AM UTC, comment #6:
I also managed to create a somewhat simplified test-case by modifying the swfmill xml generated from copter.swf. Unfortunately the movie is rather mangled, however gnash shows gaps when played and swfdec doesn't. The simplified XML file is unfortunately about 800 lines long.. so it may not be very useful (and it's malformed nature might make it even harder to debug).
(file #13725, file #13726)
|
Sun 19 Aug 2007 11:25:25 AM UTC, comment #5:
Upon further investigation I believe the discovery I made previously via the "cvs bisect" is misleading... I'm now convinced that the change on Fri May 11 actually just exposed a bug that was present with gnash all along.
However the nature of this bug is still somewhat elusive. I used swfmill's swf2xml and xml2swf to try and track what was happening. I believe the terrain is generated by calls to "duplicateMovieClip" on a sprite just to the right of the visible area. The black gaps in the terrain may be present because gnash isn't calling duplicateMovieClip at the correct rate... I'm not sure exactly why yet.
Attached are 3 images hopefully demonstrating the nature of the gaps. The first is gnash CVS's current behavior. I count about 13 terrain "blocks". The second is swfdec's behavior. I count about 16 or 17 blocks. The final image demonstrates what happens if the scroll speed of the movie is halved (I did this by modifying the the xml generated via swf2xml and changing the value "8" to a value "4" on line 2729 (search the file for "scrollSpeed"). This final image seems to have the correct number of terrain blocks (about 17), but unfortunately the game does play rather slowly!
(file #13722, file #13723, file #13724)
|
Sat 04 Aug 2007 11:45:07 AM UTC, comment #4:
I should have mentioned in my previous comment that the 3 remaining issues with the game I listed at the end of the comment were also issues with gnash before the May 11 regression. Also, it is obviously possible some of these issues are with the game itself not with gnash (we need some feedback from those with the Adobe player).
|
Sat 04 Aug 2007 11:31:11 AM UTC, comment #3:
I did a cvs "bisect" to find the patch that caused the regression Zou identified. The bug was introduced in a patch with the timestamp:
Fri May 11 07:02:01 2007 UTC
I looked at the changes made and discovered what I think caused the bug (a one-liner change to sprite_instance.cpp). On my setup the attached patch does fix the issue (tested using AGG renderer only). However I'm not too happy with this patch... I had to disable a few asserts in dlist.cpp for my simple patch to work (or else the asserts would be triggered).
Even with this patch the game still doesn't play 100% correctly. There is some flickering on the left-side once you fly a small distance into the course. If you crash into the ceiling or floor there is also a graphics artifact (a "black blank" slot reappears). Also the distance/score font doesn't display (at least with my setup). The former two issues are likely closely related to this bug.
(file #13587)
|
Tue 05 Jun 2007 10:12:51 AM UTC, comment #2:
yes, I'v trid with NEW_TIMELINE_DESIGN set to undefined, 2 and 3, and got the same result.
I suspect this was caused by a update of shape_character_def.cpp, and parsing related. Need more time to inspect what's happend.
|
Tue 05 Jun 2007 09:53:16 AM UTC, comment #1:
Did you try undefininig NEW_TIMELINE_DESIGN to see if it's related ?
|
Tue 05 Jun 2007 09:28:03 AM UTC, original submission:
tested with copter.swf
We could see the obvious visual difference, attached a picture file for this, see cmp.jpg
I could reproduce this with both AGG and GL.
It played well before(IIRC), so I guess it was a regression.
|