Ray Casting

[Mathy]

.
Hallo Leute

Hat schon jemand diesem Link auf AtariAge erwähnt?

Tschüß

Mathy

PS hab' ich mir nicht durchgelesen. Ob was brauchbares drin ist kann ich also nicht sagen.

[Dr. Irata]

Hallo Mathy,
ja der Link wurde erwähnt und ist mir bekannt. Es gibt viele interessante Informationen zum Ray Casting - auch gute Beispiele für den A8 mit echt tollen Umsetzungen, leider kocht da jeder so seine eigene Suppe und läßt wenig Infos raus, wie man das am besten speziell für den A8 macht.

Gerade jetzt stoße ich auf das nächste Problem und finde da so gut wie keine Informationen zum A8: Die Texturen!

Mittlerweile verstehe ich ganz gut, wie das funktionieren kann und wie es andere für den A8 gemacht haben. Es gibt aber noch ein paar Probleme. Hauptproblem ist wohl, daß angrenzende Sichtstrahlen ein Wandteil mehrfach treffen können und dieser dann entsprechend mehrfach gezeichnet wird. Für eine einfarbige Wand kein Problem - das tritt ja auch nur bei nahen Wänden auf und entsprechend der Nähe wird die Wand höher und breiter gezeichnet, allerdings würde das bei einer Textur blöd aussehen. Ich muss also genau wissen welcher Sichtstrahl die Wand nochmal trifft und dann entsprechend eine andere Textur nehmen. Im Grunde ist es so: Wenn die Wand nah ist, dann sieht ein Sichtstrahl nur einen kleinen Teil dieser Wand und stellt diesen dann dar. Der nächste Sichtstrahl trifft aber in der 2D-Matrix genau die gleiche Wand (hier vielleicht mit einer 1 gecodet) muss sie aber ganz anders darstellen von der Textur her... das muss ich jetzt ausarbeiten!

Vielleicht gibt es da auch ganz andere viel bessere und einfachere Lösungen - wenn ja, dann her damit

Das Thema läßt mich gerade nicht los ist aber höchst komplex. Die tollen Vorbilder zeigen aber, daß es mit dem A8 geht und also mache ich weiter. Ich werde für mich jetzt aber etwas den Druck rausnehmen und das ganz entspannt weiterentwickeln bis es gut und schön ist - incl. Texturen...
Das Projekt will ich dann zunächst so weiterentwickeln, das man es als 3D-Engine verwenden kann. Den Code möchte ich final optimieren und dann für alle freigeben...

[Dr. Irata]

... mein größtes Problem ist im Moment eigentlich, daß ich nicht genau weiß, wie ich am besten eine Textur zeichnen kann - also mit welchem Programm, wo ich dann die entsprechenden Bitcodes für den Atari bekomme... am besten noch alles auch vergrößern oder verkleinern als Option!

[Dr. Irata]

... gerade beim Kaffee ist mir etwas cooles aufgefallen:

Da habe ich ewig mit den Problemen rumgemacht: Wie bestimme ich d - also den Abstand vom Auge zum Treffer in der 2D Matrix und wie korrigiere ich den Effekt der Distorsion - als diesen Fish Eye Effekt. In den Tutorials wird das mit cos tan usw gemacht. Ich habe d zunächst über eine Näherung von Pythagoras berechnet - also statt d = Wurzel aus dx*dx+dy*dy habe ich ja folgendes genommen: d = dy - dx/2 wenn dx <dy oder d = dx - dy/2 wenn dx>dy. Das klappt ganz gut und läßt sich schnell berechnen. Dann kommt je nach Winkel des jeweiligen Sichtstrahls noch die Korrektur der Distorsion: d(korrekt) = cos alpha * d. Dann hat man die korrekte Entfernung. Die Korrektur habe ich via Tabelle gemacht.
So weit so gut.....
Jetzt habe ich herausgefunden: Das brauche ich alles gar nicht!!! d = dx (für den Fall dx>dy) oder d = dy (für den Fall dx<dy) thats it !!!!!! Nix berechnen, nix nähern!
Ich hatte schon die ganze Zeit das Gefühl, daß ich hier zwei Schritte mache, die sich irgendwie am Ende aufheben. Und genau so ist es.

