Beiträge von Omega

Du könntest es ja auch so machen: Das Spiel fängt erst mit einem affenmäßigen Tempo an (so wie es jetzt ist) und jedesmal wenn man so ein Ding gefressen hat, wird es etwas langsamer. So entwickelt sich das Spiel allmählich von "Unspielbar" über "Irrwitzig" bis hin zu "Kann-man-machen". Da kann sich der Spieler dann auf etwas freuen. Das hat es auch noch nicht gegeben (weil es völlig sinnlos ist).

Aber nein. Vergessen wir das. Du solltest das Spiel so lassen, wie du es für richtig hältst. Ich weiß ja selbst wie es ist: Man tüftelt monatelang an einem Programm und wenn es endlich fertig ist und man schon den verdienten Urlaub auf Mallorca antreten will, kommt mitten in der Nacht so ein Blödian daher und macht Vorschläge. Und versaut einem die ganze Planung. Das ist voll asi und geht ja gar nicht.

Also freuen wir uns über das Spiel so wie es ist, drehen die Emulator-Geschwindigkeit auf 1% runter und schon steht dem Spielspaß nichts mehr im Wege. Top!

Ein tolles Snake-Spiel. Inklusive Einleitungstext und Farbauswahl. Hervorragend. Und vor allem: Es läuft erstaunlich schnell, obwohl in reinem BASIC programmiert. Respekt dafür!

Allerdings ist genau das auch mein erster Kritikpunkt: Die Schlange rast so schnell übers Feld, dass ich eher das Gefühl hatte, ich spiele ein Reaktionsspiel für Kolibris mit Koffeinproblem.

Ein bisschen schade, dass du keine Änderungen mehr machen willst - ich hätte da nämlich eine Idee:

Wie wär's, wenn das Spiel langsam beginnt und die Geschwindigkeit jedes Mal ein kleines Stück steigt, sobald man einen Happen erwischt? Also: Start bei Level 1 (Rentnerschlange), und bei jedem Bissen ein Level mehr - bis hin zu Level 99999 (Schlange im Warp-Modus). Für Ungeduldige könnte man optional am Anfang direkt ein höheres Level einstellen.

Das Ganze könnte man schön im Punktesystem spiegeln: Wer auf niedrigen Levels zockt, bekommt weniger Punkte - wer mit Highspeed spielt, kassiert dafür auch Highscore-mäßig ab. Risiko wird belohnt!

Ach ja, und nur am Rande: Ich habe es nicht geschafft, auch nur ein Ding zu fressen.

Dabei habe ich auf dem Nokia 3330 mindestens 100.000.000 Snake-Stunden verbracht und gelte unter Oldschool-Snake-Veteranen eigentlich als lebende Legende.

Deshalb MUSSTE ich diesen Vorschlag machen. Aus Ehre.

Zitat von syshack

Ich habe mal die Diskussion von Programmierung in echter vs emulierter vs FPGA Hardware hierher ausgelagert.

Vielen Dank!

Zitat von FloatingRiver

Denke bis jetzt bin ich von den Relativ-Dateien verschont geblieben und darum kann man davon ausgehen, dass ich 'ein wenig' verwöhnt gewesen bin die letzten 30, 40, 50... Jahre... Na gut, 50 jetzt auch wieder nicht ...

Auch wenn der Zugriff auf RANDOM-Dateien in COMAL - egal ob mit 1541 oder 1571 - ziemlich langsam ist, lohnt sich diese Zugriffsform trotzdem. Der Vorteil liegt darin, dass man direkt zu einem bestimmten Datensatz springen kann, ohne die ganze Datei sequentiell durchlesen zu müssen.

Gerade wenn man größere Datenmengen verwaltet, macht das einen großen Unterschied. Zum Beispiel bei einer Adressverwaltung: Wenn jeder Kunde eine feste Kundennummer hat, kann man direkt zu genau diesem Datensatz springen und ihn bearbeiten - ohne vorher alle anderen Kunden durchgehen zu müssen. Das spart trotz der langsamen Zugriffszeit bei jedem Einzelzugriff insgesamt viel Zeit.

Kurz gesagt: RANDOM-Dateien ermöglichen einen gezielten und damit effizienteren Zugriff, gerade wenn man über Indizes wie Kundennummern arbeitet - und das macht sie trotz der unvermeidlichen Wartezeiten sehr sinnvoll.

