Ein Kreis ist eine Linie von Punkten mit gleichem Abstand zu einem Mittelpunkt. Der Satz von Pythagoras liefert eine Formel für den Abstand zweier Punkte in einer Ebene. Setze für c einen beliebigen Radius r ein und du erhältst mit allen Lösungspaaren (a, b) alle Punkte auf der Kreislinie des Kreises mit dem Radius r. Nun geht es darum festzustellen, ob der Abstand zwischen Punkt (x, y) und Punkt (xi, yi) kleiner (oder gleich) r ist, ob also (xi, yi) innerhalb (oder auf) der Kreislinie liegt, die durch den Mittelpunkt (x, y) und den Radius r definiert ist. Für alle Punkte innerhalb (oder auf) der Kreislinie gilt also (xi-x)² + (yi-y)² <= r² mit dem Referenzpunkt/Mittelpunkt (x, y) und dem Testpunkt (xi, yi). Ist der Term (xi-x)² + (yi-y)² größer als r², liegt (xi, yi) außerhalb der Kreislinie, ansonsten innerhalb, oder auf ihr.
Ich habe bereits mehrmals sowohl Bresenhams Kreis-, als auch sein Linien-Algorithmus und Xiaolin Wus Abwandlungen davon und Ähnliches implementiert, weiß also durchaus über die rasterbedingten Probleme Bescheid. Der Punkt ist: Sie sind hier irrelevant, da es nicht um das Zeichnen eines Kreises geht, sondern um Abstandsmessung. Selbst für die Rasterisierung eines Kreises wäre es in vielen Fällen akzeptabel, der Grund für den Bresenham-Algorithmus und gegen den naiven a²+b²=c²-Ansatz ist eher die Performance, als die genauere Rasterung. Die Hälfte aller möglichen Probleme ist außerdem bereits mit dem kleiner-gleich-Vergleich eliminiert.
Ich weiß schon was Ganzzahlen und was Gleitpunktzahlen sind. Habe übrigens auch einiges an Erfahrung in Low-Level-Optimierung. Es ging mir um die pauschale Aussage, dass Integerarithmetik langsamer sein soll als Gleitpunktarithmetik. (Ungenau ist Integerarithmetik übrigens auch nicht grundsätzlich. Addition, Subtraktion und Multiplikation sind absolut genau. Alleine bei der Division können Probleme auftauchen, da die Information hinter dem Komma verloren geht.) Das ist nämlich alles andere als gegeben und in vielen Fällen eher das Gegenteil. Auf Glauben sollte man keine technischen Entscheidungen basieren, sondern nur auf Messungen. Selbst wenn es einen Unterschied gibt, so ist dieser mit sehr hoher Wahrscheinlichkeit so marginal, dass er nur bei Millionen oder mehr von Rechenoperationen messbar ist, für den Fall einer einfachen Abstandsmessung also vollkommen irrelevant ist.
Ich habe bereits mehrmals sowohl Bresenhams Kreis-, als auch sein Linien-Algorithmus und Xiaolin Wus Abwandlungen davon und Ähnliches implementiert, weiß also durchaus über die rasterbedingten Probleme Bescheid. Der Punkt ist: Sie sind hier irrelevant, da es nicht um das Zeichnen eines Kreises geht, sondern um Abstandsmessung. Selbst für die Rasterisierung eines Kreises wäre es in vielen Fällen akzeptabel, der Grund für den Bresenham-Algorithmus und gegen den naiven a²+b²=c²-Ansatz ist eher die Performance, als die genauere Rasterung. Die Hälfte aller möglichen Probleme ist außerdem bereits mit dem kleiner-gleich-Vergleich eliminiert.
...
Ich als Programmierer (arbeite z.T. mit Assembler, größtenteils mit Turbo-/Free-Pascal [Schule] und neustens auch mit ActionScript) kenne das Problem zu genüge. Unter Turbo Pascal habe ich vor 2 Jahren mal eine eigene Grafik-Unit für VESA geschrieben (wenn ich heute mal einen Blick drauf werfe staune ich immer noch darüber wie Mächtigkeit und Funktionsumfang der Unit).
Zitat von Kyuu
Ich weiß schon was Ganzzahlen und was Gleitpunktzahlen sind. Habe übrigens auch einiges an Erfahrung in Low-Level-Optimierung. Es ging mir um die pauschale Aussage, dass Integerarithmetik langsamer sein soll als Gleitpunktarithmetik. (Ungenau ist Integerarithmetik übrigens auch nicht grundsätzlich. Addition, Subtraktion und Multiplikation sind absolut genau. Alleine bei der Division können Probleme auftauchen, da die Information hinter dem Komma verloren geht.) Das ist nämlich alles andere als gegeben und in vielen Fällen eher das Gegenteil. Auf Glauben sollte man keine technischen Entscheidungen basieren, sondern nur auf Messungen. Selbst wenn es einen Unterschied gibt, so ist dieser mit sehr hoher Wahrscheinlichkeit so marginal, dass er nur bei Millionen oder mehr von Rechenoperationen messbar ist, für den Fall einer einfachen Abstandsmessung also vollkommen irrelevant ist.
...
Da muss ich dir recht geben, aber wegen den beschränkten und langsamen Rechenmitteln des RM2K/3 ist es besser auf den PowerPatch zurück zu greifen. Besonders sollte man bedenken, dass das Spiel auch auf älteren Systemen (die die Minimalanforderung des Makers erfüllen, so ab Pentium3 @500MHZ) flüssig laufen soll, nicht nur auf den neueren PCs (@2GHz oder mehr). Deswegen sollte alle für-nicht-Programmierer-möglichen Wege der Optimierung unternommen werden.
Ich denke, dass das genug über die Optimierung, Ganzzahlen und Gleitpunktzahlen ist. Das ganze verwirrt Engel der Furcht und die anderen, die das lesen.
Wieder back on topic ...
PS. Danke, ich lerne wieder etwas aus dem Streitgespräch. Andere unterschätzt man doch immer viel zu schnell
Man kann ja den Abstand zwischen 2 Events errechnen,
wie siehts denn aber aus,wenn das ganze nur in eine Richtung gehene soll?
Bezüglich einzelner Hiebe im AKS,ebenfalls im Halbkreis?
Bsp:
Held schaut nach oben.
Nun soll er nicht nur das Feld direkt vor ihm treffen,sondern 1. die beiden daneben und 2. noch das Feld darüber...
Geändert von Engel der Furcht (09.01.2010 um 14:42 Uhr)
Kann mir denn keiner Helfen?
hier mal eine "bildliche Darstellung",wie ich das meine.
Blickt der Held nach oben,sollen die 2 Felder diagonal über ihn und 2 Felder direkt über ihn abgefragt werden.
Muss ich dafür jedes Feld einzeln nachhaken,oder gibt es dazu auch eine Rechenformel?
Also wenn ich das richtige sehe, dann ist das ja nichts weiter als ein kleiner Radius, den du mit der bereits bekannten Formel errechnen kannst. Du musst hier halt eben nur den Mittelpunkt des Radius je nach Blickrichtung des Helden in die richtige Richtung schieben (X- oder Y-Koordinate +/- eins).
Das Tile auf dem der Held steht fällt ja ohnehin automatisch weg, weil da ja niemals gleichzeitig ein Gegner stehen kann^_-
So,
Dank Cilence bin ich glaube ich auf den richtigen Weg...
so sieht der momentane Code aus.
"attack2" dient nur zu Testzwecken.
Jetzt will ich nurnoch wissen,wie ich es schaffen,dass nur vor dem Helden und nicht hinter ihm abgefragt wird...
Sorry für Doppelpost...
Aber ich habs geschafft,wenn auch total umständlich.
Jedes Feld einzeln abhaken war eine Aufgabe die innerhalb von 30 Sekunden erledigt ist...
Bitte verwende beim EasyEventExporter das nächste Mal die Formatvorlage "vb_lightbg.eft" im Ordner "ftemplates", dadurch wird der Code hier im Forum farbig gehighlighted.
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!
@Engel der Furcht
Am besten du machst es so wie Stoep es gesagt hat und benutzt den Algorithmus von R.D. Aus Faulheit schreibe ich das im Pseudo-Code.
Variable x1 = X-Position vom Gegner
Variable y1 = Y-Position vom Gegner
Variable x2 = X-Position vom Held
Variable y2 = Y-Position vom Held
Wenn der Held nach oben schaut: y2 - 1
Wenn der Held nach rechts schaut: x2 + 1
Wenn der Held nach unten schaut: y2 + 1
Wenn der Held nach links schaut: x2 - 1
x1 = x1 - x2
y1 = y1 - y2
Wenn x1 < 0: x1 = x1 * -1
Wenn y1 < 0: y1 = y1 * -1
x1 = x1 + y1
Wenn x1 <= 1 (weiter darf der Gegner nicht entfernt sein): Treffer!
Zitat
Unter Turbo Pascal habe ich vor 2 Jahren mal eine eigene Grafik-Unit für VESA geschrieben (wenn ich heute mal einen Blick drauf werfe staune ich immer noch darüber wie Mächtigkeit und Funktionsumfang der Unit).
CherryShare | Patches und Tools | Programmwunschthread | www.cherrytree.at | Cherry = CherryDT
Berechtigungen
Zitieren