[Kveldulfur]

Moin!

Ich wache hin und wieder Nachts auf, weil mir (im Traum?) eine Lösung für ein Programmierprobleme eingefallen ist.
Aber eine mathematische Gleichung war da noch nicht drunter. Schade, dass ich kein Kaffee trinke, was dass auslösen könnte...

Bin gespannt auf Deine fertige Engine.

Grüße
Janko

[Dr. Irata]

Im Moment hänge ich fest und manchmal hilft es weiter, sich mit anderen auszutauschen!
Die Texturen machen mir Schwierigkeiten...

Das Problem ist folgendes:
Im Moment berechne ich ja den Abstand d vom Standort des Betrachters in der Matrix zum Wandteil was vom jeweiligen Sichtstrahl getroffen wird.
Je nach Abstand zum Wandtreffer wird das Objekt höher gezeichnet (naher Treffer) oder weniger hoch (entfernter Treffer). Nun müsste das Objekt auch in der Breite wachsen oder schrumpfen - je nach Entfernung.
Dazu kommt jetzt, daß gerade nahe Objekte von den Sichtstrahlen teil mehrfach getroffen werden - beim Abstand 1 (also ganz nah) bis zu 9 mal. Hier zeichnet er also dann quasi 9 x das gleiche Wandobjekt in entsprechender Höhe. Für diese "Nähe" brauche ich also quasi für das gleiche Trefferobjekt 9 verschiedene Wandteile, die dann nebeneinander gezeichnet werden und die dann eine spezielle Textur (z.B. Steinmuster) ergeben. Gehe ich von der Wand zurück, dann wird das gleiche Wandstück vielleicht nur noch 7 x getroffen und entsprechend muss die gleiche Textur dann halt kleiner mit 7 verschiedenen Wandteilen gezeichnet werden. Diese Wand würde dann ähnlich aussehen nur halt etwas kleiner, was ja auch gewollt ist. Jedes Wandteil ist dann vom Aufbau auch noch abhängig von der Trefferdistanz und entsprechend unterschiedlich. Abgesehen von der erheblichen Speichermenge, muss man diese Wandteile auch erstmal erstellen und in Tabellen vorhalten... und dann richtig ansteuern!
Dazu müsste ich auch in der Matrix die jeweilig getroffene Zelle markieren, so daß ich erkenne, ob sie gerade schon getroffen wurde oder nicht. Wenn die gleiche Zelle getroffen wird, dann wird z.B. der 2. Teil der Textur dieser Wand genommen - vorher müsste ich aber auch genau wissen, wie oft denn diese Zelle am Ende wirklich getroffen wird, damit ich entscheiden kann, ob ich von diesem Wandteil den 9 er Block nehme oder z.B. den 7 er .... andererseits müsste schon die errechnete Entfernung d genau das definieren..... alles auf jeden Fall mega aufwendig und ich überlege, ob es nicht viel einfacher ginge... irgendein Kniff. Dass es gut geht, beweisen die Beispiele die schon programmiert worden sind.

Und manchmal nutzt eine gute Näherung viel mehr und funktioniert genauso gut.

