If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
List of issues
: The issue tracker is now writable again and logged users can download files too. But note that our support is very LIMITED.
#369 Shapes in internal viewer and SVG export
Assigned to: honfika
Labels: Flash ViewerShapes
> 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 file. > 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, stay tuned.
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
redneck-vs-zombies.swf (6,970 KiB)
Any news? Now I think svg export became even worst. Try to export 1413 svg from redneck-vs-zombies.swf in latest nightly and get file with all black content.
I tried it with 1.7.0, the result is the same, black. Am I wrong? So it is not worse. Can you tell me with which version was it better?
Oops. Sorry for disinformation - it seems same bad svg export result in all versions with 1413.
megalol: what is the id of the shape which is in the comparsion page? 1339 is a reindeer
I think it's 1166.
megalol: 1166 and 1339 fixed
psykauze: internal viewer and svg is the same now. only swf preview is diffrent.
Thanks, please take a look also at 520-600.
megalol: 520 fixed, i hope the others are, too from 520-600, they are very similar, but i havent checked all of them.
Good to read there is some work on it. I will try the future release and update this thread as soon as possible. Great job honfika :)
Thanks again, honfika. Btw sometimes FFDec exporting .svg with white background and sometimes with white. I think the right is with white (according Sothink Dec). Check shape №432 and many others.
roadofthedead.swf (25,092 KiB)
*sometimes with black
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.
Yes, this is what i wrote. Internal viewer is the same as SVG export. Both are wrong, but the same.
You are right. I did not notice anything else that you said.
megalol: a new SVG export algorithm was added, so please test all of your previous reports. SVG export part of this issue sholuld be fixed, too. I'll fix the preview panel issue soon.
Those exported .svg's looks goods except №1166 (in redneck-vs-zombies.swf) - look at his rifle (it's white).
Now it's OK, thanks.
psykauze: your issue is fixed, too. so everything should be fixed in this task
Assigned: → honfika
Assigned: → honfika
Thank you a lot for this update. So, there is still some issues with the internal viewer on shapes decoding like on this file. 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.
Test.swf (332 KiB)
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 control points. Maybe I should make a new bug entry ?
Please create a new issue only for the morphshape, i'll fix the misplacement problem in this issue in the evening.
Please try the latest nightly build. It should be much better now.
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 with definemorphshape2?
"2nd line" problem solved, and now definemorphshape2 should be fine, too
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.