PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Pixelmovement



Kelven
05.06.2007, 11:29
Mich würde mal interessieren wie weit die Pixelmovement-Scripte für den XP schon fortgeschritten sind. Als ich mir damals eines heruntergeladen habe, hat das nur beim Helden (also nicht per Set Move Route) funktioniert und wenn ich mich nicht irre auch nur die Tileset-Einstellungen für die Kollisionsabfrage benutzt. Nicht dass ich vor hätte ein Spiel mit Pixelmovement umzusetzen - deswegen suche ich auch keine Scripte - es geht mir nur um die Theorie.

Wenn man nur die Tileset-Einstellungen für die Kollisionsabfrage benutzt, ist das ja sehr ungenau. Ich hab nun im Internet mehrere Techniken gefunden, mit denen sich die Kollisionsabfrage genauer hinbekommen lässt, aber ich weiß nicht inwieweit das schon für den XP gescriptet wurde.

Die einfachste Möglichkeit sind Rechtecke, die man um die Sprites zieht und testet, ob sie sich überschneiden. Dazu hab ich sogar eine Formel gefunden, die aber falsch war und die erst funktionierte, nachdem ich willkürlich etwas umgeschrieben habe, ohne zu wissen was. ;) Dabei stellt sich nur die Frage, wie man die Rechtecke zur Laufzeit generiert. Zwar haben die Sprites schon von vorne rein ein Rect-Objekt, aber soweit ich weiß ist das nur die äußere Begrenzung, also wäre die Abfrage nicht besonders genau. Außerdem müsste man sich bei den Tilesets was einfallen lassen.

Auf die Methode mit den Rechtecken aufbauend, könnte man auch gleich Polygone benutzen, bei denen sich relativ leicht ermitteln lässt (zumindest sagen das die Seiten, auf denen ich die Methode entdeckt habe), ob zwei sich überschneiden. Diese Methode ist wohl genauer als der Sonderfall Rechteck, aber man müsste trotzdem noch wissen, wie man den Sprites Polygone zuordnet.

Eine sehr genaue (und wohl auch sehr rechenintensive) Methode ist ein pixelweiser Vergleich der Sprites. Dafür müsste man für jedes Sprite eine Bit-Maske anlegen, je nachdem ob die Farbe transparent oder nicht transparent ist das Bit setzen und dann die Masken zweier Sprites miteinander vergleichen (mit einem UND). Ist halt nur die Frage, ob der XP das performance-technisch überlebt und wie man das konkret in ein Script umsetzen kann.

Nun ja, meine Frage ist nun, ob es schon Scripte gibt, die eine genaue Kollisionsabfrage umsetzen bzw. ob jemand eine Idee hat, wie man so etwas auf dem XP umsetzen könnte.

Expresseon
05.06.2007, 14:33
Habe ich das richtig verstanden?
Die Kollisionsabfrage, also auch Passierbarkeit der Tileset-"Objekte" (also Bäume, Häuser, Zäune usw...) soll so funktionieren, dass sie für alle 8 Richtungen abgefragt wird? Ich stelle mir das sehr schwer vor, da ja der Maker selbst nur auf 4 Richtungen programmiert ist.

-KD-
05.06.2007, 14:39
Das einfachste wäre imo einen Kollisionsplan zu zeichnen. Einfach ein schwarz-weißes Panorama für die Map (oder das Tileset). Schwarze Flächen sind nicht begehbar, weiße schon.

Ich hab das sogar mal für ein Jump&Run Experiment ausprobiert. Dabei malte ich ein schwarz-weißes Panorama, welches das Level darstellen sollte. Die Spielfigur war ein von Ruby gezeichneter roter Ball, der sich durch das Level per Pfeiltasten bewegen, schwarze Flächen jedoch nicht betreten konnte.

Man kann natürlich auch direkt das Tileset abfragen, aber dann kriegt man Probleme mit Objekten, die über dem Helden angezeigt werden sollen. Beispielsweise ein Fass, dessen unterer Teil blockiert, dessen oberer Teil "begehbar" sein soll. Blendet man über das Tileset eine schwarz-weiße Kollisionsmap ein, kann man die ovale Grundfläche des Fasses blockieren und so ein noch genaueres Ergebnis erzielen.