Bei der ganzen Überlegung ist mir dann dazu auch noch aufgefaallen, daß meine schöne einfache Theorie mit d und Vermeidung der Distorsion falsch ist.
Leider.... wäre auch zu schön gewesen!!
d = xneu funktioniert nicht, wenn man sich dreht im Achsensystem der Matrix - man muss tatsächlich über den Pythagoras dx bestimmen und dann via cos alpha die Distorsion rausrechnen: dx = xneu + yneu/2. (wenn yneu < xneu)..... die Näherung für Pythagoras. Dann d = dx * cos alpha
Man kann es auch anders machen: beta ist der Winkel des zentralen Sichtstrahls im Koordinatensystem der Matrix und also bekannt: d = xneu * cos alpha / cos (alpha+beta)
Der Witz an der Sache ist allerdings: Mein eigentlich falscher sehr einfacher Ansatz für d funktioniert..... ich habe das gerade nochmal getestet und sicherlich sind die Abstände am Ende nicht so ganz richtig, es fällt aber gar nicht auf. Also lasse ich es erstmal und beschäftige mich weiter mit dem Problem der Texturen... vielleicht fällt mir das dann auf die Füße, wenn ich die Texturen erfolgreich umsetze. Vielleicht kann es aber auch so bleiben!

Und genau das ist es mit den Texturen... es muss doch viel einfacher gehen. Irgendwo ist sicherlich ein guter Kniff versteckt, wie ich die Texturen viel einfacher auf die Wände bekomme, als ober angedacht......

Euch einen schönen Sonntag und beste Grüße aus dem sonnigen Hamm!
Peter

[pps]

Hmm, vielleicht kann man ja zählen, wie oft ein Teil vom Strahl getroffen wird und dann eine entsprechende Textur zeichnen.

[Dr. Irata]

... so ähnlich war mein Plan. Das Problem ist dann aber noch die schräge Wand. Diese Textur müsste sich dann auch noch in Abhängigkeit der jeweiligen Entfernung ändern... oder ist da mein Denkfehler??

[Dr. Irata]

Frohe Deutsche Einheit wünsche ich uns allen!

In den letzten Tagen war ich nicht untätig und habe sehr viel geknobelt, gerechnet, gezeichnet und immer wieder alles in meinen Gedanken hin und her überlegt...
In der Summe muss man wohl sagen: Es scheint fast vermessen, einen feinen 3D Shooter mit Raycasting-Technik und Textur für sen A8 hinzubekommen... allerdings gibt es einige Beispiele, die zeigen, daß es eingeschränkt funktionieren kann - das motiviert mich letztlich seit einem halben Jahr und ich habe da ja auch schon ganz gute Fortschritte erzielen können!
Die Texturen bringen mich aber echt an Grenzen....
Es scheint fast zu komplex die ganzen Probleme hier so darzustellen, daß man es nachvollziehen kann.

Mein Problem ist der Mehrfachtreffer einer Matrixzelle in Abhängigkeit des Winkels des jeweiligen Sichtstrahls und der Entfernung zum Betrachter. Ein wirklich klares Muster habe ich da nicht finden können und wahrscheinlich gibt es das auch gar nicht... die vielen verschiedenen Treffermuster jedenfalls überschreiten die Kapazität des A8. Da muss ich andere Lösungen finden.

Meine Ausleseroutine ist ok und kann so bleiben - ich werde allerdings noch einen Zähler einbauen, um die Trefferanzahl des jeweiligen Sichtstrahls pro Zelle abzuspeichern. Klingt einfach, ist es aber nicht. Jede Zelle, die getroffen wird muss markiert werden und bei einem weiteren Treffer zählt man die Anzahl - trifft der nächste Sichtstrahl eine andere Zelle, muss die alte Zelle rückgespeichert werden, damit man die Matrix nicht verändert. Das muss ich jetzt als nächsten Schritt umsetzen.

