Wenn wir jeden Pixel mit einer Variable unterlegen: Ja, pixelgenaue Kollision ist möglich.
Nur weil etwas Aufwand bedeutet, heißt es nicht dass es unmöglich ist~
Wenn wir jeden Pixel mit einer Variable unterlegen: Ja, pixelgenaue Kollision ist möglich.
Nur weil etwas Aufwand bedeutet, heißt es nicht dass es unmöglich ist~
--" Bis dass die Massen jubeln 'Friss oder stirb' und ich antworte dann 'Schickt die Kakadus in den Ring' "
@Phno:
Cool, versuchs mal. Ist bestimmt wahnsinning praktisch. Wenn man von dem gigantischen Overhead absieht, den man mit Branches bei der Abfrage von Zehntausenden Variablen verursacht und dem gigantischen Speicherplatzverbrauch von Zehntausenden und viel mehr Variablen bleibt ja nur noch der Eigenaufwand. Ja du hast recht, könnte klappen! :)
Beim RPG-Spiel "Zitronengras" wo Butterbrot und ich arbeiten, verwenden wir selber pixelgenaue Kollisionsabfrage um im J'n'R Action-KS die Schüße abzufragen.
Dabei legst du einfach eine Variable auf den Mittelpunkt des Charas/Pictures und trägst via x/- die X und Y Koordinate auf die äußersten Punkte. Darauf folgt eine Abfrage und dieser Punkt wandert dann weiter. Sogesehen bräuchte man dann auch nur soviele Variablen, wie das Template breit ist.
As said, etwas als "unmöglich" abzustempeln nur weil es einem zuviel Aufwand bereitet, ist Schwachsinn. Für sowas braucht man keine Patchs und erst recht keine Bitmasken Vergleiche.
Edit: Ich spreche jetzt nicht davon, dass wir alle Pixel auf einer Map verwenden sondern nur die, die man benötigt, oder noch schlimmer, wir sprechen einander vorbei.
--" Bis dass die Massen jubeln 'Friss oder stirb' und ich antworte dann 'Schickt die Kakadus in den Ring' "
Das hat nicht wirklich was mit pixelgenauer Kollision zu tun. Du vernachlässigst so ziemlich fast alles, was mit pixelgenauer Kollision gemeint ist.Zitat von Phno
Nenn deine Kollisionsabfragen bitte anders.
Nochmal: Pixelgenaue Kollisionen, wie sie sonst durchgeführt werden, sind auf den alten Makern untragbar, absolut unpraktisch, idiotisch, unsinnig => unmöglich.
Wenn du es immernoch anders siehst, kann ich dir zwei Bilder liefern (der Einfachheit halber und um das Bitmaskenverfahren zu verdeutlichen, in schwarz/weiß) und du erstellst mir ein Projekt, in dem man diese Bilder beliebig überlagern kann und es mitgeteilt wird, sollten sich die weißen Flächen überlagern.
Du hast nicht ganz verstanden worauf ich hinaus wollte: Der Aufwand war nur als Spitze des Eisbergs dargestellt.
Kelven hat das "Warum" eigentlich auch schon erläutert.
Du wirst mir wahrscheinlich nicht glauben, aber C/C++ hat auch Grenzen und weit nicht alles lässt sich so umsetzen, wie man es gerne möchte. Ich würde eher sagen, dass du bei C/C++ viel kreativer arbeiten wirst, als beim Maker.
Geändert von Kyuu (03.11.2008 um 23:07 Uhr)
@Phno
Diese Methode ist aber dann letztendlich nichts anderes als eine tile-genaue Abfrage, es sei denn ich habe dich missverstanden. Wie definierst du z.B. Wände? Die können ja erstens nicht so wie Events abgefragt werden und wären zweitens bei einem Jump'n Run auch nicht unbedingt aus 16x16-Blöcken aufgebaut. Plattformen wären auf jeden Fall dünner und wenn der Charakter z.B. nur mit seinem Bauch die Plattform erreicht, dann landet er nicht auf ihr, sondern stürzt in sein Verderben. Eine einfache Kollision mit dem Event reicht also nicht aus. Man könnte höchstens die Standfläche des Charakters als Grundlage nehmen, obwohl es auch komisch wäre, wenn er nur noch mit einem Pixel auf der Plattform hängt.
Cool, ich hab grad einen schönen langen Post zum Thema Pixelmovement geschrieben, und als ich auf Antworten klickte, meinte das MMX, ich sei nicht eingeloggt und deswegen ging dann mein Post verloren. Sehr schön.
Jetzt fasse ich mich kurz: Pixelmovement ist machbar und nicht sonderlich schwer, wenn mans begriffen hat. Schrägen gehn auch recht einfach. Man sucht sich das Tile, auf dem man sich grad befindet und berechnet die Steigung vom linken oberen Pixel des Tiles zum Helden hin. So kann man herausfinden, ob sich der Held über oder unter der Schräge befidet, bzw. auf welcher Seite. ICh bastel grad übrigens ein AKS und ein Jump'n'Run, beide unterstützen Pixelmovement.
Und damit ihr auch wirklich zufrieden seid, mal mein Pixelmovementskript, das ich vor einiger Zeit mal hier im Forum vorgestellt hatte:
hier klicken
So, schnell posten und weg! Tschüss!
--
Bezüglich Strategiespiele... hat schon mal jemand Tactic Ogres versucht nachzubauen? Das Spiel hat zwei Ebenen - auf der einen Hand die Karte und auf der anderen die Kampfscreens. Auf der Karte zieht man nur Figuren herum und auf den Screens werden die eigentlichen Kämpfe zwischen kleinen Gruppen von Einheiten ausgetragen. Das müsste sich doch mit wenig Aufwand auf den RPG Maker übertragen lassen? Das Problem dabei wäre, dass man eine Möglichkeit finden muss, bis zu zehn Parties zu verwalten...
Bezüglich Actionspiele... ist ein Action-KS mit dem Tilesystem des Makers nicht vorstellbar? Man müsste eben mehr auf Timing gehen und die Pixelgenaue Abfrage auf einen Kreis um die Figuren beschränken.
Zu ein paar anderen Sachen, die mir inzwischen ins Auge springen, werde ich mich auch noch mal äußern.
--
also das bezieht sich jetzt alles auf den xp und eigene erfahrungen (ausgenommen simutlation, siehe unten)
nungut action ist recht allgemein...nen shooter ist machbar und gar nicht so schwer, vorausgesetzt man versteht was von rgss.
hab sogar mal nen online 2d shooter mit maus steuerung (ähnlich cs 2d) basierend auf dem np2+ system gemacht. funzt theoretisch auch....mal abgesehen davon, dass der server so lahm ist, dass der getroffene spieler erst 2 sec später den schaden bekommt. was bei echtzeit spielen fatal ist :/
aber offline für single player ist ein solches actionspiel nicht schwer
ebefalls möglich sind strategie spiele, sowohl echtzeit als auch rundenbasiert.
...wobei eine maximale einheitengrenze (wie zb bei empire earth nur viel niedriger) unumgänglich ist, da es sonst zu sehr laggt.
pathfinding muss nicht in echtzeit geschehen! nichtmal bei echtzeit strategie spielen.
bei dem script wird eine tabelle mit der entfernung (weg nicht luftlinie) zum ziel erstellt.
wenn nun die tabelle mit dem ziel goldmine (beispiel) vor dem spiel erstellt wird, kann man sofort darauf zugreifen ohne lade/rechen-zeit. funktioniert halt nur bei festen zielen....bäume die gefällt werden und danach nicht mehr existieren sind also unpraktisch für ein rmxp strategie spiele.
rundenbasiert ist das ganze um einiges einfacher. das Fire Emblem KS zum beispiel ist ohne weiteres machbar (momentanes projekt *werbung mach :P*)
simulation? nungut noch nicht ausprobiert, sollte aber gehen. allerdings nicht mit den standart events des xp.
heißt...erstmal alle script löschen und komplett neu schreiben.
von daher wäre es praktischer das ganze ohne den maker zu machen....schließlich bleibt nichts mehr von übrig xD
nur blöd wenn man nur ruby kann un deshalb ein ausweichen nicht möglich ist -.-'
Berechtigungen
Zitieren
