Das klang jetzt fast schon etwas klagend darüber, dass ich nicht rausfinden wollte, wie der onComment-Kram funktioniert.
download ScreenScrollBug-in
![]()
Geändert von bugmenot (21.12.2014 um 15:50 Uhr)
Camera-Scrolling ≠ pixelgenaues MoveEvent
Scheinbar ist der ganze Kamera-Kram bereits in DynRPG implementiert...
Also könnte sich - wer auch immer hier C++ kann - vielleicht dazu erbarmen zu helfen. Nein? Auch gut.
Geändert von bugmenot (22.12.2014 um 05:26 Uhr)
Es stehen dem mindestens zwei callbacks auf getEventScreen_X und getEventScreen_Y, für jedes Event jeweils immer das Neuzuweisen auf welchem Tile(X/Y) es sich gerade befindet, manuelles Nachbessern des Kamerascrolls (damit das nicht ständig rumzuckt) und ein Setzen einer entsprechend neuen MoveRoute (wegen den Animationsframes) ... im Wege. Darauf spielte ich an.
Edit²:
Es gibt intern nirgends einen Wert, welcher sichert, auf welcher Pixelposition sich ein Event / der Spieler befindet. Lediglich die Koordinaten im Tilesetraster und ein Wert (von 256 Richtung 0), der angibt wie weit sich ein Event in ein Tile hinein bewegt hat. Aus diesem Wert (0..256) und der Bewegungsrichtung (0..7) wird halt die Abweichung in Pixeln errechnet und das spuckt die interne getEventScreen_X/Y-Abfrage aus. Ändern der Bewegungsrichtung und dieses 0..256-Wertes bringt nichts, weil die MoveRoute sich selbst korrigieren will und das Events dann nur auf der Stelle laufen würde.
Das ist was "mit DynRPG ist Fast-Pixelmovement möglich" meint.
Edit:
Oder einfach onDrawEvent entsprechend die Sprites anzeigen/verschieben. Dann hat man aber keinen Zugriff auf bestehende Strukturen und kann auch kein <ChangeVar:EventScreen_X>, Eventkollisionen, MoveRoutes oder anderen default Kram nutzen.
Klar kann man alle Sprites als Pictures zeigen (oder in den Bildpuffer laden; Kazesui's mode 7 plugin macht das afaik und der Maker intern ja sowieso). Dann braucht man aber auch nicht mehr mit Tiles mappen und die Map scrollen. Dann muss halt nur noch eine eigene Struktur für Kollisionsberechnung und Eventtriggern zusammengeschustert werden.
Geändert von bugmenot (23.12.2014 um 17:08 Uhr)
Gibt irgendwo einen Quickpatch dafür. Wenn es in den nächsten Tagen keiner postet und ich wieder mal an meinen Arbeitsrechner bin, bekommst du es von mir.
--CortiWins GitHub DynRPG < Charguide < [2k3] Zahlen und Werte < [2k3] Kurven als Wertetemplates < [2k3] DynRPG Werkstatt
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Hello from the otter side
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Ah, hab ihn gefunden!
Für interessierte, die entsprechenden Stellen wären MsgCursorX=4C8685,XX | MsgCursorY=4C8695,XX
Hut ab. Fein gerechnet.
Oder anhand von Variablen neu vergeben:
download SetBlinker
(default) Var[3350+0] = y-Pos; Var[3350+1] = x-PosZitat von DynRPG.ini
Ich habe da eine Vermutung, aber:
![]()
Ich hätte mal eine Frage. Es ist ja möglich mit dem Rpg Maker 2003 (ob 2000 auch weißich nicht) nach einem Befehl der das Bild verändert, ein Show Screen zu befehligen und dadurch ändert sich diese Veränderung wie beim Show Screen. Hoffe es ist verständlich erklärt xD
Naja. Auf jeden Fall ist mein Problem, wenn man dass so macht, wird der Bildschirm aber einfrieren (heißt alle Animation und co sind wieder aus) bis der Show Screen abgeschlossen ist. Wäre es möglich eine Alternative mit einem Plugin zu erstellen?
-Soul
--