"Vibration of Nature" - It's a long story
@Ryo Saeba
Es ist prinzipiell wie du sagst, nur dass es nicht ganz so extrem sein muss (es kann ruhig mehr sein als 1 Pixel pro Berechnungsschritt).
Ich wollte im Jump'n Run skript damit einfach erreichen, dass ich mit einer Pixel-Bewegung von max. 15 Pixeln pro Berechnungsschritt hinkomme.
Wenn ich da 0,1 Sekunden Wartezeit gewählt hätte pro Berechnungsschritt, wäre die Maximale Bewegungsgeschwindigkeit nicht hoch genug gewesen.
(im endeffekt habe ich glaube ich 3x 0.0 Sekunden verwendet, was also 0,05 Sekunden entspricht)
Zitat
(wenn ich den Helden in einem PP-Event mit einem 0.0Wait pro Durchlauf um einen Pixel bewege, entspricht das doch afaik schon "normal" Eventgeschwindigkeit oder? .. weiß nicht mehr genau..-> wird dann nähmlich schwierig den Helden schneller laufen zu lassen, da ja bei jeder Bewegung die Kollisionsabfragen anspringen. Das ruckelt dann recht schnell, wenn man den Helden mit 2x oder 4x faster bewegen will).
...
ein Pixel pro 0.0 Wait entspricht der 2x Slower geschwindigkeit. Schneller kriegt man es also pixelgenau nichtmehr mit dem RPG-Maker hin. Deswegen ist es auch nicht möglich, pixel für pixel zu berechnen, mal ganz abgesehen von der Tatsache, dass es eben SEHR Rechner-Belastend wäre (andererseits würden durch Pixelgenaue Bewegungen viele Extra-Abfragen wegfallen)
Im Endeffekt sollte man die Bewegungsscritte so weit einschränken, dass sich der Charakter immer um maximal ein Tile (bzw. zwei Tiles, wenn er sich schräg bewegt) fortbewegen kann. Bewegt sich der Charakter in einem Berechnungsschritt in x oder y-Richtung über 2 Tiles hinweg (was der Fall ist, wenn er sich in x oder y Richtung um mehr als 16 Pixel bewegt), so wird die Berechnung pro Berechnungschritt nochmal deutlich erschwert, weshalb man es vermeiden sollte.
Ansonsten sieht das ganze einfach so aus:
1. Man hat de aktuellen Coordinaten der Figur.
2. Man addiert die aktuelle x- und y-Geschwindigkeit zu den Coordinaten
3. Nun kommen zahlreiche abfragen, die abtasten, ob die Bewegung so auch legitim ist (bei mir artetet das leider immer in ziemlich viele sonderfälle aus, die durch viel rumprobiererei entstanden - eine richtig Saubere Abfrage hab ich hier noch nicht hinbekommen, bisher). Sollte etwas nicht stimmen, werden die neuen Coordinten nochmal umgeändert, damit es passt.
4. Mit diesen Coordianten wird nun schließlich die BEwegung angezeigt.
Der 3. Schritt ist hierbei der mit abstand aufwändigste, ja.
Zitat
Um flüssiges Scrolling zu ermöglichen, sollte man btw die komplette Umgebungsgrafik als Pictures darstellen. Nur dann kann man wirklich immer pixelgenau in alle Richtungen scrollen.
Ansonsten wird's wie Lachsen gesagt hat, etwas knifflig, da man die PanScreens (oder halt Bewegungen vom Standard-Hero, der den Screen zum Scrollen bringt) mit der Pixellaufgeschwindigkeit synchronisieren muss und nicht wirklich immer scrollen kann, wenn sich der "Pixelheld" bewegt.
...
Im Prinzip muss man nur ein etwas tolerantes Pan-Screen-Scirpt schreiben, so kompliziert ist es von der Grundidee her nicht, es benötigt nur viel feinabstimmung, bis man eine weiche, nicht nervige Screenbewegung zustande bekommt. Im Endeffekt geht es nur darum, die SzenX und SzenY-Werte der steuerbaren Figure zu berechnen (die in abhängigkeit zum Bildschirm stehen) und mit hilfe von denen zu bestimmen, ob und wohin der Screen scrollen muss. Einige kleine Tricks dabei sind:
Der Screen sollte sich nicht bei der aller kleinsten Bewegung sofort bewegen.
Stattdessen sollte es eine kleine Toleranz-Zone geben, die in der Mitte des Screens liegt. Befindet sich der Held innerhalb von dieser, wird nichts gescrollt.
Läuft die Figur in eine Richtung, sollte sich die "Toleranz-Zone" einige Felder VOR der Figur (in Richtung seiner Blickrichtung) bewegen, damit der Bildschirm nicht so weit hinterher hinkt.
Wenn der Held springt sollte die Kamera nicht gleich hochzoomen. Eine sehr gute Lösung (abgeschaut von Yoshi's Island) ist die, dass die Höhe erst dann justiert wird, wenn der Charakter sich auf dem Boden befindet (es sei denn natürlich, er befindet sich ZU nah am Seitenrand, dann muss natürlich sofort nachgescrollt werden)
Mit all diesen Tricks lässt sich auch mit Pan-Screen eine ganz passable Screen-Bewegung erreichen. Es ist imho aufjedenfall die bessere Lösung, als die gesamte Umgebung mit Pictures dazustellen oO (wenn man dies tut, kann man überhaupt nichts mehr mit Events anzeigen, auch keine schwebenden Plattformen usw. und das wäre recht hart)
Achja, und hier das Jump'n Run Skript, von dem ich die ganze Zeit rede, hab mich entschieden es mal hochzuladen:
http://ipx22052.ipxserver.de/rpg-mak.../VP-Fanfic.rar
(die Grafiken der Figur sind btw. auch selber gepixelt - wenn auch die Animation recht derbe von Lenneth aus Valkyrie Profile abgeschaut wurde - war dennoch arbeit
... naja, ich denke soviel könnte man eh nicht mit den Grafiken anfangen, dafür sind es zu wenige ^^°... Hintergründe sind btw. von Drake, mit dem ich an diesem als Fanfic geplantem Projekt gearbeitet habe - genauer gesagt sind die aus VP gerippt)
Man kann im Maker auch die Startposition auf eine andere Map setzen (nicht alle funktionieren, aber die letzten sollten schon, irgendwie). Die sind grafisch zwar nicht so schön, dafür sieht man besser, wie gut die Kollision im Skript funktioniert.
C ya
Lachsen