Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co.

Es gibt 4.424 Antworten in diesem Thema, welches 407.129 mal aufgerufen wurde. Der letzte Beitrag (19. November 2025 um 16:35) ist von GoDot.

  • Sie gehört dir zum Selbstkostenpreis von nur 25 D-Mark.

    Hey Du!

    Wer ich?

    Genau!

    Willst Du vielleicht diese unsichtbare Heftdiskette kaufen?

    Was? Eine unsichtbare Heftdiskette? Ich kann sie gar nicht sehen.

    Natürlich nicht. Du kannst Sie auch nicht sehen weil sie unsichtbar ist.

    Ach so.

    Ich würde sie Dir verkaufen für nur 25 DM.

    Was für nur 25 DM?

    Pssttt! Genau!

    Bitte melde dich an, um diesen Link zu sehen.

  • Dein Spiel ist vor dem Release schon so erfolgreich, dass es bereits eine Brettspiel-Version von verschiedenen Herstellern gibt. Ob die allerdings offiziell lizensiert ist, weiß ich nicht. Es gibt übrigens auch Versionen mit Bildern statt Zahlen.

    Jaaaah! =O Das ist doch toll! Und mit Monstern! :grab1: Gerade heute! :freude

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Jaaaah! =O Das ist doch toll! Und mit Monstern! :grab1: Gerade heute! :freude

    Wenn Dein Spiel mit den Zahlen fertig ist, kannst Du ja später mal über eine 2nd Edition nachdenken. Mit den berühmt-berüchtigten frivolen GoDot-Girls statt Zahlen. Ob das machbar ist?

    Als Arbeitstitel würde ich "Hollywood Schieberätsel Pro" vorschlagen. Natürlich USK18. Ich wette, dass das alle jemals dagewesenen Download-Zahlen sprengt.

  • Ich habe gestern Abend ca. 2 Stunden mit dem Zeichensatzeditor gearbeitet. Und auf einmal passierte es im Hauptmenü:

    Ein OUT OF MEMORY ERROR!!! :schreck!:(=markerschütternder Schrei). Bei irgendeiner ganz unverdächtigen Zeile im Hauptmenü, in der irgendeine simple Berechnung ohne Arrays stattgefunden hat. Ich habe jetzt erstmal als schnelle Sofort-Maßnahme den Datentyp des Flood-Fill Arrays von Fließkomma in Integer geändert und eine neue Version V49 erstellt.

    Ich hoffe, das hilft. Wenn nicht dann => Verzweiflung.

    Bitte melde dich an, um diesen Anhang zu sehen.

  • Örks. Heute ist es schon wieder passiert. Trotz meiner Änderung.

    Es ist zum Mäusemelken. Früher oder später crashed das Programm mit einem OUT OF MEMORY Error.

    Heute genau an der Stelle, an der ich meine mühsam erstellten Zeichen speichern wollte.

    Ich habe auch keine Idee, was man da machen könnte. Der Fehler ist ja nicht eindeutig reproduzierbar. Er tritt anscheinend erst dann auf, wenn man relativ lange mit dem Programm gearbeitet hat. So als wenn der Speicher langsam aber sicher immer weniger wird bis dem Programm irgendwann die Luft ausgeht.

    Ich glaube ich trinke jetzt eine ganze Flasche Milch auf ex und lege mich dann ins Bett. Und dann ist mir alles egal.

    Buuuhhuuu! :cry

  • Wie lange dauert es denn? Definierst du zwischendurch immer neue Variablen? (Werden die Arrays immer größer?) Kann das Floodfill daran beteiligt sein?


    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ich arbeite so ca. 1-2 Stunden an einem Zeichensatz und da passiert es. Gestern in Zeile 4870.

    Da steht:

    4870 ad=sp+40*y+x

    Ich glaube vorgesten ist es in einer anderen Zeile im Programm passiert aber mit einer ähnlichen Berechnung.

    Ich dimensioniere die Arrays von Anfang an mit festen Größen. Auch das Array für den Flood-Fill. Kann da was größer werden?

    Und immer neue Variablen habe ich im Programm möglichst vermieden und stattdessen die selben Variablen mehrfach benutzt.

    Als ich nach dem OUT OF MEMORY ERROR mal FRE(0) angezeigt habe, hatte ich immernoch mehr als 3KB frei. Allerdings macht er vor dem FRE(0) immer die Garbage-Collection. Ich weiß nicht wie aussagekräftig das dann noch ist.

    Wie soll ich den Fehler jemals finden? Ich weiß es nicht.

    Ich werde einfach noch eine Flasche Milch trinken. Das wird das Beste für mich sein. Was besseres fällt mir nicht ein.

    :cry:

  • Ich arbeite so ca. 1-2 Stunden an einem Zeichensatz und da passiert es. Gestern in Zeile 4870.

    Da steht:

    4870 ad=sp+40*y+x

    Ah, das ist in PROC bloeschen, dort verwendest du massiv String-Konkatenation. Das müllt dir unweigerlich den Speicher zu und wenn dann die Bitte melde dich an, um diesen Link zu sehen. auf irgendwas Unvorhergesehenes stößt, dann verdreht sie Augen (lies dir den Wiki-Eintrag dazu ruhig durch). Ändere mal das Bloeschen, indem du auf Strings völlig verzichtest:

    Es gibt noch eine zweite Stelle, die Strings verwendet, die auf dem Stringheap gelandet sind und womöglich "die Sicht versperren", nämlich die für FETCH zulässigen Zeichen. Statt dass du alle Zeichen einzeln aufführst, nimm einfach die Shortcuts, das ist {home} für alle Großbuchstaben (bei CSET 0) und {crsr-down} für alle Sonderzeichen. Damit hättest du deinen Riesen-String auf zwei Zeichen verkürzt. Wenn dir ein paar Zeichen noch fehlen: na ja, die kannst du ja direkt ohne Plus dranhängen (dann ist der String immer noch im Basic-Code und nicht auf dem Heap), etwa 7360 x$="{home}{down}{Linkspfeil}{Hochpfeil}".

    Das müsste eigentlich schon viel bringen (ich hab den Code oben nicht ausprobiert, sag Bescheid, wenn er was Falsches macht!) Auf jeden Fall ist das schon mal schneller als die Routine mit den Strings.

    Arndt

    Edit: Außerdem sehe ich gerade noch, dass du die Bloeschen-Routine ja einfach verlässt, indem du zurückspringst zur übergeordneten Routine. Böse! In Zeile 4875 müsste ein einfaches END PROC ausreichen (vielleicht ein Flag für Zeile 790 einbauen, z.B. den Tasten-Code, damit dort auch abgebrochen wird).

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

    4 Mal editiert, zuletzt von GoDot (2. November 2022 um 09:42)

  • Außerdem sehe ich gerade noch, dass du die Bloeschen-Routine ja einfach verlässt, indem du zurückspringst zur übergeordneten Routine. Böse!

    Da Out-of-Memory-Error auch kommt, wenn der Stack überläuft, halte ich das für das ausschlaggebende. Da FRE(0) immer noch Speicher meldet und es nicht einmal bei einer String-Zuweisung oder -verarbeitung kracht habe ich auch an so etwas wie GOSUB ohne RETURN, FOR ohne NEXT (sofern nicht von einem RETURN aufgeräumt) oder äquivalente bei TSB gedacht.

  • Ah, das ist in PROC bloeschen, dort verwendest du massiv String-Konkatenation.

    Genaugenommen ist es in Prozedur "rasterschreiben".

    Edit: Außerdem sehe ich gerade noch, dass du die Bloeschen-Routine ja einfach verlässt, indem du zurückspringst zur übergeordneten Routine. Böse! In Zeile 4875 müsste ein einfaches END PROC ausreichen (vielleicht ein Flag für Zeile 790 einbauen, z.B. den Tasten-Code, damit dort auch abgebrochen wird).

    Ich verstehe nicht ganz. In Zeile 4875 steht:

    Code
    4875 :      if peek(197)=23 then exec rastereinlesen:end proc

    Wenn man die Abbruchtaste drückt, wird das Raster neu eingelesen und dann mit end proc die Prozedur verlassen. Das ist doch legitim. Oder nicht?

    Und das man keine Strings verketten darf, finde ich schon sehr einschränkend. Das würde meine ganze Programmierwelt auf den Kopf stellen.

    Gibt's eine andere Möglichkeiten diesen String-Heap gezielt zu löschen? Falls es daran überhaupt liegt?

    Da Out-of-Memory-Error auch kommt, wenn der Stack überläuft, halte ich das für das ausschlaggebende. Da FRE(0) immer noch Speicher meldet und es nicht einmal bei einer String-Zuweisung oder -verarbeitung kracht habe ich auch an so etwas wie GOSUB ohne RETURN, FOR ohne NEXT (sofern nicht von einem RETURN aufgeräumt) oder äquivalente bei TSB gedacht.

    So etwas denke ich mir auch. Zunächst mal muss man ja feststellen, dass ALLE Funktionen des Programms funktionienren und auch verwendet werden. Und ca. 1-2 Stunden lang läuft alles gut. Wahrscheinlich wird da irgendeine Prozedur unsauber verlassen und so langsam und allmählich baut sich der Stack auf bis er platzt. Aber wo? In Zeile 4875 sehe ich den Fehler jedenfalls nicht. Oder ich kapier's nicht.

  • Gibt's eine andere Möglichkeiten diesen String-Heap gezielt zu löschen?

    An passender, zeitunkritischer Stelle z.B. ein FR=FRE(0) räumt dir eigentlich immer alles soweit auf.

    Als Nebenwirkung stößt die Funktion FRE vor der Berechnung des freien Speichers die Bitte melde dich an, um diesen Link zu sehen. an, um auch die vorübergehend belegten Speicherbereiche wieder freizugeben.

  • An passender, zeitunkritischer Stelle z.B. ein FR=FRE(0) räumt dir eigentlich immer alles soweit auf.

    Mir ist aufgefallen, dass beim Arbeiten mit dem Programm von Zeit-zu-Zeit automatisch die Grabsch-Collection durchgeführt wird. Das merkt man daran, dass das Programm für einen längeren Zeitraum scheinbar "einfriert". Und dann geht's normal weiter. Reicht das nicht?

    Kann es tatsächlich notwendig sein, dass man die Grabsch-Collection manuell anstoßen muss?

  • An passender, zeitunkritischer Stelle z.B. ein FR=FRE(0) räumt dir eigentlich immer alles soweit auf.

    Mir ist aufgefallen, dass beim Arbeiten mit dem Programm von Zeit-zu-Zeit automatisch die Grabsch-Collection durchgeführt wird. Das merkt man daran, dass das Programm für einen längeren Zeitraum scheinbar "einfriert". Und dann geht's normal weiter. Reicht das nicht?

    Kann es tatsächlich notwendig sein, dass man die Grabsch-Collection manuell anstoßen muss?

    Ja, das müsste normalerweise auch ausreichen. Ich vermute deinen Fehler deshalb eher einem "unsauberen" Stackproblem, das langsam anwächst.

    Hin und wieder eine "erzwungende" Garbage Collection mittels FRE(0) verhindert allerdings, dass es dann mal zu einer automatischen kommt, die dann wirklich lange dauern kann. ;)

  • Ja, das müsste normalerweise auch ausreichen. Ich vermute deinen Fehler deshalb eher einem "unsauberen" Stackproblem, das langsam anwächst.

    Ja, das mit dem Stack halte ich auch für wahrscheinlich. Und strik sieht das ja auch so.

    Aber andererseits: Kommt bei Stack-Problemen nicht "Stack Overflow" und nicht "Out of Memory"? :gruebel

    Hin und wieder eine "erzwungende" Garbage Collection mittels FRE(0) verhindert allerdings, dass es dann mal zu einer automatischen kommt, die dann wirklich lange dauern kann. ;)

    Ja, ich verstehe. Das finde ich aber im Moment nicht so schlimm. Hauptsache das Programm läuft weiter und verabschiedet sich nicht mitten beim Speichern des Rasters mit einem "Out of Memory". Das ist nämlich echt ärgerlich weil man dann die großen Kunstwerke des 21. Jahrhunderts nicht mehr retten kann.

  • Genaugenommen ist es in Prozedur "rasterschreiben".


    []


    Das ist doch legitim. Oder nicht?

    BLoeschen wird von Rasterschreiben aus aufgerufen. Wenn du also in BLoeschen die Prozedur Rasterschreiben aufrufst, begibst du dich in Rekursion. Das geht ein paarmal gut, bis der Stack voll ist. Daher mein Vorschlag einfach mit END PROC raus aus BLoeschen, und dann in derselben Zeile 4710 - wenn ein Abbruch vorliegt, deshalb das angesprochene Flag - CALL rasterzeile. Damit vermeidest du eine Rekursion.


    Wenn es also an einer Rekursion liegen sollte, ist es kein TSB-Problem und sollte schnell behoben sein (der Vorschlag liegt ja jetzt vor).


    Eine unkontrollierte Rekursion (eine ohne Abbruchbedingung) ist nicht legitim.


    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von GoDot (2. November 2022 um 13:42)

  • Kommt bei Stack-Problemen nicht "Stack Overflow" und nicht "Out of Memory"?

    zumindest bei BASIC 2.0 nicht, da ist es "Out of memory".

    Hin und wieder eine "erzwungende" Garbage Collection mittels FRE(0) verhindert allerdings, dass es dann mal zu einer automatischen kommt, die dann wirklich lange dauern kann. ;)

    Bringt aber in der Regal gar nichts, außer, dass du eine unnötige Zwangspause einlegst.

    Sie würde nur etwas helfen wenn es eine Stelle gibt, wo du auf keinen Fall eine GC haben willst. Das dürfte aber selten vorkommen.

    Wenn du FRE(0) häufig aufrufst und es ungünstig ist, dann hast du immer wieder die lange Pause. Damit wirst du fast immer mehr Gesamt-Pause haben, als wenn du auf die automatische GC wartest!
    Die Laufzeit der GC hängt nämlich hauptsächlich von der Menge an String-Variablen ab, die im String-Speicher stecken, und nicht von der Menge an String-Müll!

  • Inzwischen hab ich beim Verschiebe-Puzzle die Schiebe-"Mechanik" fertig und muss mich jetzt erstmal um die Tücken von ON KEY kümmern (die Tastatursteuerung geschieht mit ON KEY, das hat so allerhand unerwartete Nebenwirkungen). Das sieht jetzt so aus (links eine Vorschau auf das Zielpuzzle, rechts ein aktueller Stand (nach 133 Zügen...):

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Maus- und Joystick-Steuerung fehlen auch noch, ebenso Benutzerhinweise (welche Tasten wofür). Und wie gesagt, die Optik am Schluss (interessantere Spielsteine, mehr Farben).

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • BLoeschen wird von Rasterschreiben aus aufgerufen. Wenn du also in BLoeschen die Prozedur Rasterschreiben aufrufst, begibst du dich in Rekursion.

    Ich kann Dir da ehrlich gesagt nicht folgen. "bloeschen" ist doch eine ganz simple Prozedur, die nur einen Teil des Bildschirms löscht und nur aus einer einzigen Zeile besteht.

    Ich verstehe nicht, wo Du da eine Rekursion siehst. Rekursion ist doch, wenn sich eine Prozedur selbst aufruft.

    Kannst Du mir das näher erläutern wo die Rekursion ist?

  • Ich verstehe nicht, wo Du da eine Rekursion siehst. Rekursion ist doch, wenn sich eine Prozedur selbst aufruft.

    Rekursion kann auch so aussehen: A ruft B auf, und B ruft wiederum A auf. Das ist sozusagen eine "indirekte" Rekursion (und für den Stack genauso tödlich). Das scheint laut Arndt hier der Fall zu sein.

    Da ich den Überblick verloren habe: Wo kann man deinen Quelltext finden, damit man mal selber reinschauen kann?