Die anschließende Printroutine - also die optische Ausgabe der 2-D-Matrix als 3-D-Raum auf den Bildschirm muss komplett neu gemacht werden.
Im Moment arbeite ich das FieldOfView quasi von links nach rechts ab und zeichne die Mauern mit entsprechender Höhe (je nach Trefferdistanz d) auf den Bildschirm. Diese Methode geht mit der Textur nicht!
Ich muss von der Mitte anfangen - also vom Zentralsichtstrahl, von hier zeichne ich erst das FoV nach links - je nach Anzahl der Treffer nehme ich. dann die entsprechende Mauer. Wenn z.B. der Zentralstrahl auf ein Feld 7 x trifft (bedeutet auch die Wand ist nah und wird groß), dann suche ich die Mauer mit 7 Einheiten und zeichne sie. Wenn das Feld daneben z.B. 5x getroffen wird, ist die Höhe der Mauer zwar gleich, die Breite aber nicht, hier nehme ich ein Mauerteil mit entsprechend 5 Teilen... usw.
Sobald das FoV links vom Zentrahlstrahl gezeichnet worden ist, muss der Bereich rechts vom Zentrahhlstrahl abgearbeitet werden.
Mehr als 9x wird eine Zelle nicht getroffen - jedes Wandteil einer bestimmten Wandart hat also 9 verschiedene Ausprägungen... so könnte es funktionieren.

LG
Peter

[Mathy]

.
Hallo Leute

Erhards Frage zu Dr. Iratas Artikel in Magazin #155 und die Reaktionen darauf findet ihr jetzt hier in einem neuen Thread.

Tschüß

Mathy

[Dr. Irata]

Guten Morgen in die Runde,
seit ein paar Tagen arbeite ich wieder am Raycaster und habe mich erstmal wieder in das Thema eingearbeitet.
Kompliziert...

Ich muss die Perspektive noch genauer ausrechnen und brauche dazu zwingend Cosinus - das werde ich mit Tabellen machen-
Den Treffpunkt ermittel ich ja mit Bresenham. Der Bresenham macht ja einen Strahl, den ich nicht zeichne, sondern wo ich ständig auslese.
Die Länge des Strahls ist dann die Perspektive D, die ich brauche um die Höhe der Mauern zu bestimmen. Diese Perspektive ist aber falsch und muss noch mit cos Winkel des Sichtstrahls etwas reduziert werden.

Jetzt die Frage: Die Länge des Strahls vom Bresenham bestimme ich derzeit über die jeweiligen xEnd-xStart / YEnd-yStart - und davon dann eigentlich mit Pythagoras die Länge bilden... hier nehme ich aber vereinfacht P= dx +dy/2 wenn dy<dx
Das muss doch aber einfacher gehen.... kann ich nicht direkt aus dem Bresenham-Algorithmus die Länge bestimmen?? Hat da jemand eine Idee??

[Dr. Irata]

Ich habe jetzt nochmal alles ganz anders durchgerechnet und werde mal eine Lösung ohne Pythagoras aber mit Cosinus implementieren.
Die Formel dazu habe ich hergeleitet und sieht dann so aus:

IMG_8216.jpg (423.64 KiB) 6410 mal betrachtet

Dabei ist alpha der Winkel des Betrachters in der Matrix zu der Matrix und ändert sich entsprechend mit der Drehung des Betrachters.
Beta ist der jeweilige Winkel des FieldofView also des jeweiligen Sichtstrahls, der über Bresenham durch die Matrix wandert, bis er auf eine Hindernis trifft.
dx ist der Differenzwert - also wieviel in x-Richtung geht der jeweilige Sichtstrahl bis zum Auftreffpunkt.

Um nun die schon korrigierte Distanz (P) zu bestimmen - die dann letztlich für die Höhe der Wand gebraucht wird - brauche ich also nur dx und die beiden Winkel.
Die Cosinus Berechnungen muss ich also 2x hintereinander durchführen mit dx * cos(beta) - das wird in einer großen Tabelle bestimmt, der entsprechende Wert muss dann nochmal mit 1/cos(90+beta-alpha) mit einer 2. Tabelle bestimmt.

Das gilt es nun umzusetzen...

[Kveldulfur]

Moin!

Ich muss zugeben, dass das für mich zu hoch ist... und kleinlaut muss ich zugeben, dass ich gelernter Vermessungstechniker bin
Aber das sieht eher nach etwas für einen Vermessungsingenieur aus

Grüße
Janko

[Dr. Irata]

.. ach Quatsch Janko, das ist nur Mathe!

