Kleine RmXP FAQ

[eisRegen2k4]

wem die movement animation seiner rmxp chars auf den sack geht,
weil sie nicht flüssig genug ist, der kann sich hier abhilfe schaffen!

Feststellung:
der RMXP benutzt charset tiles, welche in der breite und in der höhe jeweils in 4
gleiche abschnitte geteilt werden (tiles)...
in diesen tiles ist jeweils ein frame der laufanimation einer charaktärfigur!
in der horizontalen ebene gesehen, zeigen die chars jeweils in die einzelnen richtungen...
in der vertikalen ebene, sind jedoch die einzelnen laufanimationen in die bestimmten
richtungen zu sehen:



für die animation wird zunächst das erste sprite angezeigt, dann das zweite...
und dann das vierte (und letzte)...
nunja... eine lauf animation aus 4 frames, das ist ungefähr so schön,
wie wenn einem ein hammer auf den kopf fällt...
(dem einen gefällts... dem anderen nicht... - ich denke mal der mehrheit nicht^^)

Idee:
Somit habe ich mir gedanken gemacht wie man eine "flüssigere" laufanimation
mit ins spiel bringen kann...
(flüssigere animation = mehr frames pro zeitabschnitt)

Grundprinzip:
das prinzip ist relativ simpel! man schaue sich folgenden code abschnitt an (default aus "Sprite_Character")
dort wo self.src_rect.set(sx, sy, ....) steht [Z. 60] wird der char gezeichnet!
und zwar auf den koordinaten x (sx) und y (sy) mit der breite @cw
(wurde in Z.47] als ein viertel der bitmapbreite deklariert) und @ch (ein viertel der bitmaphöhe) .
diese zahlen zeichnen jeweils das gegebene rechteck auf der bitmap (charset)!
bei einer animation springt dieses virtuelle rechteck jeweils um 1/4el der bitmap breite
nach rechts... [Z. 58] und zeichnet diesen bildabschnitt!
ist das letzte animationsbild gezeichnet worden springt das rechteck wieder
auf 0|0 zurück!


[codeausschnitt aus Sprite_Character]

würden wir dem programm nun sagen, dass es das charset in 8 spalten teilen
und diese in einer bestimmten zeit (verkürzt, da mehr frames!) abspielen soll, so würde eine sehr flüssige
animation zustande kommen! die zeit muss deshalb noch zusätzlich verkürzt werden,
da sonst ein slowmotion effekt auftreten würde... bei 8 frames und gleicher
"spieldauer" wäre das eine verlangsamerung um 50%^^

um nun eine derartige animation zustande zu bekommen, brauchen wir ein charset,
aus 8 mal 4 tiles (man kann zum testen auch 1 charset kopieren und nebeneinander hängen!)
sieht dann wie folgt aus, wenn wir annehmen, dass das programm die sprites
einzeln von links nach rechts abspielt:



ein charset mit sovielen sprites zu pixeln, wäre extremst aufwändig... aber machbar!

*kurzeinesmoken*

so.... wo war ich?...
ach ja:

Lösung:
nun müssen wir dem programm nur noch sagen, dass das charset in der horizontalen richtung
bei 8 tiles doppelt so oft unterteilt werden soll (also die breite der zu zeichnenden "rechtecke" halbiert werden soll!)!

das geht wie folgt:



Bemerkungen:
probiert man das nun im maker aus, so stellt man fest, das die bewegung
bei bearbeiteten laufanimationen langsamer geworden ist (ein laufzyklus in zeit 2*t)!
bei einer kopie der charset spalte, jedoch gleichgeblieben ist (2 laufzyklen in 2*t)!
um dies bei letzterem zu verhindern bietet sich an, die charset spalten [abcd]
nicht einfach zu kopieren und dranzuhängen (-> [abcdabcd]) sondern wie folgt
zu kopieren: [aabbccdd]
dadurch entsteht 1 laufzyklus in der vereinfachten version in der zeit 2*t.
t ist die zeit die ein normaler laufzyklus von 4 frames benötigt!

