[STUFF] ZZOOOooommm

[kelor]

angeregt durch den threat untern drunter 'pendant zum prototype' habe ich hier eine kleine zoom-klasse gebastelt.

dabei galt als vorlage die alten 'mc-prototype-methoden' aus oben genannten threat.
nunja - allzu viel ist davon nimmer übrig, außer halt dem mathekrempel.

hier mal die klasse zoomClass.as :

class zoomClass extends MovieClip{
    public var targetX:Number;
    public var targetY:Number;
    public var targetXs:Number;
    public var targetYs:Number;
    public var difX:Number;
    public var difY:Number;
    public var difXs:Number;
    public var difYs:Number;
    
    public var target:Number;
    public var delay:Number;
    
    public var maxim:Number;
    public var defaultMax:Number = 500;
    
    public var pressed:String;
 
    static var isX:Number;
    static var isY:Number;
    static var isXs:Number;
    static var isYs:Number;
 
    
    public function getOrigin (startX:Number,startY:Number,startXs:Number,startYs:Number) {
                    targetX = startX;
                    targetY = startY;
                    targetXs = startXs          
                    targetYs = startYs;
                    zoom(delay, targetX, targetY);
    }
    
    public function getTarget(factor:Number,startX:Number,startY:Number,startXs:Number,startYs:Number) {
                    targetX = startX+(startX-_root._xmouse)*factor;
                    targetY = startY+(startY-_root._ymouse)*factor;
                    targetXs = targetXs < maxim ? (targetXs = startXs*factor) : maxim;
                    targetYs = targetYs < maxim ? (targetYs = startYs*factor) : maxim;
                    zoom(delay, targetX, targetY);
    }
    
    public function zoom (delay:Number, targetX:Number, targetY:Number) {
                    onEnterFrame = function(){
                        difX = targetX - _x;
                        difY = targetY - _y;
                        difXs = targetXs - _xscale;
                        difYs = targetYs - _yscale;
                        _xscale += (difXs/delay);
                        _yscale += (difYs/delay);
                        if(_xscale < 101 || _yscale < 101){ _xscale = 100, _yscale = 100, pressed = 'MIN', delete onEnterFrame;
                        }else if(_xscale >= (maxim-1) || _yscale >= (maxim-1)){ _xscale = maxim, _yscale = maxim, pressed = 'MAX', delete onEnterFrame;
                        }else {_x += (difX/delay), _y += (difY/delay);}
                    }
    }
    
    public function onPress(){
                    if(pressed == 'MIN') getTarget(target, _x, _y, _xscale, _yscale);
    }
    
    public function onRelease(){
                    getOrigin(isX, isY, isXs, isYs);
    }
    
    public function onReleaseOutside(){
                    getOrigin(isX, isY, isXs, isYs);
    }
 
    public function init (_tar:Number, _del:Number, _max:Number){
                    pressed = 'MIN';
                    target = _tar;
                    delay = _del;
                    maxim = _max == undefined ? defaultMax : _max;
    }
    
    public function zoomClass (){
                    isX = _x;
                    isY = _y;
                    isXs = _xscale;
                    isYs = _yscale;              
                    getOrigin(isX, isY, isXs, isYs);
    }
} 

allles, wa sihr noch braucht ist einen mc in der bib mit folgenden eigenschaften:

Bezeichner: mc
AS 2.0 Klasse: zoomClass

Verknüpfung:
Haken bei 'Export für AS' und bei 'In erstes Bild exportieren'.


und ein kleines script auf zeitleiste:

var mc = this.attachMovie('mc','zoom_mc',100, {_x:300,_y:300});
mc.init(10,5,1000); 

die funktion init() erwartet drei params:

1. param = target ist ein faktor
2. param = delay der devisor
3. param = [ optional] maximale skalierung, wenn nicht übergeben, wird standard 500% genommen


that´s all...

ansehen kann man sich das ganze hier:

ANGUGGEN


greetz

kelor

[kelor]

solltet ihr beim einfügen des scriptes in eine *.as datei fehlermeldungen bekommen, so liegt das nicht daran, dass das script falsch wäre oder ihr einen fehler gemacht habt, sondern daran, dass das board hier leider falsch umbricht...


die beiden übeltäter sind :
die funktion 'getOrigin' und 'getTarget' !

bei beiden müsst ihr am ende der funktionsdeklarierungszeile natürlich schliessen.
sprich: den verflixten umbruch raus machen...
dann läuft´s auch...