Noch kurz zu der Tetris-Melodie: Die Musikdaten lese ich zwar vor dem Abspielen aus den (langsamen) RANDOM-Dateien, aber ich nutze den RANDOM-Zugriff bewusst, um Wiederholungen umzusetzen. Zum Beispiel lade ich erst die Noten 1-50, dann 51-100 und lese danach nochmal die Noten 51-100 ein, um die Wiederholung der Passage ohne doppelte Daten in der Datei abzubilden. So kann ich Musikabschnitte gezielt mehrfach abspielen, ohne die Datei mit doppelten Noten vollzustopfen.

Zitat von FloatingRiver

Was mich erstaunt hat, ist die Dauer des Lesevorgang!

Ja, in der Tat. Das Schreiben und Lesen von Relativ-Dateien mit wahlfreiem Zugriff (RANDOM) dauert recht lange. Zumindest in diesem Fall, wenn die Datensatzlänge nur 4 Bytes ist (jede Note belegt 4 Bytes in der Datei). Dies ist mir auch aufgefallen.

Ich weiß nicht, ob das an COMAL oder an den C= Laufwerken im Allgemeinen liegt. Dies ist aber die einzige Möglichkeit, um direkt auf beliebige Datensätze einer Datei zuzugreifen.

Und überhaupt: Warum muss das so schnell gehen? Wo bleibt da der Genuss?

Zitat von c64held

Könntest du das Package vom Sounddemo bitte einmal als Sourcecode-asm mit beilegen und die Programme auch im Textformat.

Das lernen vom Comal80 ist dadurch auch einfacher.

Ich verstehe nicht ganz, was du meinst. Die Sounddemo benutzt keinen Assembler-Code. Sie besteht 100%ig aus reinen COMAL-Befehlen.

Und die Programme im Textformat beilegen? Wie meinst du das? Du kannst ein Programm laden und dann mit list"dateiname" als Textdatei auf Diskette speichern. Oder mit list"lp: " auf einen Drucker bzw. in eine Datei ausgeben.

Heute möchte ich euch einmal ganz praktisch zeigen, wie sich der Gültigkeitsbereich von Variablen in COMAL auswirkt - und wie man mit CLOSED-Prozeduren echten Speicher spart.

In der ersten Version meiner Tetris-Melodie hatte ich die Noten in Form riesiger DATA-Zeilen-Wüsten direkt ins Programm geschrieben. Das war weder elegant noch speichersparend - und die sechs dafür verwendeten Arrays haben während der gesamten Programmlaufzeit RAM belegt, selbst wenn sie nicht mehr gebraucht wurden.

Diesmal habe ich es besser gemacht: Die drei Stimmen der Melodie sind nun jeweils in einer Relativdatei auf Diskette gespeichert. Diese Dateien werden in einer CLOSED-Prozedur eingelesen und in sechs Arrays abgelegt. Der dafür benötigte Speicher liegt bei etwa 3,8 KB - aber nur während der Laufzeit der Prozedur.

Und das Ergebnis spricht für sich:

• Vor dem Abspielen der Musik stehen 28338 Bytes zur Verfügung.
• Während die Musik läuft, sind es 24458 Bytes.
• Und nach dem Abspielen hat man wieder die vollen 28338 Bytes frei - automatisch!

COMAL kümmert sich um die Speicherfreigabe ganz von selbst - wenn man die Prozeduren korrekt mit CLOSED definiert.

So kann man selbst auf dem C64 relativ aufwändige Musikstücke in Programme einbauen, ohne dass sie den gesamten RAM-Speicher blockieren.

Toll, oder?

Zitat von c64held

Läuft das eingeschaltete Geo-Ram beim Vice auch mit Comal80 ?

GeoRAM ist primär als Speichererweiterung für GEOS gedacht und wurde dafür auch entwickelt. COMAL80 nutzt meines Wissens nach kein spezielles Banking oder Speichererweiterung wie GeoRAM - zumindest ist mir kein Fall bekannt, wo das in Kombination verwendet wird. Ich habe das selbst nicht getestet, aber ich würde stark davon ausgehen, dass GeoRAM in COMAL80 keinen Effekt hat bzw. nicht unterstützt wird. Es ergibt in dem Kontext vermutlich auch keinen wirklichen Sinn.

Zitat von Lynx

Die Aussage "COMAL läuft auf Platform xyz" ist irrelevant, wenn "es läuft" für einen nur bedeutet, dass die COMAL Einschaltmeldung erscheint und eine handvoll Progrämmchen laufen.

