XProfan

allô Sven,

enfin suis je en supplément gekommen mon adventure plus trop programmieren et den findpath befehl einzufügen... hab mir entier joli zeit gelassen, pour dass qui befehl sur mon bitten hin eingefügt wurde

sorry, wird pas wieder vorkommen.
-quelque chose plus präzision (aussi sur coûter qui rechenzeit) wäre déjà très hilfreich, es sollte pas son, dass qui spieler sich den 20fachen weg pouvoir um à einem arbre vorbeizulaufen, qui avant seiner nez steht.

bof, den 20fachen Weg legt il sûrement pas zurück, cela hab je encore pas erlebt.
Es liegt oui aussi à qui Grobheit des eingestellten Rasters (paramètre W). Ist qui Wert trop grand, müßen qui Mauern très breit son, ist il trop petite, ensuite wird qui Weg droite ungenau et qui Berechnung dauert longtemps. là dois du deinen passenden Wert pour deine jeweilige Programmation trouver.
bien sûr, und dir aussi encore genauer, je pourrait qui Wegfindung so programmieren, cela toujours qui optimale Weg trouvé wird. en supplément devrait de chaque Punkt qui berechneten Tabelle trop chaque Punkt une Bresenham Linienkonvertierung durchgeführt volonté et chacun Punkt chacun ligne number verglichen volonté, si un Weg dorthin libre ist. cela serait mais (si Assembler ou bien pas) demaßen longtemps dauern, cela un vernünftiges Spiel so pas plus programmiert volonté pourrait.

-cela geforderte noir/sais masque muss oui c'est ca invertiert son im comparaison trop SetBackAutoCollision - cela peux sûrement pas gewollt son. so muss je zweimal un et qui selbe masque bereitstellen chez qui jeweils seulement noir et sais vertauscht ist.

oui, par-dessus J'ai eu mich aussi im Nachhinein geärgert, cela était wohl mon faute...
mais ensuite besoin du plan une Bitmap plus, sollte oui pas cela Riesenproblem son.
Invers kopieren allez mittels CopyExtBmp(...) (Kopiermodus 4).

-cela thema J'ai eu Schonmal angesprochen et du meintest es sei très compliqué et rechenaufwendig trop lösen - mais ist seeehr important! si je 4 richtungen pour une sprite benutze ist alles ok, mais qui schrägstellungen volonté meiner attitude pour pas korrekt gesetzt, alles quoi pas 100% justement ist benutzt qui schräg-frames. cela devrait viel plus gerecht aufgeteil son. dessus = -22,5° jusqu'à +22,5°,rechtsoben = +22,5 jusqu'à +77,5° ensuite folgt à droite avec +77,5° jusqu'à 110° - wobei qui idealrichtun chez meiner auflistung toujours dans qui mitte qui beiden werte lag.
chez einem MoveSpriteWithTable devrait alors seulement encore qui winkel aus jeweils 4 koordinaten berechnet volonté et so la direction zugeordnet volonté. si es trop viel rechenzeit braucht peux on es doch optionnel einbauen, car so comme maintenant ist spart on sich besser qui schräg-richtungen, cela sieht nämlich très merkwürdig aus.

Hehe. Es hat ici keinen Sinn, Winkel trop berechnen weil qui Differenz entre deux Punkten (speziell dans Kurven) souvent très petite ist, quelquefois seulement un / deux Pixel ou bien sogar 0 (chez einer Achse). et Punkte überspringen allez aussi pas toujours (speziell chez geraden Strecken)...
dans deinem le cas dois du qui Animation per main berechnen, mußte je chez meinem Spiel Asteroid aussi, ging pas anders. Hole qui qui Position des Sprites et qui dernier (bzw. prochain) Position votre Sprites (im Beispiel fx& et fy&). ensuite berechnest du den X-Offset dans qui Bitmap et mets de main qui neue Animation:
Kompilieren Marque Séparation

x&=-1
Case (fx1&>1):x&=6*48
Case (fx1&<-1):x&=2*48
Case (fy1&>1):x&=4*48
Case (fy1&<-1):x&=0*48
Case ((fx1&>3) and (fy1&>3)):x&=5*48
Case ((fx1&<-3) and (fy1&<-3)):x&=1*48
Case ((fx1&>3) and (fy1&<-3)):x&=7*48
Case ((fx1&<-3) and (fy1&>3)):x&=3*48

If x&<>-1

    SetSpriteAnim(raum1&,x&,0,48,48,1,1,8)