und irgendwelche kommentare zu dem ding ? *gugg*


greetz

kelor

[warrantmaster]

Geschrieben von kelor
...und irgendwelche kommentare zu dem ding ? *gugg*

....ja:

geil !

[kaneda]

Ich finds nicht sooo gut. Kritikpunkte:

• Es muss ein MovieClip verwendet werden ... was wenn der MovieClip aber auch auf eine andere Klasse definiert werden.
• Die Befehle sollten nicht auf Eventhandler gemappt werden (weil die vielleicht auch über ein Control gesetztn werden wollen)
• generell ist der Zugang unintuitiv: Es exisitieren keine Klaren definitionen über den Zoomstatus. (getZoomLevel) oder ein dezidiertes setzen (setZoomLevel) oder ein Verschieben ... irgendwie würd ich das lieber über ein Interval handhaben ...

[kelor]

ich muss dazu sagen, das ich lediglich das ursprungsscript lauffähig umgeschrieben hatte in ne 2004er version...

zu punkt 3
gebe ich dir wegen des intervals recht.
da wäre ein interval auch eher mein ding.

wegen unintuitiv...hmmm... das ist wohl eher etwas für den user, als für den entwickler...oder findest du nicht?! eine´info über den zoomlevel kan man als spielerei einbauen, als beigabe...hat aber nix mit der funktionalität zu tun...find ich...

zu punkt2:
welche controls sollten noch auf einer z.bsp. karte integriert sein.
nope - kann ich so nicht sehen...das ding hat ja keine andere berechtigung, als das gezoomt werden...alles andere betrifft dann etwaige weitere mc´s, die in oder auf dem zoom-mc schlummern...

wenn, dann würd ich eh alles andere über ein control-class abwickeln wollen und nicht über den zoom-mc.
[vielleicht geschmackssache...]

zu punkt1:
um ehrlich zu sein, weis ich nicht ganz, worauf du hinaus willst...
ja, man braucht nen mc...und?! *koppkratz*
erklär mal...
ne karte oder ähnliches ist meist ein grafisches element, dass man in der regel, in einen mc stopft...
kann dir da leider net ganz folgen, kaneda...
hope u clear my way...


greetz

kelor

[kaneda]

also mal schauen:

Ich hab 0 Zeit deswegen versuch ich kurz einen Vorschau zu geben : Alle deine Methoden sind fix auf deine Struktur belegt, sehr statisch. Man könnte beispielsweise einen Controller hernehmen der auf einen MOvieClip all das anlegt und dezidiert darauf bauen das jede Method separat aufgerufen werden kann und das die Methoden so minimalisitisch wie möglich sind. K(aum)eine Variablen direkt zu verwenden. Vielleicht komm ich noch dazu mehr zu schreiben.

[bloba]

cooles teil!! gefällt mir

des könnte man prima zu ner navi ausbauen
zb mit einer doppelcklickt schnell zomm funktion etc...

[kelor]

yepp bloba...z.bsp.

@kaneda: oha..ich ahne schon, worauf du hinaus willst...und um ehrlich zu sein, fürchte ich, dass das in einer grundsatzdiskussion zwischen einem 'codedesign-freak' [dir] und einem 'ungelernten selfmade-progger' [mir] endet.


du kennst sicherlich meine meinung bezüglich den meisten formen von codedesign...

und - und das ist auch eine wahrheit - leiden die meisten schön durchdesignten codes an tempo...will heißen performance.

natürlich könnte man jede mathematische berechnung einzeln in einen methode stopfen...

natürlich könnte ich jede methode so schlank als [un]möglich halten.

und natürlich kann man es so strukturieren, dass ich jede methode einzel aufrufen könnte...aber wozu?!
mir verschließt sich hier der sinn, so etwas zu tun...welchen nutzen sollte es mir bringen, methoden einzeln aufrufen zu können, die zwangsläufig aber nur miteinander ein sinnvolles ergebnis liefern...davon mal ab, dass jeder weitere methodenaufruf nur unnötig zeit in anspruch nimmt - und das bei einer 'speedgranate' wie AS...


design sollte immer einen vorteil bringen und nicht des designs wegen genutzt werden...

was nutzt mir der 27te designte stuhl von 'totaly kaputschnyi', wenn mir der ar*** darauf weh tut?!



greetz

kelor

[RustyCake]

Geschrieben von kelor

was nutzt mir der 27te designte stuhl von 'totaly kaputschnyi', wenn mir der ar*** darauf weh tut?!

Einleuchtendes Argument