Diese Methode ist sicherlich genau, allerdings hab ich sie nur bei einem Pixelgroßen Punkt ausprobiert XD Bei einem Character müsste man trotzdem auf ein Rect zurückgreifen und abfragen, ob dieses Rect einen weißen oder schwarzen Pixel berührt.

Zu den Polygonen: Bei meinem Jump&Run-Experiment wollte ich Vektoren nutzen, womit wahrscheinlich das gleiche gemeint ist wie deine Polygone. Bei Vektoren kann man super abfragen, ob sie sich schneiden. Außerdem fressen sie sich nicht so viel Rechenkapazität. Das Zuweisen der Vektoren zu den Grafiken braucht man ja nicht zur Laufzeit machen. Allerdings ist es sicherlich nicht leicht so einen Vektorzuweisungsvorgang zu automatisieren.

Letztlich hab ich mich aber nie für Pixelmovements interessiert, daher kenne ich auch den aktuellen Stand nicht. Tatsache ist, dass so ein Feature Unmengen an Performance frisst und man daher möglichst auf solche Spielereien verzichten sollte, wenn man sie nicht unbedingt braucht. Letztlich erschwert Pixelmovement nur die Steuerung, bringt aber selten irgendwelche Besserungen (kommt natürlich auch drauf an, wie sehr der Autor dieses Feature für die Spielmechanik ausnutzt).

@P-Games: X_x Nein. Der Maker kann problemlos mit 8 Richtungen arbeiten.

Macros
05.06.2007, 17:16
Eine sehr genaue (und wohl auch sehr rechenintensive) Methode ist ein pixelweiser Vergleich der Sprites. Dafür müsste man für jedes Sprite eine Bit-Maske anlegen, je nachdem ob die Farbe transparent oder nicht transparent ist das Bit setzen und dann die Masken zweier Sprites miteinander vergleichen (mit einem UND). Ist halt nur die Frage, ob der XP das performance-technisch überlebt und wie man das konkret in ein Script umsetzen kann.

Es gibt bereits ein Pixelmovement-Script, welches genau so funktioniert.
Ich benutze es selber. Funktioniert fabelhaft ist von einem deutschen Entwickler und ist recht ressourcenfreundlich. Außerdem hat es sehr viele Features.

Es funktioniert (kurzgefasst) wie folgt :
Man kopiert jedes Tileset und jedes Autotile in einen speziellen Ordner. Dannach werden alle nicht begehbaren Flächen schwarz gefärbt, wären begehbaren Flächen weiß bleiben.
Bei Events und dem Helden wird einfach die Größe in Pixeln angegeben (es wird keine Maske angelegt).

Es ist weitaus genauer in der Demo beschrieben.
Link zum Forenbeitrag (http://www.rmxp.org/forums/showthread.php?t=624) (ich konnte die Präsentation im deutschen Forum nicht mehr finden)

Pixelmovements-Script 1.4 von f0tz Bärchen (http://npshare.de//files/35/2134/Pixelmovement1.4.rar)

Expresseon
05.06.2007, 18:15
Das Skript ist wirklich gut, wenn man auch durch die Events laufen kann...
Auf Rechnern unter 1024 RAM wie meinem ist es aber zu langsam / es ruckelt.

Macros
06.06.2007, 20:37
Das Skript ist wirklich gut, wenn man auch durch die Events laufen kann...
Auf Rechnern unter 1024 RAM wie meinem ist es aber zu langsam / es ruckelt.
Normalerweise kannst du nicht durch die Events laufen. Sicher, dass du alles so gemacht hast, wie es in der Readme steht?

Expresseon
06.06.2007, 21:11
Nein, hab ich nicht. Danke, dass du mich drauf hingewisen hast, denn schließlich war die Demo ja nicht ganz fertig. Es ist trotzdem sehr verlangsamt, da ich nur 512 MB RAM besitze - naja...