Re: [Flashcoders] Tweening text more smoothly - AS3

[Juan Pablo Califano]

PD: I have made some tests and it seems like using nested loops is much more
faster than using modulo + floor or modulo + int cast.

The results shows that while the elapsed time in nested loops tends to grow
linearly, when using modulo tends to grow exponentially. It shouldn't be a
problem with a small number of rows/cols, though.

The results:

100 rows x 100 cols
rowFloor:2
rowIntCast:1
rowNestedLoops:0

500 rows x 500 cols
rowFloor:78
rowIntCast:27
rowNestedLoops:1

1000 rows x 1000 cols
rowFloor:287
rowIntCast:96
rowNestedLoops:4

2500 rows x 2500 cols
rowFloor:1822
rowIntCast:608
rowNestedLoops:18

The tested code:

package {

 import flash.utils.getTimer;

 public class Rowing {

  private var rows:int = 500;
  private var cols:int = 500;


  public function Rowing() {
  }

  public function rowFloor():int {
   var init:int = getTimer();
   var len:int = rows * cols;

   var i:int = 0;
   var r:int = 0;
   var c:int = 0;

  for (i=0; i < len; i++) {
  c = i % cols;
 r = Math.floor(i/cols);
   // trace("c:"+c+"|r:"+r);
   }

   return getTimer() - init;
  }

  public function rowIntCast():int {
   var init:int = getTimer();
   var len:int = rows * cols;

   var i:int = 0;
   var r:int = 0;
   var c:int = 0;

  for (i=0; i < len; i++) {
  c = i % cols;
 r = int(i/cols);
   // trace("c:"+c+"|r:"+r);
   }

   return getTimer() - init;
  }


  public function rowNestedLoops():int {
   var init:int = getTimer();

   var r:int = 0;
   var c:int = 0;

   for(r = 0; r < rows; r++) {
for(c = 0; c < cols; c++) {
// trace("c:"+c+"|r:"+r);
}
   }

   return getTimer() - init;
  }
 }
}

Cheers
Juan Pablo Califano



2008/5/25, Juan Pablo Califano <[EMAIL PROTECTED]>:
>
> I probably would, if it just were a superb compiler instead of a
> nice language (but incompatible at source level with AS) and a superb
> compiler ;)
>
> And if I were writting performance-critical suff (which I'm not), I'd
> certainly consider using it for building external swf libraries.
>
> Cheers
> Juan Pablo Califano
>
>
>
> 2008/5/25, laurent <[EMAIL PROTECTED]>:
>>
>> Yes. And you can jump to Haxe ;)
>>
>> cheers
>> L
>>
>> Juan Pablo Califano a écrit :
>>
>>> Thanks for the link.
>>>
>>> It seems clear from the tests that Math.floor *is* slower than casting.
>>> It
>>> think the implementation posted in the blog has a bug, though. The result
>>> of
>>> casting to int is the same as using Math.floor as long as the int is
>>> positive. But, if the int is negative, the results will be different.
>>>
>>> function testFloor():void {
>>>var num:Number = -1.5;
>>>var res:int = Math.floor(num);
>>>trace("testFloor:"+res);  // traces -2
>>> }
>>> function testCast():void {
>>>var num:Number = -1.5;
>>>var res:int = int(num);
>>>trace("testCast:"+res);  // traces -1
>>> }
>>>
>>> Maybe that's the reason why the compiler doesn't replace a call to
>>> Math.floor with a simple cast...
>>>
>>> Anyway, my point is that there are many layers under the actionscript
>>> code
>>> and the compiler could be making some optimizations you're normally not
>>> aware of. I've checked compiling and the decompiling the above functions
>>> to
>>> the assembly "il" representation (with abcdump). No such optimizations
>>> are
>>> made, so you're right about this.
>>>
>>> Nevertheless, I think some optimizations could be done (and maybe will
>>> be,
>>> some day?) on the compiler, like, for instance, inlining calls to
>>> Math.floor
>>> with code that would look like this, if it were Actionscript:
>>>
>>> Math.floor(num);
>>>
>>> -->
>>>
>>> num > 0 ? int(num) : int(num) - 1;
>>>
>>>
>>> Cheers
>>> Juan Pablo Califano
>>>
>>>
>>>
>>>
>>> 2008/5/25, laurent <[EMAIL PROTECTED]>:
>>>
>>>
 John Grden wrote a post about many Math optimisations in AS3, you can
 find
 the code to test at home here:

 http://www.rockonflash.com/blog/?p=63

 L

 Juan Pablo Califano a écrit :



> I use modulo for rowing too and int() instead of Math.floor() as it's
>
>
>> faster. ;)
>>
>>
>>
>>
> Laurent,
>
> is it, really?
>
> I'm not sure. I recently made similar assumptions about what's faster
> an
> what's slower based on what "made sense", only to be proved wrong by
> some
> actual benchmarking.
>
> Anyway, if the variable is typed as an int, my understanding is that
> you
> don't need to use Math.floor or a cast to int, since the decimal part
> will
> be truncated automatically.
>
> Another option to discard decimals is to use bit shifting ( i >> 0),
> which
> some people say it's faster. But in the end, how do you know that under
> the
> hood, the flash player is not doing exactly the same operation for an
> int
> cast, a Math.floor call and a shift zero ?
>
> Cheers
> Juan Pablo Califano
>
>

Re: [Flashcoders] Tweening text more smoothly - AS3

[Juan Pablo Califano]

I probably would, if it just were a superb compiler instead of a
nice language (but incompatible at source level with AS) and a superb
compiler ;)

And if I were writting performance-critical suff (which I'm not), I'd
certainly consider using it for building external swf libraries.

Cheers
Juan Pablo Califano



2008/5/25, laurent <[EMAIL PROTECTED]>:
>
> Yes. And you can jump to Haxe ;)
>
> cheers
> L
>
> Juan Pablo Califano a écrit :
>
>> Thanks for the link.
>>
>> It seems clear from the tests that Math.floor *is* slower than casting. It
>> think the implementation posted in the blog has a bug, though. The result
>> of
>> casting to int is the same as using Math.floor as long as the int is
>> positive. But, if the int is negative, the results will be different.
>>
>> function testFloor():void {
>>var num:Number = -1.5;
>>var res:int = Math.floor(num);
>>trace("testFloor:"+res);  // traces -2
>> }
>> function testCast():void {
>>var num:Number = -1.5;
>>var res:int = int(num);
>>trace("testCast:"+res);  // traces -1
>> }
>>
>> Maybe that's the reason why the compiler doesn't replace a call to
>> Math.floor with a simple cast...
>>
>> Anyway, my point is that there are many layers under the actionscript code
>> and the compiler could be making some optimizations you're normally not
>> aware of. I've checked compiling and the decompiling the above functions
>> to
>> the assembly "il" representation (with abcdump). No such optimizations are
>> made, so you're right about this.
>>
>> Nevertheless, I think some optimizations could be done (and maybe will be,
>> some day?) on the compiler, like, for instance, inlining calls to
>> Math.floor
>> with code that would look like this, if it were Actionscript:
>>
>> Math.floor(num);
>>
>> -->
>>
>> num > 0 ? int(num) : int(num) - 1;
>>
>>
>> Cheers
>> Juan Pablo Califano
>>
>>
>>
>>
>> 2008/5/25, laurent <[EMAIL PROTECTED]>:
>>
>>
>>> John Grden wrote a post about many Math optimisations in AS3, you can
>>> find
>>> the code to test at home here:
>>>
>>> http://www.rockonflash.com/blog/?p=63
>>>
>>> L
>>>
>>> Juan Pablo Califano a écrit :
>>>
>>>
>>>
 I use modulo for rowing too and int() instead of Math.floor() as it's