Übrigens - die 90 Grad in der Formel kann man noch rausnehmen:

cos (90+beta-alpha) ist nichts anders als sin (beta-alpha)

[Dr. Irata]

tatsächlich gibt es noch kleinere Stolperfallen:

Die Formel ist so richtig für den oberen Teil des Zentralsichtstrahles, für den unteren Teil ist es ein wenig anders:
Da lautet die Formel:

P = dx * cos beta / sin (beta + alpha) -> für unterhalb des Zentralsichtstrahles
P = dx * cos beta / sin (beta - alpha) -> für oberhalb des Zentralsichtstrahles - dabei muss man den Betrag von beta - alpha nehmen

Klingt jetzt zunächst kompliziert und rechenaufwendig, bzw. in Assembler unmöglich - aber für die superschnelle Berechnung nehme ich natürlich Tabellen.
Dabei werde ich für den Raycaster ein FoV von ca. 45 Grad haben, also 22,5 Grad über dem Zentralsichtstrahl und 22,5 Grad darunter.
Da ich den einzelnen Sichtstrahl jeweils um 2,5 Grad weiterlaufen lasse, brauche ich also 9 verschiedene Winkelberechnungen in der Tabelle.
Die möglichen dx Werte kommen ja vom Bresenham und der maximale dx-Wert ist die halbe Breite der Matrix - in meinem Fall vielleicht maximal 25-30.
Die 1. Tabelle berechnet also direkt dx * cos beta - bei 9 Winkeln und 30 dx Werten habe ich also ca. 300 Bytes.
Die 2. Tabelle wird dann entsprechend den neuen Wert mit mit dem Sinus (beta-alpha) oder Sinus (beta+alpha) ausgeben. Diese Tabelle wird etwas größer sein.

Also folgender Ablauf:
Aufbau des FoV:

Der Sichtwinkel im System ist mit alpha bekannt (und ändert sich je nach Drehung des Spielers).
Beta von 0 -22,5 Grad nach oben und dann nach unten gibt den Winkel für beta an und läßt den Bresenham in der Matrix laufen.
Bei einem Treffer in der Matrix (man fragt ständig ab) wird der dx Wert bestimmt, dann in Tabelle1 dx *cos beta abgefragt, dann in Tabelle2 den aktuellen Wert aus Tabelle1 mit 1/sin(beta-alpha) oder 1/sin (beta+alpha) bestimmen und schon hat man den Wert für die Perspektive P.
Die wird gespeichert und nach Durchlauf des gesamten FoV wird dann der Bildschirm gezeichnet.
Die Perspektive P bestimmt dann (auch wieder aus einer Tabelle) mit 1/P die Höhe des getroffenen Mauerteils.

Hört sich zunächst alles ganz einfach an, die ganze Umsetzung mit dem Bresenham, der Tabellen, der ganzen Drehung usw. ist schon recht komplex...

[Dr. Irata]

... ich hoffe, ich nerve niemanden mit diesem Post um den Raycaster... das Thema ist schon komplex für den A8 ...

Also bei der Umsetzung der 2. Tabelle mit dem 1/sin (beta+alpha) bzw. 1/sin (beta-alpha) bin ich schon auf gewisse "SWchwierigkeiten" gestossen. Ich muss ja hier den Winkel alpha berücksichtigen und jedesmal die Summe bzw. Differenz berechnen... außerdem wird die Tabelle recht mächtig und verbraucht fast 2kB an Speicher. Mit Optimierung (was aber wieder Rechenzeit kostet) komme ich vielleicht auf 1,5 kB.
Daher habe ich mich nun doch für einen anderen Weg entschlossen und gehe auf die Berechnung von D (also die Distanz des Bresenham bis zum Hindernis) mittels Pythagoras zurück. Im Prinzip mache ich das auch schon so, habe dafür aber nur eine Näherung: D= dx + dy/2 wenn dx > dy oder D = dy + dx/2 wenn dy > dx. Diese Näherung klappt recht gut und ist schnell, ist aber teilweise recht ungenau.