[kaneda]

Tut mir leid ... ich bin nicht der ansicht. Es tut mir echt leid weil ich diese Diskussion kenne. (Also weil wir gerade in die Diskussion gerutscht sind)

Ich denke Softwaredesign hat einen Hintergrund als hier illustriert. Ich vergleiche es eher mit einem Werkzeug:
Du willst etwas erreichen: sagen wir ein Bild(Hausnummer fällt mir gerade ein, kann auch was ganz anderes sein). Und du hast ein paar Werkzeuge zur Auswahl:

• Einen ganz kleinen feinen Pinsel
• Einen grossen Malerpinsel mit kantigen Borsten.
• Einen mittelgrossen Pinsel mit einer feinen kante
• Einen mittelgrossen runden Pinsel

Und wenn du das Bild malst musst du farbe draufbringen. Das heisst du brauchst Töpfe. Der Pinsel muss in den Topf passen (grosse Pinsel passen nicht in alle Töpfe) und er darf nicht drin untergehen: Warum? weil sonst die Arbeit patzt und das bild wird verkleckert. Oder du hast weniger Farben zur verfügung.

Wenn man C hernimmt ist das wie der feinste pinsel mit den grössten & meisten töpfen die man sich vorstellen kann. Man kann alles Zeichnen, grosse wie kleine Dinge, in allen Fraben, und wenn man sauber ist, patzt das auch nicht.

Wenn man Java hernimmt ist der Pinsel nicht mehr so fein (weil es ja in einer VM läuft) also lassen sich nicht mehr alle Bilder zeichnen jedoch ist Java durchdacht was einem erlaubt alle Farben herzunehmen, der Pinsel ist auch gut ausgearbeitet so dass wenn man ihn schräg hält viele möglichkeiten offen hält, er ist auch schneller wie der C weg weil man viel vorgefertigt hat und weil sich alle an die selben richtlinien halten.

Wenn man Flash hernimmt ist das momentan eine sehr wage sache: Maler in Flash haben selten gute Pinsel weil manchmal Pferdehaare (MacromediaKlassen), Schweineborsten (Klassen aus irgendwelchen Foren), und Menschenhaaren(also selbstgestrickten) zusammengebaut sind. Wenn man sich an kein Muster und an kein Qualitätssiegel hält dann kriegt man nie saubere Bilder zusammen. Ausserdem sind die Pinsel meist Breit und gross, damit man schnell grosse Flächen mit der selben Farbe ausmalen kann...... (das jedoch sehr verfranst ist)

Den Java Weg finde ich super weil der Pinsel ziemlich gut ist von Anfang an und weil man alles schnell machen kann, man hat oft eine Ahnung was passiert, es geht sehr viel auch noch sehr Betriebssystem nahe und die Entwickler sind sich einig was abgeht (und optimieren darauf hin).


TATSACHEN (die Moral von der lustigen Geschichte):

• Meist macht Softwarearchitektur Software schneller (weil überflüssiger Code entfernt wird / Techniken entwickelt werden die einfach schneller sind)
• Publizierter Code hat ein paar Anforderungen: Er muss gut lesbar sein und einfach verständlich, einfach Code aus einem Forum kopieren ist schnell gemacht einen Bug finden oder das Ding zu modden schwer
• Aufteilen in Methoden macht es einem selbst viel einfacher Lecks in Code zu finden und die Applikation schneller zu machen.
• Sauberer Applikationsaufbau ermöglicht ein breiteres Spektrum an Implemenationen/Alternativen. Wenn etwas strikt an einen Anwendungsfall gebunden ist werden die Leute immer wieder auf die Idee kommen eine sehr umständliche Lösung für einen ähnlichen Fall zu finden und es wird solange gemacht bis jeder seine eigene Lösung hat und Code nicht mehr ausgetauscht werden kann -> Chaosentwirrer wird vielleicht mal ne tolle geldquelle.

Wenn du etwas in einem Forum publizierst sollte es separierten Zugang haben.

Unter separiertem Zugang verstehe ich:

