Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

2D Abstand ohne sqrt()

Werbeanzeige

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

11

13.07.2011, 17:17

Zitat von »Foaly«

Ich versteh nicht so genau was du meinst, könntest du das nochmal erklären?

Du berechnest ein zufälliges X, welches sich in der Spanne befindet (-100,100). Aufgrund von dem kannst du die Y-Koordinate auf dem Kreis mit Radius 100 finden. Das ist dann die neue Grenze für deine zweite Zufallszahl.

BlueCobolds Methode finde ich auch ganz gut.
http://www.drakon.ch | Weltweit 31. Bester Solitär Spieler (Standard XP)

NachoMan

Community-Fossil

Beiträge: 3 885

Wohnort: Berlin

Beruf: (Nachhilfe)Lehrer (Mathematik, C++, Java, C#)

  • Private Nachricht senden

12

13.07.2011, 17:56

Wenn das Feld begrenzt ist, hat man bei BlueCobolds Methode das Problem, dass sich der Punkt innerhalb des Feldes befinden muss.
Also im Grunde das gleiche Problem :D
"Der erste Trunk aus dem Becher der Erkenntnis macht einem zum Atheist, doch auf dem Grund des Bechers wartet Gott." - Werner Heisenberg
Biete Privatunterricht in Berlin und Online.
Kommt jemand mit Nach oMan?

Jonathan_Klein

Community-Fossil

Beiträge: 3 820

  • Private Nachricht senden

13

13.07.2011, 18:09

sqrt ist nicht langsam. Es kommt immer darauf an, wann und wie es benutzt wird. Du wirst garantiert nicht in jedem Frame eine neue, zufällige Position am Kreis berechnen und selsbt wenn würdest du das nicht für tausend Sprites machen und selbst wenn, würdest du tausend sqrt Aufrufe pro Frame vermutlich nichtmal merken. Natürlich ist es trotzdem schneller, die Länge gegen die du testet zu quadrieren als die Wurzel aus deiner Rechnung zu ziehen, aber wie gesagt, du musst dir höchstwahrscheinlich keine Gedanken darüber machen.
Deshalb: Nur nicht an den falschen Stellen vorschnell optimieren, lieber messen, wo es wirklich hängt. Und immer zuerst die Algorithmus optimieren, dann erst dessen Implementierung.

Zur Zufallsposition: Bei konstantem Radius einen zufälligen Winkel zu bestimmen und daraus die Position auf dem Kreis zu berechnen, ist besser, als zu einer zufälligen YPosition die passende XPosition zu berechnen, da die Werte gleichmäßiger über den Kreis verteilt sind. Und was ist das Problem von wegen "innerhalb des Feldes"?
Lieber dumm fragen, als dumm bleiben!

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

14

13.07.2011, 18:22

Die 100Pixel sind Minimum nicht Maximum. Aber was Jonathan sagt ist schon richtig. Bestimme einen Zufälligen Winkel und dann einen zufälligen Abstand. Dann einfach den Punkt bestimmen. Hört sich so für mich nach einer schönen Lösung an.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

15

13.07.2011, 18:25

Zitat von »Schorsch«

Bestimme einen Zufälligen Winkel und dann einen zufälligen Abstand.

Ja, sagte ich bereits.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

16

13.07.2011, 18:29

Überlesen;) Entschuldige
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

Foaly

Treue Seele

  • »Foaly« ist der Autor dieses Themas

Beiträge: 136

  • Private Nachricht senden

17

13.07.2011, 18:47

Ich hab versucht BlueCobolts Methode zu implementieren, aber irgendwie kriege ich es nicht hin...
Ich hab folgendes versucht: Einen zufälligen Winkel zwischen 1 und 360 zu erzeugen. Dann einen Radius. Das Problem ist, dass ich es nicht hinkriege die Grenzen des Radius zu berechnen... Ich will ja nicht, dass das Sprite aus dem Bildschirmbereich verschwindet. Ein weiteres Problem ist, dass wenn ich meine Hauptfigur zu nah am Rand befindet (näher als 100px) die entsprechenden Winkel wegfallen müssten, da es ansonsten seinen kann, dass ich ein Problem hab wenn ich versuche eine Zufallszahl zu berechnen, deren Grenzen sozusagen negativ sind.

Ich bin mir nicht sicher, ob ich was falsch verstehe oder ob wir aneinander vorbeireden. Also ich beschreib noch mal was ich meine. Ich hab ein Sprite (die "Hauptperson") und ein zweites Sprite. Die Hauptperson muss das andere Sprite "einsammeln" wenn dass passiert, wir das zweite Sprite an eine neue (zufällige) Position gesetzt. Ich will erreichen, dass das zweite Sprite mindestens 100px vom Hauptsprite weg ist. Außerdem will ich eine while schleife mit unbekannter Laufzeit vermeiden.

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

18

13.07.2011, 18:53

Dann fragst du einfach ab ob es im Bild liegt. Bzw guckst, dass du den Bereich von Anfang an einschränkst. Eine einfache aber nicht ganz Korrekte Methode wäre nicht einen Kreis um den Spieler zu legen sondern ein Quadrat. Der Bildschirm ist dann ein Rechteck, welches das Quadrat enthält. Dann bestimmst du einfach einen Zufälligen Punkt der im Rechteck liegt, aber nicht im Quadrat. Ist dann nicht 100% das was du wolltest, aber sollte vom Ergebnis zu verkraften sein. Wenn das zu ungenau ist, ginge das bestimmt auch mit einem Kreis. Dann wären natürlich die Berechnungen ungenauer. Wobei so wie du es schilderst wird es nur alle paar Frames mal berechnet und von daher darf die Berechnung auch etwas aufwändiger ausfallen.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

Schorsch

Supermoderator

Beiträge: 5 145

Wohnort: Wickede

Beruf: Softwareentwickler

  • Private Nachricht senden

19

13.07.2011, 18:55

Nach kurzem(wirklich kurzem) überlegen bin ich auf eine etwas genauere und trotzdem einfache Lösung gekommen.
Du guckst einfach ob der Spieler weniger als 100 Pixel vom Rand entfernt ist. Wenn ja dann nimmst du einen Radius bei dem die Richtung nicht zu dieser Wand hin zeigt. Zu jeder Wand eine Abfrage und du hast die Richtungen die ok sind. Damit sind dann zwar auch nicht alle möglichen Positionen umzusetzen, was jedoch nicht auffallen sollte.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

20

13.07.2011, 19:00

Irgendwie habe ich das Gefühl, dass du einiges durcheinander bringst und probierst alle Probleme in einem zu lösen. Jetzt kommt plötzlich noch irgendwas mit Rand, Bildschirm und mindestens 100px entfernt dazu.

Probier doch die Probleme aufzuspalten und dann einzeln anzugehen.
http://www.drakon.ch | Weltweit 31. Bester Solitär Spieler (Standard XP)

Werbeanzeige

Ähnliche Themen