Detail-Wissen und Geheimnise des RPG-Makers -vorallem für Erfahrene/Profis lehrreich

[RPG Hacker]

Gut, dann lösch ich die Beiträge eben wieder... Wenn es überhaupt geht!

EDIT: Das man auch das Gamepad für Sonderfunktionen nutzen kann hab ich aber nicht in der Anleitung gefunden, deswegen lasse ich es auch stehen!

[Beril]

Mir sind einige Kleinigkeiten aufgefallen.

zB war mit noch nicht bewusst, dass man im Testmodus mit F10 ans ende des gerade aktiven Events springt...

Ich hate neulich ein Problem, von dem ich allerdings nicht sagen kann, ob es generell auftritt oder wieso es auftritt. Ich hatte ein CE, das ich in ein map-event kopiert habe und musste feststellen, dass, sobald ich einen Loop in diesem Event "verlassen" wollte (durch labels oder breaks) das Spiel abstürzte und die Fehlermeldung "??????? RPG_RT xxxxxx Reading xxxxxxx2D ???????" oder so ähnlich brachte. Als das Event wieder unter den CE's ausgeführt wurde, klappte es wieder.

Wenn man zwei Events auf "Over Hero" stellt, wählt der Maker nicht nach Event ID, sondern scheinbar willkürlich fest welches der beiden Events über dem anderen angezeigt wird.

Clear Timer funktioniert übrigens nicht in CE-Events, die auf Autostart stehen.

Tschau, Ich bin raus
Beril ^^

[Caine Luveno]

Bezüglich eiens anderen Threads ist mir das gerade nochmal eingefallen:

Bei dem Befehl "MoveEvent" werden zwischen "StartJump" und "EndJump" scheinbar keine anderen Befehle außer Richtungsangaben ausgeführt (MoveUp, MoveDown, MoveLeft, MoveRight).

Hab das ein paar mal getestet und es scheint sowohl für den RM2k als auch für den RM2k3 zu gelten.

Das erste mal ist mir das aufgefallen als ich via "ChangeGraphic" im MoveEvent während des Sprunges eine Animation erstellen wollte, diese aber nie ausgeführt wurde.

[Cloud der Ex-Soldat]

Mir ist da noch was aufgefallen!
Es gibt anscheinend immer noch Einige die dass nicht wissen:
(obwohl das zum Grundwissen gehört)

Du hast einen Fork erstellt willst ihn aber wieder löschen,
den Inhalt des Forks allerdings kopieren...
Halte Shift gedrückt und geh einfach mit den Pfeiltasten
nach unten, so markiert man sie. Dann kann man diese kopieren^^

[natix]

Du hast einen Fork erstellt willst ihn aber wieder löschen,
den Inhalt des Forks allerdings kopieren...
Halte Shift gedrückt und geh einfach mit den Pfeiltasten
nach unten, so markiert man sie. Dann kann man diese kopieren^^

...

Du kannst auch einfach einen Befehl makieren, deine Befehlsliste weiter runter gehen (Den Befehl aber markiert lassen) und mit gedrückter SHIFT Taste auf einen anderen Befehl klicken. Alles was zwischen den beiden Befehlen liegt und die Befehle werden dann markiert.

Ist im Grunde das selbe, ich wollte nur nochmal drauf aufmerksam machen, dass es mit der Maus auch möglich ist, das spart Zeit.

[MouseChaser]

Das klappt so ziemlich überall unter Windows.

[Cloud der Ex-Soldat]

Ja natürlich geht das überall^^
Ich sagte ja auch, dass es eine Grundfunktion ist.

@BW-Gamer: Ja gut, hast schon recht. Mit Maus gehts natürlich auch^^

[Fleräter]

Ich weiß nicht obs schon irgendwo hier steht ( habs nicht gefunden) aber weiß jemand wie lange die Befehle "Face UP", "Face Down" .... dauern?

[Nathrael]

Wenn du die Zeit für einen Wait brauchst: Gib einfach 0.5 Sekunden ein, das müsste genügen.

[Ryo Saeba 1000]

