If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
NEW : We have got a new blog where we post some interesting SWF internals info.
List of issues#625 swf created by crossbridge
Author: 
ddyer
ddyerDate created:
Type: other
Visibility: Everybody
Assigned to:
Labels: FlashCC
State: closed 
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.
I think current version (18.0.0) handles it way better
than it was in 2014.
State: postponed→upgraded
State: upgraded→closed