> faster. ;)
>
>
>
>
 Laurent,

 is it, really?

 I'm not sure. I recently made similar assumptions about what's faster an
 what's slower based on what "made sense", only to be proved wrong by
 some
 actual benchmarking.

 Anyway, if the variable is typed as an int, my understanding is that you
 don't need to use Math.floor or a cast to int, since the decimal part
 will
 be truncated automatically.

 Another option to discard decimals is to use bit shifting ( i >> 0),
 which
 some people say it's faster. But in the end, how do you know that under
 the
 hood, the flash player is not doing exactly the same operation for an
 int
 cast, a Math.floor call and a shift zero ?

 Cheers
 Juan Pablo Califano


 2008/5/25, laurent <[EMAIL PROTECTED]>:




> Thanks Jesse for the neat explanation, it all make sense, that's a
> clever
> trick to get a smooth movement of this type where tweening is not a
> solution.
> That can be applied to other things just to get the right value to
> change.
> Very good to know that enter Frame and Timer are approximations.
> I use modulo for rowing too and int() instead of Math.floor() as it's
> faster. ;)
>
> L
>
> Jesse Graupmann a écrit :
>
>
>
>
>
>> @Laurent
>>
>> So modulus is great and slow from what I've read. I tend to use it in
>> row/
>> column calculation rather than wrapping a MovieClip position.
>>
>> var num:int = 6;
>> var cols:int = 3;
>>
>> for ( var i:int = 0; i < num; i++ ) {
>>  var row:int = Math.floor( i / cols );
>>  var col:int = i % cols;
>>
>>  trace ( "i: " + i + "\trow:" + row + "\tcol:" + col );
>> }
>>
>> i: 0row:0   col:0
>> i: 1row:0   col:1
>> i: 2row:0   col:2
>> i: 3row:1   col:0
>> i: 4row:1   col:1
>> i: 5row:1   col:2
>>
>>
>> In the previous post I'm moving a MovieClip to the right X.X pixels
>> and
>> when
>> its position is off the screen I reset it back to 0. If I used the
>> modulus
>> method, the movement would always be rounded numbers and appear
>> jerkier
>> than
>> this experiment requires. I'm actually hoping to round to the nearest
>> twip.
>>
>>
>> As for the examples themselves
>>
>>
>> #1
>> onT is a timer tick. So about every 30ms it will move the MovieClip X
>> pixels
>> based on speed. Because Timers are never accurate to what you expect (
>> they
>> only get as close as they can - see below ) onT will alway

Re: [Flashcoders] Tweening text more smoothly - AS3

[laurent]

Yes. And you can jump to Haxe ;)

cheers
L

Juan Pablo Califano a écrit :

Thanks for the link.

It seems clear from the tests that Math.floor *is* slower than casting. It
think the implementation posted in the blog has a bug, though. The result of
casting to int is the same as using Math.floor as long as the int is
positive. But, if the int is negative, the results will be different.

function testFloor():void {
var num:Number = -1.5;
var res:int = Math.floor(num);
trace("testFloor:"+res);  // traces -2
}
function testCast():void {
var num:Number = -1.5;
var res:int = int(num);
trace("testCast:"+res);  // traces -1
}

Maybe that's the reason why the compiler doesn't replace a call to
Math.floor with a simple cast...

Anyway, my point is that there are many layers under the actionscript code
and the compiler could be making some optimizations you're normally not
aware of. I've checked compiling and the decompiling the above functions to
the assembly "il" representation (with abcdump). No such optimizations are
made, so you're right about this.

Nevertheless, I think some optimizations could be done (and maybe will be,
some day?) on the compiler, like, for instance, inlining calls to Math.floor
with code that would look like this, if it were Actionscript:

Math.floor(num);

-->

num > 0 ? int(num) : int(num) - 1;


Cheers
Juan Pablo Califano




2008/5/25, laurent <[EMAIL PROTECTED]>:
  

John Grden wrote a post about many Math optimisations in AS3, you can find
the code to test at home here:

http://www.rockonflash.com/blog/?p=63

L

Juan Pablo Califano a écrit :



I use modulo for rowing too and int() instead of Math.floor() as it's
  

faster. ;)




Laurent,

is it, really?

I'm not sure. I recently made similar assumptions about what's faster an
what's slower based on what "made sense", only to be proved wrong by some
actual benchmarking.

Anyway, if the variable is typed as an int, my understanding is that you
don't need to use Math.floor or a cast to int, since the decimal part will
be truncated automatically.

Another option to discard decimals is to use bit shifting ( i >> 0), which
some people say it's faster. But in the end, how do you know that under
the
hood, the flash player is not doing exactly the same operation for an int
cast, a Math.floor call and a shift zero ?

Cheers
Juan Pablo Califano


2008/5/25, laurent <[EMAIL PROTECTED]>:


  

Thanks Jesse for the neat explanation, it all make sense, that's a clever
trick to get a smooth movement of this type where tweening is not a
solution.
That can be applied to other things just to get the right value to
change.
Very good to know that enter Frame and Timer are approximations.
I use modulo for rowing too and int() instead of Math.floor() as it's
faster. ;)

L

Jesse Graupmann a écrit :





@Laurent

So modulus is great and slow from what I've read. I tend to use it in
row/
column calculation rather than wrapping a MovieClip position.

var num:int = 6;
var cols:int = 3;

for ( var i:int = 0; i < num; i++ ) {
  var row:int = Math.floor( i / cols );
  var col:int = i % cols;

  trace ( "i: " + i + "\trow:" + row + "\tcol:" + col );
}

i: 0row:0   col:0
i: 1row:0   col:1
i: 2row:0   col:2
i: 3row:1   col:0
i: 4row:1   col:1
i: 5row:1   col:2


