Ray Casting

[Dr. Irata]

An dieser Stelle möchte ich Ray Casting entwickeln - also ein Labyrinth aus einer 2-D Matrix in eine 3-D Ansicht überführen.
Vorbilder für den Atari gibt es ja einige - Project M, Doom etc..... am Ende darf eine allgemeine 3D Engine entstehen, die jeder benutzen kann... so der Plan!

Die Theorie ist relativ klar, schwierig wird die Umsetzung auf den Atari werden und da brauche ich Unterstützung. Hat jemand Erfahrung mit Ray Casting??

[Kveldulfur]

Moin!

Ich denke, Du meinst Ray Casting... Ray Tracing ist viel komplexer und wird der Atari sicherlich nicht schaffen.

Die Frage ist, ob man das Ray Casting für den GTIA programmieren möchte, oder vllt. für die VBXE?
Da hat man nicht nur eine bessere Auflösung, sondern kann durch die Farben auch einen besseren 3D-Effekt hinbekommen. Wäre dann natürlich nur noch auf wenige ATARIs mit Erweiterung nutzbar.

Vorweg: Ich weiß nicht, wie man die VBXE programmieren kann.

Grüße
Janko

[Dr. Irata]

Ray Casting natürlich - gleich geändert.
Ich würde das ohne Erweiterung machen, damit es kompatibel ist.

Als Erstes würde ich die 2-D Matrix für das Labyrinth erstellen aus der ja dann die Pseudo-3D Ansicht erstellt wird.
Daher müsste man sich primär Gedanken machen, welche Antic Mode für unser Ray Casting wohl am besten geeignet ist. Wer hat da Erfahrung und eine Idee??

[pps]

Erfahrungen habe ich da absolut keine bisher. Wie man an der Doom Engine sieht, geht es am Atari auch mit nur 4 Farben, allerdings ist das schon sehr beschränkt. Besser ist sicherlich einer der GTIA Modis. Project M sieht da am besten aus. Allerdings könnten so viele Farben das am Ende für ein Action Spiel zu sehr bremsen durch die Berechnung.

MIDI Maze und 3D Pac Man (vom AMC bzw. Armin Stürmer, wenn ich mich korrekt erinnere) sind auch ganz gut anzusehen oder die Fraktalwelten von Lucasfilm Games.

[CharlieChaplin]

Auf youtube gibt es viele Videos zu dem Thema, neben Theorie auch einiges an praktischer Umsetzung. Mehrere Links habe ich dazu schon gepostet. Im AA Forum und bei Fandal findet man u.a. das:

Globe's 3D Raycaster:
https://forums.atariage.com/topic/33060 ... ip/page/4/
https://forums.atariage.com/topic/32670 ... me-by-gmg/

Wolf3D demo:
https://a8.fandal.cz/detail.php?files_id=7220

Project M demo:
https://forums.atariage.com/topic/174274-project-m-20/
https://www.youtube.com/watch?v=DuZywAxfGkw

Vic-Doom on A8:
https://forums.atariage.com/topic/352886-doom-alert/

