oskob skrev:
Tack för all feedback!
Jag använder förvisso en del onEnterFrames men jag är alltid väldigt noga med att ta bort sånt när det inte används. När jag ska döda en onEnterFrame så skriver jag onEnterFrame = null; Är det rätt sätt?
Är inte säker om det funkar rätt.
Kör "delete this.onEnterFrame;" istället för säkerhets skull.
oskob skrev:
Ang. helt transparenta objekt. Jag gör så att jag steg för steg drar ner opaciteten tills den blir 0 och sätter då _visible = false på objektet (fortfarande _alpha = 0). Då har jag fått för mig att den är helt i "vila".
De behöver inte renderas om de är satta till _visible=false så det skall inte spela någon roll om de är transparenta eller inte.
Däremot är det inte samma sak som att ta bort clippet med removeMovieClip, vilket är det bästa om det inte måste återskapas snart.
oskob skrev:
Frameraten har jag satt till 30. Är det för högt kanske? Kan en för högt satt framerate påverka så att den egentliga frameraten blir lägre än om jag från början satt en låg?
Är frameraten för hög så går det inte snabbare än med en låg framrate, men blir hackigare och större skillnad mellan olika miljöer.
Runt 30 brukar vara bra, men det beror förstås på applikationen.
Håll även ett öga på hur mycket CPU den drar. För ett spel kan man väl i princip ta över användarens dator, men en banner som drar 80% CPU för att se aningen smidigare ut än en som drar 10-20% är mycket irriterande tycker jag. Tänk på användaren och inte bara på att det skall se så bra ut det kan till varje pris.
oskob skrev:
Det här med getTimer(), är det bara för att förebygga att en animation som är 30 frames inte tar 30 sekunder på en långsam maskin och 1 sekund på en snabb eller är det även i sig bättre prestandamässigt?
Det påverkar inte prestandan och är främst för att se till att animeringen tar lika lång tid på olika miljöer.
Ofta så ger det ett intryck av att röra sig jämnare på en maskin som inte riktigt hänger med, men om maskinen inte alls kan hänga med kan det bli ännu ryckigare.
oskob skrev:
Hur är det med ifsatser. I några animationer har jag byggt upp det med en massa else ifs. Tex:
var loadNew:Boolean = false;
function bytBild(nyBild) {
var loadNew:Boolean = false;
this.onEnterFrame = function() {
if ( mrMc._alpha > 0 && !loadNew ) {
mrMc._alpha -= 10; // fadar ut
}else if (mrMc._alpha <= 0 && !loadNew){
mrMc.loadMovie(nyBild); // laddar nästa bild
loadNew = true;
}else if (mrMc._alpha < 100 && loadNew){ // fadar in
mrMc._alpha += 10;
}else{
this.onEnterFrame = null; // dödar onEnterFrame
}
}
}
Varje if sats tar tid förståss, men om den första värderar till true så kommer inte else satserna köras.
Det betyder att de som är mest sannolika att värdera till true bör vara först för snabbast möjliga exekvering.
Det är även snabbare att dela upp varje villkor i en separat sats om möjligt.
I ditt exempel är det kanske inte möjligt, men av nedanstående exempel är det andra snabbast:
if(foo==true && bar==true){
// gör grejer
}
if(foo==true){
if(bar==true){
// gör grejer
}
}
Skillnaderna är små, men om du har en loop som kör mängder med if satser varje frame är det värt att kolla hur man får absolut maximal presatnda från sin kod.
oskob skrev:
Hur är det t.ex. med variablar. Man "ska" väl deklarera allt genom var hej:Number; men det fungerar ju även om man bara skriver hej = 2;. Är det ens värt att ödsla tid på?
Använder du "var" innan du deklarerar en variabel i en funktion så blir den lokal i funktionen och tas bort då funktionen körts klart. Det gör att det blir mindre oanvända variabler som ligger och dräller vilket är bra för prestandan.
Om du kör med strikt typing eller inte (var num:Number) spelar dock ingen roll prestandamässigt då det inte finns någon typing i den kompilerade koden, men det kan vara smidigt för att undvika buggar och påverkar inte prestandan negativt.