Die Verwendung der Show Picture Picture Befehle des RPG Maker 2000 und 2003 kostet sehr viel Systemleistung. Dies hängt zwar auch von der Größe des Bildes ab, aber auch wenn es sich nur um kleine Bilder von 16x16 Pixeln handelt, fängt das Spiel (besonders auf etwas älteren Rechnern) an zu stocken, sobald man mehrere dieser Befehle kurz hintereinander ausführt. Bei größeren Bildern kann es wie gesagt auch schon bei nur einem Show Picture Befehl auf älteren PCs zu einem kurzen, rapiden Einbruch der Framerate kommen.

Dies war übrigens das größte Problem bei einem meiner Kampfsysteme, bei denen ich Gegner und Held durch Bilder anzeigen ließ.

Die Lösung hierzu mag zuerst banal erscheinen. Einfach keine Show Picture Befehle verwenden!
Solange man ein Bild nur bewegen muss, kann man dies ja bequem und ohne Ruckeln, per Move Picture Befehl. Aber was soll man machen, wenn man eine andere Animationsphase anzeigen möchte? Wie kommt man nun um den Show Picture Befehl herum?
Man könnte einfach alle benötigten Animationsphasen einmal zu Beginn des Spiels per Show Picture anzeigen lassen, dadurch würde es einmal am Anfang (vielleicht beim Betreten der Map) zu einem Einbruch der Framerate kommen.
Dann könnte man einfach die benötigte Animationsphase per Move Picture Begfehl anzeigen lassen und nicht benötigte per Move Picture Befehl mit 0.0 Wait auf transparent schalten (oder besser noch außerhalb des Bildschirmausschnittes bewegen), so kann man, allein durch Move Picture Befehle, immer zwischen einzelnen Bildern (Animationsphasen) wechseln, ohne Show Picture Befehle verwenden zu müssen. Diese Idee hab ich btw von ZidanneFFIX ^^'.
Der Schwachpunkt dieser Methode ist aber offensichtlich. Man kann nur maximal 20 (rm2k ohne Patch) bzw. 50 (rm2k3) verschiedene Animationsphasen per Show Picture gleichzeitig zu Beginn anzeigen lassen.
Dies ist natürlich recht wenig, so dass man meist doch gezwungen ist, hier und da mit Show Picture Befehlen zu arbeiten.

Aber auch dafür gibt es eine Lösung! Man könnte einfach ALLE Animationsphasen einer Spielfigur, in bestimmten Abständen, in einer Reihe untereinander auf ein einziges Bild packen. Diese Abstände müssen so groß sein, wie der Bildschirm hoch ist, sodass niemals zwei Animationsphasen gleichzeitig auf dem Bildschirm zu sehen sein können. Diese Zwischenräume müssen dann natürlich auch, dank transparenter Farbe, durchsichtig sein.
Hier ist zB. ein Beispielbild, auf das 4 Animationen (rot gekennzeichnet) mit 16x16Pixel Größe passen würden (Weiß muss hier die transparente Farbe sein):


Will man nun eine andere Animation anzeigen, muss man das Bild einfach nur, per Move Picture Befehl, in Y-Richtung verschieben. Diese Verschiebung soll natürlich abrupt sein, also sollte man hier den schnellstmöglichen Move Picture Befehl mit 0.0 Wait wählen. Zu beachten ist aber, dass man dann nicht unmittelbar danach im Code einen weiteren Move Picture Befehl verwenden kann, da sich Move Picture Befehle ja überschneiden (was ja sicher den meisten bekannt ist). Man müsste also nach diesem Move Picture 0.0 Wait Befehl auch den Code um 0.0 Wait unterbrechen (zb. durch einen entsprechenden Wait Befehl), bevor man weitere Move Picture Befehle, die sich auf dieses Bild beziehen, ausführt.

Neben dem "Performanceboost" ist es auch unglaublich praktisch, alle Animationsphasen auf einem einzigen Bild zu haben. So kann man Animationen per Variable über ein und denselben Move Picture Befehl ansprechen, wo dies vorher nur durch unterschiedliche Show Picture Befehle möglich war und wenn man mal was an seinen Animationen ändert, muss man nur ein Bild neu drüberkopieren, und nicht zig Bilder neu importieren.
Die Idee hab ich übrigens von Zeph (hier afaik unter DR_Zeph registriert, Dank an ihn!).
Hier noch ein paar Anmerkungen dazu, die ich schon im Quartier gepostet habe:

