Ich meinte nicht dein Video, EdF. ^^
Da sah man es doch sehr deutlich.
Ich meinte nicht dein Video, EdF. ^^
Da sah man es doch sehr deutlich.
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!
Weisst du obs auch noch möglich ist der "pan screen" so zu manipulieren dass es möglich ist ihn zwei unabhängige geschwindigkeiten zu erteilen, bzw. für horizontale und vertikale richtung?Zitat von MagicMaker
Sonst wird man immernoch auf dem hero zu benutzen angewiesen sein fürs scrollen in die eine richtung.
Liegt wahrscheinlich daran, wie schon erwähnt wurde, dass der es nur feldweiser gescrollt wird, und der qualitet des video ist auch nicht ganz toll, was wahrscheinlich auch dazu beiträgt es schwieriger zu erkennen macht.
Der char muss naturlicherweise auch ein geschwindigkeit haben der zu dem scrollen passt, was es möglich auch als tilemovement aussehen lässt.
Wenn man aber genauer hinguckt kann man schon erkennen dass es pixelmovement ist, ins besondere an das springen.
Und auch wenn es etwas schwierig zu sehen sein soll ist es umso weniger schwierig es zu fühlen wenn man es selber spielt.
Aber ja, ist schon etwas weniger ästhetisch als dem picture scroll variant.
Oh, eine Pixelmovement-Diskussion. Wieso habe ich die übersehen? Hätte so gerne auch mitdiskutiert!
Naja, vielleicht ist es ja noch nicht zu spät.
Habe jedenfalls auch mal ein Pixelmovement-System im RPG Maker gemacht, zu sehen in diesem Video ca. ab 1:00:
http://www.youtube.com/watch?v=yJTUo5xXvTc
Das ganze hat noch ziemlich viele Bugs und ist bei weitem noch nicht perfekt. Irgendwann werde ich das mal komplett neu machen und all meine Erfahrung nutzen um ein wirklich atemberaubendes System zu kreieren. Wird nur wohl nicht all zu bald sein. :P
Wie ihr seht (oder wahrscheinlich auch eher nicht, weil es in diesem Video noch überhaupt gar nicht zutrifft), habe ich das Scrolling-Problem einfach gelöst, indem ich jede Map genau einen Bildschirm groß gemacht habe. Es gibt trotzdem noch Scrolling in mit diesem System, was im Video nicht zu sehen ist. Das ist aber nur ein Scroll von Raum zu Raum, was mich damals auch auf die Idee gebracht hatte, daraus ein Zelda-Spielchen zu machen.
Bei Jump 'n' Runs ist das ganze natürlich nochmal etwas komplizierter, weil man da noch Schwerkraft ist und auf Scrolling eigentlich auch nicht wirklich verzichten kann.
Ich bin jetzt gerade dabei,die Kollision für den Boden zu machen.
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
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.
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.
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.
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.
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.
--"Ich hab von Grandy geträumt. Er hatte lange Rastas und dicke Augenbrauen, hat gekifft und gesoffen und saß vor seinem PC und arbeitete an UiD 2. Er tat mir so leid."
(by Schattenläufer)
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.
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.
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!
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.
Berechtigungen
Zitieren