In the previous post I'm moving a MovieClip to the right X.X pixels and
when
its position is off the screen I reset it back to 0. If I used the
modulus
method, the movement would always be rounded numbers and appear jerkier
than
this experiment requires. I'm actually hoping to round to the nearest
twip.


As for the examples themselves


#1
onT is a timer tick. So about every 30ms it will move the MovieClip X
pixels
based on speed. Because Timers are never accurate to what you expect (
they
only get as close as they can - see below ) onT will always be dragging
behind the other two methods and moving at varied speeds.

//  Elapsed time from a tick on var t:Timer = new Timer(30);



47,38,36,36,36,36,36,38,36,35,35,36,36,34,36,42,36,35,35,36,35,37,40,36,36,3


6,36,36,54,36,37,35,34,36,38,38,36,36,36,36,69,39,35,36,35,36,36,42,44,36,36


,35,36,35,63,37,33,36,35,37,40,30,35,34,36,92,55,66,35,36,34,36,46,36,36,36,


36,97,50,34,35,35,36,36,34,33,218,142,49,121,59,110,84,102,65,106,66,58,55,6


5,34,36,35,36,64,33,35,36,35,37,31,48,34,36,35,35,36,77,34,34,36,36,36,70,36


,35,37,35,37,74,54,35,36,71,65,35,36,36,35,35,73,37,36,36,34,43,66,35,38,36,


35,34,73,36,34,50,59,67,37,36,36,36,56,47,37,36,36,34,36,30,46,35,36,36,36,5


9,46,35,36,36,36,59,45,35,36,36,34,36,32,48,37,37,35,38,56,48,34,36,36,36,58


,47,34,37,36,36,57,72,45,36,50,55,45,35,35,35,36,61,45,36,35,35,36,66,45,131
,39,45,33,37,34,37,34,45,51,36,51,49,38,67,35,36,36,34,43,47,38,50,35,34

//  Difference from expected 30ms



17,8,6,6,6,6,6,8,6,5,5,6,6,4,6,12,6,5,5,6,5,7,10,6,6,6,6,6,24,6,7,5,4,6,8,8,


6,6,6,6,39,9,5,6,5,6,6,12,14,6,6,5,6,5,33,7

Re: [Flashcoders] Tweening text more smoothly - AS3

[Juan Pablo Califano]

Thanks for the link.

It seems clear from the tests that Math.floor *is* slower than casting. It
think the implementation posted in the blog has a bug, though. The result of
casting to int is the same as using Math.floor as long as the int is
positive. But, if the int is negative, the results will be different.

function testFloor():void {
var num:Number = -1.5;
var res:int = Math.floor(num);
trace("testFloor:"+res);  // traces -2
}
function testCast():void {
var num:Number = -1.5;
var res:int = int(num);
trace("testCast:"+res);  // traces -1
}

Maybe that's the reason why the compiler doesn't replace a call to
Math.floor with a simple cast...

Anyway, my point is that there are many layers under the actionscript code
and the compiler could be making some optimizations you're normally not
aware of. I've checked compiling and the decompiling the above functions to
the assembly "il" representation (with abcdump). No such optimizations are
made, so you're right about this.

Nevertheless, I think some optimizations could be done (and maybe will be,
some day?) on the compiler, like, for instance, inlining calls to Math.floor
with code that would look like this, if it were Actionscript:

Math.floor(num);

-->

num > 0 ? int(num) : int(num) - 1;


Cheers
Juan Pablo Califano




2008/5/25, laurent <[EMAIL PROTECTED]>:
>
> John Grden wrote a post about many Math optimisations in AS3, you can find
> the code to test at home here:
>
> http://www.rockonflash.com/blog/?p=63
>
> L
>
> Juan Pablo Califano a écrit :
>
>> I use modulo for rowing too and int() instead of Math.floor() as it's
>>> faster. ;)
>>>
>>>
>>
>>
>> Laurent,
>>
>> is it, really?
>>
>> I'm not sure. I recently made similar assumptions about what's faster an
>> what's slower based on what "made sense", only to be proved wrong by some
>> actual benchmarking.
>>
>> Anyway, if the variable is typed as an int, my understanding is that you
>> don't need to use Math.floor or a cast to int, since the decimal part will
>> be truncated automatically.
>>
>> Another option to discard decimals is to use bit shifting ( i >> 0), which
>> some people say it's faster. But in the end, how do you know that under
>> the
>> hood, the flash player is not doing exactly the same operation for an int
>> cast, a Math.floor call and a shift zero ?
>>
>> Cheers
>> Juan Pablo Califano
>>
>>
>> 2008/5/25, laurent <[EMAIL PROTECTED]>:
>>
>>
>>> Thanks Jesse for the neat explanation, it all make sense, that's a clever
>>> trick to get a smooth movement of this type where tweening is not a
>>> solution.
>>> That can be applied to other things just to get the right value to
>>> change.
>>> Very good to know that enter Frame and Timer are approximations.
>>> I use modulo for rowing too and int() instead of Math.floor() as it's
>>> faster. ;)
>>>
>>> L
>>>
>>> Jesse Graupmann a écrit :
>>>
>>>
>>>
 @Laurent

 So modulus is great and slow from what I've read. I tend to use it in
 row/
 column calculation rather than wrapping a MovieClip position.

 var num:int = 6;
 var cols:int = 3;

 for ( var i:int = 0; i < num; i++ ) {
   var row:int = Math.floor( i / cols );
   var col:int = i % cols;

   trace ( "i: " + i + "\trow:" + row + "\tcol:" + col );
 }

 i: 0row:0   col:0
 i: 1row:0   col:1
 i: 2row:0   col:2
 i: 3row:1   col:0
 i: 4row:1   col:1
 i: 5row:1   col:2


 In the previous post I'm moving a MovieClip to the right X.X pixels and
 when
 its position is off the screen I reset it back to 0. If I used the
 modulus
 method, the movement would always be rounded numbers and appear jerkier
 than
 this experiment requires. I'm actually hoping to round to the nearest
 twip.


 As for the examples themselves


 #1
 onT is a timer tick. So about every 30ms it will move the MovieClip X
 pixels
 based on speed. Because Timers are never accurate to what you expect (
 they
 only get as close as they can - see below ) onT will always be dragging
 behind the other two methods and moving at varied speeds.

 //  Elapsed time from a tick on var t:Timer = new Timer(30);



 47,38,36,36,36,36,36,38,36,35,35,36,36,34,36,42,36,35,35,36,35,37,40,36,36,3


 6,36,36,54,36,37,35,34,36,38,38,36,36,36,36,69,39,35,36,35,36,36,42,44,36,36


 ,35,36,35,63,37,33,36,35,37,40,30,35,34,36,92,55,66,35,36,34,36,46,36,36,36,


 36,97,50,34,35,35,36,36,34,33,218,142,49,121,59,110,84,102,65,106,66,58,55,6


 5,34,36,35,36,64,33,35,36,35,37,31,48,34,36,35,35,36,77,34,34,36,36,36,70,36


 ,35,37,35,37,74,54,35,36,71,65,35,36,36,35,35,73,37,36,36,34,43,66,35,38,36,


 35,34,73,36,34,50,59,67,37,36,36,36,56,47,37,36,36,34,36,30,46,35,36,36,36,5


 9,46,35,36,36,36,59,45,35,36,36,3

