hvordan er det her lavet?

vinduet er et movieclip med en kode ala:
onClipEvent (load) {
    x=100;
    y=100;
}
onClipEvent (enterFrame) {
    if (this._xscale>x) this._xscale-=10;
    if (this._xscale<x) this._xscale+=10;
    if (this._yscale>y) this._yscale-=10;
    if (this._yscale<y) this._yscale+=10;
}

Og ind i movieclippet laver de knapper med en kode ala:

on (release) {
    x=100;
    y=100;
}

Se mit eksempel her:
http://home19.inet.tele.dk/sirvival/hvordan.swf


/Alexander

Ps. Man kan også bruge this._width og this._height istedet for!

Med dette i onClipEvent(enterFrame) i stedet for...

if(_xscale != x) {
  (_xscale += x - _xscale)/3;
  (_yscale += y - _yscale)/3;
}

...får du så samme effekt som på linket. Størrelsen "bremser op" (o;

legende --> Forklar mig lige koden: (_xscale += x - _xscale)/3
Er parentesen ikke sat forkert?

Jo for fanden !!!! ((((o;

if(_xscale != x) {
  _xscale += (x - _xscale)/3;
  _yscale += (y - _yscale)/3;
}

Sådan (o;

jeg kan sku ikke lige få legendens løsning til at virke?? men alexanders virker fint!
er der ikke en måde hvor man kan ligge knapperne udefor det movie clip det er jo ikke så fedt at mine knapper biver totalt screwed når billede bliver mindrer eller størrer!

sorry legende det virker nu... hmmm af en eller anden grund vil mit flash 5 ikke men MX vil godt

så nu virker hele mulevitten det var jo bare lige et telltarget der skulle til så ligger knappen udenfor movieclippet... er det ok hvis jeg deler pointsne mellem jer? 
så legenden.dk kommer du ikke lige med et svar ?

Den er fjong :-)

tak for det

hey legenden kan jeg få dig til at uddybe hvorfor den får den easing effect?
ikke et krav men det kunne være rat at vide hvad det er jeg har lavet :-)

Den jeg har skrevet (og brugt 1000 gange) gør det (som du kan læse i koden) at den tager forskellen mellem målet(_xscale = 100) og den aktuelle _xscale og bevæger sig en trediedel af det... Der med flytter den jo mindre og mindre ad gangen, da afstanden i hver frame reduceres med 1/3. Du kan naturligvis speede den lidt op ved at ændre 3 til 2, eller gøre den langsommere ved at hæve tallet....

(o;

Kiggede lidt på din kode legende - hvorfor har du egentlig den 'if' med? Med den her kode
  _xscale += (x - _xscale)/3;
  _yscale += (y - _yscale)/3;
vil _xscale altid være forskellig fra x!

Personligt er jeg ikke helt glad for koden, da mc'et i teorien altid vil være i bevægelse og derfor kræve regnekraft - men hvad siger praksis?

Den rammer da hurtigt det den skal... Og jeg har ikke just oplevet nogle ulemper i den metode.

Synligt ja :-) Jeg har leget lidt med mit regneark - forestil dig at _xscale er 100 og x er sat til 95

1. _xscale = 100 + (95 - 100)/3 = 98,3333333333 (10 decimaler)
2. _xscale = 98,3333... + (95 - 98,3333...)/3 = 97,2222222222
3. _xscale = 96,4814814815
4. _xscale = 95,9876543210
5. _xscale = 95,6584362140
...
50. _xscale = 95,0000000078

Nu har jeg kun lavet beregningen 50 gange - men det viser at xscale aldrig nogensinde vil få samme værdi som x - med andre ord er der tale om en uendelig proces (så længe decimaler haves!) - og derfor vil mc'et i teorien hele tiden blive en lille anelse mindre og flashplayeren vil hele tiden skulle bruge regnekraft!

Prøv at lave følgende kode:
'if(_xscale != x) {
  _xscale += (x - _xscale)/3;
  _yscale += (y - _yscale)/3;
  z++;
}'
og lav så et dynamisk tekstfelt med variablen 'z', så vil du se at den bliver ved med at køre din 'if'-sætning (jeg har selv gjort det, men gad ikke vente længere da den havde kørt den i over 6500 frames!)

Din 'if' er med andre ord overflødig, men det kunne naturligvis løses med en math.round komando!

pumpin -- > tak for point :-)

if(Math.round(_xscale*100)/100 != x) {
  _xscale += (x - _xscale)/3;
  _yscale += (y - _yscale)/3;
}

Med denne her kode ville den i et skift fra 100 til 96 ikke skulle bruge regnekraft efter 18 frames :-)

Det ku være jeg skulle få mig et liv i stedet for at skrive så meget :-)