beste onEnterFrame gebruik?

[theFlashWizard]

ey mensjes..
ik vroeg me het volgende af.. stel:
je hebt een aantal objecten die je met een ease laat bewegen, die objecten zijn deel van een menu en de bewegingen gaan niet oneindig door maar wel lang nadat je echt iets eraan gedaan hebt. bijv een paar rollovers.. gescript dan natuurlijk.. bijv over de scale..

nu waar het om gaat..
1) is het dan het handigst om per object een onEnterFrame te maken, die je dan weer eindigt wanneer de doel scale haast niks meer scheelt met de huidige scale, wat je doet door 1 if.

2) of is het beter om 1 onEnterFrame te maken met een for lus die alles beweegt totdat alles is op de scale dat hij moet zijn.. wat je dan moet doen door een paar if of een if over een optelling van alle scales..

3) of wat ook nog kan.. n x gemaakt.. een moeilijkere for lus aan de hand van een array die alleen de objecten beweegt die in die array staan. Alleen deze objecten moeten dan ook nog gescaled worden. degene die er wel zijn worden er uitgehaalt. aan de hand van ook een if.
wanneer die array dan leeg is stopt de onEnterFrame pas.

welke van de 3 methodes is volgens jullie het best / handigst.
volgens mij is methode 1 alstijd nog het makkelijkst.

alvast bedankt voor de input!

[Fl4sh3r]

Ik zou voor methode 1 gaan. Hierbij is ieder object verantwoordelijk voor zijn eigen beweging. Eén van de dingen waarnaar je streeft bij OOP (Object Oriënted Programming) is het delegeren van taken en verantwoordelijkheden.

Manier 2 en 3 zijn, mijns inziens, niet heel erg slecht, maar minder OOP.

Desalniettemin, interessante discussie

[theFlashWizard]

thnx voor de 1ste mening :)

[Roenes]

Optie 1. Ieder object heeft idd zijn eigen taken en dit is ook meteen de meest gebruikte manier. 2 vliegen in 1 klap dus ;)

[theFlashWizard]

hmm maar ik heb ooit ergens gelezen dat 1 onEnterFrame minder CPU intensief zou zijn.. dan zoude optie 2 of 3 toch beter moeten zijn..
optie 3 zou dan nog het meest effectief zijn, al vergt dat wel een wat moeilijker script.

[TheDutch]

Uiteindelijk gaat het er niet om hoeveel onEnterFrames er zijn, maar meer hoeveel acties er uitgevoerd worden in totaal. onEnterFrame is er namelijk altijd aangezien je Flashmovie altijd op een bepaald FPS draait. Alleen wanneer je een functie hebt die uitgevoerd wordt aan de hand van de FPS(onEnterFrame) dan gaat de CPU werk krijgen :).

[theFlashWizard]

ow als iedereen het daarmee eens is, en het dus niet intensiefer is, zie ik geen reden om de 1ste methode te gebruiken :)

[Folkert]

Uiteindelijk gaat het er niet om hoeveel onEnterFrames er zijn, maar meer hoeveel acties er uitgevoerd worden in totaal. onEnterFrame is er namelijk altijd aangezien je Flashmovie altijd op een bepaald FPS draait.
Can you elaborate on that please ;) Mijns inziens is het namelijk wel degelijk van belang hoeveel enterFrame Events je uit hebt staan, elke event is gewoon een call en zal als zodanig de cpu belasten. Waar je echter meer zorg om zou hebben (als je cpu belasting al merkbaar zou zijn) dat is de frameRate, die is immers van belang voor de enterFrame event.
Nu zal het bij jou menu wel loslopen en zou je denk ik best de items zelfstandig laten werken. Echter het is een beetje afhankelijk van de applicatie of het onderdeel wat je bouwt, welke keuze de beste is.
wil je geen gedoe met je animatie dan zou ik voor een interval kiezen in tegenstelling tot een enterFrame, dan heb je wat meer grip op het resultaat.
By the way, de enterFrame is er sinds flash 5, sinds daarin de onClipEvent bestaat.
De mogelijkheid om onEnterFrame als callback te gebruiken, bv _level0.clip.onEnterFrame=function() {} , is pas sinds flash mx.

[TheDutch]

bvcbcvb

[TheDutch]

Ik heb het even getest en met meer dan 500 lege onEnterFrame functies op 30FPS ga je pas wat merken(5% CPU op 3Ghz. Dus 0.005% CPU per onEnterFrame functie). Dus je hebt gelijk, het aantal onEnterFrame functies maakt weldegelijk uit maar dat is dan bij ernorm veel objecten die los van elkaar moeten bewegen. In de meeste gevallen te verwaarlozen :).