Anzumerken ist aber, dass man die Animationen wirklich nur übereinander auf das Bild packen sollte. Ich habe es mit übereinender und nebeneinander gleichzeitig probiert und hatte dann ein Bild von 1024x768 Pixeln. Dabei kam es dann aber zu heftigen Einbrüchen der Framerate bei mehreren gleichzeitigen Move Picture Befehlen.
Keinerlei Probleme scheint es aber bei besonders hohen aber schmalen Bildern zu geben (wie das, das Zeph gepostet hat).
Ich verwende zur Zeit ein 48x8976 Pixel großes Bild (32 Animationen von 48x48 Pixel Größe), habe es aber schon mit bis zu 65000 Pixel hohen Bildern getestet, es lief ruckelfrei bei 20 gleichzeitigen Move Picture 0.0Wait Befehlen (in einem PP Event mit abschließendem gesetzten 0.0 Wait) auf meinem 750MHz Test PC.
Auf so ein Bild würden dann um die 224 verschiedene 48x48 Pixel große Animationen passen.

Importieren muss man die mit der guten alten Methode, die in einer der Makersmind Ausgaben erläutert wurde. Erst kleines "Dummie Bild" importieren (selbe Farbpalette!, sonst ist die Transparenz beim großen Bild falsch) und dann einfach das große Bild über das "Dummie Bild" im Picture Ordner drüberkopieren.
Da man vorher ein kleines Bild importiert hat, dürfte es eigentlich auch keinen Map Tree Data Break Fehler geben.. hoffe ich zumindest xD

Die Grenze scheint hier also nicht der RPG Maker zu sein.. sondern meine Bildbearbeitungsprogramme ^^'
IDraw macht bei einer Größe von 10000 Pixeln schlapp, das gute alte Paint bei 65535 Pixeln. An "professionelleren Programmen" hab ich nur Gimp getestet, das kommt zwar auch mit größeren Bilder klar, wenn ich da das Bild allerdings als PDF speichere, ist die entstehende Datei WESENTLICH größer als die mit IDraw oder Paint gespeicherten Bilder.
Mein 48x8976 Bild ist nicht mal 4KB groß^^ mit Gimp werden die Bilder aber zigmal größer oO
Gimp scheint also noch irgendwelche anderen Dinge mitzuspeichern.. vielleicht gibt es da noch irgendeine Option im Speicherdialog, die ich übersehen hab kA.
Aber naja, 65000 Pixel reichen sicher aus, ist nur leider etwas unkomfortabel mit dem alten Paint auf so großen Bildern rumzuscrollen und diese zu bearbeiten ^^'

Nebenbei habe ich übrigens auch noch herausgefunden, dass angezeigte Bilder an der Systemleistung zehren, auch wenn sie auf transparent geschaltet sind, oder sich nur ein transparenter Teil des Bildes auf dem Bildschirmausschnitt befindet.
Man sollte also nicht verwendete Bilder nicht auf transparent schalten, sondern per Move Picture Befehl, zu einem Punkt außerhalb des Beildschirmausschnittes bewegen, da kosten sie keine Systemleistung.

...

[Greyce]

Importieren muss man die mit der guten alten Methode, die in einer der Makersmind Ausgaben erläutert wurde. Erst kleines "Dummie Bild" importieren (selbe Farbpalette!, sonst ist die Transparenz beim großen Bild falsch) und dann einfach das große Bild über das "Dummie Bild" im Picture Ordner drüberkopieren.
Da man vorher ein kleines Bild importiert hat, dürfte es eigentlich auch keinen Map Tree Data Break Fehler geben.. hoffe ich zumindest xD

...

Sehr nützlicher Hinweis.
Vorallem wenn es sicher keinen Map tree Data Error gibt ^^
Das ganze wäre in KS und Menüs sicher extrem hilfreich, spart nochdazu
Systemressis (und Speicherplatz??, werd das mal mit einem Grafikprog ausprobieren)