Ob alles "läuft", sprich komplett korrekt durchemuliert wird, zeigt sich immer erst, wenn Fehler auftreten.

Keine Sorge. Mein COMAL-Test auf dem TheC64 ging weit über das bloße Erscheinen der Einschaltmeldung hinaus.

Ich habe gezielt sehr komplexe Programme getestet, die viele verschiedene Sprachfeatures von COMAL nutzen, darunter verschachtelte Prozeduren mit Parameterübergabe, strukturierte Kontrollabläufe, der Umgang mit Gültigkeitsbereichen von Variablen und auch der Zugriff auf relative Dateien. All das lief stabil, reproduzierbar und ohne Fehlverhalten. Natürlich kann kein Test jemals absolut vollständig sein, aber nach dem, was ich geprüft habe, kann ich mit gutem Gewissen sagen: COMAL läuft auf dem TheC64 nicht nur oberflächlich, sondern zeigt sich in allen getesteten Bereichen voll funktionstüchtig.

Zitat von FloatingRiver

...da fragt man sich schon wie wichtig eine geschlossene Prozedur eigentlich sein kann?

Hey FloatingRiver,

nachdem ich meinen Herzinfarkt überwunden und mich mit dem Defibrillator erfolgreich reanimiert habe, möchte ich dir gerne noch etwas zum Thema CLOSED mitgeben.

Wenn man COMAL so nutzt, wie es gedacht ist, sollten PROC und FUNC immer mit CLOSED geschrieben werden. Und zwar aus folgenden Gründen:

Lokale Variablen sind nur mit CLOSED möglich

Nur in CLOSED-Prozeduren bleiben Variablen innerhalb der Prozedur. Ohne CLOSED sind alle Variablen global. Das heißt: Prozeduren können sich gegenseitig beeinflussen, und der Überblick geht schnell verloren. Das macht Programme fehleranfälliger - und widerspricht dem Grundprinzip prozeduraler Programmierung: Klare, abgeschlossene Bausteine.

Speicher wird effizienter genutzt

In CLOSED-Prozeduren werden Variablen nur während der Ausführung im Speicher gehalten. Nach dem Ende der Prozedur wird der Speicher sofort freigegeben. Ohne CLOSED bleiben alle Variablen dauerhaft erhalten - selbst wenn sie gar nicht mehr gebraucht werden. Auf einem C64 mit begrenztem RAM kann das schnell zum Problem werden.

Der Code bleibt sauber und nachvollziehbar

Prozeduren sollten so geschrieben sein, dass sie für sich selbst funktionieren - ohne Abhängigkeiten von außen. Das erreicht man nur mit CLOSED. Der Code bleibt dadurch übersichtlich, leichter zu testen und vor allem: Sicher vor unerwarteten Seiteneffekten.

Fazit:

Wer COMAL sinnvoll und strukturiert einsetzen möchte, sollte PROC und FUNC grundsätzlich mit CLOSED schreiben. Alles andere führt zu genau den Problemen, die COMAL gegenüber BASIC eigentlich vermeiden wollte.

Ich sage das bewusst so klar, weil ich oft den Eindruck habe, dass COMAL zwar irgendwie verwendet wird, aber die Konzepte prozeduraler Programmierung nicht wirklich verstanden werden. Manche sehen die Stärken von COMAL in der LOGO-ähnlichen Turtle-Grafik oder in bestimmten Grafikbefehlen - aber das sind eigentlich nur nette Zugaben.

Die eigentliche Stärke von COMAL liegt in seiner sauberen, strukturierten und prozeduralen Programmierung - genau das unterscheidet es fundamental von den alten BASIC-Varianten.

Mit freundlichen Grüßen,

der Oberlehrer

Zitat von FloatingRiver

Seit dem ist natürlich bei mir alles OPEN und ich habe es nicht weiter verfolgt.

OMG!!!!!

Dann nutzt du COMAL nicht richtig. Eine Prozedur/Funktion sollte im Idealfall immer CLOSED sein. Wenn du das nicht so machst, dann hast du wahrscheinlich das Konzept einer prozeduralen Programmiersprache nicht verstanden.

Ich glaube, ich muss da später noch mehr zu schreiben. Im Moment geht es nicht. Ich krieg' nämlich gerade einen Herzinfarkt. Wo ist der Defilibrator?

Zitat von FloatingRiver

Vergessen wir dann das Spiel. Werde damit diesen Grund und Boden nicht mehr belasten

Verstehe mich bitte nicht falsch:

