Anaglyphen-Systeme gibt es X verschiedene, und die sind gar nicht mal teuer.
Da ist bestimmt eine bei, mit der sich ein schönes 3er-Combo aus 2 Farb-Päärchen finden lässt, die sich jeweils auf einem Auge ähnlich sehen.
Und wenn das nicht reicht kann man auch noch Filter kombinieren.
Rot-Cyan scheint aktuell das gebräuchlichste System zu sein, die Sorte gibt es auch im Ramschladen Pearl.
2 64er an 2 Beamern mit 2 Polfiltern fallen mir grad mal ein. Das braucht aber auch noch eine spezielle Leinwand.
Das wird nicht billig, und es wird sehr wenig Anwender geben.
Ich hab in meiner Fototasche ein Probeset von "Lee Filters" gefunden, sicher 100 kleine Farbfilter-Folien incl. Transmissionsspektrum.
Ich hab noch nicht nach üblichen Farbbrillen gesucht. Wenn es mit denen schlecht geht, gäbe es jedenfalls noch mehr Farben zum Testen.
Und noch ein Gedanke:
Weltkarten sahen durch RG-Brillen phantastisch metallisch aus.
An Stelle von 3D-Grafik könnte man mit den Farbbrillen auch Grafiken mit Metallic-Effekt probieren.
Ein Freund und ich haben damals(tm) mal versucht, einfache Stereo-Liniengrafiken für 3D-Brillen zu erstellen, aber mit der VIC-Palette meines 128ers war da rein gar nichts zu machen. Auf dem CPC des besagten Freundes haben wir dann aber passende Farben gefunden.
Lief das am Ende auf möglichst reines R/G/B hinaus? Dann wird das mit einem Speccy bestimmt auch gut funktioniert haben.
Erinnerst Du Dich noch, ob Ihr auch den umgekehrten Weg versucht habt, also nach Farben zu suchen, die in einem Filter möglichst gleich aussehen? Wegen dem hier:
Da es nicht ganz sauber werden wird: Man wird bestimmt auch Farben zum Kaschieren finden. Grün wird durch den Rotfilter sichtbar sein. Da findet sich bestimmt eine Farbe, die durch den Rotfilter wie Grün aussieht, im Grünfilter aber vom echten Grün möglichst weit weg ist.
=> Vielleicht ist es sogar andersrum besser, gar nicht erst nach möglichst unterschiedlichen Farben für den Rotfilter zu suchen, sondern nach möglichst gleichen, um die dann für Grün zu verwenden?
...mit entsprechender Plastikfolie...
Das ist der spannende Teil daran, das sollte möglichst nice zum Monitor passen und möglichst reinfarbig sein.
Woher bekommt man das?
Ich muss mal in meine Fototasche gucken, vielleicht finde ich da was.
Einiges ließe sich vielleicht über die Einstellungen am Fernseher erreichen, Kontrast runterdrehen oder so?
Im Vice sieht es ganz gut aus, Sättigung auf 2 und Kontrast auf 0,5 zu stellen.
Was imho bei der Such nach 2-4 passenden Farben möglich wäre:
Die Farben der Brille sollten gut zu R,G,B des Monitors passen.
Gibt es Farbbrillen überhaupt noch, und wenn ja, sind die Rot-Blau oder Rot-Grün (oder noch was anderes)?
Auch CMY käme in Frage.
Passen die dann gut zu LCD oder zu alten Röhren?
Auch bei der Suche nach passenden Farben zur Darstellung kommen CMY in Frage.
Da es nicht ganz sauber werden wird: Man wird bestimmt auch Farben zum Kaschieren finden. Grün wird durch den Rotfilter sichtbar sein. Da findet sich bestimmt eine Farbe, die durch den Rotfilter wie Grün aussieht, im Grünfilter aber vom echten Grün möglichst weit weg ist.
=> Vielleicht ist es sogar andersrum besser, gar nicht erst nach möglichst unterschiedlichen Farben für den Rotfilter zu suchen, sondern nach möglichst gleichen, um die dann für Grün zu verwenden?
Mit J=32-(pE(56320)and31) müsste man auch den Fall ohne Bewegung erschlagen können.
Noch ein kleiner Aspekt:
Verschiedene Richtungen sind im Original verschieden schnell. Von den 4 Richtungen ist Rechts am schnellsten, unten am langsamsten.
Und von allen 8 Richtungen ist Unten-Rechts am langsamsten.
Endurions Variante dürfte am gleichmäßigsten laufen.
Das Begrenzen (sx=sx-(sx<36)+(sx>327):sy=sy-(sy<56)+(sy>245)) dürfte falsch sein, weil in 8er-Schritten gezählt, aber hier nur in 1er-Schritten korrigiert wird.
Das AND ist tatsächlich langsamer als ein Vergleich + Addition auf eine Variable!
Kleiner Benchmark mit einer alternativen Joystick-Abfrage:
Endurions Variante in den Benchmark gepresst + eine Mischversion:
In der Regel musst Du nicht jeden der Zahlenwerte einzeln vergleichen. Unter Umständen ergibt sich auch nebenbei die Steuerung in Diagonalen, wenn Du mit AND prüfst.
Ob das WAIT das Ganze schneller oder langsamer macht muss man mal ausprobieren...
Und die Variable J zu nennen und früh im Programm benutzt zu haben (z.B. 1 DIM J) beschleunigt auch.
Nicht ganz genau das Gleiche, aber die passende Richtung:
Wenn Du noch einen draufsetzen willst, dann
Ich wollte mal gucken, ob auch Elemente mit Steigung 2 oder noch mehr in einen Zeichensatz passen würden.
Man kann ja auch mit den vorhandenen Elementen beliebig hoch bauen, man benötigt nur genügend Fläche. Wenn man die ISO-Tiles steiler macht, gibt es hinter den Bergen automatisch Verdeckungen.
Das würde wohl Verdeckung nötig machen, falls irgendwas dahinter entlang fliegen könnte. Aber braucht man das nicht eh für Bäume und Häuser? Und sind für diese Objekte nicht auch die Felder im Hintergrund nie einsehbar, so dass man da besser eh nicht reinfliegen sollte?
Falls einfach crashen lassen keine gute Lösung wäre, dann könnte man ja auch Pi mal Daumen auf eine Umriß-Darstellung wechseln, um den Flieger im Hintergrund darzustellen. Erst wenn das alles nichts taugt, dann würde ich über richtiges Verdecken nachdenken.
"Dran" ist übertrieben... Mein Kopfprogrammieren ist zur Zeit voll auf der Arbeit, und wenn ich wieder was C64-mäßig mache, dann hab ich noch ein paar andere Dinge auf der ToDo-Liste.
Ich wollte mal gucken, ob auch Elemente mit Steigung 2 oder noch mehr in einen Zeichensatz passen würden. Konkret angefasst habe ich da aber nix.
Dann ist aber ein File dieser Grösse nicht mal eben ein "kleiner Text" mehr. Da bieten sich Filestreams oder allenfalls BLOBs an.
Sind Usersettings, die im alten Registry-Format abgelegt sind. Wäre es ein neuerer SQL-Server könnte man ja einen Wechsel zu XML ins Auge fassen, aber eigentlich kommt so ein Aufwand nicht in Frage. 64KB-Textlimit ist sooo Windows95, es sollte seit 20 Jahren kein Problem sein, auch mehr zu erlauben.
Ich hatte noch nie den Bedarf um mich tiefer mit Datenbanken zu beschäftigen.
Ich habe sogar ein Buch über Datenbanken und VB.net, das steht aber auch
schon 20 Jahre ungelesen im Regal.
Kenn ich... man ist halt mit Arbeiten beschäftigt, und ruck-zuck ist ein Jahrzehnt vorbei.
Aber auch die MS Visual Studio Code Umgebung ist nicht zu verachten.
Ist ein Versuch wert. Ich hab mich inzwischen ganz gut mit vsCode angefreundet, vielleicht taugt das was.
Nein. SQL Server ist m.M. das beste Produkt, das sie führen.
Mit Datenbanken kenne ich mich nicht aus.
Vielleicht kannst Du Dir nebenbei MS Access oder OpenOffice Base ansehen und ein Gefühl dafür bekommen. Wenn Du in Excel schon Tabellen nachschlägst, dann ist der Unterschied nicht mehr sehr groß.
Der SQLManager zum SQLServer ist allerdings ein bisschen absurd. Je nachdem, ob man Tabellen zur Ansicht oder zum Bearbeiten öffnet, ist alles anders: Tastaturkürzel, Syntax-Highlighting, Auswahl der Datenbank, das Überarbeiten des SQL-Spruchs... Und mehr als 64K in Textfeldern gehen auch nicht zu bearbeiten.
Was hat die Aussage "häufig benutzte Strings" mit "sortierte Descriptoren" zu tun. Ich sehe da keine Verbindung (oder hab die Frage nicht verstanden).
Strings, deren Descriptor auf eine kleine Speicheradresse zeigt, sind auch zuletzt verwendet worden.
Wenn man daraus schließt , dass die damit auch am häufigsten verwendet werden (also ein MRU-Cache), dann wäre es nicht falsch, wenn die auch früh im Variablenspeicher zu finden wären.
Noch ein Gedanke:
Wenn ich mich richtig erinnere, dann sind die Variablen komplett unsortiert, einfach nach Reihenfolge, in der sie angelegt wurden.
Würde man vor der GC String-Variablen nach ihrem aktuellen Descriptor sortieren, wäre das eine gute Chance, dass das Basic-Programm anschließend schneller läuft, weil es häufig benutzte Strings schneller findet?
Ja, ich denke auch, dass Du Dir länger und tiefere Gedanken zum Thema gemacht hast 
Ich hab da meine Gedanken nur frisch rausgeblasen, das muss noch reifen.
Auf der einen Seite sehe ich 5 mal durchlaufen + 5 mal Anpassen der Descriptoren + 2 mal kopieren der Inhalte + recht simpler Code.
Auf der anderen sehe ich 2 mal kopieren + sortieren der Descriptoren + 1 mal kopieren der Inhalte + komplizierter Code + geht nicht bei zu vielen Strings.
Auf den ersten Blick würde ich den 2. Weg nicht weiter verfolgen.
"Ghost of a Tale" ist auch weitestgehend frei von Kämpfen und Zeitdruck und man steuert eine sehr putzige Maus durch eine Burg und so weiter mit recht schicker Grafik für ein Indie-Spiel.
Das war wirklich nett und abwechslungsreich 
Ja, die Ähnlichkeit mit Sortieren ist mir auch aufgefallen, aber nu ist das ja alles eine Stufe indirekt...
Vielleicht lohnt es sich, nicht den String-Inhalt, sondern Zeiger auf die Descriptoren in den Puffer zu schreiben und die dann zu sortieren? Das könnte sich lohnen, wenn es um eher wenig Strings geht.
Als ich mir gestern frische Luft in den Schädel gepumpt habe kam mir der GEdanke, dass es sehr praktisch wäre, wenn alle Pointer absteigend sortiert wären.
Ich hatte aber noch keinen brauchbaren Gedanken, wie man den Zustand erreichen könnte.
Da fällt mir grad ein:
Wenn jemand in den String-Descriptoren rumgePOKEt hat und mehrere Zeiger auf den gleichen String zeigen, dann wird es ein Problem geben.
Wird je eh so gemacht. Wieso sollte man das anders machen?
"Sollen" würde ich nicht sagen
Der Extremfall sin 8K zu kopieren, es kann auch überlappende Strings geben => Da könnte ein Sonderfall drohen.
Trotzdem muss man den String, der von dem Betrachtungsfenster zerteilt wird in einem der beiden Fenster berücksichtigen. Wenn man ihn ignoriert, fehlt er am Schluss und man hat einen String, der auf eine Position des alten String-Heaps zeigt, wo sich aber der Inhalt nicht mehr befindet.
Der wird ja vollkommen natürlich gefunden, wenn man alle Strings mit Startadresse im Suchfenster betrachtet. Vom vorherigen Durchlauf ist er auch nicht zerstört worden - ich sehe da jetzt keinen Sonderfall mehr. Das Suchfenster rückt immer 8K weiter, die Zieladresse für den Buffer immer nur so weit, wie er gefüllt ist.
Ah jetzt ja, eine Insel!
Der erste Durchlauf mit dem letzten Puffer hat noch kein Problem. Am oberen Ende hören die Strings garantiert passend zum Pufferende auf, und die 200 Bytes am unteren Ende, die ein String aus dem vorigen Puffer dort hineinragt, sind auch kein Problem.
Beim 2. Durchlauf sind diese 200 Bytes über das obere Ende hinaus mit dabei. Und wenn gleichzeitig das ganze Suchfenster voll ist, dann würden 8.2K Buffer gebraucht.
Wird je eh so gemacht. Wieso sollte man das anders machen?
"Sollen" würde ich nicht sagen Da ist nur der Auslöser für den Gedanken:
Der Extremfall sin 8K zu kopieren, es kann auch überlappende Strings geben => Da könnte ein Sonderfall drohen.
Trotzdem muss man den String, der von dem Betrachtungsfenster zerteilt wird in einem der beiden Fenster berücksichtigen. Wenn man ihn ignoriert, fehlt er am Schluss und man hat einen String, der auf eine Position des alten String-Heaps zeigt, wo sich aber der Inhalt nicht mehr befindet.
Der wird ja vollkommen natürlich gefunden, wenn man alle Strings mit Startadresse im Suchfenster betrachtet. Vom vorherigen Durchlauf ist er auch nicht zerstört worden - ich sehe da jetzt keinen Sonderfall mehr. Das Suchfenster rückt immer 8K weiter, die Zieladresse für den Buffer immer nur so weit, wie er gefüllt ist.