allô frank,

peut-être pas den 20 fachen weg mais déjà un le détour, qui den adventure helden comme trottel erscheinen peut

so dans etwa: [...]

>cela serait mais (si Assembler ou bien pas) demaßen longtemps >dauern, cela un vernünftiges Spiel so pas plus programmiert >volonté pourrait.
es muss erstens pas qui perfekte weg son et zweitens pas pixelgenau, du könntest cela bild wieder dans cluster de x-pixel breite et höhe einteilen et une zusätzlichen genauigkeitgrad angeben. peut-être peut es aussi deine jetztige prozedur trop, statt einem 10 wege auszuprobieren et en den besten prendre - cela wäre encore vite genug

>oui, par-dessus J'ai eu mich aussi im Nachhinein geärgert, cela >était wohl mon faute...
>mais ensuite besoin du plan une Bitmap plus...
oui, cela habe je gemerkt et mich par-dessus geärgert

je s'il te plaît toi entweder findpath ou bien backcollision anzupassen. es pourrait pour qui bisherigen user ne...aucune problem son ses grafik ggf. trop invertieren, mais deux grafiken im grenier trop tenir ist unnötig.

>Pour diesem Code pourrait je aussi une schnellere Funktion >faire, si cela gewünscht ist. exposition dir mon Asteroid Spiel >la fois à, speziell qui Contrôle.
jaaa, chacun ici wünscht cela

qui prospeed dll soll alles décroître quoi rechenzeit braucht.

allô Sven,

peut-être pas den 20 fachen weg mais déjà un le détour, qui den adventure helden comme trottel erscheinen peut

so dans etwa: [...]

eh bien, du könntest pour différent Situationen zusätzliche Wände dans qui masque einbauen, si un le détour de vorn herein verhindert serait.

es muss erstens pas qui perfekte weg son et zweitens pas pixelgenau, du könntest cela bild wieder dans cluster de x-pixel breite et höhe einteilen et une zusätzlichen genauigkeitgrad angeben. peut-être peut es aussi deine jetztige prozedur trop, statt einem 10 wege auszuprobieren et en den besten prendre - cela wäre encore vite genug

Es wäre aussi pas pixelgenau mais richtet sich pour paramètre W.
je wüßte aussi pas, comment je une presque-genauen Weg realisieren sollte... peut-être la hâte du oui hierzu une concept

)
10 Wege bedeuten zehnfache Ausführdauer, cela wäre cela dernier, quoi je voulais. Ausserdem wird IMMER qui gleiche Weg berechnet et une Wegsuch-Funktion, sur Zufallsbasis führt trop pas et au maximum trop entier grand Umwegen...

je s'il te plaît toi entweder findpath ou bien backcollision anzupassen. es pourrait pour qui bisherigen user ne...aucune problem son ses grafik ggf. trop invertieren, mais deux grafiken im grenier trop tenir ist unnötig.
Frage: voyons que voici car alle so ?

jaaa, chacun ici wünscht cela

qui prospeed dll soll alles décroître quoi rechenzeit braucht.
son depuis verwöhnt !!

))))
Ok.

Salut, Frank

>eh bien, du könntest pour différent Situationen >zusätzliche Wände dans qui masque einbauen, si un le détour >de vorn herein verhindert serait.
je wüsste pas comment je cela sinnvoll faire sollte

>eh bien, du könntest pour différent Situationen >zusätzliche Wände dans qui masque einbauen, si un le détour >de vorn herein verhindert serait
il peut par chaque labyrinthe aller, dans dem on sich toujours à droite hält ou bien toujours à gauche hält (simple la fois ausprobieren) si on maintenant den direkten weg de a pour b wählt et chez einem hindernis toujours interne à droite et à gauche daran vorbeiläuft et den idealeren le cas wählt.
beispiel: [...]

qui sprite bewegt sich sur dem direkten weg de a pour b, chez einem hindernis wird bevorzugt à droite gegangen après wird wieder qui directe weg pour b aufgenommen.

>son depuis verwöhnt !!

))))
c'est aussi dans deinem sinne, dass deine dll toujours perfekter wird alors mach la fois

allô,

mir ist justement une simple et très sinnvolle amélioration pour qui findpath funktion eingefallen. du checkst seulement si qui directe weg libre ist, si pas ensuite berechnet qui funktion comment bisher den weg. car justement si un freier weg existiert pouvoir qui funktion qui größten umwege.