Numen / Vector sources:
http://numen.scene.pl/download.html
http://numen.scene.pl/download/numen_src.zip
(siehe subdir "duke")
https://a8.fandal.cz/detail.php?files_id=5474
There are some keys you can use in adition of the stick movement:
A-Jump
Z-Crouch
W-Center head
S-Noad the head up
X-Noad the head down
, . - Strafe left/right
J - toggles jet pack (fly with A and Z)
Space - open/close doors and use elevators
1-3 - choose a weapon (there aren't guns in Numen, but the code supports them)

Wayout:
https://a8.fandal.cz/detail.php?files_id=4597

Capture the Flag:
https://a8.fandal.cz/detail.php?files_id=1567

Midi Maze:
https://a8.fandal.cz/detail.php?files_id=5298

Maze of Agdagon:
https://a8.fandal.cz/detail.php?files_id=2364

XXL 16k 3D engine:
https://forums.atariage.com/topic/330879-16k-3d-engine/

3D Maze:
https://atariwiki.org/wiki/Wiki.jsp?page=3dMaze

3D oder nicht 3D:
https://forums.atariage.com/topic/19079 ... on/page/4/

Ray casting:
https://www.researchgate.net/figure/Ray ... _329503247
https://www.youtube.com/watch?v=NbSee-XM7WA&t=4s
https://permadi.com/1996/05/ray-casting-tutorial-7/
https://permadi.com/1996/05/ray-casting ... -contents/
https://www.youtube.com/watch?v=SmKBsArp2dI
https://en.wikipedia.org/wiki/Ray_casting

[CharlieChaplin]

Daher müsste man sich primär Gedanken machen, welche Antic Mode für unser Ray Casting wohl am besten geeignet ist. Wer hat da Erfahrung und eine Idee??

Im AA Forum gibt es recht viele Meinungen, welcher Antic Mode dazu geeignet sein könnte. Es wurden u.a. genannt: Antic Mode 5 (Gr. 13), Antic Mode D (Gr. 7), Hi-Res (Gr. 8), Gr.9/Gr.9++, Apac/256 colours, etc.

Erfahrungen: Eru (Numen/Vector), FoX (Numen/Vector), NRV (Project-M), Globe (Final Assault 64k, Raycaster 128k), Konop (Asskicker!), Swiety/Saint (Maze, Rewind-Demo, Vic-Doom port, etc.) und wohl auch Heaven (Karolij Nadj). Leider weiß ich nicht, ob einer von denen auch Abbuc Member ist... vielleicht ja Heaven ?

[Dr. Irata]

vielen Dank für die Inputs... leider nur Demos und gute Erklärungen - leider nirgends mal ein Code zum anschauen oder eine Art Engine für die Allgemeinheit.
Jeder muss immer das Rad für sich neu erfinden... also dann!

[CharlieChaplin]

Bei Numen / Vector ist aber Sourcecode dabei, zu finden in der subdir "duke", wenn ich mich nicht irre wurde dort Assembler, C und Pascal genutzt. Ob die Sources hilfreich sind, weiß ich halt nicht.

Zur Not einfach mal Heaven anschreiben (via PN hier oder bei Atari Age) und ihn mal fragen, was er so auf Lager hat. Soweit ich weiß hat er Sources zu Wayout oder Capture the Flag vorliegen und er weiß wie Raycasting funktioniert, kann also bestimmt ein paar Beispiele geben.

[Dr. Irata]

super cool, vielen Dank erst einmal!!

[Dr. Irata]

.... nun hatte ich wenig Zeit in den letzten Tagen, möchte aber jetzt weiter voranschreiten ....

Als ersten Schritt muss ich jetzt eine einfache Matrix aufbauen. Ich fange mit vielleicht 20 x 20 an - hier werden zunächst nur entweder eine 0 oder eine 1 reinkommen. 1 bedeutet Wandelement und 0 bedeutet Luft - also freie Fläche.Irgendwo in dieser Matrix steht dann der Spieler und schaut zunächst nach Norden (das wäre dann in Richtung erste Reihe der Matrix) und hat ein Blickfeld welches definiert ist.
Auf die Matrix muss ich einfach zugreifen können, da sie ständig abgefragt wird. Wenn der Blick nach vorne geht, dann muss ja quasi der Blickweg durchschritten werden und jedes einzelne Matrixfeld wird in Blickrichtung abgefragt. Es ist quasi als würde man eine Linie zeichnen, nur man zeichnet nichts, sondern liest die Matrix aus. Immer wenn man auf eine 1 stößt, wird dann an dieser Stelle ein Wandelement gezeichnet.
Die x-Position der Matrix ist einfach auszulesen, bei der y-Position bin ich mir nicht sicher, wie ich das am einfachsten (schnellsten) mache...

[pps]

Die x-Position der Matrix ist einfach auszulesen, bei der y-Position bin ich mir nicht sicher, wie ich das am einfachsten (schnellsten) mache...

Also Du schaust ja immer von der Position des Spielers aus. Dessen X und Y in der Maze ist ja bekannt. Diese Position wird der Routine übergeben (xX und yY) und dann dieses übergebene yY immer hoch oder runtergezählt bis an die Grenzen der Maze (also 19 oder 0). xX+yY*20 sollte die korrekte Position des zu prüfenden Elements der Matrix sein.

[Dr. Irata]

hmmm... also ich muss ja den Raum quasi definieren und das wollte ich über eine .txt Datei machen (siehe Bild).
Das geht auch - da muss ich dann halt immer vorher die y-Position so konvertieren, daß ich je nach Zeile entsprechend y0...y20 abfrage.
Das klingt allerdings irgendwie umständlich und dadurch langsam und ich frage mich wie das schneller und eleganter gehen könnte...

Meine derzeitige Lösung wäre folgende:

[Dr. Irata]

an der Position x=7 und y=5 will ich die entsprechend hinterlegte Zahl 2 auslesen.

Eine kleine Konvertierungsroutine macht zunächst aus dem einfachen y Wert (hier 5) y5 und speichert das dann per selbstmodifizierenden Code an die Position der Abfrageroutine, wo dann mit lda y5,x die entsprechende Zahl (in diesem Falle 2) ausgelesen wird. Was besseres fällt mir jetzt nicht ein... klingt aber kompliziert und geht bestimmt mit MADS viel schneller und eleganter...

[Kveldulfur]

Code: Alles auswählen

		ORG $2000
		
; Karte eines Raumes
Y00		dta "####################"
Y01		dta "#                  #"
Y02		dta "#                  #"
Y03		dta "#                  #"
Y04		dta "#                  #"
Y05		dta "#                  #"
Y06		dta "#                  #"
Y07		dta "#                  #"
Y08		dta "#                  #"
Y09		dta "####################"

YLow		dta <Y00, <Y01, <Y02, <Y03, <Y04, <Y05, <Y06, <Y07, <Y08, <Y09
YHigh		dta >Y01, >Y02, >Y03, >Y03, >Y04, >Y05, >Y06, >Y07, >Y08, >Y09

YPos		equ $A0		; $A0 und $A1 werden genutzt

;Wenn Du nun X=10 und Y=5 abfragen willst, machst Du folgendes:

.proc XY_Abfrage
		; Y-Position in X setzen
		; X-Position in Y setzen
		LDA YLow,x
		STA YPos
		LDA YHigh,x
		STA YPos+1
   		LDA (YPos),Y
   		RTS
.endp

.proc Main

		LDX #5		; Y Position
		LDY #10		; X Position
		JSR XY_Abfrage	; Der AKKU enthält die gesuchte Position 
.endp

Hallo!

Hier ein kleines Beispiel, wie man innerhalb einer Matrix abfragen machen kann.

Grüße
Janko

[Dr. Irata]

Hallo Janko,
lieben Dank! Ja genau das habe ich gesucht. Supi!!

[Dr. Irata]

... gerade hänge ich an dem Problem des Field Of View....
Ein gutes FoV beim RayTr ist 60 Grad - wenn ich also von meinem Standort (der bekannt ist) schräg in Richtung Wand schaue, dann ist mein FoV 30 Grad nach links plus 30 Grad nach rechts. Meine Sehstrahlen müssen also x mal in die eine Richtung nach vorne "absuchen" und x mal in die andere Richtung nach vorne absuchen bis jeweils ca. 30 Grad erreicht sind. Das bedeutet die Winkel 30 Grad teilen sich jeweils in kleinere Teilwinkel auf - je nachdem wie weit weg ich von der Wand stehe.
Das kann ich natürlich alles mathematisch berechnen, aber wir sprechen hier von arcTan und so weiter.....

Das muss doch einfacher gehen.... eine Art Näherung. Ich muss ja eigentlich nur wissen, wir oft ich (in Abhängigkeit der Entfernung von der Wand und der Senkrechten zur Wand) in zB 1er Schritten den Abtaststrahl nach links und nach rechts machen muss....

[Dr. Irata]

.... folgende Überlegung fällt mir dazu gerade ein:
Ich befinde mich ja zunächst nur auf einer virtuellen Matrix. Diese Matrix analysiere ich und stelle sie dann auf dem Bildschirm dar. Die Breite des Bildschirmes bzw. des Ausschnittes, den ich darstelle, bildet mein FoV, meine Sichtlinie ist die Mitte des Bildschirmes, dadurch ist eigentlich immer auch genau definiert, wie oft ich nach links und rechts von der Hauptsichtlinie (die immer in der Mitte ist) in der Matrix gehen muss...

[Erhard]

Vielleicht mal versuchen, den Author von Final Assault zu fragen?

[Dr. Irata]

Hallo Erhard,
es gibt ja genügend Literatur, was das Ray Casting angeht. Das Prinzip ist klar und auch die theoretische Umsetzung.
Das Problem ist dann praktischer Natur: Wie baue ich das speziell auf einem Atari 8 Bit in Assembler. Die neueren Beispiele nutzen überwiegend C als Hochsprache oder haben spezielle Grafikprogramme. All das geht beim Atari nicht. Man muss das Prinzip extrem auf unsere kleine Kiste anpassen und dabei 3x um die Ecke denken. Fast alle Beispiele kochen ihre eigene Suppe und haben sicherlich ganz eigene knifflige und pfiffige Umsetzungen. Die entsprechenden Assemblercodes werden extrem komplex sein - jeder hat auch so seine Art zu programmieren - und so macht es wenig Sinn andere Autoren zu fragen... vor einem Jahr wollte ich die Softwaresprites lernen, hatte eine wirklich gute Vorlage und dann aber alles in die Ecke geworfen und es für mich komplett neu von Grund auf gemacht und so erlernt. Und das macht es ja auch aus. Ich möchte das hier entwickeln und alle Klippen umschiffen bzw. meistern - gerne mit Inputs von anderen Programmierern - und daraus am Ende was schönes zu bauen...
Liebe Grüße
Peter

[Erhard]

Hi,

Die neueren Beispiele nutzen überwiegend C als Hochsprache

ich habe selber schon einige Sachen umgesetzt, für die im Internet entweder nur die Hardwarebeschreibung oder ein schlecht dokumentiertes Ablaufdiagramm verfügbar waren.

Dazu gehören Bubble-Sort (hab ich in jungen Jahren mal für eine DB in BASIC gebraucht), ein RC4-Tool für SpartaDOS und 1-Wire. Besonders RC4 hat mir damals das Gehirn verbogen. Und gerade weil das alles immer noch deutlich einfacher ist als das abgefahrene Grafikzeugs hatte ich angenommen, daß native Beispiele vom echten A8 erleuchtend wirken können. Deshalb muß man ja noch lange nicht beim Quellcode Copy'n'Paste machen ...

CU

[Dr. Irata]

Hi Erhard,
ich verstehe das ja, aber mittlerweile habe ich mich tief in die Assemblerprogrammierung des Ataris eingearbeitet... mein Programmierstil ist auch anders, glaube ich, da ich mir alles selber erarbeitet habe und die Profis in der Regel aus der C++ am besten noch objektorientiert herkommen. Das merke ich immer, wenn ich mich mit Janko austausche, der das halt professionell gelernt hat und ich aber was das angeht ganz anders programmiere... andere Codes zu lesen finde ich eher schwierig.
Das Thema der 3D ist so kompliziert, ich kann mir echt nicht vorstellen, daß ich da einen fremden Code so richtig durchdringe. Außerdem erlerne ich solche Dinge auch selber gerne und schöpfe daraus meine Befriedigung.
Ich versuche bis zur Fujiama ein wenig weiterzukommen und dort gibt es massiv know how ... alleine die Gespräche mit Peter werden in dieser Hinsicht sicherlich weiterführen - darauf freue ich mich schon ganz besonders! Aber auch auf die M.U.L.E. Zockabende und einfach auf 5 tolle Tage!
Kommst du eigentlich auch?
LG
Peter

[Kveldulfur]

der das halt professionell gelernt

Hallo Peter!

Nein, dass habe ich mir auch selbst beigebracht. Ich bin Querseinsteiger in die IT. Gelernt habe ich Vermessungstechniker
Warte ab, soviel wie Du Dich mit Assembler beschäftigst, sieht dein Quellcode bald genauso aus, wenn nicht sogar besser.

Grüße
Janko

[Dietrich]

Das kann ich natürlich alles mathematisch berechnen, aber wir sprechen hier von arcTan und so weiter.....

Also, generell würde ich für komplizierte Funktionen vorab berechnete Werte in eine Tabelle stellen und dann per Index reingreifen, etwa so (passend skaliert):
ldy arctan_argument: lda arctan_tabelle,y: sta arctan_wert

Oder einfach direkt nähern, z.B. ist für arctan(x) für betragsmäßig kleine x (so -0.8 bis 0.8) ungefähr x und für betragsmäßig große x etwa -Pi/2 bzw. +Pi/2.

[Dr. Irata]

... ja, das werde ich mit einer Tabelle machen... oder mir fällt etwas viel einfacheres ein. Ich habe da eine Idee, die Frage ist nur, wie das nachher aussieht.

[Dr. Irata]

... heute habe ich mich noch sehr viel mit Grundlagen beschäftigt und war erstaunt, was es alles so "gibt".
Zunächst war mir klar, daß ich ja zur Berechnung des Blickpunktes bis zur 1. Wand den Satz des Pythagoras benötigen werde. Hier muss ich quadrieren, was kein größeres Problem darstellt und dann aber die Wurzel ziehen.
Eine Iteration macht es möglich das auszurechnen - nur das Problem ist die vorherige Quadrierung, denn ruck zuck ist man über 255 und schon braucht man eine 16 Bit - Zahl. Also habe ich ein paar Ideen entwickelt, wie man das Problem umgehen kann - und das funktioniert auch. Hier würde ich einige Tabellen brauchen und dann eine gute Näherung während des Bresenham-Zuges für die Distanz hinbekommen. Dann habe ich mich mal umgeschaut, ob es nicht eine Iteration bzw. Näherung gleich für den ganzen Pythagoras gibt - und siehe da, die Lösung ist so easy: Aus c*c = a*a+b*b wird einfach: c = a + b/2 , wobei b dann die kürzere Seite ist.
Jetzt kann ich loslegen:

Die 4 Bresenham-Routinen reinbauen, um den Weg vom Betrachter zu einem virtuellen Punkt zu detektieren (auf der Matrix) - sobald ein Wert > 0 gefunden wurde bricht dieser Strahl ab, die Länge wird berechnet und je nach Länge wird die Wand entsprechend groß oder klein gezeichnet. Dann kommt der nächste Sichtstrahl usw. bis das ganze FoV abgearbeitet wurde.
Ich denke ich werde mit zwei Bildschirmen arbeiten, damit immer nur im nicht sichtbaren Bereich gezeichnet wird.... auf gehts...

[Erhard]

Hi.

Kommst du eigentlich auch?

auf dem Plan steht es. Wollen tu ich auch. Aber ich kann nicht beschwören, daß es klappt.

[Dr. Irata]

... eine erste kleine noch sehr rudimentäre Umsetzung habe ich jetzt realisiert.
Alles noch ohne Größenperspektive und Drehung - aber schon mal ein begrenztes Field of View mit Umsetzung einer 2D Matrix in eine 3D Perspektive...

Als nächstes werde ich die Größen in Abhängigkeit der Entfernung zu den Wandteilen umsetzen, dann kommen die ersten Bewegungen...

[Dr. Irata]

... ein weiteres kleines Update...
Ich muss sagen, die Umsetzung ist nicht einfach!! Tatsächlich schaffe ich es jetzt schon, relativ einfache Wände auch verschieden farbig darzustellen. Die Perspektive stimmt noch nicht - da ist echte Handarbeit nötig, damit die Wände alle in der richtigen Größe je nach Abstand zum Beobachter stehen. Auch die schrägen Linien sind noch zu grob... kann man alles machen, kostet aber Rechenzeit, die schnell weg ist.... Noch wirkt alles irgendwie ruckelig und nicht gut aufgelöst - aber immerhin schaffe ich jetzt schon einen Rundumblick... alles ist vorbereitet, um durch die Matrix zu gehen und die Wände und Dinge entsprechend darzustellen.
Am Ende muss ich sehen, ob es für ein Game reicht, oder ob das hier nur so eine Art Machbarkeitsstudie wird...

toevideo.mov

(920.06 KiB) 25-mal heruntergeladen

[Erhard]

Hi,

wenn man mal bedenkt, daß allein für "matrix1.txt" über ein 1K drauf geht ...

Die Tabelle enthält nur Nullen und Einsen, wäre also auch binär abbildbar, was dann aber wieder auf die Rechenzeit gehen dürfte ... aber bei einer Datenkompression von 1:8 ?

Ich hab so gar keine Ahnung von dem Thema aber das ist mir als Unbedarftem aufgefallen.

CU, Erhard

[Dr. Irata]

Hallo Erhard,
das stimmt natürlich. Die Tabelle wird aber noch andere Elemente bekommen. Und dennoch macht eine Kompression evt. später Sinn - wobei ich mich mit der Kompression gar nicht auskenne und das daher meide.
Insgesamt wäre das 3D Game (wenn ich es überhaupt realisieren kann) auf einen XE mit 128 kB ausgerichtet. Da sollte dann genug Platz für die Matrix sein...
Im Moment habe ich aber noch ganz andere Probleme:
Der Schwenk nach rechts und links funktioniert nur für einen Teilausschnitt - sobald ich an die rechte oder linke Matrixwand stoße bekomme ich Fehler (was logisch ist), hier ist noch ein wenig Hirnschmalz und Code nötig.
Mein derzeitiges größtes Problem ist allerdings die nicht stimmende Perspektive. Im Prinzip macht er, was ich will - allerdings dann doch nicht . Es liegt an der Berechnung des Abstandes vom Betrachter zur jeweiligen Wand und dann die Umsetzung: Weiter Abstand / kleine Wand, naher Abstand / große Wand. Hier muss ich noch richtig viel tun, damit es gut aussieht... vielleicht scheitere ich auch daran...
Liebe Grüße
Peter

[Erhard]

Hi,

vielleicht scheitere ich auch daran

ist halt ein riesiges Vorhaben.

CU, Erhard

[Dr. Irata]

absolut... ich denke am WE werde ich mir das mal genau auf einem Blatt aufmalen und dann die Entfernungen ausrechnen und entsprechend die Perspektiven danach anschauen und berechnen... das dann evt. in einer Tabelle umsetzen...

[Dr. Irata]

... das habe ich jetzt mal getan und alles neu berechnet:

und dabei ist für die Darstellung der entsprechenden Wandteile in Abhängigkeit von der Perspektive und des jeweiligen Sichtstrahles eine für mich neues Formel rausgekommen: P(x / y0-d+dx/2)
x ist die horizontale Position der Wand, die y-Position der Wand berechnet sich aus der y-Position des Players minus der Perspektive d - also der Entfernung des Betrachters zur Wand plus der Abstand Betrachter zur Wand in x-Richtung durch 2... läßt sich alles super einfach berechnen!
Folgende erste Umsetzung ist dabei bereits herausbekommen:

toe1.mov

(1.41 MiB) 24-mal heruntergeladen

Das ist bereits jetzt echtes Ray-Casting. Probleme gibt es noch mit der Drehung und dem Schwenk nach rechts und links. Die Wandteile sind bislang einfarbig und ich habe bislang nur 2 Farben eingesetzt, das kann man aber leicht erweitern. Der Bildaufbau ist insgesamt noch ruckelig... da fällt mir aber sicherlich noch einiges an Optimierungen ein und die Tabelle mit der Perspektive muss ich noch optimieren...

[Dr. Irata]

... ein weiteres Problem ist mir jetzt gerade klar geworden: Im Prinzip schaue ich die ganze Zeit nach vorne (in der Matrix nach oben) und beziehe mich bei dem FoV auf die x-Werte und lasse dann meinen jeweiligen Sichtstrahl z.B. von x=5 bis x=25 wandern. Das funktioniert. Wenn ich nach rechts schwenke, dann geht der x-Bereich entsprechend nach rechts oder links mit. Die Bewegung nach vorne bzw. nach hinten läuft ähnlich, es wird der jeweilige y-Wert incrementiert oder decrementiert... das ist natürlich nicht korrekt und spätestens wenn ich an den linken oder rechten Rand stoße, dann geht es nicht mehr. Die komplette Rotation funktioniert entsprechend auch gar nicht. Im Grunde muss ich es so programmieren, daß ich mich völlig frei in der Matrix bewegen kann und sich das FoV (field of view) immer nach der jeweiligen Blickrichtung ausrichtet.... hat da jemand Erfahrung mit? Wahrscheinlich komme ich nun doch nicht an Winkeln mit sin cos etc. vorbei....

[Erhard]

Ich weiß, daß ein PC allein von der Taktrate der CPU 2000 mal schneller ist als der A8 aber wenn man so liest, wie schwierig allein so eine "einfache" Sache ist wundere ich mich, daß sowas wie ArchAge, Hogwarts Legacy, Landwirtschaftssimulator oder New World, wo man alles aus jedem Blickwinkel betrachten und jeden Baum umrunden kann plus der Effekte wie Beleuchtung und Schatten, überhaupt möglich ist ...

[Dr. Irata]

Guten Morgen Erhard,
ja in der Tat wundert einen das so manchmal. Nun muss man allerdings bedenken, daß die allermeisten dieser Programme in C geschrieben werden und die Befehle dort einfach viel mächtiger sind, als in Assembler. Irgendwelche komplexen Fließkommaberechnungen mit Winkelfunktionen etc. gehen da mit einer Kommandozeile und laufen sehr schnell ab, in Assembler - und gerade auf unserem alten A8 - muss man alles quasi neu erfinden und optimieren. Theoretisch könnte man relativ einfach einen Raycaster in Basic schreiben, dann kannst du aber zusehen wie die Pixel gemütlich über den Screen stolpern

[Dr. Irata]

Ich habe ja einen täglichen Arbeitsweg von 2x45 Minuten und verbringe diese Zeit sehr oft zum Grübeln... und im Kopf habe ich nun eigentlich alle Lösungen für meinen Raycaster parat.
Eigentlich ist es relativ simple - so far ....

Es gibt 2 Ebenen: Die erste Ebene - die nicht sichtbare Ebene - ist die Matrix. Hier sind alle Informationen der Landschaft enthalten und auch nur hier bewege ich mich und hier "arbeite" ich.
Die andere Ebene ist die des Bildschirmes. Diese Ebene ist simpel. Ich habe einen definierten Bildausschnitt und in diesen Bildausschnitt printe ich die ganze Zeit mein FieldOfView. Die Position des Betrachters in Bezug auf den Bildschirm ist immer gleich. In der Mitte. Der linke Rand des Bildschirmes ist der linke Rand meines FoV und entsprechend der rechte Rand rechts. Nun brauche ich nur noch den Abstand von mir und dem Objekt und die jeweilige x- und y-Position - und das erhalte ich direkt aus der Matrix!

Eigentlich muss ich mich also fast nur um die Matrix kümmern. In der Matrix hat der Player eine bestimmt x- und y-Position. Um den Player herum werde ich in einer Tabelle einen relativ großen Kreis spannen. Der Kreis ist virtuell, hat dabei aber eine klare Nord-Süd-Ausrichtung genau wie die Matrix. Meine Blickrichtung bezieht sich auf den Kreis und je nachdem wo ich auf dem Kreis bin (ich werde das winkelabhängig festlegen) wird eine Tabelle abgefragt. Hier werde ich dann entsprechende Werte hinterlegen in wie weit man in x- bzw. y-Richtung zu laufen hat. Im Grunde ist das dann die Steigung einer virtuellen Geraden in Blickrichtung - mein Sichtstrahl. Konkret bedeutet das z.B.:
wenn ich für den Kreis 72 mögliche Positionen festlege, dann wandert der Blick jeweils um 5 Grad weiter, auf Position 9 steht der Blick bei 45 Grad, die Tabelle würde jetzt für x und y den Wert 1 ausgeben, also ein Schritt in x-Richtung und ein Schritt in y-Richtung, jeweils vom Ausgangspunkt des Players. Trifft man auf ein Hindernis der Matrix, stoppt der Sichtstrahl und die Position und der Abstand wird berechnet und dann auf den Bildschirm geprintet. Der Abstand wird mit Pythagoras berechnet und hier nehme ich die bekannte einfacher Näherung c=a+b/2, b<a
Die Bewegung erfolgt auch in der Matrix und geht immer nur nach vorne oder nach hinten und dann in Abhängigkeit des einen Sichtstrahls genau in der Mitte des FoV.

Damit habe ich alles (im Kopf) und muss das jetzt nun noch umsetzen. Den ganzen Bresenham-Algorithmus oder das Zeichnen schneller Linien mit viel Rechenzeit brauche ich damit nicht mehr...

Mein Ziel ist es am Ende natürlich einen Raycaster für mich zu entwickeln, aber auch eine relativ einfache Engine für alle zu bauen. Dann muss man nur noch die Matrix erstellen und kann die dann 3D auf den Bildschirm über die Engine ausgeben...

Gruß
Peter

P.s. Dieses Thema wird relativ wenig kommentiert. Liegt es daran weil es zu speziell oder kompliziert ist?

[andymanone]

P.s. Dieses Thema wird relativ wenig kommentiert. Liegt es daran weil es zu speziell oder kompliziert ist?

Hallo Peter,

ich denke, das hat mehrere Gründe.
Zum einen haben wir gerade Urlaubszeit und die Leute sind - wenn das Wetter es zulässt - auch mehr draußen unterwegs.
Zum anderen ist das Thema super spannend und interessant aber auch schon recht komplex und wenn man sich nicht selber
damit direkt beschäftigt, ist es nicht so einfach, sich da reinzuversetzen.

Trotzdem lese ich alle deine Gedanken & Ideen hier - auch wenn ich selbst nicht viel Nützliches dazu beisteuern kann (und ich denke, es geht hier vielen Usern wie mir ),
darum will dich auch ermutigen, weiterzumachen!

Gtx.,
andY

[Erhard]

Hi,

P.s. Dieses Thema wird relativ wenig kommentiert. Liegt es daran weil es zu speziell oder kompliziert ist?

ich finde das Thema (obwohl ich in Mathe im Gymmi gut war und nicht alles vergessen habe) durchaus kompliziert und für mich, als jemanden der Deine Beiträge zwar liest aber die Sachen nicht selbst am Rechner abarbeitet kommt hinzu, daß ich versuchen muß, mir alles vorzustellen (b.t.w.: klappt nur bedingt)

Ich hab dabei immer so ein Spiel wie "Final Assault" vor Augen.

die Leute sind - wenn das Wetter es zulässt - auch mehr draußen unterwegs

Nebenbei: auch Thom bittet ja hier im Forum für das FujiNet um Unterstützung und soweit ich das erkennen kann kommt da auch so gut wie nichts. Das liegt da sicher auch an der Sommerpause. Dann haben Leute mit Familie pauschal weniger Zeit (keine Ahnung wie Carsten (Club) und Peter (WUDSN) das alles auf die Kette kriegen). Dann hat der ein oder andere vielleicht sein eigenes Projekt oder Spieletests oder einen Magazinbeitrag in Arbeit.

Ich hab momentan auch nur Zeit zum Texten, weil in meinem IT-Job gerade Sommerloch ist.

Bei uns hat es bis Ende Mai kein "outdooractivity-taugliches" Wetter gegeben. Im Juni waren es 3 Wochen Sonne, was mit der Sommersonnenwende dann auch vorbei war. Dann war da noch ein heißes Wochenende Anfang Juli und seitdem schüttet es. Und ja, nach 7-9 Monaten Scheißwetter wollte ich in der Tat mal mehr raus. Da das nicht klappt bin ich mit Freunden am WE im Freizeitbad. Und wenn da sonst mal noch etwas Zeit war habe ich am Thema Analyse von Formaten von Disketten gearbeitet.

will dich auch ermutigen, weiterzumachen

Da stimme ich zu. Ist wie Magazinbeiträgen. Wann kriegt da mal ein Author eine Rückmeldung trotz der theoretischen rund 500 Leser? (Wobei ich tatsächlich schon mal das Glück hatte).

[Erhard]

Bei toe1.mov sehe ich bei Bewegung immer unten flackernde Fragmente ...