Re: [Flashcoders] Tweening text more smoothly - AS3

[EECOLOR]

>But in the end, how do you know that under the
>hood, the flash player is not doing exactly the same operation for an int
>cast, a Math.floor call and a shift zero ?

Well, the thing here is that Math.floor is a function call. Function calls
are by default more complex than using operators. This would explain why
Math.floor is heavier than any other way of doing it.


Greetz Erik


On 5/25/08, Juan Pablo Califano <[EMAIL PROTECTED]> wrote:
>
> >
> > I use modulo for rowing too and int() instead of Math.floor() as it's
> > faster. ;)
>
>
>
> Laurent,
>
> is it, really?
>
> I'm not sure. I recently made similar assumptions about what's faster an
> what's slower based on what "made sense", only to be proved wrong by some
> actual benchmarking.
>
> Anyway, if the variable is typed as an int, my understanding is that you
> don't need to use Math.floor or a cast to int, since the decimal part will
> be truncated automatically.
>
> Another option to discard decimals is to use bit shifting ( i >> 0), which
> some people say it's faster. But in the end, how do you know that under the
> hood, the flash player is not doing exactly the same operation for an int
> cast, a Math.floor call and a shift zero ?
>
> Cheers
> Juan Pablo Califano
>
>
> 2008/5/25, laurent <[EMAIL PROTECTED]>:
>
> >
> > Thanks Jesse for the neat explanation, it all make sense, that's a clever
> > trick to get a smooth movement of this type where tweening is not a
> > solution.
> > That can be applied to other things just to get the right value to
> change.
> > Very good to know that enter Frame and Timer are approximations.
> > I use modulo for rowing too and int() instead of Math.floor() as it's
> > faster. ;)
> >
> > L
> >
> > Jesse Graupmann a écrit :
> >
> >> @Laurent
> >>
> >> So modulus is great and slow from what I've read. I tend to use it in
> row/
> >> column calculation rather than wrapping a MovieClip position.
> >>
> >> var num:int = 6;
> >> var cols:int = 3;
> >>
> >> for ( var i:int = 0; i < num; i++ ) {
> >>var row:int = Math.floor( i / cols );
> >>var col:int = i % cols;
> >>
> >>trace ( "i: " + i + "\trow:" + row + "\tcol:" + col );
> >> }
> >>
> >> i: 0row:0   col:0
> >> i: 1row:0   col:1
> >> i: 2row:0   col:2
> >> i: 3row:1   col:0
> >> i: 4row:1   col:1
> >> i: 5row:1   col:2
> >>
> >>
> >> In the previous post I'm moving a MovieClip to the right X.X pixels and
> >> when
> >> its position is off the screen I reset it back to 0. If I used the
> modulus
> >> method, the movement would always be rounded numbers and appear jerkier
> >> than
> >> this experiment requires. I'm actually hoping to round to the nearest
> >> twip.
> >>
> >>
> >> As for the examples themselves
> >>
> >>
> >> #1
> >> onT is a timer tick. So about every 30ms it will move the MovieClip X
> >> pixels
> >> based on speed. Because Timers are never accurate to what you expect (
> >> they
> >> only get as close as they can - see below ) onT will always be dragging
> >> behind the other two methods and moving at varied speeds.
> >>
> >> //  Elapsed time from a tick on var t:Timer = new Timer(30);
> >>
> >>
> >>
> 47,38,36,36,36,36,36,38,36,35,35,36,36,34,36,42,36,35,35,36,35,37,40,36,36,3
> >>
> >>
> 6,36,36,54,36,37,35,34,36,38,38,36,36,36,36,69,39,35,36,35,36,36,42,44,36,36
> >>
> >>
> ,35,36,35,63,37,33,36,35,37,40,30,35,34,36,92,55,66,35,36,34,36,46,36,36,36,
> >>
> >>
> 36,97,50,34,35,35,36,36,34,33,218,142,49,121,59,110,84,102,65,106,66,58,55,6
> >>
> >>
> 5,34,36,35,36,64,33,35,36,35,37,31,48,34,36,35,35,36,77,34,34,36,36,36,70,36
> >>
> >>
> ,35,37,35,37,74,54,35,36,71,65,35,36,36,35,35,73,37,36,36,34,43,66,35,38,36,
> >>
> >>
> 35,34,73,36,34,50,59,67,37,36,36,36,56,47,37,36,36,34,36,30,46,35,36,36,36,5
> >>
> >>
> 9,46,35,36,36,36,59,45,35,36,36,34,36,32,48,37,37,35,38,56,48,34,36,36,36,58
> >>
> >>
> ,47,34,37,36,36,57,72,45,36,50,55,45,35,35,35,36,61,45,36,35,35,36,66,45,131
> >> ,39,45,33,37,34,37,34,45,51,36,51,49,38,67,35,36,36,34,43,47,38,50,35,34
> >>
> >> //  Difference from expected 30ms
> >>
> >>
> >>
> 17,8,6,6,6,6,6,8,6,5,5,6,6,4,6,12,6,5,5,6,5,7,10,6,6,6,6,6,24,6,7,5,4,6,8,8,
> >>
> >>
> 6,6,6,6,39,9,5,6,5,6,6,12,14,6,6,5,6,5,33,7,3,6,5,7,10,0,5,4,6,62,25,36,5,6,
> >>
> >>
> 4,6,16,6,6,6,6,67,20,4,5,5,6,6,4,3,188,112,19,91,29,80,54,72,35,76,36,28,25,
> >>
> >>
> 35,4,6,5,6,34,3,5,6,5,7,1,18,4,6,5,5,6,47,4,4,6,6,6,40,6,5,7,5,7,44,24,5,6,4
> >>
> >>
> 1,35,5,6,6,5,5,43,7,6,6,4,13,36,5,8,6,5,4,43,6,4,20,29,37,7,6,6,6,26,17,7,6,
> >>
> >>
> 6,4,6,0,16,5,6,6,6,29,16,5,6,6,6,29,15,5,6,6,4,6,2,18,7,7,5,8,26,18,4,6,6,6,
> >>
> >>
> 28,17,4,7,6,6,27,42,15,6,20,25,15,5,5,5,6,31,15,6,5,5,6,36,15,101,9,15,3,7,4
> >> ,7,4,15,21,6,21,19,8,37,5,6,6,4,13,17,8,20,5,4
> >>
> >>
> >> #2
> >> onT2 - To compensate for the difference, I decide that for every 30ms
> that
> >> have passed the MovieClip should increment the correct amount ( 1 pixel
> ).
> >> When the tick occurs, I subtract the stored 

