+ update 2020: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means we will NOT develop new features and/or fix most of bugs. We left the tracker running in case somebody from community would like to work on it. Sorry for the inconvenience.
State: closed new: Initial state. As long as issue is in this state, the work on the issue has not yet begun. opened: Opened state means developer started working on the issue. Feature/Fix will probably be in the next release. postponed: This means developer is not working on it now, for some reason it cannot be implemented now. Issue may be opened again in the future. upgraded: Issue is in upgraded state when developer made changes to the program and new version was released. closed: This means the user is satisfied with issue results and no more changes are needed. invalid: These issues cannot be solved. ignored: Developer decided to take no action on this issue. returned: Program changes were made but user is not satisfied and returned the issue.
> What steps will reproduce the problem?
Opening some SWF files including shapes (like 0023.swf). Viewing shapes with the internal
viewer and/or exporting shapes to SVG files.
> What is the expected output? What do you see instead?
Using Flash viewer, internal viewer or opening the SVG output file with a recent browser,
the output screen should be nearly the same.
In this case, we can see some glitches with internal viewer and wrong colors with the SVG
> What version of the product are you using? On what operating system?
I am using ffdec v1.7.1 with "debian testing amd64" and an original "Windows 7 Entreprise
SP1 64 bit".
> Please provide any additional information below. Attach the file you have problem with
if necessary. If you do not want to publish files YOU CAN CHANGE VISIBILITY TO PRIVATE
compare-0023.png show the 3 ways to see the same shape (shape 84)
84.svg is the shape 84 exported
0023.swf is the original SWF file
Yeah, "should be", thats the right word.
Internal viewer was intended as some kind of "atleast something" or last resort for
Linux/MacOS users, because I can't run flash player on these systems.
I am afraid the results will never be the same, because there is a lot things to do for
making pixel perfect copy of what Adobe player renders.
However, I will try to fix the shapes preview as well as the SVG file,
Title: Bugs in shapes decoding and exporting to SVG→Shapes in internal viewer and SVG export
Yes, I also have the same bug with shapes (.svg) export. It's fully different (100%) from
original and bugged when I exporting them in FFDec. Tryed in Sothink (OK - looks fine in
preview and the same after export) and FFDec (fine in preview and very bugged and looks
awful after export). http://screenshotcomparison.com/comparison/41774
Fixed. It will be included in the next release/nightly build. Next time please try to
create smaller files if it is not a problem for you. E.g with removing the unnecessary
tags fith ffdec, until the problem is reproducable. Sometimes i cant download such big
files. (At work, or with mobile net)
I have tested the nightly build of 01/23/14 and exporting SVG files seems to be the same
as internal viewer.
Internal viewer still have some decoding issues with the 0023.swf file and probably with
many others swf files.
Thank you a lot for this update.
So, there is still some issues with the internal viewer on shapes decoding like on this
Some failed decoding:
- Shape 59 (Red part of missile)
- Shapes 61,67,69,... (Shapes are lightly truncated at the edges)
- Shape2s 36,40,43,... (Texts are missing)
In addition, the 76 morphshape has issue too. The "orange" curve should be at top of the
yellow circle and not in the middle.
Red part of missle and truncated images souhld be fixed.
I can!t find any missing texts. I checked the shapes with another decompiler, and the
result was the same. Probably the texts are not part of the shape.
Morphshape 76 needs further investigation.
Btw: the red part of the missle was truncated because it is a curved edge, and the control
point is outside of the bounds which is calculated from the endpoints. So now the control
point is used for calculating the bounds. Control point can be out of the real bounding
box, so now the image is larger than required. But at least not truncated:)
Great, shapes looks better now. So now, there is some misplacement of the shapes in
sprites, buttons and frames. Look at the 0023.swf.
From the previous softwares, sprites bounds does not take account too of line thickness or
Maybe I should make a new bug entry ?
Define morph shape is fixed, too.. (there is a 2nd line, i don't know what it it, but it
is in the flash file)
BTW: probably the definemorphshape2 rendering is wrong, too. Can you attach a similar swf
All the mentioned problems are fixed since a long time ago. +In the latest version a lot
of internal viewer bugs were fixed, so I'll close this issue now. If you find any new
problem please feel free to create a new issue.