Ich würde da allerdings nicht übertreiben. Sonst musst du am Ende auch noch Multicolor berücksichtigen.
Ach du Schreck! Nein, wie gut, dass MAP ein Befehl sein wird, den man erstmal einbinden muss. Da kann dann jeder seine eigene Version basteln, wie er es halt braucht. Mir reicht vorläufig die Hires-Variante, auch als Anschauungsmaterial... 
Arndt
Oder halt so wie in Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co. (1673) beschrieben einfach Strings inkl. Cursor-Steuercodes und Farbcodes ausgeben.
Das geht schon (einfach String anhängen). Ist aber mit PRINT vergleichbar, also langsam. Man kann damit immerhin im schnellen "GHOSTVIEWMAPPRINT" Akzente setzen.
Arndt
Ich experimentiere schon mal ein bisschen mit dem neuen MAP-Befehl (um zu sehen, was man da noch einbauen könnte). Hier mal ein Screen aus einem Spiel, über das ich sonst keinerlei Informationen habe, es ist nur als Beispiel im CharPad dabei (Cave Adventure, ich hab dazu nichts im Web gefunden). Was in TSB (bzw. überhaupt) benötigt wird, ist der Zeichensatz, die Farben (der einzelnen Zeichen), die Liste der Kacheln und schließlich die Map (die Anordnung der Kacheln auf dem Screen). Dabei fiel mir auf, dass die Farben (anders als bei Omega ) üblicherweise zeichenweise (und nicht kachelweise) abgelegt werden. Ich hab das erst mal so gemacht wie Omega (kachelweise und dann hier und da "nachgefärbt", links das Original):
Man braucht ein bisschen Vorarbeit (mit Endurion s C64Studio) und dann sieht das doch ganz brauchbar aus.
Arndt
Hier eine Steuerung für beide (Tastatur und Joystick), wie ich sie in meiner Bastel-Version von GV drin habe. Omega arbeitet da mit den CHR$-Codes der Cursor-Tasten, die muss ich also dem Joystick auch beibringen. Komischerweise reagiert die Joysticksteuerung *viel* schneller als die Tastatur, obwohl in der Schleife immer beide abgefragt werden. Die String-Behandlung (wenn GET einen Tasten-String abgeholt hat) in Basic muss sehr zeitaufwendig sein.
Also mein Code (Erläuterung unten drunter), die Zeilen bis 999 zum Testen:
Der LOOP ist endlos, muss also mit STOP abgebrochen werden. Das Array DI% enthälz die CHR$-Codes der vier JOY-Richtungen (oben=1, rechts=3, runter=5 und links=7). Zuerst fragt die Erkennung ob die Taste a$ in n$ enthalten ist (und an welcher Position, 1, 3, 5 oder7). Dann wird aus dem Array DI% der zugehörige CHR$-Code ausgelesen. War in a$ nichts drin, tritt JOY in die Bresche. Dabei wird die Feuertaste mit AND 15 weggeblendet.
Funktioniert wunderbar. Wie gesagt, der Joystick ist schneller, die Tastatur aber deshalb nicht gleich langsam.
Arndt
Die Umfrage hat kein überzeugendes Ergebnis hervorgebracht
...weil der Punkt "Steuerung sowohl als auch" fehlte!
Arndt
Wieso fragt dein Spiel nicht am Anfang den Benutzer, ob er mit Tasten oder mit Joystick steuern möchte? Und dann wird nur das abgefragt.
Nicht nötig. Wer keinen Joystick hat, merkt gar nicht, dass eine Joystick-Option besteht.
Arndt
Wenn ich nur mit Tastatur spiele, bemerke ich den Unterschied (auch zu „nur Tastatur“) gar nicht. Ich finde das nicht unmöglich langsamer.
Arndt
Leider ist es mir aus performancetechnischen Gründen nicht möglich, Joystick UND Cursortastensteuerung gleichzeitig in das Spiel zu integrieren. Das würde, wegen des zusätzlichen Codes, zu einer spürbaren Verlangsamung der Spielfigur führen.
Die einzige Möglichkeit, die ich sehe, bei der es nicht zu einer Verlangsamung kommt, ist, dass man entweder Joystick ODER Tastatursteuerung ins Spiel einbaut.
Wie Du weißt, habe ich mir selber eine Version gebastelt, die *mit* Joystick und *mit* Tastatur bedienbar ist. Ich weiß ja nicht, was du da mit deinen Tasten machst, aber auf meinem System (Vice 3.1 unter Win10) sehe ich keinen inakzeptablen Unterschied. Der Joystick ist allenfalls etwas schneller als die Tastatur. Codemäßig reicht eine zusätzliche Zeile…
Deine Umfrage ist für mich also nicht beantwortbar. Ich würde beide Möglichkeiten bevorzugen.
Arndt
Bei GoDot muss was Prinzipielles faul sein (falscher Launcher
Hab jetzt einen uralten Launcher installiert (den ersten, den ich mal runtergeladen hatte). Mit dem funktioniert es. Musste allerdings beim Ausprobieren der Menüpunkte gefühlt 100 Mal neustarten...
Arndt
Im DirMaster gibt‘s unter „More“ den Menüpunkt „Compact“. Der tut genau das, was Omega vorschwebt: verwaiste Einträge im Directory entfernen und die anderen nach vorne rutschen lassen. Am Ende sind alle Lücken (Fragmente) weg.
Arndt
Hier mein TSB-Mobil-Arbeitsplatz! Im Hintergrund mein (Aldi-) PC. 
Das ist ein iPad mit Tastatur dran, darauf läuft ein C64-Emulator (den ich gerade betateste) Auf dem Bildschirm ein BLister-Listing.
Arndt
Ich würde ja erst ganz am Ende die Dateien so sortieren, wie ich sie brauche... 
Arndt
Und bei dem andern ging es darum, Regentropfen, die vom Himmel gefallen sind, mit einem Raumschiff einzufangen damit die Welt nicht überflutet wird.
Das war ja schon damals sehr löblich! Übrigens war für mich das Comal damals ebenfalls einer der Gründe, mich mit Simons' Basic zu befassen. Ich war dann ziemlich entsetzt, was da alles nicht ging bzw. mangelhaft gelungen war. Da *musste* ich mich der Sache ja annehmen!
Arndt
COMAL ist ziemlich gut, das habe ich früher in der Schule im Informatikunterricht gelernt als ich noch jung war. Und das hatte auch Funktionsprozeduren.
Ihr hattet die Module in der Schule? Wow! 
Wie habt ihr das denn finanziert gekriegt? Meins hat damals 190 DM gekostet!
Neben der Basis-Einstellung, die der C64 hardwaremäßig mitbringt, läuft Comal komplett im RAM und kann 4 16KB-ROM-Pages, die auf dem Modul liegen (also noch mal 64 KB), für bestimmte Zwecke einblenden (Sound, Sprites, Turtle usw.), erweiterbar um noch mal 2 16-KB-Eproms. Das, damit EgonOlsen71 eine Vorstellung hat, was den Unterschied zwischen TSB und COMAL ausmacht. Das ist mit einer einfachen Basic-Erweiterung wie TSB nicht zu leisten.
Arndt
wäre es nicht besser einen Functions-Befehl einzubauen, statt laufend die bestehende Befehle zu veränderen
Der Befehl PROC ist so etwas Ähnliches, nur dass Variablenwerte eben global sind. Was ich hier neu einbaue, ist ein Befehl, der *auf schnelle Weise* selbstdefinierte Kacheln ausgibt. Omega hat das bisher mit PROCs (was du als FUNCTION bezeichnest) gemacht, was nun mal in Basic ziemlich gemächlich vonstatten geht. Und die bestehenden Befehle werden nur dann verändert, wenn wir daran einen gravierenden Mangel feststellen (worin Omega unschlagbar ist).
Arndt
einen entsprechend modifizierten LIST-Befehl sehr viel nützlicher
Würde ich auch wünschenswert finden, aber es fehlt (wie so oft) der nötige Platz dafür. Ich benutze das Programm zur Eigendokumentation bei fertigen Basic-Programmen und auch zum Debugging, da es Strukturfehler sichtbar macht und bei den PROC-Namen anzeigt, ob darin eventuell schädliche Schlüsselwörter enthalten sind.
Arndt
Ist auf Win10.