Ich möchte nicht, dass wir dein Spiel vergessen. Im Gegenteil: Ich finde es sehr gelungen und ich möchte, dass es noch mehr Aufmerksamkeit bekommt.

Aber es wäre sinnvoll, wenn du für das Spiel einen eigenen Thread eröffnen würdest. Wir können dann dort weiter darüber diskutieren und uns ganz auf das Spiel konzentrieren.

Ich würde das genauso machen: Wenn ich ein tolles COMAL-Programm erstellen würde, dann würde ich es hier im Thread kurz erwähnen und dann auf einen anderen Thread verweisen, in dem ich das Programm gebührend mit Pauken und Trompeten vorstellen würde.

Dieser Thread hier soll eher dazu dienen, allgemeine COMAL-Fragen zu klären. Z.B. "Was ist eine Prozedur?". Oder: "Warum funktioniert GOTO 10 nicht?". Oder "Sollte ich CLOSED verwenden oder besser nicht?".

Nix für Ungut.

Zitat von FloatingRiver

Natürlich...

Jetzt wo das Allgemeinwissen breit verbreitet ist, kommen neue Ideen ins COMAL-Spiel rein

Eigentlich wäre es nett, wenn du für dein Spiel einen separaten Thread aufmachen würdest. Hier im Thread soll es eigentlich um COMAL im Allgemeinen- und nicht um spezielle Projekte gehen.

Hat das alles noch irgendwas mit COMAL zu tun?

Zitat von FloatingRiver

'PRESS ON RETURN/ENTER/SPACE KEY' war der Plan! 'KEY' ist aber bei "Sparmaßnahmen" zum Opfer gefallen. Wer denkt da schon an grammatische Korrektheit >>> Aber PRESS SPACE wird sofort umgesetzt! Spart wieder ein paar Bytes...

Danke, dass du das anpassen willst. Das zeigt, wie viel Sorgfalt du in dein Spiel steckst.

Nur zur Sprachsache:

Auch "press on space key" wäre im Englischen leider nicht ganz korrekt.

Man sagt entweder einfach "press space" (was in Spielen am üblichsten ist) oder etwas ausführlicher "press the space key".

Das "on" passt hier nicht.

Kurz gesagt: "press space" ist völlig richtig - kurz, klar, und genau das, was man erwartet.

Freu mich, dass du weiter dran feilst - MEGA-DOG wird von Mal zu Mal besser!

Jetzt, wo das Spiel von FloatingRiver auch in älteren VICE-Versionen läuft:

Lasst uns wieder zurück zum Thema kommen. Was habt ihr zuletzt in COMAL80 programmiert?

Zitat von SkulleateR

Irrelevant...

Auch wenn wir hier mittlerweile deutlich im Off-Topic-Bereich gelandet sind - ich möchte trotzdem noch meine Tube Fischstäbchen dazugeben, weil das Thema mir wichtig erscheint:

Es ist keineswegs irrelevant, ob ein Spiel auf Emulatoren läuft - im Gegenteil. In der heutigen Realität nutzen die meisten Menschen die C64-Plattform über Software-Emulatoren wie VICE oder CCS64 oder über FPGA-basierte Reimplementierungen wie MiSTer oder Ultimate64. Auch wenn man letztere technisch nicht als "Emulatoren" im engeren Sinn bezeichnen sollte, haben sie gemeinsam, dass sie nicht der originale Brotkasten sind - aber trotzdem (oder gerade deswegen) die Plattform am Leben erhalten.

Dass ein Spiel nur auf echter Hardware funktioniert, mag puristisch korrekt sein, bringt aber der heutigen Nutzerbasis wenig. Ein Spiel, das auf vielen Systemen reibungslos läuft, erreicht mehr Menschen - und das sollte im Sinne der Entwickler wie auch der Szene sein.

Wenn man Emulatoren und FPGA-Systeme ignoriert oder inkompatibel bedient, grenzt man sich effektiv von einem Großteil der heutigen Nutzerschaft ab. Gute Software berücksichtigt daher beide Seiten: Sie nutzt die C64-Hardware effizient, ohne sich auf zweifelhafte Tricks zu stützen, die bekannte Probleme verursachen - weder in Emulatoren noch in Reimplementierungen.

