Ray Casting

[Dr. Irata]

... danke für die Rückmeldungen...
das Flackern sehe ich auch und verstehe ich nicht - muss aber eh alles komplett neu überarbeitet werden, da der alte Ansatz zwar schon recht gut funktioniert, aber doch in eine Sackgasse führt.
Ich werde fast alles komplett neu stricken müssen (und freue mich schon drauf!!).

Eigentlich echt interessant - ähnlich wie letztes Jahr wo ich die Softwaresprites in Angriff genommen hatte - jetzt das Ray-Casting... bin ich jetzt so langsam dabei das Thema zu durchdringen (ok -wie das mit den Texturen geht... das bekommen wir später) und am Anfang komplett ahnungslos, zwischendurch frustriert und mehrfach so weit das Projekt zu stoppen und aufzugeben. Aber nach vielen Wochen komme ich so langsam dahinter und bin mittlerweile richtig zuversichtlich, daß ich am Ende alle Klippen meistern werde.

So in noch etwas größerer Ferne winken die Themen wie: Texturen, animierte Gegener/Schüsse - alles natürlich in korrekter Perspektive in 3D.... das wird richtig tricky!!

Eines noch zum Flackern: Wenn alles läuft - also die Drehung und Bewegung nach vorne und hinten mit Kollisionsabfragen, werde ich den eigentlichen Printvorgang wohl wieder mittels zweier Bildschirmen realisieren. Der Printvorgang läuft dann jeweils im nicht sichtbaren Bereich und erst wenn das komplette FoV gezeichnet wurde, wird entsprechend umgeschaltet. Beide Bildschirmbereiche will ich in eine eigene Bank legen, wo dann der Grafikchip direkt zugreifen kann... so der Plan

[Mathy]

.
Hallo Peter

Ich kann mich bei meine "Vorschreiber" auch nur anschliessen.

Tschüß

Mathy

[Mathy]

.
Hallo Peter

So in noch etwas größerer Ferne winken die Themen wie: Texturen, animierte Gegener/Schüsse - alles natürlich in korrekter Perspektive in 3D.... das wird richtig tricky!!

Du vergisst die Routinen mit der du die Nutzung von MIDI-Mate-Interface ermöglichst.

Tschüß

Mathy

[Erhard]

wo dann der Grafikchip direkt zugreifen kann

bitte daran denken, daß es nicht bei allen Systemen getrennten Zugriff von CPU und ANTIC auf Speichererweiterungen gibt.

[Dr. Irata]

das Programm wird sicher wieder allen Speicher kosten und daher plane ich es wieder direkt für den 130 xe

[patjomki]

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

Eher Letzteres. Ich lese hier interessiert mit, kann aber leider nichts Erhellendes zur Situation beitragen, deswegen unterbleiben Kommentare von meiner Seite

[Dr. Irata]

