JPEXS Free Flash Decompiler Issue Tracker

If you are looking for the decompiler itself, visit

List of issuesList of issues

#625 swf created by crossbridge
Author: user ddyer
Date created:
Type: other
Visibility: Everybody
Assigned to:
Labels: FlashCC
State: closed Help

Jpexs is next to useless for looking at code that is produced by crossbridge. I'm not too surprised, but I'd be very happy if this were to be improved. Here's a small snip: public function F__Z10rgb_to_hsvdddPdS_S_() : void { var _loc1_:* = 0; var _loc5_:* = NaN; var _loc6_:* = NaN; var _loc3_:* = 0; var _loc2_:int = ESP; _loc1_ = _loc2_; _loc2_ = _loc2_ - 152; _loc5_ = op_lf64(_loc1_) /*Alchemy*/; _loc5_ = op_lf64(_loc1_ + 8) /*Alchemy*/; _loc5_ = op_lf64(_loc1_ + 16) /*Alchemy*/; _loc3_ = op_li32(_loc1_ + 24) /*Alchemy*/; _loc3_ = op_li32(_loc1_ + 28) /*Alchemy*/; _loc3_ = op_li32(_loc1_ + 32) /*Alchemy*/; _loc5_ = op_lf64(_loc1_ - 24) /*Alchemy*/; _loc6_ = op_lf64(_loc1_ - 16) /*Alchemy*/; ... This is compiled from C code that uses double floats and pointers to double floats. I suppose the code is using subprimitives that would not normally appear when the natural actionscript type would be : Number. My underlying motivation is to gain insight into why this code runs so much faster than the corresponding code written directly in actionscript.
Check issue #277
State: new→postponed
I think current version (18.0.0) handles it way better than it was in 2014.
State: postponed→upgraded
State: upgraded→closed