Jump and Run Pixelmovement

[Engel der Furcht]

Ich bin jetzt gerade dabei,die Kollision für den Boden zu machen.

- SCRIPT -
<> Wait: 0.0 sec.
<> Change Variable: [7] = V[25]
<> Change Variable: [8] = V[26]
<> Change Variable: [8] += 21
<> Change Variable: [7] /= 16
<> Change Variable: [8] /= 16
<> Get Terrain ID: (V[7], V[8]), Store in var. [9]
<> Fork Condition: If Variable [9] == 2 then ...
. <> Fork Condition: If Variable [10] >= 0 then ...
. . <> Fork Condition: If Variable [10] <= 1 then ...
. . . <> Change Variable: [10] = 6
. . . <>
. . : End of fork
. . <>
. : End of fork
. <>
: Else ...
. <>
: End of fork
<> Fork Condition: If Variable [9] == 1 then ...
. <> Fork Condition: If Variable [10] == 6 then ...
. . <> Change Variable: [10] = 0
. . <>
. : Else ...
. . <>
. : End of fork
. <>
: Else ...
. <>
: End of fork

...

Das ist das Event für die Terrainüberprüfung.
Variable 7,8 sind X/Y für Terrain,9 die ID.
Variable 10 ist die sogenannte "StateID",die gibt an,wie sich Lara verhält(Laufen,springen...)
StateID6 bedeutet Runterfallen
StateID0 bedeutet Stehen.
Das ganze ist aber glaube ich nicht ganz relevant.
Jedenfalls,
wenn die olle Kuh runterfällt, stoppt sie erst 5-10 Pixel unter der eigentlichen Grenze und fällt in den Boden hinein.
Wie mache ich nun,dass das Weib wirklich auf der Graskante steht?
Hier zur verdeutlichung.
http://npshare.de/files/b83c20e3/Mein%20Film.wmv

[RPG Hacker]

Hat vielleicht was mit dem Show-Picture-Befehl zu tun. Der benutzt ja immer den Bildmittelpunkt als Refferenz. Da könnte es bei Berechnungen schonmal passieren, dass ein Bild nicht ganz da landet, wo man es haben wollte.

[Engel der Furcht]

Das Bild des Spielers ist immer in der Mitte (160;120,bei Animationen abweichend)
Die Koordinaten sind aber immer richtig und das bild sitzt auch richtig.

[Kazesui]

nur jedes frame zu checken ist nicht schnell genug um rechtzeitig zu stoppen, ausser der char mit nem geschwindigkeit entsprechend "3: half normal" runterfällt.
Es gibt wohl 2 lösungen auf das problem die mir einfällt. Entweder du guckst einige pixel vorraus beim jedem check, oder du lässt ein event dich wieder auf dem korrekten höhe korrigieren bevor das bild des spielers wieder refreshed wird.

[RPG Hacker]

Was noch ein Problem sein könnte (war auch bei meinem Pixelmovement damals so): Du benutzt ja um die Terrain ID zu bekommen Map-Koordinaten und nicht Screen-Koordinaten/Pixel-Koordinaten. Da aber ein Tile ja nunmal 16x16 Pixel groß ist, könnte es vorkommen, dass das Spiel, obwohl du eigentlich schon zu 1/3 bis 1/2 auf einem bestimmten Tile stehst, immer noch DIESES Tile statt des Tiles darunter abfragt. Verstehst du, wie ich meine? Also das Tile drunter wird quasi erst dann abgefragt, wenn du schon ganz oder fast ganz auf dem Tile darüber draufstehst. Ist bisschen schwer zu erklären. Bei mir war es aber anfangs ähnlich. Oben und links machte der Held immer haargenau vor der Wand halt, unten und rechts hingegen konnte er bis zu einem Tile in die Wand hineinlaufen. Ich weiß nicht mehr ganz genau, wie ich das gelöst hatte. Ich glaube ich hatte irgendwie Berechnungen benutzt, um in bestimmten Fällen das richtige Tile zu bekommen.

[Jonn]

Ist eine Ewigkeit her, dass ich hier was gepostet habe. Aber da mich das Thema so sehr interessiert, erzähl ich mal von meinen Erfahrungen. Aber vorher fange ich mit etwas Eyecandy an. Ich hatte mal geplant Neo23 bei einem Megaman X Fangame auf dem Maker zu helfen und ihm ein auf Pixelmovement basierendes Jump and Run Skript zu erstellen. Fertig geworden ist das zwar nie und wird es wohl auch nicht mehr, aber ich habe hier noch ein Video von damals auf der Platte rumfliegen, das irgendeinen Zwischenstand dokumentiert hat.

>Video<

Dem Anschein nach konnte man bereits Laufen, Springen, Dashen, die Wand runter rutschen und von der Wand abspringen. Ich bin mir ziemlich sicher, dass ich auch schon den Air-Dash irgendwann mal umgesetzt hatte, aber das ist jetzt auch egal.

Als ich angefangen habe daran zu arbeiten, wollte ich, dass man genauso wie bei meinen Tile-Movement Systemen sich mittels Terrain IDs eine Map ganz normal zusammenklicken kann. Wenn man aber Picture-Koordinaten verwendet, kann man die Terrain ID nicht einfach so auslesen, da diese Koordinaten immer den aktuellen Bildausschnitt als Bezugssystem wählen. Das Problem habe ich gelöst, indem ich mir selbst einen Bezugspunkt definiert habe. Ich habe in die obere Linke Ecke der Map ein Event gesetzt, das Nullpunktevent. Wenn ich nun die genaue Position von Megaman abgefragt habe, habe ich einfach die Differenz zwischen den Picture-Koordinaten des Nullpunktevents und den Picture Koordinaten von Megaman gebildet. Diese Differenz geteilt durch 16 entspricht dann genau den Tile-Koordinaten auf denen Megaman gerade steht. Dadurch ließen sich im wesentlichen wieder Terrain IDs nutzen.

