[JS] Veel of weinig methods gebruiken

[André]

Mijn vraag is moet je veel methods gebruiken om je progje sneller te maken, of maakt het geen verschil. Voorbeeld:

code:

function bla_Object(ID)
{
  this.ID = ID;
}
bla_Object.prototype.Method = bla_Method();

function bla_Method() 
{
  //collision detection
  //movement
  //graphicsupdate
  //enz enz enz
}

Je kunt op deze manier de complete functionaliteit in bla_Method() kwijt. Maar is het niet beter om meerdere prototypes te maken. (coll detection, movement, ...enz). Word het daar sneller van, of is dat meer om het overzicht te houden in je code.

[Bosmonster]

de enige reden is overzichtelijkheid en herbruikbaarheid.

Als je eenzelfde functie op tig plekken hergebruikt is het makkelijker aanpassingen doen natuurlijk..

Voor de snelheid van de code maakt het niks uit.

Je kunt op deze manier de complete functionaliteit in bla_Method() kwijt. Maar is het niet beter om meerdere prototypes te maken. (coll detection, movement, ...enz). Word het daar sneller van, of is dat meer om het overzicht te houden in je code.

Volgens mij snap je het prototype principe ook nog niet helemaal. Je maakt niet meerdere prototypes. Je past slechts het prototype object aan dat gebruikt wordt voor het maken van een instantie van het object.

Begin met coden dan kom je er vanzelf achter dat dingen die je iedere keer weer wilt gebruiken gaat hergebruiken door ze in losse methods te zetten.

[Clay]

Mijn vraag is moet je veel methods gebruiken om je progje sneller te maken, of maakt het geen verschil. Voorbeeld:

code:

function bla_Method() 
{
  //collision detection
  //movement
  //graphicsupdate
  //enz enz enz
}

Als je specifiek dit gaat doen in JS is het wel degelijk sneller om het in losse methoden te zetten. Dan kan je namelijk zelf bepalen wanneer wat aangeroepen wordt.

Het is bijvoorbeel niet handig om de graphics update in dezelfde keten als de berekeningen te laten volgen, stel:

code:

for(i in dingen) {
   dingen[i].update()
}

function update() {
   // movement
   // collision
   // graphics update
}

Als je nu 50 dingen hebt die per interval geupdate moeten worden zal de update van het 2e ding op de movement, collision EN graphics moeten wachten van de 1e, de 5e zal op de eerste vier moeten wachten, en de 50e dus op de 1e 49, en het allertraagste in js is het updaten van graphics, dus deze constructie zal supertraag zijn en exponentieel trager worden voor elk extra update-ding.

Een oplossing is om in Js gewoon met een soort threads te gaan werken. En dan is het het handigste om de graphics kant (presentatie) te scheiden van de berekeningen (back end). Berekeningen kan je nog gewoon in 1 grote for loop plempen, aangezien JS prima in staat is om duizenden berekeningen per seconde te doen, maar voor de grahpics update kan je het beste ieder ding zijn eigen "thread" geven zodat elk ding op _niemand_ hoeft te wachten bij zijn update:

code:

for( ... ) {
   ding[i] = new dinges()
   ding[i].timer = setInterval("ding["+i+"].update()", 40)
}

berekeningen = setInterval("mainUpdate()", 50);

function mainUpdate() {
   for( ... ) {
    // movement
    // collision
   }
}

function dingUpdate() {
    // graphicsupdate
    // ding object methode, geen for loops
}

Zoiets als dit dus.
Zo kan je dus in plaats van 30 dingen schokkend animeren, 200 dingen vloeiend animeren in js.

[André]

Volgens mij snap je het prototype principe ook nog niet helemaal. Je maakt niet meerdere prototypes. Je past slechts het prototype object aan dat gebruikt wordt voor het maken van een instantie van het object.

Weet ik, de formulering was niet helemaal juist.

[Bosmonster]

Clay:

volgens mij maakt het nog steeds niks uit of je code sequentieel uitvoert of in losse methodes.

Uiteraard wel als je met timers enzo aan de gang gaat maar dat lijkt me logisch dan.. Je zult toch een methode/stuk code aan een timeout/interval moeten hangen.. en die moeten elkaar niet in de weg zitten..

Weet ik, de formulering was niet helemaal juist.

Dan heb ik niks gezegd

Zijn de macromedia timelines niet ook een proging tot JS-threading?

[André]

Zoiets als dit dus.
Zo kan je dus in plaats van 30 dingen schokkend animeren, 200 dingen vloeiend animeren in js.

Oke Clay, goed bezig. Ik had inderdaad de constructie gebruikt zoals je beschreef en door de graphics update bleef het traag, want alle objecten moesten op elkaar wachten.
Nu ga ik de berekeningen even scheiden van de grafische troep. Thnx

Kijk trouwens maar eens op http://www.nobellaan.nl. Klik op spellen en dan op invaders. Dit zijn probeersels van 2 jaar geleden. Vooral die invaders is ontzettend traag.