Ray Casting

[Dr. Irata]

darüber habe ich tatsächlich auch nachgedacht, eine Stelle nach dem Komma würde ja auch durchaus reichen... das Problem ist dann aber immer noch die Geschwindigkeit. Ich könnte dann zwar einigermaßen ausreichend "rechnen" - wobei die Distorsion mit D x cos (alpha) würde ich trotzdem mittels Tabelle bestimmen müssen - aber das würde deutlich mehr CPU-Last bedeuten.

[JoSch]

Der Vorteil von FP ist doch erstmal, dass man z.B. die Zahlen einfach als Ganzzahlen addiert. Man muss bei der Multiplikation zwar die Stellen korrigieren, aber das geht mWn mit Shiften.

[Dr. Irata]

... ja klar, aber beim Raycasting ist am Ende alles so zeitkritisch, daß ich besser gar nichts rechne...

[Dr. Irata]

Im Grunde ist der Ablauf folgender:

Da ist diese 2D-Matrix â 30x30 Größe. In dieser Matrix sind Wände und irgendwo der Player.
Der Player läuft in dieser 2D-Matrix herum und kann sich jeweils nach rechts oder links drehen, nach vorne oder nach hinten bewegen.
Der Player schaut nach vorne und hat ein FOV (field of view) von 40 Grad. Insgesamt nutze ich dann 19 Sichtstrahlen in einem Winkel von je 2,5 Grad - also von 0 (Hauptsichtstrahl nach vorne) nach -20 Grad (das sind dann 8 Blickstrahlen -2,5 Grad, -5 Grad ... -20 Grad, 0 Grad, 2,5 Grad ... 5 Grad .... 20 Grad) also 19 Sichststrahlen. Alle diese 19 Strahlen laufen nacheinander nach vorne bzw. schräg vorne (hier braucht man den Bresenham-Algorithmus) bis jeweils ein Treffer erfolgt. Anhand des x- und y-Wertes wird dann mit Pythagoras die Distanz berechnet, mit cos Blickwinkel dann die Distorsion korrigiert und dann kommt noch 1/x (nah dran kleiner Wert = hohe Mauer) x ein Faktor (ich nehme 40 - hängt von der Bildschirmauflösung dann ab). Dies wird also alles 19x durchlaufen und berechnet und abgespeichert und im nächsten Schritt wird dann diese Block der 19 Distanzen auf den Bildschirm gezeichnet uns so entsteht dann aus der 2D-Matrix ein 3D-artiges Bild ... und alles quasi in Echtzeit. Bei jeder Joystickbewegung muss das komplett durchgeführt werden!
Da kann man nicht viel rumrechnen mit unserer kleinen 6502 CPU

[Erhard]

Wie macht das dann dieses Netzwerk-Labyrinth-Spiel für den A8?
Oder ein Spiel wie Final Assault?

(Ich weiß, Du willst das selber "erfinden")

[skr]

Bei jeder Joystickbewegung muss das komplett durchgeführt werden!

Hm. Ich habe ja wirklich keine Ahnung, aber genau hier würde ich doch fragen: Warum?
Ich setze mal ein statisches Spielfeld (Labyrinth oder wasauchimmer) voraus, wie zum Beispiel in MidiMaze. Da würde ich denken, dass ich einmal "alle Wände" berechne, das Ergebnis als LUT ablege und dann "nur noch" die Veränderung zur Bewegung in Echtzeit berechne. Sprich, ich bräuchte eine Formel, welche die abgelegten Daten der neuen Position entsprechend verändert.
Da wir hier ja auch von relativ wenigen Richtungsänderungen reden - wir haben 8 mögliche Richtungen mit dem Joystick, vertikale Änderung ignoriere ich gerade mal - wäre es vielleicht weniger Rechenintensiv als bei jedem Frame ein neues Raycasting zu starten?

Vielleicht liege ich völlig daneben oder übersehe wichtige Dinge. Aber halt so als Idee in den Raum geworfen.

[Dr. Irata]

Hallo Sascha,
interessante Idee, aber ich glaube das geht nicht. Die Datenmengen, die du vorberechnen müsstest wäre einfach zu groß. Alle Wände müssten ja hinsichtlich Höhe, Breite, Winkelung vorberechnet werden.
Ich habe mich allerdings tatsächlich mit der Idee grundsätzlich beschäftigt, da ich so etwas ähnliches bei einer Textur brauchen könnte. Wände in verschiedenen Höhen mit unterschiedlichen Winkelungen... das habe ich mal in etwa kalkuliert - und würde bei mind. 70-90 kb landen...
LG Peter