Und selbst wenn ein Fehler "nur" in einem Emulator auftritt, ist er für den Nutzer ein reales Problem. Die Emulatoren sind inzwischen für viele Leute DIE PLATTFORM, nicht ein zweitrangiges Werkzeug zur Entwicklung. Und das gilt übrigens auch für TheC64 - eine kommerzielle Plattform mit großer Verbreitung, die aus genau diesen Gründen nicht ignoriert werden sollte.

Zitat von SkulleateR

Solange es (mit den Pokes) auf einem Original C64 läuft, zeigt es eher BUGs in VICE auf und dass der Code in Ordnung ist

Der echte C64 sollte irgendwie immer die Referenz sein. Da stimme ich dir prinzipiell zu.

Aber das ist nur eine Idealvorstellung.

In der realen Welt sind mehr Leute mit einem Emulator unterwegs als mit echter Hardware. Und ältere Versionen von Emulatoren, wie VICE 2.3 oder 3.3, sind weit verbreitet. - Ein in der heutigen Zeit geschriebenes Spiel sollte sowohl auf echter Hardware, als auch auf den am weitesten verbreiteten Emulatoren lauffähig sein. - Wenn z.B. Sam's Journey nicht auf dem TheC64 (Vice 2.3) lauffähig wäre... Undenkbar!

Ihr könnt ja weiterhin in eurer Fantasiewelt dahinschweben. Aber ich sage euch: Ein Spiel muss auf so vielen Konfigurationen wie möglich lauffähig sein. Sonst ist man raus aus dem Business.

Zitat von FloatingRiver

Stundenlang habe ich alles getestet, ausprobiert, angepasst, modifiziert {was ja eigentlich nichts heißt }, damit es rund um die Uhr funktioniert!

Ich bin jetzt erst zum Testen gekommen.

Ja, das stundenlange Testen hat sich gelohnt. Jetzt funktioniert es auch bei mir.

Übrigens: Dein Spiel sollte grundsätzlich überall dort laufen, wo auch COMAL läuft. Wenn du es schaffst, bestimmte VICE-Versionen mit den POKEs zu zerschießen, dann ist das zwar bemerkenswert, aber es zeigt auch, dass der Code nicht "sauber" ist. Deswegen würde ich solche Angaben wie "läuft ab VICE Version 3.1" gar nicht machen. Dein Spiel sollte überall da laufen, wo auch COMAL80 läuft. (Warum das Spiel unbedingt auf dem C128 laufen muss, erschließt sich mir nicht.)

Hier noch eine kleine Anmerkung:

Du schreibst da an mehreren Stellen "press on return", "press on space". Das ist grammatikalisch falsch. Es heißt entweder nur "press space" oder "press the spacebar", wenn du es ausführlicher bevorzugst.

Auf jeden Fall ist es ein tolles Spiel. Leider ist es heute schon so spät, dass ich nicht wirklich zum Spielen komme. Aber früher oder später werde ich die Highscore-Liste erobern.

Amtliche Sondermeldung aus dem Ministerium für COMAL-Kompatibilität

Betrifft: "COMAL läuft nicht auf dem TheC64 bzw. dem TheC64 Mini" - eine Untersuchung

Ermittlungsstand:

Im Rahmen einer unabhängigen, gründlich durchgeführten Systemüberprüfung durch den erfahrenen Prüfer Herrn Pokémon (siehe Bildbeweis unten), konnte zweifelsfrei festgestellt werden:

✅ COMAL 80 V2.01 läuft auf dem TheC64 (Mini) absolut problemlos!

Getestet wurden u. a.:

• Eigene komplexe COMAL-Programme
• Zugriff auf relative Dateien
• Diverse COMAL-Befehle und Strukturen
• Bedienung mit und ohne Flusen in der USB-Buchse

Testergebnis: Keine Abstürze, keine Einschränkungen, keine Anomalien.

🧪 Testumgebung:

• TheC64 Mini (Firmware aktuell)
• COMAL80 V2.01 (Originalabbild)
• Ausreichend Kaffee

Die von Benutzer SkulleateR geäußerte Vermutung, dass COMAL nicht auf den Geräten von Retro Games Ltd. lauffähig sei, kann somit offiziell als entkräftet betrachtet werden.

📸 Fotodokumentation:

✅ Fazit:

approved.pngWer COMAL auf dem TheC64, dem TheC64 Mini oder dem TheVIC20 nutzen möchte, kann dies mit ruhigem Gewissen tun. Die Plattform ist dafür voll kompatibel.

Unterzeichnet: Herr Pokémon

Unterzeichnet: Herr Prof. Dr. Omega

🆗 (Digital signiert)