Re: [Flashcoders] Tweening text more smoothly - AS3

[laurent]

John Grden wrote a post about many Math optimisations in AS3, you can 
find the code to test at home here:


http://www.rockonflash.com/blog/?p=63

L

Juan Pablo Califano a écrit :

I use modulo for rowing too and int() instead of Math.floor() as it's
faster. ;)




Laurent,

is it, really?

I'm not sure. I recently made similar assumptions about what's faster an
what's slower based on what "made sense", only to be proved wrong by some
actual benchmarking.

Anyway, if the variable is typed as an int, my understanding is that you
don't need to use Math.floor or a cast to int, since the decimal part will
be truncated automatically.

Another option to discard decimals is to use bit shifting ( i >> 0), which
some people say it's faster. But in the end, how do you know that under the
hood, the flash player is not doing exactly the same operation for an int
cast, a Math.floor call and a shift zero ?

Cheers
Juan Pablo Califano


2008/5/25, laurent <[EMAIL PROTECTED]>:
  

Thanks Jesse for the neat explanation, it all make sense, that's a clever
trick to get a smooth movement of this type where tweening is not a
solution.
That can be applied to other things just to get the right value to change.
Very good to know that enter Frame and Timer are approximations.
I use modulo for rowing too and int() instead of Math.floor() as it's
faster. ;)

L

Jesse Graupmann a écrit :



@Laurent

So modulus is great and slow from what I've read. I tend to use it in row/
column calculation rather than wrapping a MovieClip position.

var num:int = 6;
var cols:int = 3;

for ( var i:int = 0; i < num; i++ ) {
   var row:int = Math.floor( i / cols );
   var col:int = i % cols;

   trace ( "i: " + i + "\trow:" + row + "\tcol:" + col );
}

i: 0row:0   col:0
i: 1row:0   col:1
i: 2row:0   col:2
i: 3row:1   col:0
i: 4row:1   col:1
i: 5row:1   col:2


In the previous post I'm moving a MovieClip to the right X.X pixels and
when
its position is off the screen I reset it back to 0. If I used the modulus
method, the movement would always be rounded numbers and appear jerkier
than
this experiment requires. I'm actually hoping to round to the nearest
twip.


As for the examples themselves


#1
onT is a timer tick. So about every 30ms it will move the MovieClip X
pixels
based on speed. Because Timers are never accurate to what you expect (
they
only get as close as they can - see below ) onT will always be dragging
behind the other two methods and moving at varied speeds.

//  Elapsed time from a tick on var t:Timer = new Timer(30);


47,38,36,36,36,36,36,38,36,35,35,36,36,34,36,42,36,35,35,36,35,37,40,36,36,3

6,36,36,54,36,37,35,34,36,38,38,36,36,36,36,69,39,35,36,35,36,36,42,44,36,36

,35,36,35,63,37,33,36,35,37,40,30,35,34,36,92,55,66,35,36,34,36,46,36,36,36,

36,97,50,34,35,35,36,36,34,33,218,142,49,121,59,110,84,102,65,106,66,58,55,6

5,34,36,35,36,64,33,35,36,35,37,31,48,34,36,35,35,36,77,34,34,36,36,36,70,36

,35,37,35,37,74,54,35,36,71,65,35,36,36,35,35,73,37,36,36,34,43,66,35,38,36,

35,34,73,36,34,50,59,67,37,36,36,36,56,47,37,36,36,34,36,30,46,35,36,36,36,5

9,46,35,36,36,36,59,45,35,36,36,34,36,32,48,37,37,35,38,56,48,34,36,36,36,58

,47,34,37,36,36,57,72,45,36,50,55,45,35,35,35,36,61,45,36,35,35,36,66,45,131
,39,45,33,37,34,37,34,45,51,36,51,49,38,67,35,36,36,34,43,47,38,50,35,34

//  Difference from expected 30ms


17,8,6,6,6,6,6,8,6,5,5,6,6,4,6,12,6,5,5,6,5,7,10,6,6,6,6,6,24,6,7,5,4,6,8,8,

6,6,6,6,39,9,5,6,5,6,6,12,14,6,6,5,6,5,33,7,3,6,5,7,10,0,5,4,6,62,25,36,5,6,

4,6,16,6,6,6,6,67,20,4,5,5,6,6,4,3,188,112,19,91,29,80,54,72,35,76,36,28,25,

35,4,6,5,6,34,3,5,6,5,7,1,18,4,6,5,5,6,47,4,4,6,6,6,40,6,5,7,5,7,44,24,5,6,4

1,35,5,6,6,5,5,43,7,6,6,4,13,36,5,8,6,5,4,43,6,4,20,29,37,7,6,6,6,26,17,7,6,

6,4,6,0,16,5,6,6,6,29,16,5,6,6,6,29,15,5,6,6,4,6,2,18,7,7,5,8,26,18,4,6,6,6,

28,17,4,7,6,6,27,42,15,6,20,25,15,5,5,5,6,31,15,6,5,5,6,36,15,101,9,15,3,7,4
,7,4,15,21,6,21,19,8,37,5,6,6,4,13,17,8,20,5,4


#2
onT2 - To compensate for the difference, I decide that for every 30ms that
have passed the MovieClip should increment the correct amount ( 1 pixel ).
When the tick occurs, I subtract the stored time (lastTick2) from the
current time giving me the most accurate elapsed time. Dividing by the
tick
time gives me a percentage of my expected elapsed time. Multiplying that
value by the speed produces the most accurate change over time.

#3
onT3 - Because I can assume speed based on elapsed time is the most
accurate, it won't matter when I call the function as long as it happens
once per frame. So onT3 just uses the ENTER_FRAME event to calculate speed
based on elapsed time using lastTick3.

Here is another example that is commented a bit better and should make all
this very apparent.

stage.align = "TL";
stage.scaleMode = "noScale";
stage.addEventListener ( Event.ENTER_FRAME, onFrame );

//  for every (stepTime)ms move (stepRate)pixels
var stepTime:int = 30; var stepRate:int = 1;
var 

Re: [Flashcoders] Tweening text more smoothly - AS3

[Juan Pablo Califano]