Ich mache das nun mit einer Tabelle. Da ich ja bereits dx und dy habe, lese ich einfach nur aus einer großen Tabelle den zugehörigen Wert nach Pythagoras je nach dx und dy aus. Diesen ausgelesenen Wert nehme ich für die Cosinus Tabelle und lese den Wert P aus.
Die Pythagorastabelle hat dabei einen Umfang von 1-40 für jeweils dx und y also 40 x 40 = 1600 Bytes. Die erste Tabelle musste ich etwas erweitern, da wir nun Werte bis knapp 60 bekommen können in einer Matrix 40 x 40 und verbraucht somit knapp 400 Bytes.
Der ganze Prozess kostet mich also etwas 2 kB. Das ist auf jeden Fall vertretbar. Dafür ist die Bestimmung von P exakt und schnell...

[andymanone]

... ich hoffe, ich nerve niemanden mit diesem Post um den Raycaster... das Thema ist schon komplex für den A8 ...

Nein! Ganz im Gegenteil! Das ist super spannend!
Ich lese auch, aber stecke in der Materie nicht drin, darum kann ich leider auch nicht viel (Nützliches) dazu beitragen .

Gtx.,
andY

[Dr. Irata]

... lieben Dank ... nach meiner langen Pause an dem Projekt, brauchte ich auch zunächst etwas Zeit, alles wieder zu durchdringen. Jetzt habe ich wieder alle Gedanken klar

ich möchte mir auch damit etwas Zeit lassen und das ganz ohne Druck weiterentwickeln. An Ende wird man sehen, was dabei rauskommt - gute Beispiele gibt es ja (Capture the flag)- also gehen tut es. Ob ich die Texturen schön hinbekomme, wird man sehen - wenn nicht, dann werden die Wände halt relativ glatt.
Sobald der Raycaster mit der neuen Logik gut läuft, werde ich das Projekt umziehen und dann dort weiterberichten. Ich weiß nun mittlerweile auch schon in welche Richtung es gehen soll: Shamus 3D

Ob da jemals etwas spielbares rauskommt wird man dann sehen... vielleicht ja, vielleicht nein

[Mathy]

.
Hallo Peter

Mach ruhig weiter. Auch wenn man nicht alles kapiert, interessant ist es trotzdem. Du schneidest hier ein Thema an, das nicht alle Tage vorbei kommt. Dafür kann man nur Bewunderung haben.

Tschüß

Mathy

[Dr. Irata]

Das Sommerloch, Urlaub, viel Arbeit lassen die Dinge beim Raycaster etwas schleifen.
Das Thema ist auch echt komplex - was in Gottes Namen hat mich bloß dazu getrieben dieses Projekt zu versuchen .....

Nebenbei arbeite ich mich ja auf Unity ein. Dies ist ein hochkomplexes Programm - eine 3D Engine - um 3D-Programme später entwickeln zu können.
Das schluckt natürlich viel Zeit, aber keine Angst, ich bleibe natürlich dem A8 treu.

Was ich schon echt krass finde ist dieser Unterschied zwischen Raycaster A8 und 3D-Engine auf einem modernen PC. Über 40 Jahre Entwicklungszeit liegen dazwischen.
Was mit dem A8 fast unmöglich erscheint und nur mit vielen Tricks und viel viel Gehirnschmalz und Entwicklungszeit vielleicht mit schwacher Grafikqualität geht, das braucht auf Unity vielleicht maximal 20 Minuten, um eine komplette Landschaft mit Texturen zu erstellen, mit Licht und Schatten und mit einem First- oder Third-Kontroller, den man dann sofort durch die Landschaft steuern kann... es ist schon beeindruckend, wie sich das in einer halben Generation entwickelt hat. Werde hier mal vergleichende Bilder posten.

