The result of the action to which the scale of the object is changed is different between EXE(preview in MMF2) and SWF.
How can I make the result of both the same?
SWF and MFA: exe_and_swf.zip
![]()
The result of the action to which the scale of the object is changed is different between EXE(preview in MMF2) and SWF.
How can I make the result of both the same?
SWF and MFA: exe_and_swf.zip
![]()



Can you send me the MFA? I will check if the scale factor is really set to zero. If it is then it is Flash fault, but I doubt.
Francois, will you access the following address and get the mfa and swf.
http://www7a.biglobe.ne.jp/~bp-827z/asd/temp/exe_and_swf.zip



There must be a problem here, as I see no difference between the exe and the swf version.
In your calculation, you test for Alt Variable A to be greater OR EQUAL to 1, which means that the calculation ends at 1.1. This is what happens in EXE and the same happens in SWF.
It works very well!
Ah yes.Originally Posted by Francois
However, I use the HWA with D3D9, that greater OR EQUAL to 1 is ends at 1.
Is the calculation of D3D different from standard?



I Have no clue...

If you're working with fractional numbers (e.g. 0.1) then it's not perfectly accurate. e.g. for 0.1 you really get either 0.0999999 or 0.1000001 (roughly). If you get the first one and add it ten times you'll get 0.999999, which is less than 1.0. It would add one more time to get above 1.0, with a result that's nearly 1.1.
Unfortunately, it works slightly differently on different PCs. It'll also be different between .exe/flash/java. It's also different between using a CPU's FPU and using its SSE unit, so if the HWA version is compiled with SSE optimisations and the standard one is not, they will behave slightly differently with floats.
Yes, fractional numbers (aka floating point numbers or floats in programmer speak) are horrible. You're better off working in percents, and dividing by 100 when you want to use the result. So you'd add 10 every time, compare against 100, and set the scale to number/100.
The alternative is to compare to greater or equal to 0.999999 instead.
tl;dr If you're looking for an accurate answer then you should not rely on floatsmake sure you account for the precision possible with floating point numbers, it's only about 6 digits.
Just as a curiosity and to confirm what Dynasoft said, when I run ASD's example it does not look like his screenshot :crazy: In fact it's hard to see the problem at all.