| |
| |
|
 | hallo frank,
endlich bin ich dazu gekommen mein adventure weiter zu programmieren und den findpath befehl einzufügen... hab mir ganz schön zeit gelassen, dafür dass der befehl auf mein bitten hin eingefügt wurde  sorry, wird nicht wieder vorkommen.
-etwas mehr präzision (auch auf kosten der rechenzeit) wäre schon sehr hilfreich, es sollte nicht sein, dass der spieler sich den 20fachen weg macht um an einem baum vorbeizulaufen, der vor seiner nase steht.
-das geforderte schwarz/weiß maske muss genau invertiert sein im vergleich zu SetBackAutoCollision - das kann sicher nicht gewollt sein. so muss ich zweimal ein und die selbe maske bereitstellen bei der jeweils nur schwarz und weiß vertauscht ist.
-das thema hatte ich schonmal angesprochen und du meintest es sei sehr kompliziert und rechenaufwendig zu lösen - aber ist seeehr wichtig! wenn ich 4 richtungen per einen sprite benutze ist alles ok, aber die schrägstellungen werden meiner meinung nach nicht korrekt gesetzt, alles was nicht 100% gerade ist benutzt die schräg-frames. das müsste viel mehr gerecht aufgeteil sein. oben = -22,5 bis +22,5,rechtsoben = +22,5 bis +77,5 dann folgt rechts mit +77,5 bis 110 - wobei die idealrichtun bei meiner auflistung immer in der mitte der beiden werte lag.
bei einem MoveSpriteWithTable müsste also nur noch der winkel aus jeweils 4 koordinaten berechnet werden und so die richtung zugeordnet werden. wenn es zu viel rechenzeit braucht kann man es doch optional einbauen, denn so wie es jetzt ist spart man sich besser die schräg-richtungen, das sieht nämlich sehr merkwürdig aus.
das wars eigentlich schon wieder, ich hoffe auf eine erfreuliche antwort
gruß,
sven |
|
| |
| |
| |
|
|
| Hallo Sven,
endlich bin ich dazu gekommen mein adventure weiter zu programmieren und den findpath befehl einzufügen... hab mir ganz schön zeit gelassen, dafür dass der befehl auf mein bitten hin eingefügt wurde sorry, wird nicht wieder vorkommen.
-etwas mehr präzision (auch auf kosten der rechenzeit) wäre schon sehr hilfreich, es sollte nicht sein, dass der spieler sich den 20fachen weg macht um an einem baum vorbeizulaufen, der vor seiner nase steht.
Naja, den 20fachen Weg legt er sicher nicht zurück, das hab ich noch nicht erlebt.
Es liegt ja auch an der Grobheit des eingestellten Rasters (Parameter W). Ist der Wert zu grande, müßen die Mauern sehr breit sein, ist er zu klein, dann wird der Weg recht ungenau und die Berechnung dauert lange. Dort mußt du deinen passenden Wert per deine jeweilige Programmazione finden.
Klar, es geht auch noch genauer, ich potuto die Wegfindung so programmieren, das immer der optimale Weg gefunden wird. Dazu müßte von jedem Punkt der berechneten Tabelle zu jedem Punkt eine Bresenham Linienkonvertierung durchgeführt werden und jeder Punkt jeder Linie verglichen werden, ob ein Weg dorthin frei ist. Das würde aber (ob Assembler oder nicht) demaßen lange dauern, das ein vernünftiges Spiel so nicht mehr programmiert werden potuto.
-das geforderte schwarz/weiß maske muss genau invertiert sein im vergleich zu SetBackAutoCollision - das kann sicher nicht gewollt sein. so muss ich zweimal ein und die selbe maske bereitstellen bei der jeweils nur schwarz und weiß vertauscht ist.
Ja, darüber hatte ich mich auch im Nachhinein geärgert, das war wohl mein Fehler...
Aber dann benötigst du eben eine Bitmap mehr, sollte ja nicht das Riesenproblem sein.
Invers kopieren geht mittels CopyExtBmp(...) (Kopiermodus 4).
-das thema hatte ich schonmal angesprochen und du meintest es sei sehr kompliziert und rechenaufwendig zu lösen - aber ist seeehr wichtig! wenn ich 4 richtungen per einen sprite benutze ist alles ok, aber die schrägstellungen werden meiner meinung nach nicht korrekt gesetzt, alles was nicht 100% gerade ist benutzt die schräg-frames. das müsste viel mehr gerecht aufgeteil sein. oben = -22,5° bis +22,5°,rechtsoben = +22,5 bis +77,5° dann folgt rechts mit +77,5° bis 110° - wobei die idealrichtun bei meiner auflistung immer in der mitte der beiden werte lag.
bei einem MoveSpriteWithTable müsste also nur noch der winkel aus jeweils 4 koordinaten berechnet werden und so die richtung zugeordnet werden. wenn es zu viel rechenzeit braucht kann man es doch optional einbauen, denn so wie es jetzt ist spart man sich besser die schräg-richtungen, das sieht nämlich sehr merkwürdig aus.
Hehe. Es hat hier keinen Sinn, Winkel zu berechnen weil die Differenz zwischen zwei Punkten (speziell in Kurven) oft sehr klein ist, manchmal nur ein / zwei Pixel oder sogar 0 (bei einer Achse). Und Punkte überspringen geht auch nicht immer (speziell bei geraden Strecken)...
In deinem Fall mußt du die Animation per Hand berechnen, mußte ich bei meinem Spiel Asteroid auch, ging nicht anders. Hole die die Position des Sprites und die letzte (bzw. nächste) Position deines Sprites (im Beispiel fx& und fy&). Dann berechnest du den X-Offset in der Bitmap und setzt von Hand die neue Animation:
KompilierenMarkierenSeparieren |
|
| |
|
|
| hallo frank,
vielleicht nicht den 20 fachen weg aber schon ein umweg, der den adventure helden als trottel erscheinen lässt so in etwa: [...] 
>Das würde aber (ob Assembler oder nicht) demaßen lange >dauern, das ein vernünftiges Spiel so nicht mehr programmiert >werden potuto.
es muss erstens nicht der perfekte weg sein und zweitens nicht pixelgenau, du könntest das bild wieder in cluster von x-pixel breite und höhe einteilen und einen zusätzlichen genauigkeitgrad angeben. vielleicht lässt es auch deine jetztige prozedur zu, statt einem 10 wege auszuprobieren und davon den besten nehmen - das wäre noch schnell genug
>Ja, darüber hatte ich mich auch im Nachhinein geärgert, das >war wohl mein Fehler...
>Aber dann benötigst du eben eine Bitmap mehr...
ja, das habe ich gemerkt und mich darüber geärgert ich bitte dich entweder findpath oder backcollision anzupassen. es potrebbe per die bisherigen user kein problem sein ihre grafik ggf. zu invertieren, aber zwei grafiken im speicher zu halten ist unnötig.
>Für diesem Code potuto ich auch eine schnellere Funktion >machen, wenn das gewünscht ist. Schau dir mein Asteroid Spiel >mal an, speziell die Steuerung.
jaaa, jeder hier wünscht das die prospeed dll soll alles abnehmen was rechenzeit braucht. |
|
| |
| |
| |
|
|
| hallo Sven,
vielleicht nicht den 20 fachen weg aber schon ein umweg, der den adventure helden als trottel erscheinen lässt so in etwa: [...]
Na ja, du könntest per unterschiedliche Situationen zusätzliche Wände in die Maske einbauen, sodaß ein Umweg von vorn herein verhindert würde.
es muss erstens nicht der perfekte weg sein und zweitens nicht pixelgenau, du könntest das bild wieder in cluster von x-pixel breite und höhe einteilen und einen zusätzlichen genauigkeitgrad angeben. vielleicht lässt es auch deine jetztige prozedur zu, statt einem 10 wege auszuprobieren und davon den besten nehmen - das wäre noch schnell genug
Es wäre auch nicht pixelgenau sondern richtet sich nach Parameter W.
Ich wüßte auch nicht, wie ich einen fast-genauen Weg realisieren sollte... Vielleicht hast du ja hierzu eine Idee )
10 Wege bedeuten zehnfache Ausführdauer, das wäre das letzte, was ich wollte. Ausserdem wird IMMER der gleiche Weg berechnet und eine Wegsuch-Funktion, auf Zufallsbasis führt zu nicht und höchstens zu ganz grande Umwegen...
ich bitte dich entweder findpath oder backcollision anzupassen. es potrebbe per die bisherigen user kein problem sein ihre grafik ggf. zu invertieren, aber zwei grafiken im speicher zu halten ist unnötig.
Frage: Sehen das hier denn alle so ?
jaaa, jeder hier wünscht das die prospeed dll soll alles abnehmen was rechenzeit braucht.
Ihr seit verwöhnt !! ))))
Ok.
Saluto, Frank |
|
| |
| |
| |
|
|
| >Na ja, du könntest per unterschiedliche Situationen >zusätzliche Wände in die Maske einbauen, sodaß ein Umweg >von vorn herein verhindert würde.
ich wüsste nicht wie ich das sinnvoll machen sollte
>Na ja, du könntest per unterschiedliche Situationen >zusätzliche Wände in die Maske einbauen, sodaß ein Umweg >von vorn herein verhindert würde
man kann durch jedes labyrinth gehen, in dem man sich immer rechts hält oder immer links hält (einfach mal ausprobieren) wenn man jetzt den direkten weg von a nach b wählt und bei einem hindernis immer intern rechts und links daran vorbeiläuft und den idealeren fall wählt.
beispiel: [...]
der sprite bewegt sich auf dem direkten weg von a nach b, bei einem hindernis wird bevorzugt nach rechts gegangen danach wird wieder der direkte weg nach b aufgenommen.
>Ihr seit verwöhnt !! ))))
es ist auch in deinem sinne, dass deine dll immer perfekter wird also mach mal |
|
| |
| |
| |
|
|
| hallo,
mir ist gerade eine einfache und sehr sinnvolle verbesserung per die findpath funktion eingefallen. du checkst erst ob der direkte weg frei ist, wenn nicht dann berechnet die funktion wie bisher den weg. denn gerade wenn ein freier weg existiert macht die funktion die größten umwege. |
|
| |
| |
| |
|
|
| diese funktion soll den spieler mit findpath laufen lassen, wird kein weg gefunden geht der spieler normal mit movesprite und bleibt bei einem hinderniss dank SetBackAutoCollision(player&,mask&,1,0,0,0,0,0,0,0,0) stehen. das problem: wenn kein weg gefunden wird corre der spieler bis zum hinderniss, dreht dann um und geht wieder zum startpunkt! lösche ich die zeile path& = findPath... dann funktioniert das stehen bleiben am hinderniss wieder wie früher - eigentlich sollte das doch kein einfluss darauf haben, es wird zwar ein pfad gesucht aber ich bewege den spieler dann ja nicht danach (weil sowieso keiner gefunden wurde wenn movesprite verwendet wird)
ein bug oder ein fehler meinerseits?
KompilierenMarkierenSeparieren
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
|
|
| |
| |
| |
|
|
| Hallo Sven,
kannst du mir vielleicht ein funktionierendes Beispiel zuschicken, mit Sprite- und Maskendaten ?
Saluto, Frank |
|
| |
| |
| |
|
(456)
Deutsch
English
Français
Español
Italia