Ich weiß ja nicht, ob das von Relevanz ist, aber wenn man 1024 -40 rechnet, wäre man auch nicht mehr im Screen-Bereich. Sollte man da nicht auch einfach auf der 2ten Zeile anfangen und das Programm sauber schreiben? Der Zeilenumbruch in die nächste Zeile ist ja beim setzen des Leerzeichens wahrscheinlich egal, aber das gehen in den Norden auch?
@@boarschtl Sehr gut aufgepasst, und ja... die Schleife bei 1104 zu beginnen wäre besser. Man läuft "im Norden" zwar nicht Gefahr den Programmspeicher zu überschreiben, in sofern fiele das erstmal nicht negativ auf. Aber im Norden liegen die Basic Pointer und die sollte man nur anrühren wenn nan weiß was man tut. Danke für den Hinweis!
Ja und um das problem generell zu beheben, macht mans wie folgt: wir fangen nicht in Zeile 0 an, sondern in zeile 1 (zeile 0 ist eh rand, da muss nix passieren). Außerdem gehen wir von spalte 1, nicht 0 bis 38. Die Randspalten müssen nie bearbeitet werden, auch nicht die Randzeilen. Das spart 2 zeilen und 2x die Höhe des Bildschirmes an Zeit. Außerdem ist der code failprove wegen überlauf. Man kann hier immernoch nur jede 2te zeile und/oder spalte bearbeiten, dann spart man nochmal viel. Aber: die wahrscheinlichkeit, das es aus dem Bereich rausläuft, ist enorm reduziert.
1104 ist ja Zeile 2 (1024-1063 = Zeile 0 Rand, 1064-1103 leere Zeile 1). Unten haben wir das ja schon korrigiert (nicht bis 2023 sondern bis 1943). Bei den Spalten kann man bei 1 beginnen und bei 37 enden. Alles andere regeln die Steps in den FOR-Schleifen (STEP 80 in den Zeilen, STEP 2 in den Spalten). Wenn Du das so machst sparst Du ein wenig Rechenzeit. Sehr viel ist das sicher nicht, aber wenn man es optimieren wollte würde man es sicher so machen. Und ja, auf diese Weise fallen wir dann auch nicht mehr unbeabsichtigt aus dem Bildschirmspeicher raus. 😊
Ja, vor allem sollte man beachten, welche Speicherbereiche auf den Speicherbereich folgen den man gerade bearbeitet. Ansonsten passiert nämlich genau sowas. Ich hatte nun glück, weil ich - anständig wie ich bin - das Programm vor der Ausführung gespeichert habe. Hätte ich das nicht getan, wäre der Code verloren. Eine ganz böse Falle ist das. Deshalb: Immer aufpassen was man wo in welche Speicherstelle schreibt. Insbesondere bei Schleifen übersieht man solche Fehler gerne. Grüße an Dich!
Wie sagt man so schön? Lieber zu spät als niemals. 😊Aber Scherz beiseite. Schau Dich mal um im Internet (z.B. hier bei YT) und Du wirst staunen wie groß und lebendig die Retro-Computing-Community ist. Es gibt nach wie vor Menschen die sich für diese Computer interessieren, entweder aus nostalgischen Gründen, oder aber auch , weil sich auf diesen Geräten sehr gut die Grundlagen der Programmierung lernen lassen. Oder die Grundlagen der Computer-Hardware. Auch heute noch werden z.B. für diese Geräte Hardwareerweiterungen und -Zusätze mit sehr viel Liebe zu diesen Geräten erdacht und z.B. über Crowdfunding-Projekte in die Realität umgesetzt. Das Interesse an diesen Geräten ist also wieder (oder noch immer) vorhanden. Und so lange das so ist, sind diese Videos hier nicht sinnlos. Und ich selbst erfülle mir damit einen Traum. Nämlich den Traum diese Geräte mit den Mitteln und Möglichkeiten des Internets (das es ja damals noch nicht gab) heute so kennenzulernen wie ich sie damals gerne kennengelernt hätte.
Erst mal: megageniales Video. Es ist suuuuuuuperlange her, dass ich tatsächlich mit meinem damaligen C128-D ein paar Basic 2.0 (und auch Basic 7.0) Anfänger-Schrittchen gemacht habe. Daher kann ich zumindest die Essenz Deines Vids verstehen. Abo ist auf jeden Fall "gebongt". Meine Frage/Anmerkung: könnte man die Begrenzung nicht mit "if... then..." ebenfalls hinbekommen? Denn so ist unten rechts das Kästchen - soweit ich dein Programm verstanden habe - immer frei. Oder sehe ich das falsch? Viele Grüße aus Köln und Daumen hoch!
Es werden eine ganze Reihe von Feldern niemals gesetzt, was daran liegt wie ich das Dungeon aufbaue. Es werden - ausgehend von den Kästchen die in jeder Zeile alle 2 Spalten gesetzt werden - niemals diagonal Kästchen gesetzt sondern nur oben/rechts/links/unten. Das heißt die Felder die diagonal von den Spaltenkästchen liegen bleiben immer frei. Wollte man das ändern, müsste man Kästchen diagonal setzen, was grundsätzlich natürlich machbar ist, dann aber - so denke ich - dazu führen würde dass das Dungeon schwerer "begehbar" wird. Man muss ja darauf achten, dass man Laufwege (also Gänge) schafft. Aber hey, versuche es doch einmal! Anregung hast Du jetzt. Und wie DEIN Dungeon aussieht bestimmst nur Du! 😊
Man kann auch während des Codings "Sicherungen" einbauen, die man, wenn fertig, wieder löscht. ZB: If ziel < min or ziel > max then print"Fehler":end Damit kann man, wenn man UNGERNE Saved, viel Codingarbeit sparen 🙂
@@MsHolgerM Der im C64 von Werk aus verbaute Basic V2 Interpreter kennt leider keine MOD-Funktion. Das Äquivalent wäre sowas hier: INT(Z)-INT(INT(Z)/INT(N))*INT(N). Ob das nun bei dem einfachen Beispielcode unbedingt nötig ist lasse ich mal offen. Es reicht ja aus den Bereich so klein zu halten dass ein Über- oder Unterschreiten rechnerisch gar nicht möglich ist. Aber danke für den Denkanstoss.
Ich weiß ja nicht, ob das von Relevanz ist, aber wenn man 1024 -40 rechnet, wäre man auch nicht mehr im Screen-Bereich. Sollte man da nicht auch einfach auf der 2ten Zeile anfangen und das Programm sauber schreiben? Der Zeilenumbruch in die nächste Zeile ist ja beim setzen des Leerzeichens wahrscheinlich egal, aber das gehen in den Norden auch?
@@boarschtl Sehr gut aufgepasst, und ja... die Schleife bei 1104 zu beginnen wäre besser. Man läuft "im Norden" zwar nicht Gefahr den Programmspeicher zu überschreiben, in sofern fiele das erstmal nicht negativ auf. Aber im Norden liegen die Basic Pointer und die sollte man nur anrühren wenn nan weiß was man tut. Danke für den Hinweis!
Ja und um das problem generell zu beheben, macht mans wie folgt: wir fangen nicht in Zeile 0 an, sondern in zeile 1 (zeile 0 ist eh rand, da muss nix passieren). Außerdem gehen wir von spalte 1, nicht 0 bis 38. Die Randspalten müssen nie bearbeitet werden, auch nicht die Randzeilen. Das spart 2 zeilen und 2x die Höhe des Bildschirmes an Zeit. Außerdem ist der code failprove wegen überlauf. Man kann hier immernoch nur jede 2te zeile und/oder spalte bearbeiten, dann spart man nochmal viel. Aber: die wahrscheinlichkeit, das es aus dem Bereich rausläuft, ist enorm reduziert.
1104 ist ja Zeile 2 (1024-1063 = Zeile 0 Rand, 1064-1103 leere Zeile 1).
Unten haben wir das ja schon korrigiert (nicht bis 2023 sondern bis 1943).
Bei den Spalten kann man bei 1 beginnen und bei 37 enden. Alles andere regeln die Steps in den FOR-Schleifen (STEP 80 in den Zeilen, STEP 2 in den Spalten).
Wenn Du das so machst sparst Du ein wenig Rechenzeit. Sehr viel ist das sicher nicht, aber wenn man es optimieren wollte würde man es sicher so machen. Und ja, auf diese Weise fallen wir dann auch nicht mehr unbeabsichtigt aus dem Bildschirmspeicher raus. 😊
10:00 Wir haben früher gesagt, dass man nicht zu weit nach Süden poken soll... Man was kommen da für Erinnerungen hoch....
Ja, vor allem sollte man beachten, welche Speicherbereiche auf den Speicherbereich folgen den man gerade bearbeitet. Ansonsten passiert nämlich genau sowas. Ich hatte nun glück, weil ich - anständig wie ich bin - das Programm vor der Ausführung gespeichert habe. Hätte ich das nicht getan, wäre der Code verloren. Eine ganz böse Falle ist das. Deshalb: Immer aufpassen was man wo in welche Speicherstelle schreibt. Insbesondere bei Schleifen übersieht man solche Fehler gerne. Grüße an Dich!
4:55 Ganz klar. Du pokest ins Basicram hinein... Habe ich früher auch sehr oft gehabt. 🙂
Meinste nicht der Kurs kommt 45 Jahre zu spät?
😆😅🤣
Wie sagt man so schön? Lieber zu spät als niemals. 😊Aber Scherz beiseite. Schau Dich mal um im Internet (z.B. hier bei YT) und Du wirst staunen wie groß und lebendig die Retro-Computing-Community ist. Es gibt nach wie vor Menschen die sich für diese Computer interessieren, entweder aus nostalgischen Gründen, oder aber auch , weil sich auf diesen Geräten sehr gut die Grundlagen der Programmierung lernen lassen. Oder die Grundlagen der Computer-Hardware. Auch heute noch werden z.B. für diese Geräte Hardwareerweiterungen und -Zusätze mit sehr viel Liebe zu diesen Geräten erdacht und z.B. über Crowdfunding-Projekte in die Realität umgesetzt. Das Interesse an diesen Geräten ist also wieder (oder noch immer) vorhanden. Und so lange das so ist, sind diese Videos hier nicht sinnlos. Und ich selbst erfülle mir damit einen Traum. Nämlich den Traum diese Geräte mit den Mitteln und Möglichkeiten des Internets (das es ja damals noch nicht gab) heute so kennenzulernen wie ich sie damals gerne kennengelernt hätte.
Erst mal: megageniales Video. Es ist suuuuuuuperlange her, dass ich tatsächlich mit meinem damaligen C128-D ein paar Basic 2.0 (und auch Basic 7.0) Anfänger-Schrittchen gemacht habe. Daher kann ich zumindest die Essenz Deines Vids verstehen. Abo ist auf jeden Fall "gebongt".
Meine Frage/Anmerkung: könnte man die Begrenzung nicht mit "if... then..." ebenfalls hinbekommen? Denn so ist unten rechts das Kästchen - soweit ich dein Programm verstanden habe - immer frei. Oder sehe ich das falsch? Viele Grüße aus Köln und Daumen hoch!
Es werden eine ganze Reihe von Feldern niemals gesetzt, was daran liegt wie ich das Dungeon aufbaue. Es werden - ausgehend von den Kästchen die in jeder Zeile alle 2 Spalten gesetzt werden - niemals diagonal Kästchen gesetzt sondern nur oben/rechts/links/unten. Das heißt die Felder die diagonal von den Spaltenkästchen liegen bleiben immer frei.
Wollte man das ändern, müsste man Kästchen diagonal setzen, was grundsätzlich natürlich machbar ist, dann aber - so denke ich - dazu führen würde dass das Dungeon schwerer "begehbar" wird. Man muss ja darauf achten, dass man Laufwege (also Gänge) schafft. Aber hey, versuche es doch einmal! Anregung hast Du jetzt. Und wie DEIN Dungeon aussieht bestimmst nur Du! 😊
Man kann auch während des Codings "Sicherungen" einbauen, die man, wenn fertig, wieder löscht. ZB:
If ziel < min or ziel > max then print"Fehler":end
Damit kann man, wenn man UNGERNE Saved, viel Codingarbeit sparen 🙂
Sauber wäre, wenn man den Bildschirmbereich über den Divisionsrest des Randoms ermittelt (Stichwort Modulo) und gerät dann nie außerhalb des Bereichs.
@@MsHolgerM Der im C64 von Werk aus verbaute Basic V2 Interpreter kennt leider keine MOD-Funktion. Das Äquivalent wäre sowas hier: INT(Z)-INT(INT(Z)/INT(N))*INT(N).
Ob das nun bei dem einfachen Beispielcode unbedingt nötig ist lasse ich mal offen. Es reicht ja aus den Bereich so klein zu halten dass ein Über- oder Unterschreiten rechnerisch gar nicht möglich ist. Aber danke für den Denkanstoss.
Ha! Erster :-) Nun schaue ich das Video....