DynRPG - Der Pluginwunschthread

[Corti]

Natürlich gibts das im Kampf. Packs in ein CommonEvent.

[MarcL]

Natürlich gibts das im Kampf. Packs in ein CommonEvent.

...

oO; ganz vergessen... gleich mal testen ^^; thx

[Stray]

In diesem Thread habe ich zwar schon danach gefragt, aber hier frage ich einfach noch mal, da ich denke, dass das dadurch eher Aufmerksamkeit erlangt:

Hat jemand für DynRPG schon mal pixelgenaues Scrollen programmiert? Im Moment wäre mir das fü ein Pixel-Jump'N'Run sehr hilfreich.

[Stray]

Noch mal wegen pixelgenauem Scrollen, bugmenot hat mal ein paar Ansätze(?) gepostet, die dafür scheinbar notwendig sind.

Code:

int mapOffsetX;     //positiv=rechts, negativ=links
int mapOffsetY;     //positiv=hoch, negativ=runter
int scrollSpeed;

//[...] Argumente zuweisen

mapOffsetX = mapOffsetX*16;     //16 je pixel
mapOffsetY = mapOffsetY*16;     //16 je pixel
scrollSpeed = scrollSpeed*32;   //"normal" speed = 32 (2x = 64; 1/2x = 16; ...)
( **reinterpret_cast<long ***> (0x4CDE54) ) [45] -= mapOffsetX;
( **reinterpret_cast<long ***> (0x4CDE54) ) [46] -= mapOffsetY;
( **reinterpret_cast<long ***> (0x4CDE54) ) [47] = scrollSpeed;

Zuweisung der Argumente mapOffsetX/Y und scrollSpeed per onComment callback oder so.
Frag jemanden (versuch es mal an Schalter 2), der Ahnung von C++ hat.

Edit:
Und die originalen Kamerapositionen wiederherstellen:

Code:

( **reinterpret_cast<long ***> (0x4CDE54) ) [45] = 2304;
( **reinterpret_cast<long ***> (0x4CDE54) ) [46] = 1792;

...

[bugmenot]

Danke. Seit ich im Juli dort nachgefragt habe hat keiner mehr einen Beitrag geschrieben.

...

Das klang jetzt fast schon etwas klagend darüber, dass ich nicht rausfinden wollte, wie der onComment-Kram funktioniert.


download ScreenScrollBug-in

Scrollt den Bildschirm um eine angegebene Anzahl an Pixeln.


>> SCROLL

Nutzt einen Comment mit dem Inhalt:

@scroll_screen [1], [2], [3]

[1] = Anzahl Pixel auf x-Achse (pos.=rechts | neg.=links)
[2] = Anzahl Pixel auf y-Achse (pos.=runter | neg.=hoch)
[3] = Speed (normal speed = 32, double speed = 64, ...)

Ersetze [x] mit Zahlen oder einer Var_ID mit einem vorangestellten "V"
Bsp.
"@scroll_screen 32, -5, V17"

bewegt den Bildschirm 32 Pixel nach rechts, 5 Pixel nach oben und die Geschwindigkeit wird aus Var[0017] genommen.


>> RESET

@scroll_screen_reset [1]

[1] = Speed (normal speed = 32, double speed = 64, ...)

Scrolls the screen by a specified number of pixels.


>> SCROLL

Use a comment with the contents:

@scroll_screen [1], [2], [3]

[1] = number of pixels on x-axis (pos.=right | neg.=left)
[2] = number of pixels on y-axis (pos.=down | neg.=up)
[3] = speed (normal speed = 32, double speed = 64, ...)

Substitute [x] with numbers or a Var_ID with a "V" in front
e.g.
"@scroll_screen 32, -5, V17"

will scroll the screen 32 pixel to the right, 5 pixel up and the speed is taken from Var[0017].


>> RESET

@scroll_screen_reset [1]

[1] = speed (normal speed = 32, double speed = 64, ...)

[WeTa]

Ich schlimmer Mensch witzel ja immer mal wieder ein wenig über die ganze Rumpatcherei weil in ein paar Jahren unspielbar und komplizierter als "richtige" Engine verwenden und massiver Arbeitsaufwand für kleinste Ergebnisse, aber

...

Spätestens hierfür hat sich das Ganze gelohnt!

[goldenroy]

...

...

Dann steht ja jetzt dem Zelda-Klon aufm Maker mit Pixelmovement nix mehr im Wege! °L°

[bugmenot]

Zelda-Klon aufm Maker mit Pixelmovement nix mehr im Wege

...

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.

[goldenroy]

Camera-Scrolling ≠ pixelgenaues MoveEvent

...

Der RPG-Hacker hatte ja schonmal ein Proof-Of-Concept im Rahmen des Metropolis-Projektes geschaffen, das komplett auf Pictures basierte. Ich glaube er scheiterte dann aber an größeren Maps aufgrund des Scrollings. Darauf spielte ich an.

[bugmenot]

Zelda-Klon aufm Maker mit Pixelmovement nix mehr im Wege

...

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.

[goldenroy]

Wo wir grade schon mal hier sind: Hätte jemand zufällig eine Möglichkeit, die Position des blinkenden Cursors in der Textbox zu ändern? Alternativ auch eine Möglichkeit, die ganze Textbox zu verschieben oder sowas. °J°

[Corti]

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.

[goldenroy]

Ah, hab ihn gefunden!
Für interessierte, die entsprechenden Stellen wären MsgCursorX=4C8685,XX | MsgCursorY=4C8695,XX