Zu meinem Raycaster:
Ich hatte mich jetzt viel mit der geeigneten Grafikstufe beschäftigt, da nichts wirklich optimal ist.
Entweder Farben oder Auflösung. Einen Tod muss man sterben.
GTIA 10 ist natürlich recht schön mit 9 Farben und hat Scanlinemodus 1 - also in y-Achse hübsch fein aufgelöst, in x-Achse ist es mir aber zu grob. Da haben wir immer 4 Pixel zusammen.
Antic D finde ich von der Auflösung besser, da haben wir Scanline 2 - also in x- und y- Achse gleich gut aufgelöst, dafür aber nur 4 (eigentlich nur 3) Farben.
Ich glaube dies wurde auch bei Capture The Flag genommen.
Capture The Flag ist gut gemacht! Die Wände sind grau und mit schwarz abgesetzt (das ist schlau). Dann hat man noch 2 Farben übrig, eine Farbe für den Boden bzw. Himmel (diese werden dann über DLI´s noch verändert - so daß der mehrfarbige stimmungsvolle Eindruck entsteht), bleibt sogar noch eine Farbe übrig für Items oder andere Wände.
Auf eine komplizierte Texture wird verzichtet, das ist auch gut so, dann damit spart man Zeit, Aufwand und optisch ist alles viel besser erkennbar.

So ähnlich versuche ich das nun auch.
Thema Texturen: Das ist echt schwierig... ich weiß nicht wirklich, wie man das bei Projekt M gemacht hat. Wird das on the fly berechnet? Oder liegen da viele Tabellen für die verschiedenen Wände in Drehung und Perspektive dahinter?
Mit Tabellen würde ich es machen. Ich habe das mal durchgerechnet - Stand jetzt würde das ca. 70kb an Speicher kosten. Geht also rein theoretisch.... ich denke mal, daß die neueren Programme (Doom zB.) das ähnlich lösen, aber da noch etliche gute Optimierungen umgesetzt wurden.
70 kB finde ich jetzt auch deutlich zu viel, da muss ich mir noch gute Tricks bzw. Optimierungen einfallen lassen.

Der Ablauf wird jetzt aber zunächst so sein: Ich werde versuchen die Printroutine komplett neu zu gestalten und den Raycaster ähnlich wie Capture The Flag aussehen zu lassen. Das sieht nämlich optisch sehr schön aus. Sollte ich das zum laufen bringen, versuche ich noch Texturen reinzubringen. Die neue Printroutine werde ich so aufbauen, daß später die Texturen einfacher einzufügen sind. Ich baue also auch jetzt schon ganz Wände bei einem Treffer in Abhängigkeit von Distanz und Winkel.

Dieses Projekt wird sich sicherlich noch über 1-3 Jahre ziehen, denke ich.

Warum wurde Projekt M nie zu einem fertigen Spiel weiterentwickelt und warum zog sich das Projekt M über 10-12 Jahre hin? Weil es so komplex ist.
Vielleicht wurden hier auch Videos etwas gefaket... mit Grafik- oder Speichererweiterungen gearbeitet... wer weiß...

Grüße
Peter

[Irgendwer]

Vielleicht wurden hier auch Videos etwas gefaket... mit Grafik- oder Speichererweiterungen gearbeitet... wer weiß...

Diesen Satz verstehe ich nicht. Du kannst Dir doch das Executable herunterladen und selbst probieren...?

[Dr. Irata]

Das Projekt nähert sich jetzt einem vorläufigen Ende!

Ich baue noch ein wenig an der Routine zum Printen auf den Bildschirm, so daß es etwas bessere Dimensionen hat und besser aussieht und dann ist erstmal gut.

Fazit wird für mich sein: Der A8 ist nicht geschaffen für ein wirklich gutes 3D Spiel wie Doom oder ähnliches. Mit viel Aufwand und intelligenter Programmierung geht es doch (siehe WayOut), es wird aber immer reduziert sein - spätestens bei den Texturen muss man extreme Abstriche machen (Doom für den A8 finde ich nicht spielbar).
Einzige wirklich beeindruckende Entwicklung ist m.E. Projekt M bzw. X - warum dieses Projekt sich über fast 15 Jahre hingezogen hat und nie ein richtiges Spiel daraus resultiert ist und nun komplett eingestellt wurde liegt auf der Hand: Die Hardwarekapazitäten wurden wohl alleine für die Demo komplett ausgenutzt, für ein echtes Spiel reicht es dann wohl nicht mehr...

