Hey Guys,
Jeg sidder og undre mig lidt over, hvordan jeg kan udregne et objekts fart.
F.eks. hvis jeg har en tekst box med scrollbar tilknyttet og gerne vil have at den skal blur'e når jeg scroller med en hvis fart, hvordan kan jeg så udregne den fart?
(Jeg prøve noget med at tag objektets y værdig og gemme det, og så tage den igen og minusse de to fra hinanden, men det synes jeg ikke fungerede optimalt.. Jeg brugte enterframe til at fange de to værdier)
Og så et extra spørgsmål om, hvordan man får den bedste virkelighedstro blur effekt?
Mvh David // Programmere i AS3 ..
12 kommentarer
jeg vil våge at påstå at den eneste og mest præcise måde at gøre det på er at regne distance ud mellem før og nu koordinater og så gange med fps så har du pixels i sekundet -
ENTER_FRAME er lidt problematisk, da det kommer an på om computeren kan trække de givne frame du har sat pr. sekund.
Istedet brug en timer:
var dinTimer:Timer = new Timer(1000);
var lastX:Number = 0;
dinTimer.addEventListener(TimerEvent.TICK, checkSpeed);
dinTimer.start();
function checkSpeed(e:TimerEvent):void {
// Der er en indbygget Math funktion for altid at give en plus værdi, kan den dog ikke lige i hovedet
trace("Pixels pr. sekund: " + Number(mc.x - lastX));
lastX = mc.x;
}
Enig med Daugaard, brug en Timer.
men så checker han jo kun 1x i sekundet med timer(1000) - objectet vil alligvel flytte sig hver frame så den mest precis vil være ENTER_FRAME - om man checker 1000x i sekundet eller 1x i sekundet så vil man allivel kun få informationer om object hver ENTER_FRAME når de blir flyttet i render
hvis jeg sætter en timer til at spørge hva distance er mellem nu og sidste frame lad os sige 1000x i sekundet så vil den give dig 41x den samme værdi i tilfælde af jeg bruger 24 fps
Lige præcis - et objekt farts er jo netop hvor hurtigt objektet bevæger sig på skærmen,
og ikke hvor hurtigt ligningen bagved er.
Hvis du tager en lineal op foran skærmen vil du få en forskellig fartværdi alt efter fps,
og ikke hvor mange pixels pr sekund objektet bevæger sig i.
Så egentlig er frames helt irrelavant, og er egentlig bare en ekstra ugyldig faktor, som gør resultet mere upræcist.
Hvis det skal være meget præcist og du vil undgå det "lag" der kan opstå med EnterFrame og Timer så skal du bruge: getTimer() istedet.
Mvh. Ricki
AS1 < AS2 < AS3
ja men jeg tror ik i forstå hva jeg skriver om det lagger eller ej så blir værdierne kun opdateret hver ENTER_FRAME - hvis i bruger timer er eller get timer som ricki rigtigt nok siger er den eneste timer i flash som ikke er affektet af lag
så vil i få et output der ser sådan her ud
41
41
41
41
41
41
41
41
41
41
41
41
41
25
25
25
25
25
25
25
25
25
25
25
25
25
fordi i forsøger at efterspørge en data som ikke blir opdatere før næste frame render - det er useless at bruge noget hurtigere end ENTER_FRAME
ENTER_FRAME er totalt irrelevant medmindre den har et fast framerate, og det kan den aldrig have det det kommer an på computerens hastighed og hvor meget den kan trække - vi snakker jo pixels pr sekund - hvis det var pixels pr. frame kunne den bruges - simpel matematik ..
Umiddelbart så lyder det som overkill med andet end ENTER_FRAME, skulle scrollbaren så blur' lidt for ofte så går det nok.
Jeg mente getTimer() på mission critical måden.
noget ligende:
while(true)
{
if(getTimer() % 4 == 0)
{
opdater rumraket
}
}
hvis du kører med 30 fps så får du optimalt en sampling rate på ≈ 33 ms. skulle alt lagge, så vil scrollbaren jo også lagge og det vil nærmest udligne hinanden.
Lav en test og se om du kan trække så hurtigt i scrollbaren at du ikke kan fange dine samples med de 30 fps.
Hvis du ikke kan så er det jo mere end nok med 30-40 fps, hvis du kan så kan du begynde at overveje getTimer() og smøre VM'en i kylligeblod.
Mvh. Ricki
AS1 < AS2 < AS3
Jamen, helt sikkert - så ville getTimer() optimeringsmæssigt være hurtigere - men samtidig har man jo så mulighed for at lave en handling ved behov med Timer, og så meget mere krævende er TimerEvent ikke i forhold til ENTER_FRAME
Øhh hvis en "almindelig timer" skal bruges for at give en højere opløsning end enterFrame så vil den trække lige så meget.
Jeg mener, hvis du sætter en timer op til at skyde hver 30 ms. så giver det jo hverken flere eller færre events der skal fanges end en fps på 30 og en enterframe listener.
Der er lavet benchmarks rundt omkring og der er næsten ikke noget der sejler mere rundt end stabiliteten på Timer.
Hvad mener du med at man har mulighed for at lave en handling ved behov med Timer? taler vi forbi hinanden
det er Event.ENTER_FRAME og TimerEvent.TIMER på den ene side og getTImer() på den anden 
de 2 første har listeners hæftet på sig og den sidste er nød til at tjekke med den forgående værdi
Mvh. Ricki
AS1 < AS2 < AS3
Det handler ikke om optimering, men præcisionen ved det, og der vil ENTER_FRAME aldrig være ligeså præcis som en timer - det er jo logisk at en ENTER_FRAME er låst fast på hvor mange frames ens computer kan trække i den givne flash.
Skal også lige siges at der ikke er noget problem med stabiliteten med timeren, men at den tager tid om at blive tilføjet ligesom alle andre elementer og classer gør.
Fordelen ved TIMER.TIMER_COMPLETE, er at du har mulighed for at tilknytte handler dertil efter behov - synes egentlig det giver meget mening.