[TheDutch]

5% op een 3Ghz is eigenlijk best veel zit ik me te bedenken. Op een 1.2Ghz zal dat zeker wel 10% zijn... Ik was in de veronderstelling dat het uitvoeren van de onEnterFrame functies niet zoveel zou kosten en dus eigenlijk te verwaarlozen was, kennelijk niet.

Goed even getest te hebben :).

[theFlashWizard]

hmm maar bij veel objecten die los bewegen.. zoals particles.. gebruikt men toch altijd aparte onEnterFrames.. vreemd dan eigenlijk..

[Folkert]

niet vreemd hoor, 5000 enterframes is beetje bizar natuurlijk he, zoveel menu items heb jij vast niet ;), daarnaast wat een welkome aanvulling is, je framerate dropt niet heel hard (dat word vlot anders met wat checks bijin je enterFrames). maar goed ga eens na wat het met de framerate doet als je elke enterframe 5000 clips zou moeten checken in een loop ;)

[theFlashWizard]

ey kommop dat menu was n voorbeeld.. ik heb et over het algemeen he.. dus mshn ook wel n particle systeem.. :P

hmm ik vind van wel want vooral bij particles moet je erg op efficentie letten omdat je erg veel vraagt van flash.. dus dan zou je zegge dat ze dan voor de meest efficiente manier zoude moete kieze..

en idd.. zoals methode 2 alles onEnterFrame checken is n btje fout..
maar dat zou mshn wel met methode 3 kunnen.. dan checkt hij alleen wat nodig is..

[Folkert]

okee tot een 2000 losse enterFrames (met een if else check en trace) is het voordeel voor de losse enterFrames in tegenstelling tot de loop check in 1 enterframe. echter doe je daarboven is het hoe meer daarboven hoe meer je loop in het nadeel is.

[theFlashWizard]

em.. daar snap ik niks van..
wat is het voordeel?
doe je daarboven? waarboven? :P

[Fl4sh3r]

Als je 2000 objecten of minder hebt, kun je het beste losse onEnterFrames gebruiken.
Heb je er meer (dan 2000) dan kun je beter een loop doen in 1 onEnterFrame.

(Dat is wat ik uit de post van Folkert haal)

[theFlashWizard]

hmm owke... Kzou nie wete wat ik daar tegenop zou moete inbrenge.. :P ik ga mezelf aanleren voortaan altijd een onEnterFrame per mc te gebruike.. ik werk bijna nooit met meer dan 2000 objecten..

[TheDutch]

dus mshn ook wel n particle systeem.. :P
Kijk naar mijn signature...dat zijn er maximaal 150 :).

[Folkert]

psies ;) check die signature. die maffe getallen had ik enkel even voor wat testjes gebruikt.
Ik heb de testen even herdaan om wat output te genereren want jullie snappen het exact verkeerd om. Dus voor de duidelijkheid even naast elkaar op rij :-D

traces van 1 enkele enterframe die 'aantal' clips checkt (let niet op de exacte notatie maar op het verschil ;)
aantal = 2000 // duurt rond de 0,6 seconden
aantal = 3000 // duurt rond de 1,4 seconden
aantal = 4000 // duurt rond de 2,6 seconden
aantal = 5000 // duurt rond de 4,3 seconden

bij enterframes in elke mc (die hetzelfde doen als er in de andere test werd gedaan)
aantal = 2000 // duurt rond de 0,4 seconden
aantal = 3000 // duurt rond de 0,55 seconden
aantal = 4000 // duurt rond de 0,66 seconden
aantal = 5000 // duurt rond de 0,75 seconden.

Hopelijk maakt dat 1 en ander wat duidelijker ;)

[theFlashWizard]

dus op alle fronten wint een onEnterFrame per mc het.. :|

[theFlashWizard]

Folkert, hoe heb je die test eigenlijk gemaakt? zou ik het script of de fla eens mogen zien? want Kzou het wel mooi vinden als ik dit soort tests ook zelf kan uitvoeren..

[Folkert]

je kan heel simpel je code timen via getTimer()

//waar je begint
startTime = getTimer();
//waar je klaar bent
verlopen = (getTimer()-startTime) /1000;

het verlopen geeft aantal seconden terug, getTimer is in milliseconden.

[theFlashWizard]

ow owke.. :|
zo simpel.. :)
naja dan ken ik bij het starten van dit soort dingen teminste eerst zelf onderzoek doen.. :)
thnx!

[XemonerdX]

Folkert, care to share the code? :) Dit is de eerste keer dat ik zo'n test in het voordeel van een oEF per MC uit zie vallen. De meeste 3D engines in AS bijv gebruiken 1 oEF en niet een oEF op iedere MC.