Ich selber bin dann jetzt zufrieden, da ich es hinbekommen habe. Es zu perfektionieren (wie Projekt M) würde mich wohl die nächsten Jahre beschäftigen und mein Kapazitäten komplett binden...

Relativ zeitnah werde ich stattdessen mein nächstes Programm für den Softwarecontest 2025 starten - diesmal wird es ein Jump´nRun werden...

[Dr. Irata]

Nach langer Pause überlege ich das Projekt im Herbst - vielleicht zur Fujiama - zu reaktivieren.
Einge wichtige Dinge habe ich ja schon umsetzen können, das Projekt bedarf aber einige Anpassungen und kann gerne auch eine längerfristige "Sache" werden... ich habe ja Zeit!!

Ein wichtiger Bestandteil ist ja der Sichtstrahl, den ich mittels Bresenham-Lookup-Tabellen umgesetzt habe. Das war schon eine gute Idee, da es sehr schnell ist. Das Problem war dann immer die Länge des Strahls vom Betrachter zum Aufprall an ein Hindernis zu berechnen. Die einfache Näherung ist schnell und gut, aber durchaus in bestimmten Bereichen recht fehlerhaft. Daher der Versuch der besseren immer noch schnellen fehlerkorrigierten Näherung.
Allerdings hatte ich immer das Gefühl, wenn man schon nach dem Bresenham-Algorithmus den Sichtstrahl entlang geht, dann müsste man doch eigentlich quasi als Abfallprodukt auch die Länge des Strahls bekommen. Das geht aber nicht! Selbst ChatGPT hat das erkannt... aber.. da kam mir dann doch die Idee:
Bresenham zählt die Steps in x-Richtung und in y-Richtung. Ab und an braucht es dann halt auch einen Step sowohl in x- und y-Richtung.
Wenn man jetzt mal die Winkel betrachtet zum Playfield, dann geht der Bresenhamstrahl bei 45 Grad die ganze Zeit in unserer Pixellandschaft schräg. Und die Länge dafür ist √ 2 - warum? Das Pixel ist ein kleines Quadrat mit Seitenlänge 1.
Daraus folgt: c^2=1^2+1^2 also c^2=2 und c=√2
Wenn jetzt Bresenham z.B. bis zum Auftreffen auf ein Hindernis (bei 45 Grad) 11x schräg weiterläuft, dann ergibt sich daraus die Länge von
L=11 x √2 = 15,6
Bei einem steileren Winkel geht der Strahl vielleicht 3x in x-Richtung und 5x in schräg-Richtung. Die Länge ergibt sich dann wie folgt:
L= 3 x 1 + 5 x √2 = 10,1
Bei einem flachen Winkel könnte der Strahl z.B. 8 x in y Richtung laufen und 4 x schräg. Die Länge wäre dann:
L= 8 x 1 + 4 x √2 = 13,7
Weil wir immer mit 1 multiplizieren müssen, fällt die Multiplikation einfach weg. Wir müssen also während des Bresenham-Strahls einfach nur geschickt und schnell mitzählen, wie oft sowohl in x- als auch in y-Richtung gelaufen wird (also schräg) und wie oft nur in eine Richtung x oder y. Die Anzahl der Einzelbewegungen werden dann addiert, die Anzahl der Schrägschritte mittels Lookup-Tabelle als Produkt mit √2 dann ebenfalls addiert und schon hat man die so wichtige Länge des Sichtstrahls bis zum Auftreffen auf ein Hindernis (Wand).
Keine weiteren Berechnungen mit Pythagoras sind nötig....