Wenn man auf Nummer sicher gehen will muss man halt ein 640x480 Pic
importieren. Darauf würde man aber nur 4 Animationsstufe bringen.

Obwohl es auch schon bei 4 Stufen hilfreich wäre, weiß ich jetzt nicht
ob sich das von der Größe(wahrscheinlich minimaler Unterschied) rentieren würde.
Aber der Übersichtlichkeit würde wegen wäre es sicher überlegenswert.

Nebenbei habe ich übrigens auch noch herausgefunden, dass angezeigte Bilder an der Systemleistung zehren, auch wenn sie auf transparent geschaltet sind, oder sich nur ein transparenter Teil des Bildes auf dem Bildschirmausschnitt befindet.
Man sollte also nicht verwendete Bilder nicht auf transparent schalten, sondern per Move Picture Befehl, zu einem Punkt außerhalb des Beildschirmausschnittes bewegen, da kosten sie keine Systemleistung.

...

Heißt dass, so lange auch nur ein einziger Pixel eines Bildes im Bildschirmausschnitt ist, wird die Systemleistung beansprucht, aber sobald
es außerhalb des Bildschirmausschnitts ist braucht es keine Systemleistung mehr
(braucht es keine oder weniger Systemleistung)

Eine Frage hätte ich da noch:
Ich gehe da mal von meinem Pic aus.
Sagen wir der rote Punkt wäre ein Menüpunkt und ich will ihn mit 4 animationsstufen einblenden lassen. Wenn ich das jetzt per Move Pic Befehl mache würde es sicher weniger Systemressis brauchen, da das Pic aber größer ist wieder mehr und somit wäre es egal ob man ein 4x320 oder 1x640 verwendet.

Deine Methode gefällt mir btw super, aber es ist einfach ein bisschen unsicher
wegen dem importieren.

~Waradience~

[Ryo Saeba 1000]

Sehr nützlicher Hinweis.
Vorallem wenn es sicher keinen Map tree Data Error gibt ^^

...

Wenn.. wie gesagt kann ich da nichts garantieren, bei mir trat dieser Fehler jedoch noch nicht auf und ich arbeite schon eine geraume Weile mit dieser Methode.

Wenn du auf der sicheren Seite sein willst, kannst du natürlich auch bis zu vier Animationsphasen auf ein Bild packen, dass nicht die 640x480 Grenze übersteigt.
Das Bild sollte aber bei vier 16x16 Pixel Animationsphasen nicht so wie das von dir gepostete Aussehen, sondern, damit du die optimale Performance (geringste Bildgröße bei maximaler Anzahl Animationsphasen) herauskriegst, so:


Das ist immer noch definitiv besser, als die vier Animationsphasen per Show Picture zu realisieren, was die Performance angeht.

Eine Frage hätte ich da noch:
Ich gehe da mal von meinem Pic aus.
Sagen wir der rote Punkt wäre ein Menüpunkt und ich will ihn mit 4 animationsstufen einblenden lassen. Wenn ich das jetzt per Move Pic Befehl mache würde es sicher weniger Systemressis brauchen, da das Pic aber größer ist wieder mehr und somit wäre es egal ob man ein 4x320 oder 1x640 verwendet.

...

Hä? Angenommen deine Animation ist nur dieses rote Quadrat, dann brauchst du, wenn du die althergebrachte Show Picture Methode verwendest, auch nur ein 16x16 Pixel großes Quadrat anzeigen und kein 320x240 Pixel großes Bild.
Daher sollte die Frage lauten:
zeigt man die Animationen mit
a) vier Bildern (je 16x16 Pixel) per Show Picture Befehlen an oder
b) mit einem Bild (352x272 Pixel) per einmaligem initialisierenden Show Picture Befehl und anschließenden Move Picture Befehlen.

Und auch hier ist die zweite Variante weniger leistungshungrig.
Einzig die Initialisierung des Bildes (Show Picture Befehl beim betreten der Map) kann kurz ruckeln auf älteren Rechnern, die Move Picture Befehle dürften aber dennoch weit weniger Leistung kosten, als die Show Picture Befehle, trotz der Größenunterschiede der Bilder.