| |
| |
|
 | hallo frank,
sry das ich es so hart formuliere aber wenn ich solche pfade erhalte...
...kann ich nichts anderes mehr sagen! ich hab wirklich den eindruck das die funktion mit einem zufallsgenerator arbeitet!
wie du vielleicht schon gemerkt hast programmiere ich gerade ein kleines spiel in profan mit deiner dll,deswegen schreibe ich hier so viel
ich hab bis jetzt ausschließlich voller anspannung auf diesen moment hinprogrammiert in dem die sprites sich das erste mal autonom durch den hintergrund bewegen, umso größer war meine enttäuschung als ich die ersten ergebnisse sah...
in 50% aller fälle ist der pfad vollkommen hirnrissig,man hat echt den eindruck die sprites wären betrunken und torkeln am ziel vorbei!
in weiteren 25% wird garkein pfad gefunden obwohl einer da ist und die pixelbreite des weges auch schon auf 1 ist...
die restlichen 25% prozent wären vielleicht noch akzeptabel,sind aber immernoch weit vom ideal entfernt.
ohne diese (vernüftig funktionierende) funktion ist mein spiel leider zum scheitern verurteilt! selber programmieren kann man sowas auch nicht da getpixel zulangsam arbeitet! |
|
| |
| |
| |
|
|
| Hallo,
sry das ich es so hart formuliere aber wenn ich solche pfade erhalte...
...kann ich nichts anderes mehr sagen! ich hab wirklich den eindruck das die funktion mit einem zufallsgenerator arbeitet!
Natürlich ist ein kleines Quäntchen Zufall mit im Spiel...
Deine beiden Beispiele kranken aber daran, das überhaupt kein Weg gefunden werden muß, weil er nirgendwo verspeert ist...
Dafür ist FindPath auch nicht ausgelegt. Die Funktion arbeitet immer besser, je schlimmer der direkte Weg verstellt ist.
Arbeite viele Wände ein, dann merkst du es.
Nochmal zu deinen Beispielen: In dem Wegsuche Demo habe ich darauf verzichtet, zunächst den direkten Weg zu suchen, warum ein Demo unnötig kompliziert machen ?
wie du vielleicht schon gemerkt hast programmiere ich gerade ein kleines spiel in profan mit deiner dll,deswegen schreibe ich hier so viel
ich hab bis jetzt ausschließlich voller anspannung auf diesen moment hinprogrammiert in dem die sprites sich das erste mal autonom durch den hintergrund bewegen, umso größer war meine enttäuschung als ich die ersten ergebnisse sah...
in 50% aller fälle ist der pfad vollkommen hirnrissig,man hat echt den eindruck die sprites wären betrunken und torkeln am ziel vorbei!
in weiteren 25% wird garkein pfad gefunden obwohl einer da ist und die pixelbreite des weges auch schon auf 1 ist...
die restlichen 25% prozent wären vielleicht noch akzeptabel,sind aber immernoch weit vom ideal entfernt.
ohne diese (vernüftig funktionierende) funktion ist mein spiel leider zum scheitern verurteilt! selber programmieren kann man sowas auch nicht da getpixel zulangsam arbeitet!
Auszug aus der Anleitung:
Sinnvolle Werte für W gehen von 6 bis 48. Werte von 1-5 sind zu klein...
Nimm den Wert 12.
Ein paar Tips von mir:
- wenn du eine feste Landschaft zusammen mit Sprites nutzt, dann benutze besser MoveSpriteWithTable(), siehe auch die Ballersprite Demos
- baue Zusatzwände in die Maske ein, die der User ja nicht sieht, die das Sprite aber dazu veranlassen kann, einen optimalen Weg zu suchen
- bearbeite die Pathdaten mit SmoothPath(path#,anzahl&,4), das beseitigt das Torkeln.
So, noch was.
Eine FindPath Funktion ist nicht einfach zu realisieren, auch kann sie nicht auf alle Situationen angewendet werden.
Der Schwachpunkt von FindPath() sind in der Tat große Flächen ohne Mauern. In deinem Fall würde ich zuerst versuchen direkt zum Zielpunkt zu gelangen.
Wenn das nicht ging (du kannst ja abfragen, ob sich das Sprite nicht mehr bewegt und den Zielpunkt schon erreicht hat) startest du FindPath().
Ich hoffe, das hilft schon etwas.
Gruß, Frank |
|
| |
| |
| |
|
|
| habs nochmal ausführlich mit hindernissen getestet, ergebnis sieht nicht sehr viel besser aus...
die letzten 2 beispiele demonstrieren die problematik von findpath ganz gut.
die funktion versucht erst auf einer achse auf die höhe zu kommen und dann sich auf der anderen achse dem ziel zu nähern.
vom direktweg ist da keine spur zu sehen!
wie wäre es wenn du als orentierung immer den direktweg nimmst und versuchst immer auf diesen weg zu bleiben bzw. wieder dahin zu kommen wenn der weg versperrt ist?
würde um einiges besser sein als zu versuchen über die achsen zum ziel zu kommen.. |
|
| |
| |
| |
|
|
| Hallo,
Die letzten 2 beispiele demonstrieren die problematik von findpath ganz gut.
die funktion versucht erst auf einer achse auf die höhe zu kommen und dann sich auf der anderen achse dem ziel zu nähern.
Falsch vermutet !
Die Funktion teilt die Grafik in ein einfarbiges Mosaikbild auf, je größer der Wert in W, je grober das Mosaik...
Innerhalb dieses Bilds wird mittels eines Füllmechanismus (Wave-Marble) versucht, zum Ziel zu gelangen, wobei jede Station des Füllens in einer Tabelle vermerkt wird.
Wurde ein Weg gefunden, dann wird diese Tabelle optimiert, indem Schleifen (also Punkte) die doppelt durchlaufen wurden, entfernt werden. Dieser halboptimierte Path ist der, den FindPath() berechnet.
Um jetzt den KÜRZESTEN Weg zu finden, müßte ich ausgehend von allen Punkten der Tabelle untereinander eine Linienberechnung (Bresenham z.B.) durchführen (also direkt zum Ziel laufen).
Dann hätte ich tatsächlich immer den kürzestzen Weg gefunden, aber absolut auf Kosten der Geschwindigkeit. Mal abgesehen vom Aufwand.
Das würde sogar in Assembler den Rahmen sprengen 
Vielleich mache ich diesen Zusatz ja mal mit einer Option verfügbar. Momentan aber wohl nicht.
vom direktweg ist da keine spur zu sehen!
Hab ich ja nie behauptet. Das müßtest du in deinen Programm halt zuerst versuchen, direkt zum Ziel zu gelangen. Wenn das nicht klappt, läßt du dann FindPath laufen.
Gruß, Frank |
|
| |
| |
| |
|
|
| ok,sah so aus als ob du es so gemacht hättest.
würde mir ja evtl.auch noch selbst was basteln aber mit getpixel kann man ja nicht arbeiten so langsam wie das ist.
kann man da evtl.mit einem array das schneller abfragen?
würde mich freuen wenn du die funktion doch noch verbessern würdest,weil im jetzigen zustand ist ja quasi unbracuhbar... |
|
| |
| |
| |
|
|
| Hallo,
beschreib deine Idee doch mal näher, was genau möchtest du denn machen?
Meinst du nicht, du bist mit festen Pfaden besser bedient ?
Gruß, Frank |
|
| |
| |
| |
|
|
| moin,
suche eigentlich nur einen ersatz für getpixel!
dann kann ich mir selbst was programmieren(hoffentlich). irgendwie hast du es ja schon schneller hingekriegt weil bei backgroundcollision fragst du ja auch ein bitmap-array ab.
es reicht vollkommen wenn die funktion nur 0 oder 1 zurückgibt! |
|
| |
| |
| |
|
|
| Hi,
nein, dort wird tatsächlich GetPixel() verwendet...
Nimm die API Version, ist schneller als Profans GetPixel.
Aber glaub mir, eine FindPath-Funktion zu machen ist alles andere als einfach... Aber probiers halt.
Gruß, Frank |
|
| |
| |
| |
|
|
| ich wollte ja garkeine findpath funktion machen(gott bewahre),sondern es quasi on-the-way abfragen:
das bild bewegt sich auf direktem weg zur zielposition,wenn es jetzt auf ein hinderniss trifft entscheide ich wo lang das bild gehen soll: oben/unten-links/rechts
bei backgroundcollision gibt es ja nur die möglichkeit das bild abprallen zu lassen und nicht wenn möglich vorbei laufen zulassen.
aber wie wäre es hier mit einem neuen flag? wenn das flag gesetzt ist wird automatisch mit findpath ein weg um das hinderniss herum gesucht(dürfte dann ja eigentlich nicht solche unsinnigen pfade erzeugen,oder?). es soll also nur der punkt(der auf der breseham linieliegt) direkt hinterdem hinderniss angesteuert werden... |
|
| |
| |
| |
|
|
| Hi,
schöne Idee. Aber um diesen Punkt zu erkennen, müßten trotzdem alle möglichen direkten Wege gecheckt werden
Na, ich werde demnächst nochmal versuchen FindPath() weiter zu optimieren.
Gruß, Frank |
|
| |
| |
| |
|
(922)
Deutsch
English
Français
Español
Italia