Ein zweites Problem bestand im Mitscrollen der Map. Wenn man die Map einfach mit Pan Screen bewegt, behält man die aktuelle Position im Bezug zum Bildausschnitt bei. Man bleibt also nicht in der Bildmitte, sondern wird durch Pan Screen einfach mitgeschoben. Das habe ich gelöst, indem ich bei jedem Schritt, den die Map mitgescrollt ist, die Position von Megaman um 16 Pixel in die entsprechende Richtung verschoben habe, so dass das Picture in der Bildschirmmitte bleibt. Dazu hab ich einen Pan Screen Schritt für den Movement Speed Normal in 8 0,0 Waits unterteilt und nach(oder vor? Weiß ich nicht mehr.) jedem Wait die Position um 2 Pixel korrigiert. Dadurch sieht das ganze flüssig aus und funktioniert wunderbar. Worauf man dabei achten muss, ist diese Positionskorrektur zu deaktivieren, sobald die Map nicht mehr scrollt, also am linken und rechten Bildschirmrand beispielsweise.

Kein Problem ist es meiner Meinung nach, dass Pan Screen nicht pixelgenau funktioniert. So lange man sich flüssig in eine Richtung bewegt, fällt es gar nicht auf. Und wenn man aus welchem Grund auch immer sich wirklich nur langsam Pixel für Pixel fortbewegt, stört es auch nicht wirklich, zumindest mich nicht. Eher problematisch ist, dass man sich dadurch auf bestimmte Bewegungsgeschwindigkeiten reduziert. 2 Pixel (Normal) oder 4 Pixel (2xFaster) pro 0,0 Wait geht, aber 3 Pixel pro 0,0 Wait ist nicht wirklich gut umzusetzen. Man kann natürlich einen Char auch mal um 3 Pixel pro 0,0 Wait bewegen, aber als kontinuierliche Bewegungsgeschwindigkeit ist das nicht geeignet.

Ansonsten konnte ich das meiste völlig analog von meinem Tile-Movement Jump and Run Skript übernehmen. Hier und da gab es noch ein paar Dinge zu beachten, zum Beispiel bei der Landung auf dem Boden: Man muss ja auf dem Bodentile immer wieder auf der gleichen Pixelreihe landen, aber da war die Modulusfunktion mein Freund. Außerdem verändert sich die Geschwindigkeit im Sprung und im Fall. In Y-Richtung bewegt man sich zunächst mit 4 Pixel pro 0,0 Wait, dann 3, dann 2, dann 1 und dann fällt man genauso wieder nach unten. Dadurch ergibt sich eine schöne, rundwirkende Flugbahn und nicht so ein hässliches Dreieck wie bei Tile-Movement. Das muss natürlich alles entsprechend im Sprungevent angepasst werden, aber vom Prinzip her ist es völlig analog zum Tile-Movement.

Nagut, wenn mir noch was einfällt, trag ich es nach. Ich find's cool, dass hier Leute immer noch an Pixelmovement auf den alten Makern rumwerkeln. Vielleicht packt es mich irgendwann auch noch mal.

[RPG Hacker]

Hier und da gab es noch ein paar Dinge zu beachten, zum Beispiel bei der Landung auf dem Boden: Man muss ja auf dem Bodentile immer wieder auf der gleichen Pixelreihe landen, aber da war die Modulusfunktion mein Freund

...

Ja, ich glaube ähnlich habe ich es auch bei mir gemacht, um zu verhindern, dass der Held in die Wand läuft. Und ich hatte übrigens - genau wie du - auch Probleme mit ungeraden Laufgeschwindigkeiten. Den Fehler habe ich bisher noch nicht ausfindig gemacht. Was passiert ist jedenfalls, dass mit 2 und 4 ppf alles super funktioniert, mit 3 ppf hingegen kommt es des öfteren mal vor, dass der Held, wenn man beispielsweise diagonal läuft, einfach in eine Wand reinläuft. Solange man die Geschwindigkeit aber nur auf gerade Werte gesetzt hat, war das kein Problem.

[Rosa Canina]

Das liegt daran, dass die Umgebung weiterhin ein 16px-Raster hat.
Du kannst den Helden also 1, 2, 4 und 8 Px gleichzeitig laufen lassen, aber KEINE andere
Zahl. Jedenfalls nicht im Normalfall, mit Tricks geht das sicher auch, ist aber halt weitaus
aufwendiger.

Da mich das Thema sehr interessierte, habe ich mich auch mal rangesetzt... und etwas
hinbekommen... yeah. Nur ohne Map-Scrolling bislang XD
Aber ich habe KA ob das EdF helfen könnte, da der Code wirklich... komplex ist.

[RPG Hacker]

Das seltsame ist aber, dass ich eben diesen Fall (ungerade Pixel) in meinem Script speziell behandelt hatte. An und für sich funktioniert die Kontaktabfrage mit Wänden ja (solange man nicht 16 oder mehr Pixel auf einmal geht). Nur wenn man diagonal läuft, taucht dieser Fehler oftmals auf.