>
> I use modulo for rowing too and int() instead of Math.floor() as it's
> faster. ;)


Laurent,

is it, really?

I'm not sure. I recently made similar assumptions about what's faster an
what's slower based on what "made sense", only to be proved wrong by some
actual benchmarking.

Anyway, if the variable is typed as an int, my understanding is that you
don't need to use Math.floor or a cast to int, since the decimal part will
be truncated automatically.

Another option to discard decimals is to use bit shifting ( i >> 0), which
some people say it's faster. But in the end, how do you know that under the
hood, the flash player is not doing exactly the same operation for an int
cast, a Math.floor call and a shift zero ?

Cheers
Juan Pablo Califano


2008/5/25, laurent <[EMAIL PROTECTED]>:
>
> Thanks Jesse for the neat explanation, it all make sense, that's a clever
> trick to get a smooth movement of this type where tweening is not a
> solution.
> That can be applied to other things just to get the right value to change.
> Very good to know that enter Frame and Timer are approximations.
> I use modulo for rowing too and int() instead of Math.floor() as it's
> faster. ;)
>
> L
>
> Jesse Graupmann a écrit :
>
>> @Laurent
>>
>> So modulus is great and slow from what I've read. I tend to use it in row/
>> column calculation rather than wrapping a MovieClip position.
>>
>> var num:int = 6;
>> var cols:int = 3;
>>
>> for ( var i:int = 0; i < num; i++ ) {
>>var row:int = Math.floor( i / cols );
>>var col:int = i % cols;
>>
>>trace ( "i: " + i + "\trow:" + row + "\tcol:" + col );
>> }
>>
>> i: 0row:0   col:0
>> i: 1row:0   col:1
>> i: 2row:0   col:2
>> i: 3row:1   col:0
>> i: 4row:1   col:1
>> i: 5row:1   col:2
>>
>>
>> In the previous post I'm moving a MovieClip to the right X.X pixels and
>> when
>> its position is off the screen I reset it back to 0. If I used the modulus
>> method, the movement would always be rounded numbers and appear jerkier
>> than
>> this experiment requires. I'm actually hoping to round to the nearest
>> twip.
>>
>>
>> As for the examples themselves
>>
>>
>> #1
>> onT is a timer tick. So about every 30ms it will move the MovieClip X
>> pixels
>> based on speed. Because Timers are never accurate to what you expect (
>> they
>> only get as close as they can - see below ) onT will always be dragging
>> behind the other two methods and moving at varied speeds.
>>
>> //  Elapsed time from a tick on var t:Timer = new Timer(30);
>>
>>
>> 47,38,36,36,36,36,36,38,36,35,35,36,36,34,36,42,36,35,35,36,35,37,40,36,36,3
>>
>> 6,36,36,54,36,37,35,34,36,38,38,36,36,36,36,69,39,35,36,35,36,36,42,44,36,36
>>
>> ,35,36,35,63,37,33,36,35,37,40,30,35,34,36,92,55,66,35,36,34,36,46,36,36,36,
>>
>> 36,97,50,34,35,35,36,36,34,33,218,142,49,121,59,110,84,102,65,106,66,58,55,6
>>
>> 5,34,36,35,36,64,33,35,36,35,37,31,48,34,36,35,35,36,77,34,34,36,36,36,70,36
>>
>> ,35,37,35,37,74,54,35,36,71,65,35,36,36,35,35,73,37,36,36,34,43,66,35,38,36,
>>
>> 35,34,73,36,34,50,59,67,37,36,36,36,56,47,37,36,36,34,36,30,46,35,36,36,36,5
>>
>> 9,46,35,36,36,36,59,45,35,36,36,34,36,32,48,37,37,35,38,56,48,34,36,36,36,58
>>
>> ,47,34,37,36,36,57,72,45,36,50,55,45,35,35,35,36,61,45,36,35,35,36,66,45,131
>> ,39,45,33,37,34,37,34,45,51,36,51,49,38,67,35,36,36,34,43,47,38,50,35,34
>>
>> //  Difference from expected 30ms
>>
>>
>> 17,8,6,6,6,6,6,8,6,5,5,6,6,4,6,12,6,5,5,6,5,7,10,6,6,6,6,6,24,6,7,5,4,6,8,8,
>>
>> 6,6,6,6,39,9,5,6,5,6,6,12,14,6,6,5,6,5,33,7,3,6,5,7,10,0,5,4,6,62,25,36,5,6,
>>
>> 4,6,16,6,6,6,6,67,20,4,5,5,6,6,4,3,188,112,19,91,29,80,54,72,35,76,36,28,25,
>>
>> 35,4,6,5,6,34,3,5,6,5,7,1,18,4,6,5,5,6,47,4,4,6,6,6,40,6,5,7,5,7,44,24,5,6,4
>>
>> 1,35,5,6,6,5,5,43,7,6,6,4,13,36,5,8,6,5,4,43,6,4,20,29,37,7,6,6,6,26,17,7,6,
>>
>> 6,4,6,0,16,5,6,6,6,29,16,5,6,6,6,29,15,5,6,6,4,6,2,18,7,7,5,8,26,18,4,6,6,6,
>>
>> 28,17,4,7,6,6,27,42,15,6,20,25,15,5,5,5,6,31,15,6,5,5,6,36,15,101,9,15,3,7,4
>> ,7,4,15,21,6,21,19,8,37,5,6,6,4,13,17,8,20,5,4
>>
>>
>> #2
>> onT2 - To compensate for the difference, I decide that for every 30ms that
>> have passed the MovieClip should increment the correct amount ( 1 pixel ).
>> When the tick occurs, I subtract the stored time (lastTick2) from the
>> current time giving me the most accurate elapsed time. Dividing by the
>> tick
>> time gives me a percentage of my expected elapsed time. Multiplying that
>> value by the speed produces the most accurate change over time.
>>
>> #3
>> onT3 - Because I can assume speed based on elapsed time is the most
>> accurate, it won't matter when I call the function as long as it happens
>> once per frame. So onT3 just uses the ENTER_FRAME event to calculate speed
>> based on elapsed time using lastTick3.
>>
>> Here is another example that is commented a bit better and should make all
>> this very apparent.
>>
>> stage.align = "TL";
>> stage.scaleMode = "noScale";
>> stage.addEventListener ( Event.ENTER_FRAME, onFr

Re: [Flashcoders] Tweening text more smoothly - AS3

[Pedro Kostelec]

Ther is something that i don't like here. Sorry for changing the subject.
It's the Zoom in /Zoom out
When i click zoom in it works but it doesn't de-zoom when you click Zo0om
out.

Does someone know why is that so?

On Thu, May 22, 2008 at 11:57 AM, Vayu Robins <[EMAIL PROTECTED]> wrote:

> Hej.
>
> I am wondering if there is anything that could be done to improve the
> panning/scrolling/tweening of the news items at the bottom of the this
> page:
>
> http://flashkompagniet.dk/flash/main.php
>
> I am running a timer at 20 milliseconds Timer(20, 0);
>
> And the news items are being moved a 1px everytime the timer event is
> dispatched.
>
> I dont think they are runnning very smoothly.  Is that just me or does
> anyone else see that too.
>
> Can anything be done?
>
> Thanks
> Vayu
>
>
> ___
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>



-- 
Pedro D.K.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] preventing client spoofing with SWFs

