| |
| |
|
 | hallo frank,
endlich bin Yo dazu gekommen mein adventure más a programa y el findpath befehl einzufügen... tener me bastante schön zeit gelassen, dafür dass el befehl en mein bitten hin eingefügt wurde  sorry, no es otra vez vorkommen.
-algo mehr präzision (auch en costo el rechenzeit) wäre ya muy hilfreich, lo debería no ser, dass el spieler se el 20fachen weg macht en a una baum vorbeizulaufen, el antes su nase es.
-el geforderte schwarz/weiß maske muss genau invertiert ser en el vergleich a SetBackAutoCollision - el kann sicher no gewollt ser. así muss Yo zweimal una y el selbe maske bereitstellen en jeweils sólo schwarz y weiß vertauscht es.
-el thema Tuve schonmal angesprochen y du meintest lo sei muy kompliziert y rechenaufwendig a lösen - aber es seeehr wichtig! si yo 4 richtungen para una sprite benutze es alles ok, aber el schrägstellungen voluntad meiner meinung después de no korrekt gesetzt, alles qué no 100% gerade es benutzt el schräg-frames. el debería viel mehr gerecht aufgeteil ser. oben = -22,5 a +22,5,rechtsoben = +22,5 a +77,5 entonces folgt rechts con +77,5 a 110 - wobei el idealrichtun en meiner auflistung siempre en el mitte el beiden werte lag.
en una MoveSpriteWithTable debería also sólo todavía el winkel de jeweils 4 koordinaten berechnet y ser así el richtung zugeordnet voluntad. si a viel rechenzeit braucht puede ser lo doch optional einbauen, porque ya que ahora es spart uno se mejor el schräg-richtungen, el sieht nämlich muy merkwürdig de.
el wars eigentlich ya otra vez, Yo hoffe en una erfreuliche antwort
gruß,
sven |
|
| |
| |
| |
|
|
| ¡Hola Sven,
endlich bin Yo dazu gekommen mein adventure más a programa y el findpath befehl einzufügen... tener me bastante schön zeit gelassen, dafür dass el befehl en mein bitten hin eingefügt wurde sorry, no es otra vez vorkommen.
-algo mehr präzision (auch en costo el rechenzeit) wäre ya muy hilfreich, lo debería no ser, dass el spieler se el 20fachen weg macht en a una baum vorbeizulaufen, el antes su nase es.
Naja, el 20fachen Weg legt él sicher no zurück, el tener Todavía no erlebt.
Lo liegt en efecto a el Grobheit des eingestellten Rasters (Parámetro W). Ist el Valor a groß, müßen el Mauern muy breit ser, es él a klein, Luego se el Weg bastante ungenau y el Berechnung dauert largo. Dort mußt du deinen passenden Valor para deine jeweilige Programación encontrar.
Klar, lo va auch todavía genauer, Yo podría el Wegfindung así programa, el siempre el optimale Weg gefunden se. Dazu müßte de cada Punkt el berechneten Tabla a cada Punkt una Bresenham Linienkonvertierung durchgeführt y ser cada Punkt cada Linie verglichen voluntad, si una Weg dorthin frei es. Das sería aber (si Ensamblador oder no) demaßen largo dauern, el una vernünftiges Spiel así no mehr programmiert voluntad podría.
-el geforderte schwarz/weiß maske muss genau invertiert ser en el vergleich a SetBackAutoCollision - el kann sicher no gewollt ser. así muss Yo zweimal una y el selbe maske bereitstellen en jeweils sólo schwarz y weiß vertauscht es.
Sí, darüber Tuve mich auch en el Nachhinein geärgert, el war wohl mein Fehler...
Aber entonces necesidad du eben una Mapa de bits mehr, debería sí no el Riesenproblem ser.
Invers kopieren va mittels CopyExtBmp(...) (Kopiermodus 4).
-el thema Tuve schonmal angesprochen y du meintest lo sei muy kompliziert y rechenaufwendig a lösen - aber es seeehr wichtig! si yo 4 richtungen para una sprite benutze es alles ok, aber el schrägstellungen voluntad meiner meinung después de no korrekt gesetzt, alles qué no 100% gerade es benutzt el schräg-frames. el debería viel mehr gerecht aufgeteil ser. oben = -22,5° a +22,5°,rechtsoben = +22,5 a +77,5° entonces folgt rechts con +77,5° a 110° - wobei el idealrichtun en meiner auflistung siempre en el mitte el beiden werte lag.
en una MoveSpriteWithTable debería also sólo todavía el winkel de jeweils 4 koordinaten berechnet y ser así el richtung zugeordnet voluntad. si a viel rechenzeit braucht puede ser lo doch optional einbauen, porque ya que ahora es spart uno se mejor el schräg-richtungen, el sieht nämlich muy merkwürdig de.
Hehe. Lo ha hier no Sinn, Winkel a berechnen porque el Differenz zwischen zwei Punkten (específicamente en Kurven) oft muy klein es, manchmal sólo una / zwei Pixel oder incluso 0 (en uno Achse). Und Punkte überspringen va auch no siempre (específicamente en geraden Strecken)...
In deinem Fall mußt du el Animation por Hand berechnen, mußte Yo en mi Spiel Asteroid auch, ging no anders. Hole el el Position des Sprites y el letzte (o. nächste) Position su Sprites (en el Ejemplo fx& y fy&). Dann berechnest du el X-Offset en el Mapa de bits y setzt a mano el neue Animation:
KompilierenMarcaSeparación |
|
| |
|
|
| hallo frank,
tal vez no el 20 fachen weg aber ya una umweg, el el adventure helden como trottel erscheinen lässt así en etwa: [...] 
>Das sería aber (si Ensamblador oder no) demaßen largo >dauern, el una vernünftiges Spiel así no mehr programmiert >voluntad podría.
lo muss erstens no perfekte weg ser y zweitens no pixelgenau, du könntest el bild otra vez en cluster de x-pixel breite y höhe einteilen y una zusätzlichen genauigkeitgrad angeben. tal vez lässt lo auch deine jetztige prozedur a, en lugar de una 10 wege auszuprobieren y su el besten nehmen - el wäre todavía rápidamente genug
>Sí, darüber Tuve mich auch en el Nachhinein geärgert, el >war wohl mein Fehler...
>Aber entonces necesidad du eben una Mapa de bits mehr...
sí, el Yo gemerkt y mich darüber geärgert Yo Por favor, dich entweder findpath oder backcollision anzupassen. lo dürfte para el reciente user kein problem ser ihre grafik ggf. a invertieren, aber zwei grafiken en el speicher a halten es unnötig.
>Für diesem Code podría Yo auch una schnellere Función >hacer, si el gewünscht es. Schau dir mein Asteroid Spiel >veces a, específicamente el Steuerung.
jaaa, cada hier wünscht el el prospeed dll se alles abnehmen qué rechenzeit braucht. |
|
| |
| |
| |
|
|
| hallo Sven,
tal vez no el 20 fachen weg aber ya una umweg, el el adventure helden como trottel erscheinen lässt así en etwa: [...]
Na sí, du könntest para diferente Situationen zusätzliche Wände en el Maske einbauen, sodaß una Umweg de vorn herein verhindert sería.
lo muss erstens no perfekte weg ser y zweitens no pixelgenau, du könntest el bild otra vez en cluster de x-pixel breite y höhe einteilen y una zusätzlichen genauigkeitgrad angeben. tal vez lässt lo auch deine jetztige prozedur a, en lugar de una 10 wege auszuprobieren y su el besten nehmen - el wäre todavía rápidamente genug
Lo wäre auch no pixelgenau pero richtet se después de Parámetro W.
Yo wüßte auch no, Yo una fast-genauen Weg realisieren debería... Tal vez hast du sí hierzu una Concepto )
10 Wege bedeuten zehnfache Ausführdauer, el wäre el letzte, Yo quería. Ausserdem se IMMER el gleiche Weg berechnet y una Wegsuch-Función, en Zufallsbasis führt a no y höchstens a bastante großen Umwegen...
Yo Por favor, dich entweder findpath oder backcollision anzupassen. lo dürfte para el reciente user kein problem ser ihre grafik ggf. a invertieren, aber zwei grafiken en el speicher a halten es unnötig.
Cuestión: Sehen que aquí porque todos así ?
jaaa, cada hier wünscht el el prospeed dll se alles abnehmen qué rechenzeit braucht.
Ihr seit verwöhnt !! ))))
Ok.
Saludo, Franco |
|
| |
| |
| |
|
|
| >Na sí, du könntest para diferente Situationen >zusätzliche Wände en el Maske einbauen, sodaß una Umweg >de vorn herein verhindert sería.
Yo saber no como yo sinnvoll hacer debería
>Na sí, du könntest para diferente Situationen >zusätzliche Wände en el Maske einbauen, sodaß una Umweg >de vorn herein verhindert sería
uno kann por cada labyrinth ir, en el uno se siempre rechts hält oder siempre links hält (simplemente veces ausprobieren) si uno ahora el direkten weg de a después de b wählt y en una hindernis siempre intern rechts y links daran vorbeiläuft y el idealeren fall wählt.
beispiel: [...]
el sprite bewegt se en el direkten weg de a después de b, en una hindernis se bevorzugt después de rechts gegangen danach se otra vez el direkte weg después de b aufgenommen.
>Ihr seit verwöhnt !! ))))
es auch en deinem sinne, dass deine dll siempre perfekter se also mach veces |
|
| |
| |
| |
|
|
| hallo,
me es gerade una einfache y muy sinnvolle verbesserung para el findpath funktion eingefallen. du checkst sólo si el direkte weg frei es, si no entonces berechnet el funktion como bisher el weg. porque gerade si una freier weg existiert macht el funktion el größten umwege. |
|
| |
| |
| |
|
|
| esta funktion se el spieler con findpath laufen dejar, se kein weg gefunden va el spieler normal con movesprite y restos en una hinderniss dank SetBackAutoCollision(player&,mask&,1,0,0,0,0,0,0,0,0) posición. el problem: si kein weg gefunden se se ejecuta el spieler a para hinderniss, dreht entonces en y va otra vez para startpunkt! lösche Yo el zeile path& = findPath... entonces funktioniert el posición bleiben al hinderniss otra vez como früher - eigentlich debería el doch kein einfluss darauf haben, lo se Aunque un pfad gesucht pero yo bewege el spieler entonces sí no danach (porque sowieso keiner gefunden wurde si movesprite verwendet se)
una bug oder una fehler meinerseits?
KompilierenMarcaSeparación
Proc Wegsuche
declare path#,path&,array&,temp$
parameters handle&,wstartx&,wstarty&,wzielx&,wziely&
dim path#, 2048
array&=InitExtFX(mask2&)
path& = findPath(path#,array&,10,wstartx&,wstarty&,wzielx&,wziely&,1)
if path&
SmoothPath(path#,path&,8)
SpriteTableMode (handle&,1)
movespritewithtable(handle&,path#,div(path&,4),0,0,1)
else
MoveSprite(player&,wzielx&,wziely&)
endif
dispose path#
ENDPROC
|
|
| |
| |
| |
|
|
| ¡Hola Sven,
kannst du me tal vez una funktionierendes Ejemplo zuschicken, con Sprite- y Maskendaten ?
Saludo, Franco |
|
| |
| |
| |
|
(459)
Deutsch
English
Français
Español
Italia