Leider hatte ich da doch noch einen kleinen Denkfehler, denn auch ich kann die Physik / Mathe nicht austricksen... jedenfalls nicht komplett.
Für die ganzen Berechnungen in der Matrix bleibt es wie es ist. Für die Darstellung auf dem Bildschirm brauche ich zwingend sin und cos!!
Aus der Matrix generiere ich ja nur den Abstand des Betrachters zum Gegenstand/zur Wand in Abhängigkeit vom Blickwinkel 0 Grad.
Für den Bildschirmprint benötige ich aber die Position in x und y-Richtung zum Hauptsichtstrahl - dieser ist ja immer fix und auch die Position des Betrachters zum Bildschirm bleibt immer gleich und fix. Das gesamte FoV rotiert oder kommt näher, oder weiter weg und nicht der Betrachter selber... also in der Matrix bewege ich mich, die eigentliche Darstellung des sich immer ändernden FoV auf den Bildschirm muss aber so erfolgen, daß alle Objekte quasi bewegen... klingt kompliziert.
Na jedenfalls brauche ich den Abstand a und b (was nix anderes ist als x und y für die Bidschirmausgabe des Objektes.
Demnach ist dann a = d * cos alpha und b = d * sin alpha

Weil man das in Assembler nicht gut rechnen kann, mache ich also eine weitere Tabelle für jeweils 8 verschiedene Winkel und 30 verschiedenen Abständen d (von 0-30). Verbraucht dann nochmals ca. 500 Bytes....

Hier die ersten Werte:

Die ganze Sache ist schon wirklich kompliziert.....

[DjayBee]

Rechnest du das echt von Hand auf Zettel?

Ich würde das in Excel, Atari BASIC oder sonstwas tun.

[Irgendwer]

Ich würde das in Excel, Atari BASIC oder sonstwas tun.

...oder einfach die Implementierung aus der cc65 Bibliothek nehmen. (Die Symmetrien der Funktionen auch noch speicherplatzsparend nutzt.)

https://github.com/cc65/cc65/blob/maste ... n/sincos.s

[Dr. Irata]

das mache ich doch alles für euch hier

Als alter Hobbymathematiker bin ich allerdings Geodreieck, Rechner und Bleistift gewöhnt und finde das für mich auf einem Blatt Papier immens plastisch, anschaulich

[Dr. Irata]

der Link ist natürlich super... vielen Dank dafür!

[Erhard]

Hi,

Als alter Hobbymathematiker bin ich allerdings Geodreieck, Rechner

falls Dir das schon zu fortschrittliche Mittel sind - ich hätte da auch noch einen Rechenschieber ...



CU, Erhard

[Dr. Irata]

... tatsächlich habe ich damals schon wegen eines progressiven Mathelehrers als einer der Ersten mit einem TI Taschenrechner rechnen dürfen. Dieser hatte sogar schon erste Programmierfunktionen...
Damals hatte ich aber den alten Rechenschieber meines Vaters irgendwo gefunden und mich mal damit beschäftigt... geht!!!

Manche Dinge muss man einfach auch pragmatisch sehen! Wenn ich schon dabei bin die Mathematik zu meinen Problemen geometrisch und arithmetisch auf einem Zettel herzuleiten, dann kann ich auch schnell ein paar Zahlen berechnen. Die Zahlen habe ich dann direkt auf dem Zettel und kann sie später dann in mein Programm übertragen. Manchmal geht das händisch tatsächlich schneller.
Alternativ hätte ich natürlich auch ein kleines Programm mit Atari Basic machen können... oder eine Numbers Tabelle. Ich wette insgesamt wäre es mit den paar Zahlen nicht schneller gewesen

Ich mache ja fast alles digital, manche Dinge sind aber analog auch gut und evt. sogar übersichtlicher...

[Dr. Irata]

.... ich habe das jetzt mal aus Spaß versucht umzusetzen: Excel ist echt gut und früher habe ich damit viel und gerne gearbeitet... das war mit Abstand beste Programm von Microsoft!! Numbers von Apple stinkt da echt ab. Ich habe nur Numbers. Die benötigte Integer Funktion habe ich nicht gefunden, daher gestaltet sich die Tabelle zunächst schwierig. Habe ich dann aufgegeben.
Dann habe ich ein kleines Programm in Atari Basic geschrieben. Die doppelte Schleife war einfach programmiert, gibt aber für Sinus falsche Werte aus... keine Ahnung warum. Insgesamt rechne ich es zu Fuss, weil es nicht viel zu rechnen ist und mir tatsächlich Zeit spart...

[Dr. Irata]

... ok ... also Atari Basic ist auf Bogenmaß eingestellt! Mit DEG stellt man auf Grad um und dann kommen auch die korrekten Werte raus...

Die Tabellenfunktion von Numbers ist ebenfalls auf Bogenmaß eingestellt - die Umstellung auf Grad ist echt mega umständlich - die Integer - Funktion heißt "ABRUNDEN" - wie blöd ist das denn.... also wenn mir was fehlt bei Apple dann ist echt mindestens Excel......

[Dr. Irata]

... open office ...

[Mathy]

.
Hallo Peter

Ich benutze NeoOffice. Das läuft nativ auf dem Mac und kann sowohl Tabellenkalkulation als auch Textverarbeitung und wenn ich mich nicht irre PowerPoint. Ist verwand mit OpenOffice.

Es gibt aber auch Office für den Mac. Da ich aber Microsoft nicht mag...

Tschüß

Mathy

[CharlieChaplin]

das Programm wird sicher wieder allen Speicher kosten und daher plane ich es wieder direkt für den 130 xe

(Siehe auch den obigen Kommentar von Erhard!)
Der 130XE hat 128k RAM und sep. Antic Zugriff - viele andere XL/XE Speichererweiterungen haben zwar XRAM aber eben keinen sep. Antic Zugriff, z.B. alle Rambo kompatiblen Erweiterungen (Rambo, Atari Magazin, Newell, TOMS, Buchholz, etc.). Den 130XE gibt es seit 1985, also gibt es den sep. Antic Zugriff seit ca. 40 Jahren und in dieser Zeit sind "mega" viele Programme erschienen, die das nutzen - insgesamt weniger als 10 Stück ! Daher verzichten auch viele Erweiterungen (und Atarianer) auf die Nutzung dieses Modus, weil es halt kaum etwas dafür gibt. Zwischenzeitlich wurden sogar schon mehrere Programme mit sep. Antic Zugriff so gepatcht, dass sie auch ohne diesen laufen. Also landet dein Programm sodann in einer Nische, weil es von weniger als 50% der Atarianer genutzt werden kann, schade um die viele Arbeit!

[Mathy]

.
Hallo Andreas

... - insgesamt weniger als 10 Stück ! Daher verzichten auch viele Erweiterungen (und Atarianer) auf die Nutzung dieses Modus, weil es halt kaum etwas dafür gibt.

Das stimmt so leider nicht. Claus Bucholz hat damals die erste Speichererweiterung vom Typ "$D301" entwickelt. Diese hat noch 32kB Bänke umgeschaltet. Als dann Atari der 130XE rausgebracht hat, hat Bucholz seine Erweiterung umgestrickt auf "16kB Bänke". Was er aber nicht gemacht hat, ist den separaten ANTIC und CPU Zugriff hinzufügen. Den separaten Zugriff braucht etwas mehr Hardware als die Bucholz-Methode. Deswegen haben wohl (auch) die meisten die eine Speichererweiterung vom Typ "$D301" entwickelt haben, auch darauf verzichtet. Speichererweiterung waren damals nicht billig, extra Hardware hätte die Erweiterungen noch teurer gemacht. Und mittlerweile haben (fast) alle einen bezahlten (Ganztags-)Job, damals aber haben viele von uns noch die Schulbank gedrückt.

Tschüß

Mathy

[LarsImNetz]

Ich finde das Thema auch sehr interessant nur auch noch nicht dazu gekommen mal meinen "Sempf" dazu abzugeben.
Aber einen Tipp hätte ich...

Also, wenn ich es richtig verstanden habe, stellt die Matrix den Raum dar, indem man sich bewegt, richtig?
* Dann ist die Frage, wozu Sinus/Cosinus nutzen, das ist doch viel zu teuer.
* Also es wird ein virtueller Kreis um die eigene Position gezogen, mit einem Radius von 16?
* Jetzt die Frage, der Blickwinkel, von, bis. Ich rate mal ~90°
* Dann die Frage, wie viele Steps, um von 0° auf 90° zu kommen? Vielleicht 15 Steps, dann ruckelt es vielleicht nicht ganz so.(Geraten) Insgesamt also 60 verschiedene Richtungen in die man blicken kann bei 360° (Vollkreis).

Also eine Idee von mir wäre die 60 Positionen (x,y) in einer Tabelle abzulegen.
Wenn man in eine Richtung blickt, ziehe eine imaginäre Linie von Richtung N bis N+15 (90° bei 15 Steps) mit einem Line-Algorithmus. Jeder Punkt auf dieser Linie ist ein Zielpunkt für die Blickberechnung nennen wir ihn Blicklinie. Jetzt braucht man nur einen weiteren Line-Algorithmus um von der eigenen Position (x,y) zu jedem Punkt auf der Blicklinie zu kommen. Die Tiefe ist die Länge auf dieser Linie. Stößt man auf eine Wand ist die Berechnung zu Ende. Man kennt dann die Entfernung.
Legt man in der 60-Positionen Tabelle noch den Winkel mit ab, lässt sich das bestimmt auch nutzen.

Der Zugriff auf die Matrix ist immer x+y*n also sollte es auch hier eine Tabelle geben, die y*n vorberechnet hat, dann wäre der Zugriff auf die Matrix x+tabelle[y]
Jetzt kann man bestimmt mal kurz durchrechnen, was das denn an Rechenzeit kosten würde sich so durch die Matrix zu hangeln.

Dabei ist mir aber aufgefallen, das ich die erste Linie gar nicht brauche, es reicht völlig aus, sich von N bis N+15 auf der Positionentabelle längst zu hangeln.
Also müssten 16 Linien verfolgt werden von der eigenen Position (x,y) zu N bis N+15. Dabei würden aber sehr viele Punkte mehrfach besucht gerade am Anfang, was man bestimmt noch optimieren könnte. Also verwerfen wir auch diese Idee.
Aber:
Im Endeffekt ist es grob ein Dreieck das auf der Matrix durchsucht werden müsste. Also 16 * 16 / 2 Punkte. Wir müssen von der eigenen Position also 128 Punkte in der Matrix besuchen. Was läge hier näher als diese 60 Dreiecke in Offset-Tabellen abzulegen, die belegen dann ca. 16kb RAM die eigene Position muss dann immer nur als Offset addiert werden zur Position in der Matrix.
Kein Punkt müsste für eine Blickrichtung doppelt besucht werden.
Hier könnte evtl. ein flotter Rechner mal eben diese Offset-Tabellen(Matrix-Access-Tables) berechnen und doppelt besuchte Punkte innerhalb der Matrix herausfiltern oder ggf. vergessene Punkte extra hinzufügen.

Wenn wir also oben links stehen (0,0) und nach unten rechts blicken (15,15) das entspräche 45°, würde die Matrix-Access-Table bei einer Größe von (64x64) = 4096 Bytes, wie folgt besucht werden müssen. 0 könnten wir uns sparen, da stehen wir selbst.

0, 1, 64, 2, 65, 128, 3, 66, 129, 192, ...

Eine Entfernungungstabelle würde wie folgt aussehen:
0, 1, 1, 2,2,2, 3,3,3,3, ...

0 1 2 3 ...
1 2 3 ...
2 3 ...
3 ...

Die weiteren Matrix-Access-Tables sind jeweils um 5° weiter gedreht.

Kannst ja mal drüber nachdenken.

LG
Lars

[Dr. Irata]

Hallo und guten Morgen Lars,
sehr interessanter Aspekt mit der Matrix und den Punkten... werde ich mal durchdenken.
Eigentlich war mein jetziger Ansatz ganz ähnlich. Ich betrachte einen 1/4 Kreis - also von 0-90 Grad und lege für jeweils plus 2,5 Grad die entsprechenden Wege in Blickrichtung fest. Für eine Blickrichtung könnte das z.B. folgende Logik sein: 1,2,1,2,1,3,1,2,1,4... dann wieder die gleiche Folge. Der erste Wert geht in x-Richtung und der 2. in y-Richtung. Bei jedem Step wird geschaut, ob ein Hindernis vorliegt. Wenn ein Hindernis kommt, stoppt die Blickrichtung sofort und die nächste wird ausgeführt.
Ich muss noch schauen bei dieser Methode, ob es blinde Flecken geben kann - vielleicht ist da deine Methode besser...

Das Problem kommt jetzt leider aber erst noch und das war mir immer nie so richtig klar: Die x- und y-Werte der Matrix kann ich nicht so einfach für die Wiedergabe auf den Bildschirm nutzen. Die Blickrichtung in der Matrix ist ja immer verschieden wenn man sich dreht - und das tut man ständig - die Blickrichtung auf dem Bildschirm ist immer ganz fix nach vorne - um nun die x- und y-Positionen bei einem Treffer in der Matrix auf die Position auf dem Bildschirm darzustellen muss ich es mit sin und cos umrechnen. Es sei denn ich habe gerade einen Knoten in der Denke und / oder es geht noch viel einfacher...
LG
Peter

[Dr. Irata]

... nach 2 Wochen im Camper quer durch Südeuropa und nach über 4000 Km nun zurück. Eine Woche arbeiten und dann ist endlich die Fujiama!! Vorher werde ich endlich mein Projekt weiter entwickeln - es gibt viel zu tun - und dann auf der Fuji programmieren programmieren programmieren... freue mich total auf die Zeit mit Euch...

[Dr. Irata]

...
jetzt habe ich 2650 Bytes dafür investiert, um den Bresenham - Algorithmus zu ersetzen. Insgesamt 140 Draw-Anweisungen in einer Tabelle und je nach Blickwinkel von 0-360 Grad in 2,5 Grad-Schritten kommen dann die entsprechenden Anweisungen der Schritte in x- bzw. y-Richtung zur Anwendung. Einen Endpunkt des jeweiligen Sehstrahls gibt es nicht, lediglich wenn man beim Auslesen auf eine Zahl größer Null trifft, wird der Sehstrahl beendet, die Informationen berechnet und abgespeichert. Dann kommt der nächste Sehstrahl, bis das gesamte FoV abgearbeitet ist.
Alle Werte werden für die spätere Bildschirmausgabe berechnet (Sinus / Cosinus) und in Variablen gespeichert und wenn das FoV abgearbeitet ist am Stück geprintet.
Insgesamt erhoffe ich mir damit deutliche Geschwindigkeitsvorteile bei der Bilderstellung und auch insgesamt, da ich nun nichts mehr mit Bresenham berechnen muss. Außerdem war das notwendig, da der Betrachter ja in der Matrix sich bewegt und der virtuelle 0-360 Grad Blickwinkelkreis ebenfalls. Bei Bresenham brauche ich ja immer einen definierten Start und ein definiertes Ende, was ich so nicht habe und aufwendig mitberechnen müsste. Das fällt weg.

Als nächstes erstelle ich noch eine umfangreiche Tabelle für die Sinus und Cosinus Berechnungen... dann müsste ich es haben!!

[Olix]

... ich verstehe ja seit längerem nur noch Bahnhof

Bin aber trotzdem schon gespannt auf das nächste Ergebnis und vor allem tief Beeindruckt!

[Dr. Irata]

... nun habe ich die Sinustabelle eingefügt, darin sind die Werte enthalten für die Berechnung der x-Position der gefundenen Wand in Abhängigkeit vom Winkel zum Hauptsichtstrahl (0 Grad) und dem Abstand d vom Betrachter (Player) und dem getroffenen Wandteil. Dabei habe ich d-Werte von 0-50 und Winkel 2,5-22,5 Grad genommen. Das kostet mich nun also ca. ein halbes Kilobyte.

Als nächstes wollte ich die Cosinustabelle entsprechend reinbringen.. und siehe da: Die Werte für Winkel zwischen 0-22,5 Grad unterscheiden sich kaum. Cos 2,5 = 0,999 und Cos 22,5 = 0,92
Selbst bei einem maximalen Abstand von d=50 habe ich für den somit berechneten y-Werte nur eine Differenz von 4, bei kleineren Werten kann man fast sagen: d = y

Hier kann ich bestimmt eine schnelle Näherung reinbringen!!

[pps]

Schön, dass Du weiter voran kommst. Ich bin echt gespannt, ob Du eine spielbare Routine am Ende hinbekommst. Das Sowas gehen muss, sieht man ja an einigen echt beeindruckenden Spielen, von früher aber auch aktuell.

[Dr. Irata]

.... endlich hatte ich auf der Fujiama Zeit mich konzentriert mit der Umsetzung des neues Algorithmus zu beschäftigen.
Mein eigener Bresenham liegt nun in Tabellen und der Rundumblick mit Bewegung ist so möglich und das habe ich nun umgesetzt. Leider trat ein sehr hartnäckiger Bug auf, an dem ich mehrere Tage und Stunden rumgesucht habe. Letztlich konnte ich es am letzten Tag weiter eingrenzen und heute fiel der Groschen... mit einem sehr smarten Trick ist es mir gelungen, den Rundumblick nun vollständig durchzuführen und dabei nach vorne zu laufen.
Damit ich das alles besser sehen und kontrollieren kann, habe ich unter dem Fenster eine Art Radar eingebaut, wo man praktisch von oben auf die Matrix schaut und wo die Blickrichtung dargestellt wird. Die Matrix ist dabei allerdings in y-Richtung stark gestaucht, daher läuft die Drehung nur scheinbar in unterschiedlicher Rotationsgeschwindigkeit.
Die Wände werden jetzt auch richtig dimensioniert dargestellt, am Ende werde ich hier aber noch ein wenig optimieren müssen.
Leider passt die Auflösung nicht so gut und gerade bei schrägen Wänden wird der obere und untere Rand zu grob - daher stelle ich als nächstes von GTIA 10 mit 9 Farben wieder auf ANTIC 5 mit 4 Farben um, da bekomme ich die Auflösung in x-Richtung besser hin.

Hier noch ein kleines Video:

toe.mov

(3.2 MiB) 140-mal heruntergeladen

[Dr. Irata]

.... TempleOfEris sollte Teil 3 meiner Programmreihe werden. Ursprünglich wollte ich einen weiteren Shooter mach, diesmal aber als
Jump´n Run Spiel, wo man durch eine Art Höhlensystem zur Alienqueen vorstossen muss und diese dann final besiegen muss.
Irgendwie bin ich dann auf diese Idee gekommen es 3D zu machen. Zuerst habe ich mich mit Vektorgrafik beschäftigt und viel über den Bresenhamalgorithmus gelernt, danach habe ich dann gesehen, daß man mit Ray-Casting alles viel besser machen könnte. Das wollte ich lernen und umsetzen. Mir war dabei immer klar, wie schwierig und anspruchsvoll das Thema ist - aber nach jetzt fast 5 Monaten kann ich stolz sagen: Es geht und ich habe das Ray-Casting umsetzen können!!
Leider fehlt noch ganz viel:
1. Ein Bug hat mich viele Tage mehr als gequält und nun endlich habe ich ihn fast beseitigen können - durch einen Trick. Es funktioniert aber nicht vollständig.
2. Die Auflösung passt einerseits gut (9 Farben, die ich auch brauche), aber in x-Richtung bin ich eigentlich zu grob.
3. Die schrägen Wände sehen nicht wirklich gut aus, eine richt schön gezogene Wand bekomme ich noch nicht gut hin, da war ich mit der Vektorgrafik schon deutlich weiter.
4. Die Textur habe ich noch gar nicht bearbeitet und ehrlich gesagt, da habe ich noch fast keine guten Ideen.
5. Die Gegner mit Animation, Schuss und Perspektive... da bin ich noch meilenweit weg.

Wenn ich jetzt jeden Tag 3-7 Stunden am Projekt rumtüfteln würde, würde ich vielleicht in den nächsten 6 Monaten fast alle Probleme in den Griff bekommen - ob es dann vergleichbar gut wäre wie zB. Doom oder Projekt M oder Way Out ... glaube ich nicht!!!
Daher lege ich das jetzt auf Eis!

Jetzt werde ich die späten Sommertage noch geniessen und mir überlegen, was ich als nächstes mache.... vielleicht ein kleines Projekt!

Liebe Grüße
Peter

[pps]

Das ist sehr schade. Aber natürlich muss man immer abwägen, ob ein solch großes Projekt am Ende wirklich auch selbst bis zum Abschluss gebracht werden kann. Erst recht, da man das ja als Hobby macht und nicht als bezahlter Programmierer.

Genieße die Tage und ich bin gespannt auf Dein nächstes Projekt.

Gruß aus Bärlin,
Ralf

[Olix]

Ich kann nur meinen größten Respekt aussprechen. Wenn man bedenkt dass das mit einer Routine zum Zeichnen von Linien begonnen hat und jetzt schon Richtung 3D Engin sich entwickelt hat, kann ich nur den Hut ziehen. Also weiter so, mit einem neuen Projekt. Ich freu mich auf jeden Fall auf das was da noch von dir kommt.

[Dr. Irata]

... nach Rücksprache mit meinem Kumpel und Freund Janko, habe ich beschlossen das Projekt hier zu pausieren und doch nicht zu beenden.... ich werde erstmal etwas anderes starten und dann irgendwann ohne Druck an meinem Raycaster weiter arbeiten...

[Erhard]

Ich konnte dem Stoff (wie das geht, wie die Rechnerrei ausehen müßte und das dann noch einigermaßen in Echtzeit) schon gedanklich kaum folgen und ich hab mich die ganze Zeit gefragt, wo "der Typ" nur die Zeit für das alles hernimmt.

Also mein "Wow" hast Du auf jeden Fall auch.

[Dr. Irata]

... vorgestern bin ich um 5 Uhr aufgewacht und konnte nicht mehr einschlafen, da meine Gedanken die ganze Zeit um meinen Raycaster kreisten.
Ihr kennt das sicherlich, wenn man die ganze Zeit im Kopf Lösungsmöglichkeiten für Probleme durchgeht... na jedenfalls bin ich gestern und heute nochmal alle mathematischen Dinge durchgegangen - alles stimmt soweit. Nur bei der Berechnung der Höhe der Wände habe ich noch große Probleme gehabt. Da passte fast nichts!
Ich muss ja nach berechneter Distanz diese umkehren und dann mit irgendeinem Wert multiplizieren je nach erwünschter Wandhöhe. Das habe ich aber gar nicht mathematisch gemacht, sondern nach Auge / Gefühl.
Jetzt bin ich die ganze Logik nochmal durchgegangen und habe aus d die entsprechende Höhe mit H = 1/d * 80 neu berechnet - vielleicht ist 80 noch zu wenig, da probiere ich ein wenig rum.
Dann muss man noch die Distorsion rausrechnen. Die Distorsion bewirkt eine Verzerrung, da die Distanzen unbedingt parallel zum Hauptsichtvektor zu bestimmen sind und man ja durch den Blickwinkel der einzelnen Sichtstrahlen eine etwas zu große Distanz bekommt (siehe Bild).

Wenn d0 die gefundene Distanz zur Wand ist, dann muss man die Verzerrung noch rausrechnen: d = d0 * cos alpha
Je größer der Winkel, desto größer die Verzerrung.
In meinem Fall habe ich ja ein FoV von insgesamt 40 Grad - also jeweils 20 Grad nach links oder rechts vom Hauptsichtstrahl. Cos 20 = 0,94 .... die Verzerrung ist also nicht stark. Ich werde die Verzerrung aber in die Tabelle einrechnen, da ich 8 Sichtstrahlen habe, muss ich also dann für jeden Sichtstrahl eine eigene Tabelle anlegen, damit ich den cos nicht berechnen muss ... das ist dann ja in der Tabelle berechnet!

Ihr seht also: Ich komme von dem Thema kaum los, bin schon weit und komme auch voran und mache hier dann doch weiter!!

Was folgt nun: Ich muss einiges umbauen!

1. Ich muss 8 Tabellen ausrechnen, für jeden Sichtstrahl eine eigene Tabelle.
2. Die Abfragelogik anpassen - jetzt gehe ich von Sichtstrahl -20 aus und lauf bis +20. In Zukunft starte ich vom Sichtstrahl 0 und laufe erst bis -20 und dann von 0 bis +20
3. Bewegung nach hinten möglich machen.
4. Kollisionsabfrage - wenn der Player auf eine Wand trifft, bleibt er davor stehen.
5. Die Graphik anpassen - 256 Farben möglich machen.
6. Die Texturen reinbringen.
7. Die Matrix ausbauen.
8. Gegner reinbringen.
9. .......

LG und ein schönes WE
Peter

[Erhard]

Vielleicht ein guter Melissentee vor dem Schalfengehen? ....

[Dr. Irata]

Jetzt habe ich die Tabelle angepasst und entsprechend die Abstände korrigiert und die Distorsion raus.
Die Bewegung geht jetzt auch nach hinten, die Kollisionserkennung ist drin, d.h. geht man vor eine Wand, bleibt man da einfach stehen und läuft nicht durch.
Als nächstes muss ich noch die Ausnahme der "nahen Wand" fixen... in einigen Fällen detektiert er vor einer sehr nahen Wand einen Wandteil mit mehreren Sichtstrahlen und zeichnet diese Wand in gleicher Höhe mehrmal - das sieht blöd aus.
Das muss ich abfangen...
Danach baue ich die DL etwas um, damit ich 256 Farben bekomme... dafür nehme ich eine Vorlage, die ich von Janko bekommen habe - und dann kommt das große Thema der Texturen.
Die vielen Farben brauche ich, um die Texturen schön hinzubekommen. Das wird sicherlich nochmal extrem schwer....
Immerhin habe ich jetzt aber die Ray-Cast-Engine so weit, daß sie wirklich sehr gut funktioniert!!
Am Ende wird es noch jede Menge Feintuning geben - aber Rom ist ja auch nicht an einem Tag erbaut worden und außerdem sind wir Weltmeister
LG

[Dr. Irata]

... man kann sich jetzt komplett frei durch die Matrix bewegen, nach links und nach rechts drehen, dabei nach vorne und auch nach hinten laufen. Wenn man vo einer Wand steht, dann bleibt man stehen und läuft nicht durch. Ich habe die Farben angepasst - jetzt schalte ich per DLI zwischen GTIA 9 und 11 und kann somit 256 Farben darstellen.
Das will ich für Schattierungen der Wände nutzen.
Als nächstes baue ich noch den Wandplot um - ich werde alle Daten für die FoV-Matrixauslesung sammeln und speichern, danach wird der komplette Bildschirm an einem Stück gezeichnet. Das wird die Bewegung stabiler machen.
Danach geht es an die Texturen. Da habe ich bereits einige Ideen...

Anbei der letzte Stand des Raycasters:

Bildschirmaufnahme 2023-09-12 um 20.30.43.mov

(8.18 MiB) 123-mal heruntergeladen

[Erhard]

Hi,

hab mir das Video gerade einmal angeschaut. Die hellen und dunklen Streifen von oben bis unten über den Bildschirm - sind die beabsichtigt?

Die Bewegung im Labyrinth sieht ja ziemlich gut aus. Allerdings scheinen beim Vorwärtsgehen manchmal einzelne Säulen neben einer Wand aufzutauchen?

CU, Erhard

[Dr. Irata]

... also die Streifen entstehen, wenn man 256 Farben haben will und quasi ständig zwischen 2 Grafikmodi schaltet. Die verschiedenen Farben entstehen dann quasi durch eine Art Teilfusion (Artifacting) der Scanzeilen. Das ist also erstmal so gewollt.
Vielleicht baue ich das auch wieder um, wenn es zu sehr stört und ich die ganzen Farben so nicht brauche.
Hier mal ein Bild von Projekt M (kann man auch bei youtube anschauen), wo die das ähnlich machen:

Die Wand wird manchmal noch nicht ganz korrekt erkannt und in diesem Fall wohl etwas zu groß gezeichnet, daher denkt man sie steht raus.... da muss ich noch einiges an Fehlern abfangen! Das Thema ist und bleibt tricky.....

[Dr. Irata]

Heute habe ich mir mal erste tiefere Gedanken über die Wandtextur gemacht und auf dem Sofa einige Ideen gesammelt....

Ich werde es so machen:
Ich möchte zunächst ähnlich wie bei Wolfenstein eine Steinwand/Felswand bauen. Die Farben (grau) mit verschiedenen Schattierungen habe ich ja durch das Mischen von GTIA 9+11... nun ist die Frage, wie man die Wände perspektivisch zeichnet und je nach Abstand die gleiche Wand größer und kleiner wird.
Ich werde ca. 15-20 verschiedene Wandstreifen erstellen, die zusammengesetzt nebeneinander ein Steinmuster ergeben. Jeder Wandstreifen hat eine gewisse Basishöhe und hat ein Muster, welches quasi aus einzelnen horizontalen Linien besteht. Je nach Entfernung zur Wand besteht dann ein Wandstreifen aus diesen Linien, die dann aber nicht einmal sondern mehrmals gezeichnet werden - so wird dieser Wandstreifen dann entsprechend höher oder weniger hoch, behält aber sein Muster.
Ich kalkuliere für jeden Wandstreifen ca. maximal 6-30 Bytes also im Mittel vielleicht ca. 20 Bytes - bei 20 Steifen sind das ca. 400 Bytes an Daten. Dazu kommt noch für jeden Streifen die verschiedene Größe je nach Entfernung - 400 * 40 = 16 kB also eine komplette Bank für die Wändtextur. Dazu kommen später noch Tore und weitere Items...
Aber erstmal die Wandtextur!!

[Irgendwer]

Du kannst einiges an Rechenzeit und Speicherplatz für die Texturen sparen, wenn Du nur die obere Hälfte des Bildes berechnest und die untere "einfach" über die Display-List spiegelst. Das funktioniert sogar mit einer Mauertextur, wenn sie richtig "angelegt" ist.
So weit ich mich erinnern kann verwendet "Capture the Flag" das gleiche Prinzip und schafft dadurch den 2-Spieler Simultan-Modus...