[Juan Pablo Califano]

Ghost,

Though I think in many situations there's not really a way to make an
app/game 100% spoof-proof, there are some things you can do to make it
harder on the spoofer. Most of them rely on putting some extra logic on the
server-side and/or moving some client-side logic to the server, when
possible.

1) Always use server-side sessions.
That way, if I download your swf, modifiy it and try to post data, you
can detect that I don't have a valid session and not save the date I've
sent.
There are ways to circumvent server sessions, since the client is
involved in the session mechanism (the data that allows the server to
identify a client is partially held by the client), and with tabbed browsers
you can navigate to the original page to get a valid session, then open a
new tab and use any of the plugins available in Firefox, for instance, to
post data to the server with a valid session.

2) In some cases, you can move the logic that assigns points from the client
to the server. For instance, in a trivia.

Instead of loading from the server something like:






Use something like this:






That way, you just inform the server that the user has picked the option
whose id is, say, 7, for the question 2, instead of telling it that the
user's answer was right or wrong. The server will determine whether that's
correct or not and assign points accordingly.

2) Use "unique handlers" (UH) each time you send some data to the database.
Before starting the game (or a level in the game), make a call to the
server and have it return to the swf a unique handler that will identify
that particular "transaction". A GUID (http://en.wikipedia.org/wiki/Guid)
can be a good option, since most databases implement it.
When you save data (for instance, the score), pass the unique handler
too, so the server can do some validation. That forces the spoofer to add a
new step to their "process".

3) Save the time of each "transaction"
This can be used in combination with unique handlers. You save in your
DD.BB. the time when the "unique handler" was asked by the swf and save the
time when the actual data was sent. That allows some auditing if there are
prices involved. For example, if you know it's not possible to complete the
level 1 of your game in less than 60 seconds and the time diff between the
UH request and the actual data post is, say 10 seconds, you know the data
has been spoofed (or you have a bug in your game...)

A couple of months ago, at work, we put online a trivia. There was a
total of 75 questions stored in the database, and server randomly picked 5
of them to send to the client, one at the time (each question had 5 possible
answers). Once the swf posted the option picked by the user, the server
would check if it was valid and would respond back accordingly, to inform
the user of the result. The number of correct answers was the first
criterion to determine the winner, and the total time used to complete the
trivia was used in case of a tie.
At some point we noticed that there were a couple of users that had
"too" perfect scores, so we made an "informal" audit. Googling some of the
registered names (A real name plus some real ID was required to collect the
prices). We found that one of these names appeared in a page about a robot /
automata course in an Argentinian university.
Apparently the guy built a "robot" (some automated set of scripts?) that
would "play", just for "data mining", so to speak. Our guess is that it
called the server, saved the xml with each question, and systematically
posted each answer looking for the correct one. At some point, he had
replicated the "questions" and "answers" tables from our database, so he
knew in advance all the correct answers (and you just can't lose if you know
that!). Once he got to that point, he created a legit user with his real
name, an answered the trivia without errors. The problem was the time it
took him... Comparing the time at which the xml with the questions was
returned by the server with the time the answers were posted, it was obvious
that the player was not human (There's no way anyone can read a question,
choose the correct answer and click send in 50 ms or even less...).
So, we were able to invalidate the user because we were saving a
timestamp for each request. Anyway, if he hadn't been so greedy and had put
some time delay between each answer, using timestamps wouldn't have been
enough. But the point is that by using them, you're adding an extra layer of
"protection". It's not perfect, and it's not guaranteed to prevent spoofing,
but it helps.

4) Use some form of encryption for sensitive data
Again, this only adds complexity, but it doesn't make your app
"unspoofable". The idea is avoid sending data such as scores in plain text.
Instead, encrypt or cipher it in some way.
Even a simple xor encryption can help. (
http://www.google.com/sea

Re: [Flashcoders] Tweening text more smoothly - AS3

[laurent]

Thanks Jesse for the neat explanation, it all make sense, that's a 
clever trick to get a smooth movement of this type where tweening is not 
a solution.
That can be applied to other things just to get the right value to 
change. Very good to know that enter Frame and Timer are approximations.
I use modulo for rowing too and int() instead of Math.floor() as it's 
faster. ;)


L

Jesse Graupmann a écrit :

@Laurent

So modulus is great and slow from what I've read. I tend to use it in row/
column calculation rather than wrapping a MovieClip position.

var num:int = 6;
var cols:int = 3;

for ( var i:int = 0; i < num; i++ ) 
{

var row:int = Math.floor( i / cols );
var col:int = i % cols;

trace ( "i: " + i + "\trow:" + row + "\tcol:" + col );
}

i: 0row:0   col:0
i: 1row:0   col:1
i: 2row:0   col:2
i: 3row:1   col:0
i: 4row:1   col:1
i: 5row:1   col:2


In the previous post I'm moving a MovieClip to the right X.X pixels and when
its position is off the screen I reset it back to 0. If I used the modulus
method, the movement would always be rounded numbers and appear jerkier than
this experiment requires. I'm actually hoping to round to the nearest twip.


As for the examples themselves


#1
onT is a timer tick. So about every 30ms it will move the MovieClip X pixels
based on speed. Because Timers are never accurate to what you expect ( they
only get as close as they can - see below ) onT will always be dragging
behind the other two methods and moving at varied speeds. 



//  Elapsed time from a tick on var t:Timer = new Timer(30);

47,38,36,36,36,36,36,38,36,35,35,36,36,34,36,42,36,35,35,36,35,37,40,36,36,3
6,36,36,54,36,37,35,34,36,38,38,36,36,36,36,69,39,35,36,35,36,36,42,44,36,36
,35,36,35,63,37,33,36,35,37,40,30,35,34,36,92,55,66,35,36,34,36,46,36,36,36,
36,97,50,34,35,35,36,36,34,33,218,142,49,121,59,110,84,102,65,106,66,58,55,6
5,34,36,35,36,64,33,35,36,35,37,31,48,34,36,35,35,36,77,34,34,36,36,36,70,36
,35,37,35,37,74,54,35,36,71,65,35,36,36,35,35,73,37,36,36,34,43,66,35,38,36,
35,34,73,36,34,50,59,67,37,36,36,36,56,47,37,36,36,34,36,30,46,35,36,36,36,5
9,46,35,36,36,36,59,45,35,36,36,34,36,32,48,37,37,35,38,56,48,34,36,36,36,58
,47,34,37,36,36,57,72,45,36,50,55,45,35,35,35,36,61,45,36,35,35,36,66,45,131
,39,45,33,37,34,37,34,45,51,36,51,49,38,67,35,36,36,34,43,47,38,50,35,34