es empfiehlt sich beim einsetzen des scripts, alle charsets auf diese weise umzuwandeln, falls man sich nicht den
aufwand machen möchte, 8 frame animationen zu pixeln!
das resultat bleibt auf diese weise das selbe wie ohne das script (nach dem Zusatz)!
da sonst nur halbe charaktäre gezeigt werden.... *nachteil#1

Zusatz:
da die animation langsamer geworden ist brauchen wir einen weg, um das
ganze geschehen etwas schneller abzuspielen!

in der klasse Game Character (2) befindet sich die Lösung:



die variable anime_count gibt die geschwindigkeit an, mit der die frames durchlaufen!
1.5 ist default! da wir eine um 50% verlangsamte animation haben müssen wir den wert (mindestens) verdoppeln!
der wert darunter ist die framerate, bei einem schritt (also bei einer einzigen bewegung auf das
jeweils nächste tile)

hat man alles umgestellt, dürfte man nun eine flüssigere animation zu sehen bekommen

Wichtig:
- Vorher Backup von allen zu verändernden Scripten anlegen!
- Alle Charsets, die benutzt werden müssen erweitert werden! sonst werden sie nicht korrekt angezeigt!
- Der maker zeigt die sprites nicht einzeln, sondern im doppelpack an!
das linke ist jeweils das was im spiel angezeigt wird!
- Sprites von geraden spaltennummern also (1 - 2 - 3 - 4 - 5... 8)
können nicht im maker als fixed direction ausgegeben werden! (nachteil bei posen charsets!)
diese spalten erfüllen somit keinen zweck!^^
die posen müssen dann in den "ungeraden" spalten liegen!

öhm... wenn ich noch was vergessen hab oder was verwechselt hab dann korrigiert mich^^

ich werd zusehen, das ich für ein 8 wege system, laufanimationen erstelle!
also auch diagonale richtung!

[Wischmop]

Ich werde das mit diesem Thread schmelzen. Denn eigentlich ist der andere Thread dazu gedacht, genau sowas reinzuschreiben. Umsonst steht der nicht da.

[systemchaos]

Wichtig:
- Vorher Backup von allen zu verändernden Scripten anlegen!
- Alle Charsets, die benutzt werden müssen erweitert werden! sonst werden sie nicht korrekt angezeigt!*1
- Der maker zeigt die sprites nicht einzeln, sondern im doppelpack an!
das linke ist jeweils das was im spiel angezeigt wird!
- Sprites von geraden spaltennummern also (1 - 2 - 3 - 4 - 5... 8)
können nicht im maker als fixed direction ausgegeben werden! (nachteil bei posen charsets!)
diese spalten erfüllen somit keinen zweck!^^
die posen müssen dann in den "ungeraden" spalten liegen!

öhm... wenn ich noch was vergessen hab oder was verwechselt hab dann korrigiert mich^^

ich werd zusehen, das ich für ein 8 wege system, laufanimationen erstelle!
also auch diagonale richtung!*2

...

*1: Überprüfe doch mit IF wie breit die Charakteranimations PNG ist, damit man eben nicht alle PNGs anpassen muss. Wäre doch echt extrem lästig oder?
*2: Die Charaktere bewegen sich in den vorgesehenen Kästchen. Hatte schon einen 8-RichtungsMod aber der war fürn Hintern. Sah einfach nicht aus und hatte Fehler. Wenn dann hol dir n Mod um die Charaktere Pixel für Pixel bewegen zu können. Gab's hier auch irgendwo nur geht der Link irgendwie nicht.

Ist eh am Maker doof, dass man die Kolisionen nicht einfach auf die Karte zeichnen kann. Wo ist das Problem? Vor allem wäre es genial wenn man wirklich für jede Karte unendlich viele Ebenen hätte und dementsprechend unendlich Kollisionsebenen die man verknüpft um sie zu wechseln (wenn man zB eineTreppe hochgeht). Es müsste ja nicht jede Kollisionskarte ständig abgefragt werden sondern die auf der man sich grade befindet. Aber neee ... bleiben wir bei den Kästchen -.- ... ... ...