• darf keine andere standardfunktionalität ausschliesen (wenn du extends Movieclip verwendest und object.registerClass dann kann kein anderes Objekt mehr darauf zugreifen, man stelle sich vor jemand möchte das aber auf einen MovieClip anwenden den er bereits mit Funktionalität gefüllt hat, onenterframe ist auch ein leidiges thema)
• Zoomen kann man bei dir nur auf MovieClips wobei es eigentlich für jegliche Art von Rechteck möglich wäre (auch die Animation davon).
• Deine Methoden sind abhängig von der Ausgangsituation das jemand genau diesen Fall braucht: Wenn man draufklickt und beim draufklicken hinzoomen will und dann abhängig von der position dorthinkommt. (was wenn jemand das per Zeit oder per serverseitigem aufruf machten will (keine Ahnung)
• wenn jemand die methoden durchliest kann man sich nur schwer vorstellen was man sich meint.

vieleicht hab verdeutlicht was ich meine,

[Madokan]

@Diskussionsgruppe kelor/kaneda: Jungs ich könnt jetzt den Informatiker raus hängen lassen - aber meine Antwort zu dieser Diskussion an dieser Stelle: Ich find es klasse das Rainer (kelor) das Skript angepasst hat - wieviel Zeit er für OOA und OOD verschwendet hat sei mal dahin gestellt - was mir nicht passt ist das daraus eine Grundsatzdiskussion gestrickt wird. Macht doch dafür einen neue Thread auf - die Zoom-Klasse wird es euch danken und ich auch.

By the way wozu gibt es updates - macht es wie die grossen. Das ist Zoom Klasse v1.0 und in kürze, wenn genügend Zeit ist gibts v1.1 oder v2.0 - je nach Modifikationen und Erweiterungen.

Liebe Grüsse
Matze K.

P.S.: Sorry für den unterschwellige und offensichtlichen Sarkasmus - aber diese Diskussion ist für mich einfach nur noch ein schmutzeln wert. Gibt eine tolle Lösung: Jeder sollte nach seiner Lösung streben mit, welcher er gut auskommt, alles andere ist heisse Luft!

[kaneda]

*heisseluftschwafel*

[kelor]

...wieviel Zeit er für OOA und OOD verschwendet hat sei mal dahin gestellt - was mir nicht passt ist das daraus eine Grundsatzdiskussion gestrickt wird.

meine meinung...

und kaneda...ganz so 'unbedarft', wie du vielleicht denken magst ist deine umwelt mitnichten...



aber lassen wir das...ich habe diese diskussionen schon gehört, da glaubten noch ganz andere alles zu wissen...

TATSACHEN (die Moral von der lustigen Geschichte):

Meist macht Softwarearchitektur Software schneller (weil überflüssiger Code entfernt wird / Techniken entwickelt werden die einfach schneller sind)

Publizierter Code hat ein paar Anforderungen: Er muss gut lesbar sein und einfach verständlich, einfach Code aus einem Forum kopieren ist schnell gemacht einen Bug finden oder das Ding zu modden schwer

Aufteilen in Methoden macht es einem selbst viel einfacher Lecks in Code zu finden und die Applikation schneller zu machen.

Sauberer Applikationsaufbau ermöglicht ein breiteres Spektrum an Implemenationen/Alternativen. Wenn etwas strikt an einen Anwendungsfall gebunden ist werden die Leute immer wieder auf die Idee kommen eine sehr umständliche Lösung für einen ähnlichen Fall zu finden und es wird solange gemacht bis jeder seine eigene Lösung hat und Code nicht mehr ausgetauscht werden kann -> Chaosentwirrer wird vielleicht mal ne tolle geldquelle.

warum kommt mir das so bekannt vor und warum muss ich darüber schmunzeln...?!*g*

das wort : TATSACHEN...hähä... *bauchhalt*

angeregt durch den threat untern drunter 'pendant zum prototype' habe ich hier eine kleine zoom-klasse gebastelt.

dabei galt als vorlage die alten 'mc-prototype-methoden' aus oben genannten threat.

just my intention...noth more







greetz

kelor

[kaneda]

Okay. wie madokan angedeutet hat sollten wir das besser lassen... lebe dein Zeugs für dich hin. Ich werde es nicht verwenden und auch nicht für gut empfinden.

[nky]

ohne in den Code gekuckt zu haben muss ich sagen das Ding ist für nen Picture Viewer wohl mehr als brauchbar...

sieht auf jeden Fall fein aus

achja:
Wer wie lange über was nachdenkt soll das für sich entscheiden...
Fakt ist das in der heutigen Arbeitswelt Praktiker gesucht werden - die ihr zeug schnell erledigen....und keine Leute die sich 5 tage lang den Kopf über irgendwelche tollen Strukturen zerbrechen - und im Endeffekt kommt dann das gleiche bei raus ...
das ist zwar nicht immer - aber hierzu meine Meinung !

Gruss nky