//  Difference from expected 30ms

17,8,6,6,6,6,6,8,6,5,5,6,6,4,6,12,6,5,5,6,5,7,10,6,6,6,6,6,24,6,7,5,4,6,8,8,
6,6,6,6,39,9,5,6,5,6,6,12,14,6,6,5,6,5,33,7,3,6,5,7,10,0,5,4,6,62,25,36,5,6,
4,6,16,6,6,6,6,67,20,4,5,5,6,6,4,3,188,112,19,91,29,80,54,72,35,76,36,28,25,
35,4,6,5,6,34,3,5,6,5,7,1,18,4,6,5,5,6,47,4,4,6,6,6,40,6,5,7,5,7,44,24,5,6,4
1,35,5,6,6,5,5,43,7,6,6,4,13,36,5,8,6,5,4,43,6,4,20,29,37,7,6,6,6,26,17,7,6,
6,4,6,0,16,5,6,6,6,29,16,5,6,6,6,29,15,5,6,6,4,6,2,18,7,7,5,8,26,18,4,6,6,6,
28,17,4,7,6,6,27,42,15,6,20,25,15,5,5,5,6,31,15,6,5,5,6,36,15,101,9,15,3,7,4
,7,4,15,21,6,21,19,8,37,5,6,6,4,13,17,8,20,5,4


#2
onT2 - To compensate for the difference, I decide that for every 30ms that
have passed the MovieClip should increment the correct amount ( 1 pixel ).
When the tick occurs, I subtract the stored time (lastTick2) from the
current time giving me the most accurate elapsed time. Dividing by the tick
time gives me a percentage of my expected elapsed time. Multiplying that
value by the speed produces the most accurate change over time.

#3
onT3 - Because I can assume speed based on elapsed time is the most
accurate, it won't matter when I call the function as long as it happens
once per frame. So onT3 just uses the ENTER_FRAME event to calculate speed
based on elapsed time using lastTick3.

Here is another example that is commented a bit better and should make all
this very apparent.

stage.align = "TL";
stage.scaleMode = "noScale";
stage.addEventListener ( Event.ENTER_FRAME, onFrame );

//  for every (stepTime)ms move (stepRate)pixels
var stepTime:int = 30; 
var stepRate:int = 1;

var time:int = getTimer();

function onFrame ( e:Event ):void 
{

//  time since last frame
var elapsedTime:int = getTimer() - time;

//  store current time for the next check
time = getTimer();

//  percentage of expected time
var timePercentage:Number = elapsedTime / stepTime;

//  rate compensation
var movement:Number = timePercentage * stepRate;

//  move mc
mc.x += movement;

//  wrap if off the stage
if ( mc.x > stage.stageWidth ) mc.x = 0;
}


Hasta!
Jesse


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of laurent
Sent: Saturday, May 24, 2008 2:13 AM
To: Flash Coders List
Subject: Re: [Flashcoders] Tweening text more smoothly - AS3


:) I just read about wraping using modulus on Grant Skinner's blog:

sprite.x = (sprite.x + 5) % stage.stageWidth;

And then get where was

[Flashcoders] test 123..ignore

[artur]

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

[Flashcoders] preventing client spoofing with SWFs

[ghost]

Hi all.

Anyone know a solution for preventing client spoofing for sending data  
with flash apps?


Like say with sending high scores for a flash game?

Let's say you have a flash game. Someone decompiles the SWF, (and  
grabs all the relevant SWFs in case you were using loader shell SWFs),  
extracts the url to send the scores to, then creates a flash app to  
mimic yours just for sending fake scores (now that he/she knows the  
proper variables & values to send after having decompiled your SWF and  
had a thorough look at your algorithms).


How does one prevent client spoofing? (building a fake app that will  
pretend to be legit and send illegal data)


Let's say a PHP or ASP file receives the scores from your flash game.

Is there any way to authenticate that the scores are coming from a legit app?

http referrer doesn't seem to be working properly with Flash.

Any help is much appreciated.

Regards,

-Naz
http://www.object404.com

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] Blank flash problem...

[Rich Shupe]

I forgot to mention this. This always happens on every browser, and there's
a very easy fix.

The CSS is set to visible, and JavaScript (SWFObject) makes it invisible.
just reverse these conditions. Make flashcontent hidden to start and, upon
SWFObject failing to detect Flash, et the div to visible.


On 5/25/08 8:56 AM, "Fabio Pinatti" wrote:

> except for the beginning of application, that
> shows a quick screen with some content, and disappears quickly, to a black
> screen until the full loading..

Rich
http://www.LearningActionScript3.com


___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] Blank flash problem...

[Fabio Pinatti]

On Thu, May 22, 2008 at 6:51 AM, Glen Pike <[EMAIL PROTECTED]>
wrote:

> Hi,
>
>   I have a live site where a friend of mine just sees a black page - the
> Flash is written in with SWFObject, but after this nothing happens and he
> sees a black screen - the movie bg colour is #00
>
>   http://www.sas.org.uk/education/sos/
>
>   This is in Win XP - Firefox 2.0.0.14 with the latest release of Flash
> Player 9.0.124.0 - it also happened with an older version 9.0.45.0(Debug), 
> but we upgraded to try and discover the source of the problem.
>
>   The site works fine in IE on his machine and a mirror of the site on
> another domain works fine in FF.  All the files are local to the site, so no
> cross-domain issues here.
>
>   So the question is, do any of you have the same setup as above Win/FF
> 2.0.0.14 FP > 8 and if you visit the URL do any of you just get a blank
> screen?
>   Or, do any of you have any suggestions as to what to look for?
>
>   If it works, you will get "TV" which loads a cartoon guy, etc. etc.
>
>   Thanks in advance.
>
>   Glen.
> --
>
> Glen Pike
> 01326 218440
> www.glenpike.co.uk 
>
> ___
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>

Firefox 2.0.0.14, loads fine, except for the beginning of application, that
shows a quick screen with some content, and disappears quickly, to a black
screen until the full loading.. maybe a main preloader fixes your problem.

Cheers!

-- 
Fábio Pinatti
:: web.developer
 www.pinatti.com.br
:: 19. 9184.3745 / 3342.1130
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders