| |
| |
|
 | allô frank,
sry le moi es so dur formuliere mais si je solche pfade erhalte...
...peux je rien d'autre plus dire! je hab wirklich den impression cela qui funktion avec einem zufallsgenerator arbeitet!
comment du peut-être déjà gemerkt la hâte programmiere je justement un kleines spiel dans profan avec deiner dll,deswegen schreibe je ici so viel
je hab jusqu'à maintenant ausschließlich voller anspannung sur cette moment hinprogrammiert dans dem qui sprites sich cela erste la fois autonom par den hintergrund bewegen, umso größer était mon enttäuschung comme je qui ersten ergebnisse sah...
dans 50% aller fälle ist qui pfad vollkommen hirnrissig,on hat vraie den impression qui sprites wären betrunken et torkeln am but vorbei!
dans weiteren 25% wird garkein pfad trouvé quoique einer voilà et qui pixelbreite des weges aussi déjà sur 1 ist...
qui restlichen 25% prozent wären peut-être encore akzeptabel,sommes mais immernoch large vom ideal entfernt.
sans cet (vernüftig funktionierende) funktion ist mon spiel malheureusement zum échouer verurteilt! selber programmieren peux on quelque chose comme aussi pas là getpixel zulangsam arbeitet! |
|
| |
| |
| |
|
|
| Salut,
sry le moi es so dur formuliere mais si je solche pfade erhalte...
...peux je rien d'autre plus dire! je hab wirklich den impression cela qui funktion avec einem zufallsgenerator arbeitet!
Bien sûr est un kleines Quäntchen Zufall avec im Spiel...
Votre beiden Beispiele kranken mais daran, cela überhaupt ne...aucune Weg trouvé volonté doit, weil il nirgendwo verspeert ist...
Pour cette ist FindPath aussi pas ausgelegt. qui Funktion arbeitet toujours besser, je schlimmer qui directe Weg verstellt ist.
Arbeite viele Wände un, ensuite merkst du es.
Nochmal trop deinen Beispielen: dans dem Wegsuche Demo habe je puis verzichtet, zunächst den direkten Weg trop chercher, pourquoi un Demo unnötig compliqué faire ?
comment du peut-être déjà gemerkt la hâte programmiere je justement un kleines spiel dans profan avec deiner dll,deswegen schreibe je ici so viel
je hab jusqu'à maintenant ausschließlich voller anspannung sur cette moment hinprogrammiert dans dem qui sprites sich cela erste la fois autonom par den hintergrund bewegen, umso größer était mon enttäuschung comme je qui ersten ergebnisse sah...
dans 50% aller fälle ist qui pfad vollkommen hirnrissig,on hat vraie den impression qui sprites wären betrunken et torkeln am but vorbei!
dans weiteren 25% wird garkein pfad trouvé quoique einer voilà et qui pixelbreite des weges aussi déjà sur 1 ist...
qui restlichen 25% prozent wären peut-être encore akzeptabel,sommes mais immernoch large vom ideal entfernt.
sans cet (vernüftig funktionierende) funktion ist mon spiel malheureusement zum échouer verurteilt! selber programmieren peux on quelque chose comme aussi pas là getpixel zulangsam arbeitet!
Auszug aus qui Anleitung:
Sinnvolle Werte pour W aller de 6 jusqu'à 48. Werte de 1-5 sommes trop petite...
prends la valeur 12.
un paire Tips de mir:
- si du une feste paysage zusammen avec Sprites utilise, ensuite benutze besser MoveSpriteWithTable(), siehe aussi qui Ballersprite Demos
- baue Zusatzwände dans qui masque un, qui qui User oui pas sieht, qui cela Sprite mais en supplément provoquer peux, une optimalen Weg trop chercher
- bearbeite qui Pathdaten avec SmoothPath(path#,anzahl&,4), cela beseitigt cela Torkeln.
So, encore quoi.
une FindPath Funktion ist pas simple trop realisieren, aussi peux vous pas sur alle Situationen angewendet volonté.
qui Schwachpunkt de FindPath() sommes dans qui acte grand Flächen sans Mauern. dans deinem le cas serait je d'abord versuchen direct zum Zielpunkt trop gelangen.
si cela pas ging (tu peux oui abfragen, si sich cela Sprite pas plus bewegt et den Zielpunkt déjà erreicht hat) startest du FindPath().
je hoffe, cela hilft déjà quelque chose.
Salut, Frank |
|
| |
| |
| |
|
|
| habs nochmal en détails avec hindernissen getestet, ergebnis sieht pas très viel besser aus...
qui letzten 2 beispiele manifester qui problematik de findpath pas mal.
qui funktion versucht seulement sur einer achse sur qui höhe trop venons et ensuite sich sur qui anderen achse dem but trop nähern.
vom direktweg ist là aucun vestige trop voyons!
comment wäre es si du comme orentierung toujours den direktweg prends et versuchst toujours sur cette weg trop rester bzw. wieder dahin trop venons si qui weg versperrt ist?
serait um einiges besser son comme trop versuchen sur qui achsen zum but trop venons.. |
|
| |
| |
| |
|
|
| Salut,
qui letzten 2 beispiele manifester qui problematik de findpath pas mal.
qui funktion versucht seulement sur einer achse sur qui höhe trop venons et ensuite sich sur qui anderen achse dem but trop nähern.
faux vermutet !
qui Funktion teilt qui Grafik dans un einfarbiges Mosaikbild sur, je größer qui Wert dans W, je grober cela Mosaik...
dedans cet Bilds wird mittels eines Füllmechanismus (Wave-Marble) versucht, zum but trop gelangen, wobei chacun station des Füllens dans einer Tabelle vermerkt wird.
Wurde un Weg trouvé, ensuite wird cet Tabelle optimiert, indem Schleifen (alors Punkte) qui doppelt durchlaufen wurden, entfernt volonté. cette halboptimierte Path ist qui, den FindPath() berechnet.
Um maintenant den KÜRZESTEN Weg pour trouver, devrait je ausgehend de allen Punkten qui Tabelle untereinander une Linienberechnung (Bresenham z.B.) durchführen (alors direct zum but courir).
ensuite hätte je réellement toujours den kürzestzen Weg trouvé, mais absolu sur coûter qui Geschwindigkeit. la fois abgesehen vom Aufwand.
cela serait sogar dans Assembler den cadre sprengen 
Vielleich fais je cette Zusatz oui la fois avec einer Option disponible. Momentan mais wohl pas.
vom direktweg ist là aucun vestige trop voyons!
Hab je oui nie behauptet. cela müßtest du dans deinen Programme arrêt d'abord versuchen, direct zum but trop gelangen. si cela pas klappt, läßt du ensuite FindPath courir.
Salut, Frank |
|
| |
| |
| |
|
|
| ok,sah so aus comme si du es so gemacht hättest.
serait mir oui peut-être.aussi encore selbst quoi bricoler mais avec getpixel peux on oui pas travailler so lente comment c'est.
peux on là peut-être.avec einem array cela plus rapide abfragen?
serait mich freuen si du qui funktion doch encore améliorer würdest,weil im jetzigen zustand ist oui quasi unbracuhbar... |
|
| |
| |
| |
|
|
| Salut,
beschreib deine concept doch la fois näher, quoi oui c'est ca vouloir du car faire?
Avez- du pas, tu es avec festen Pfaden besser bedient ?
Salut, Frank |
|
| |
| |
| |
|
|
| moin,
cherche eigentlich seulement une ersatz pour getpixel!
ensuite peux je mir selbst quoi programmieren(hoffentlich). irgendwie la hâte du es oui déjà plus rapide hingekriegt weil chez backgroundcollision fragst du oui aussi un bitmap-array ab.
es reicht vollkommen si le funktion seulement 0 ou bien 1 zurückgibt! |
|
| |
| |
| |
|
|
| Hi,
non, là wird réellement GetPixel() verwendet...
prends qui API Version, ist plus rapide comme Profans GetPixel.
mais glaub mir, une FindPath-Funktion trop faire ist alles autre comme simple... mais probiers arrêt.
Salut, Frank |
|
| |
| |
| |
|
|
| je voulais oui garkeine findpath funktion faire(gott bewahre),mais es quasi on-le-way abfragen:
cela bild bewegt sich sur direktem weg zur zielposition,si es maintenant sur un hinderniss trifft entscheide je wohin long cela bild aller soll: dessus/unten-à gauche/à droite
chez backgroundcollision gibt es oui seulement qui möglichkeit cela bild abprallen trop laisser et pas si possible vorbei courir zulassen.
mais comment wäre es ici avec einem neuen flag? si cela flag gesetzt ist wird automatisch avec findpath un weg um cela hinderniss herum gesucht(pourrait ensuite oui eigentlich pas solche unsinnigen pfade erzeugen,ou bien?). es soll alors seulement qui punkt(qui sur qui breseham linieliegt) direct hinterdem hinderniss angesteuert volonté... |
|
| |
| |
| |
|
|
| Hi,
belle concept. mais um cette Punkt trop erkennen, müßten quand même alle möglichen direkten Wege gecheckt volonté
Na, je werde bientôt nochmal versuchen FindPath() plus trop optimaliser.
Salut, Frank |
|
| |
| |
| |
|
(926)
Deutsch
English
Français
Español
Italia