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.Zitat von goldenroy
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.
Zitieren
