Also das Variable Array vom RPG Maker benutzt ausschließlich Integers (ganze Zahlen), aber weiß ja hier jeder ^^
Soweit ich weiß, werden bei Integern potentielle Nachkommastellen einfach abgehackt bzw. ignoriert, somit wird immer abgerundet. Und somit wäre diese Modoloberechnung in Kombination mit der Division nicht möglich.
Beispiel, nehmen wir die Zahl 145.
CurrentDigit=145 % 10 = 5. Erste Ziffer
CurrentDigit=145 / 10 = 14 (die 0.5 am Ende hackt er ab)
CurrentDigit=14 % 10 = 4. Zweite Ziffer
CurrentDigit=145 / 100 = 1 (.45, jedoch auch hier wieder abegehackt, weil Integer) Dritte Ziffer.
Man braucht für die Modoloberechnung einzelner Ziffern keine extra Variablen. Ich habe bei meinem Custommenü gewiss 40 bis 50 Ziffern geskriptet und für alle eine einzige Variable benutzt! Beispiel:
CurrentDigit wird berechnet, dann über Conditions entsprechend die Ziffer dargestellt und dann wird erst die nächste Ziffer berechnet, aber auch wieder mit derselben Variable. Das analog für jede Ziffer.
Die Variable wird nur zur kurzen Berechnung gebraucht, es wird ja so oder so alles der Reihe nach berechnet und angezeigt, somit auch bei einer regelmäßigen Aktualisierung nur eine Variable. Aber es empfiehlt sich, die Zahlen per Aufruf zu aktualisieren, wenn sie sich verändern und nicht per Parallel Process. :) Bei schwächeren Rechnern kann das immernoch zu Performanceproblemen führen!
Funktioniert somit nicht anders, aber (!) somit behält man Übersicht und kann besser copy-pasten, in dem Beispiel mit individuell zugeordneten Variablen muss man im worst case quasi immer neu skripten, hier kann man den shit kopieren und muss nur die V[0002] ändern. Wenn man sich dann noch leere Condition-Zweige in irgendeinem Event Zwischenspeichert, dann muss man die auch nicht jedes Mal neu skripten. Nur ein kleiner stilistischer Tipp am Rande ;)
Soweit ich weiß, werden bei Integern potentielle Nachkommastellen einfach abgehackt bzw. ignoriert, somit wird immer abgerundet. Und somit wäre diese Modoloberechnung in Kombination mit der Division nicht möglich.
...
Welche meinst du denn genau? Das Beispiel von BDraw sollte funktionieren.
Zitat
Man braucht für die Modoloberechnung einzelner Ziffern keine extra Variablen. Ich habe bei meinem Custommenü gewiss 40 bis 50 Ziffern geskriptet und für alle eine einzige Variable benutzt!
...
In deinem Beispiel ist die Anzeige der Ziffern aber in den Code integriert. Die kann von Zahl zu Zahl wechseln: Manchmal gibt es mehr Ziffern, die Positionen unterscheiden sich und vielleicht auch die Picture-IDs. Ich finde es praktischer, die Zerlegung der Zahl in ein Common Event (in eine eigene "Methode") zu packen. Dort braucht man dann aber für jede Stelle eine Variable und außerdem noch eine für die Zahl, die zerlegt werden soll.
Das ist jetzt etwas OT, aber wenn ich mal eine Alternative in den Raumen werfen darf, die Zahlen anzuzeigen:
Packt alle Zahlen auf ein einziges Picture, jeweils mit ordentlich Leerraum dazwischen, sodass immer nur eine Zahl aufs Bild passt. Dann könnt ihr mit zwei weiteren Variablen, die x und y beinhalten, das Bild so verschieben, dass immer nur die jeweilige Zahl angezeigt wird. Der "neue" (a.k.a. offizielle) 2k3 kann das meine ich sogar Problemlos importieren, bei den alten Versionen muss man tricksen, indem man erst ein kleineres Bild mit den selben Farben importiert und das dann einfach im Ordner austauscht.
Wenn zwischen den Zahlen bspw. immer horizontal 320px Leerraum sind und die Ausgangsposition bei... was weiß ich, (-640|-480) liegt, braucht ihr nur das Bild (das ihr natürlich vorher bereits mit Show Picture geladen habt, bspw. 100% Transparenz) entsprechend verschieben:
Das ist etwas Friemelsarbeit, zu Beginn die passenden Ausgangskoordinaten zu finden, aber danach deutlich simpler. Man erspart sich die ganzen Show Picture-Befehle und noch dazu ist es afaik schonender für die Performance (auch wenn das fast nie wirklich was ausmacht). Auch das erstellen des Zahlenpictures ist etwas aufwendiger (gibt eben Bilder mit Abmessungen von 3200x240px oder so), aber dafür ist der Code bedeutend kürzer. Denn wenn es hier schon darum geht, den Code möglichst wiederverwendbar zu machen, würden mich die Mod-Rechenfunktionen hier bei weitem weniger nerven als diese Massen an drögem Code, der nur aus immer der selben Abfrage plus Show Picture besteht.
Das ist zwar immer noch bei weitem nicht so komfortabel wie der DynPatch, aber auf jeden Fall angenehmer als "if V[1]=0 then Show Picture 0; if V[1]=1 then Show Picture 1; ..." und das für eine Zahl mit 3 Ziffern von 0-9 insgesamt 30x.
@Drakee:
Stimmt das funktioniert auch alles mit einer bzw. sogar zwei Variablen. Allerdings hat man mittlerweile über 5000 davon zur Verfügung und wenn man evtl. noch etwas weiter mit den einzelnen Ziffern im Nachhinein rumhantieren möchte, halte ich es für simpler, die einfach direkt einzeln zu speichern anstatt dann wieder neu zu berechnen. Zumal, wie Kelven schon erwähnte, dann die Ziffern-Zerlegung im Wechsel mit der Bildanzeige passieren muss und das daher so aus dem Kontext gerissen eher ungünstig ist.
Wenn man natürlich weiß, dass man die nur einmal berechnet und gut ist, würde ich das auch zusammenstauchen.
Welche meinst du denn genau? Das Beispiel von BDraw sollte funktionieren.
...
Das war einfach nur eine allgemeine Erklärung zu der Funktionsweise dieses Skripts.
@BDraw
Ich liebe dich. Diesen Vorschlag werde ich ab sofort immer so umsetzen! :D #nohomo
Ein Tipp noch allgemein dazu: Die Ausgangskoordinaten kann man sich mehr oder weniger errechnen, indem man die Bildmitte von dem Bitmap der Zahlen nimmt (also Bildgröße/2) und dann von 160 abzieht... oder so. Irgendwie so ^^ Auf jeden Fall nimmt der Maker immer die Bildmitte als Referenzpixel, wenn die Bildmitte aus 2 Pixeln besteht, nimmt er immer den größeren. Die Verschiebung von 320 muss noch um die Länge der Zahl in Pixeln (z.B. 7px) erweitert werden. (EDIT: Nein, muss sie nicht :D)
EDIT: Ich hab das mal umgesetzt. Hier ist ein konkretes Beispiel. Die Grafik hat eine Breite von 3270, bei der neun hängen allerdings noch Pixel hintendran, aber wenn ich da noch 313 Px abziehen würde, würde es die Berechnung etwas verkomplizieren. Die Länge setzt sich zusammen aus: 10 Ziffern mal Bildschirmbreite 320 plus 10 mal Zahllänge 7. Das Skript generiert eine zufällige dreistellige Nummer jede Zehntelsekunde und aktualisiert. Ich weiß, dass ich das noch optimieren kann und mir vor allem über ein Call Event mehr oder weniger Arbeit sparen kann, aber das hab ich auf die Schnelle hingeklatscht, nur um schnell dahinter zu kommen wie das funzt.
Und auf die selbe Weise werde ich für die Darstellung der Items auf If-Verschachtelungen verzichten, denn das geht auch mit einer Item ID * Y-Shift Verschiebung :D
Muss man allerdings auch nicht 30 Items in ein Bitmap packen. Vertikal ist sogar besser, weil das Bitmap weniger Höhe als Breite hat. 240 < 320. Easy.
Zitat
Berechtigungen
Zitieren