Member Avatar for trishtren

Hello,
iv been working on generating a swf tag generator for a project. However i am having trouble understanding how certain values are generated.
The shape i have defined in flash is 200 pixels wide and 200 pixels in height and placed at X, 20 and Y 20.
The problem is this, the output from the program gives negative values according to a decompiler i used :

Xmin = -4129, Xmax = -1509
Ymin = -1656, Ymax = 150 (only non negative)

The structure of the binary data according to the specification should be :

Nbits = 5 bits to denote the length of each value (xmin, ymin etc)
Xmin [Nbits]
Xmax [Nbits]
Ymin [Nbits]
Ymax [Nbits]

The problem i am having is i cant seem to figure out even with the specification and binary how the values i got from decompiling the file are even valid.
01110
NBits
10111111011111
11101000011011
11100110001110
00000010010110

Or in hex : 75 FB FD 0D F3 1C 04 B0

Can anyone tell me how the binary above is possible outputting the negative values that i retrieved from decompiling an swf generated by flash? The output is correct, i just do not understand how the binary values above represent -4129 etc.

Edited by trishtren
  • 2 Contributors
  • 1 Reply
  • 109 Views
  • 5 Days Discussion Span
  • Latest Post Latest Post by firdousahmad

Dani AI

Generated

The negative values are coming from the way SWF packs rectangle coordinates: the file gives a small unsigned bit‑count (the Nbits prefix) and then four bitfields of that width that must be interpreted as signed two's‑complement numbers in twips (1/20th of a pixel). That explains why a decompiler shows negatives even though Flash placed the shape at a small positive pixel offset — the stored numbers are bit‑packed, signed, and in twips rather than plain 8‑bit pixels (, Twip, Two's complement).

How to decode reliably:

  • Read the 5‑bit Nbits value (gives the width).
  • Read the next four fields, each Nbits long, MSB‑first across byte boundaries.
  • Interpret each field as a signed two's‑complement value of Nbits width. A robust conversion is:
    unsigned = readBits(Nbits)
signMask = 1 << (Nbits - 1)
if (unsigned & signMask) != 0:
  signed = unsigned - (1 << Nbits)
else:
  signed = unsigned
pixels = signed / 20.0   // twips -> pixels

Notes and troubleshooting:

  • was right that the MSB is the sign, but it is not fixed to 8 bits here — it uses the Nbits size, so values can exceed typical 8‑bit ranges.
  • Bit ordering and alignment matter: SWF is MSB‑first inside bytes and fields are not byte aligned after the Nbits header. If decoded values still look wrong, dump the Nbits, the raw unsigned bit values, and the sign test; that will quickly show whether the parser is misaligned or using the wrong endianness. Also check transforms/registration and strokes/filters in the Flash asset — they can change the stored bounds compared with simple pixel expectations.
Member Avatar for firdousahmad

it is so simple as u have eight bit repersentation msb is used as symbol for positive or negative and so is the reason we have negative no moer than the positive number eg -128to127

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.