[[KoA-Dani]]

*1: Überprüfe doch mit IF wie breit die Charakteranimations PNG ist, damit man eben nicht alle PNGs anpassen muss. Wäre doch echt extrem lästig oder?

...

Bitte ? Was würde es bringen, die Größe(Breite) der PNG abzufragen ? Der Xp zerteilt die PNGs nach den im entsprechenden Script angegebenen Werten (also Standart 4 auf 4 - 16 Kästchen) und das deswegen, weil die Größe des Charsets variierbar ist. An welchen Kriterien soll ein/der Code denn erkennen, ob es sich bei der Grafik nur um ein größeres/kleineres breiteres/schmaleres Charset oder um eine andere Art von Laufanimation handelt ? Genau, garnicht. . Es sei denn, man legt eine Standartgröße fest, aber dann wären wir wieder beim 2k .-. .

*2: Die Charaktere bewegen sich in den vorgesehenen Kästchen. Hatte schon einen 8-RichtungsMod aber der war fürn Hintern. Sah einfach nicht aus und hatte Fehler. Wenn dann hol dir n Mod um die Charaktere Pixel für Pixel bewegen zu können. Gab's hier auch irgendwo nur geht der Link irgendwie nicht.

...

Ich benutze ein 8 direction Script, es ist gut und basiert nicht auf Pixelmovement. Der Link zum Pixelmovement-Script ist übrigens auch in dieser FAQ und er funktioniert auch, man muss sich im entsprechenden Forum nur anmelden/muss angemeldet sein wenn man den Link benutzt.

Es müsste ja nicht jede Kollisionskarte ständig abgefragt werden sondern die auf der man sich grade befindet.

...

Ach nein ? Was ist mit der Abfrage, auf welcher Ebene man sich befindet bzw auf welcher nicht ? Und das würde andauernd passieren o_O. Es meckern jetzt schon Leute an der performance des Makers...

[Der Drake]

Bitte ? Was würde es bringen, die Größe(Breite) der PNG abzufragen ? Der Xp zerteilt die PNGs nach den im entsprechenden Script angegebenen Werten (also Standart 4 auf 4 - 16 Kästchen) und das deswegen, weil die Größe des Charsets variierbar ist. An welchen Kriterien soll ein/der Code denn erkennen, ob es sich bei der Grafik nur um ein größeres/kleineres breiteres/schmaleres Charset oder um eine andere Art von Laufanimation handelt ? Genau, garnicht. . Es sei denn, man legt eine Standartgröße fest, aber dann wären wir wieder beim 2k .-. .

...

Nunja, ich würde es so lösen, dass man die Anzahl an Frames in den Dateinamen schreibt (zum Beispiel als Anhängsel a la f[8] wobei 8 für die Zahl der frames steht.), das könnte man dann per regexp abfragen (in diesem Fall: /f\[(\d+)\]/) und für die Berechnungen benutzen.
Man müsste nur Geschwindigkeit und Anzahl an Spalten mit einer Variable berechnen, was aber an für sich kein Problem sein sollte.

[[KoA-Dani]]

Nunja, ich würde es so lösen, dass man die Anzahl an Frames in den Dateinamen schreibt (zum Beispiel als Anhängsel a la f[8] wobei 8 für die Zahl der frames steht.), das könnte man dann per regexp abfragen (in diesem Fall: /f\[(\d+)\]/) und für die Berechnungen benutzen.
Man müsste nur Geschwindigkeit und Anzahl an Spalten mit einer Variable berechnen, was aber an für sich kein Problem sein sollte.

...

Ich meinte ja nur, dass die Abfrage der Größe hierbei nichts bringt (da es keine Standarts bei dieser gibt ^_°).
But jou, keine schlechte Lösung - kann im Gegensatz zur Abfrage der PNG größe sogar funktionieren. Gut, wer machts ? :>