[Flash MX (2004)] Pixel shift

[hobbit_be]

Hoi

voor een projectje doe ik zoom van een image (dynamically loaded) die 100x100 is. Als ik hem eerst zet (zoom out dus) staat die op 50x50. Dan doe ik een animatie die hem dus groter laat worden tot exact 100x100.

Echter als die precies op 100x100 dan springt het beeldje een pixeltje naar beneden (of toch de data erin, de MC size blijft natuurlijk dezelfde) en word ie net iets scherper. Dit zowel op player 6 / 7. Ik dacht dat dit "probleem" opgelost was?

Hebben jullie tips hoe dit te omzeilen? (ie ik dacht een mask te gebruiken als ie perfect staat, of net fout zetten tijdens het zoomen zodat ze toch "overeen: komen.

Eender andere tips zijn ook welkom ivm Image related "issues" (ahem bugs)

[oh,when?]

hobbit_be schreef op 13 mei 2004 @ 09:58:
Dit zowel op player 6 / 7. Ik dacht dat dit "probleem" opgelost was?

Nope. Technische verklaring van Flash Player Engineering team:

Coordinates in Flash are fixed point numbers. A 32-bit integer is divided
into an integer half and a fractional half.

IIIIIIIIIIIIIIII . FFFFFFFFFFFFFFFF

The "." is the "binary point", like a decimal point.

For instance, the number 200.5 would be represented as

0000000011001000 . 1000000000000000

This representation was chosen for speed back in the FutureSplash days.
Back then, Flash was running on machines like 486/33's. Fixed point numbers
was the only way to reasonably render Bezier curves in real-time... the
FPU's on older PC's were just not powerful enough to do all of these
calculations with floating point numbers.

This representation has its limits. The smallest fraction that can be
represented is 1/(2**16) or 1/65536, which is 0.000015. Anything after that
will just be rounded off.

0.000015 sounds pretty small, but whenever you do a transformation like a
scale or rotate, or group something or turn it into a symbol, that is
expressed as a 2D matrix multiply which is a series of math operations.
Each operation adds its own contribution to the final round-off error. What
you're seeing when a coordinate goes from 200 to 200.1, etc. is when the
round-off error was bigger than 0.05 and enough to knock it over to the next
tenth in the decimal representation.

In this day and age, floating point support is much better on PC's (games
rely on it heavily) and Macromedia could conceivably rewrite the low-level
geometry and shape engines in Flash and the Flash Player to use floating
point instead of fixed-point representations. Round-off error still happens
in floating point, but the precision of math operations would be much higher
so it'd be a lot harder to get it to manifest.

[...]

It would take several hotshot graphics engineers
many months to do it, and it would have to be a coordinated effort for both
the Flash Authoring Tool and Flash Player. There would be mammoth
considerations for compatibility with existing FLA and SWF files to not
break anything. A lot of up-front design work would have to happen,
followed by a long and hard implementation and testing phase.

Hopen dat het misschien gefixed wordt in Flash 8

[Yellow|A]

Hopen dat het gefixed wordt doe ik al jaren, maar het werkt tot nu toe niet echt

Bitmaps op alpha 99% zetten of er een shape boven zetten met een alpha van 1% werkt tot altijd wel?

[XangadiX]

een transparant randje om je plaatje zetten van 1px wil ook nog wel eens wonderen doen, maar het blijven workarounds die niet altijd honderd procent werken.

* XangadiX knuppelt gele even neer, nu hij hem toch ziet

[OzBoz]

Ik los het altijd op door bij alles waar ik bitmaps in gebruik qua Flash gewoon op de maat van mijn movie een instance van een gfx helemaal bovenop te gooien met gewoon een alfa van 0. Dan verschuift er ook niets.

[Verwijderd]

Alles uitlijnen op hele pixels (.0) is ook niet onbelangrijk. En soms buggy(de authoring tool dan).

[ Voor 14% gewijzigd door Verwijderd op 13-05-2004 17:44 ]