Kleine BASIC-Compo fuer zwischendurch: Draw The Frog

  • Bin mal wieder etwas viel zu spät
    Aber von mir alles nachträgel alles Gute zum Burzeltag " ZeHa " :winke:

    Jetzt bin ich richtig gespannt auf die kurzen Basic-Versionen.
    Bei mir lag es ja so bei etwas über 900 Byte. Habe wohl zu etwas zu viel von den Dim Befehl verwendet. Dafür ist es ein sauberes Basiclisting. :D
    Gruß

    :D :D Ich liebe den Sound vom C64ér :thumbsup: :thumbsup: :thumbsup:
  • Neu

    So, habe jetzt mal alles zusammengesammelt. Ich hoffe ihr nehmt es mir nicht uebel dass ich jetzt erstmal das ZIP mit allen Beitraegen poste (Link am Ende des Posts), dann koennt ihr schonmal drin rumgucken und euch die Loesungen anschauen. Ich selbst muss das aber auch noch machen, da ich in den letzten Tagen nicht mehr dazu gekommen bin, mir einzelne Beitraege anzuschauen. Es sind einfach sau-viele Einsendungen (insgesamt 27 User, von einigen mehrfache Varianten), damit habe ich wirklich nicht im entferntesten gerechnet! An dieser Stelle erstmal vielen Dank fuer die rege Teilnahme :thumbsup:

    Aber jetzt muss ich mir die auch erst nochmal alle durchschauen und am Ende bewerte ich sie dann. Den kuerzesten Beitrag zu finden duerfte dabei nicht so sehr das Problem sein, da man sich an der Dateigroesse orientieren kann, aber ich werde trotzdem noch im Detail schauen, denn es sind z.B. Loesungen dabei, die am Ende noch einen Error ausgeben, oder es sind Loesungen dabei, wo der BASIC-Code wirklich nicht mehr sauber lesbar oder eintippbar ist. Daher werde ich die kuerzteste Loesung vermutlich 2x praemieren, einmal die kuerzeste "saubere" Loesung und einmal die kuerzeste "dreckige" Loesung :)

    Den schoensten Beitrag bewerte ich nach meinem eigenen Geschmack. Da gibt es momentan einen Favoriten, allerdings habe ich wie gesagt die letzten paar Einsendungen zum Teil noch nicht anschauen koennen. Daher weiss man nie, was noch kommt :) Falls mir zwei Beitraege gleich gut gefallen sollten bzw. ich mich nicht entscheiden kann, werde ich auch evtl. hier 2 Plaetze vergeben.

    Die Gewinner werden uebrigens entweder eine Frosch-Tasche oder ein Frosch-Mauspad bekommen, das darf sich dann jeder Gewinner selbst aussuchen :)


    Also nochmals vielen Dank fuer die Einsendungen und jetzt erstmal viel Spass beim Durchschauen des ZIP-Files, meine Bewertung folgt vermutlich im Laufe des Tages oder heute abend, spaetestens morgen :)
    drwuro.com/zeha/frogs-basic-compo.zip

    EDIT: Auch hier nochmal die Bitte: vermisst jemand seine Einsendung im ZIP, bitte bescheid geben!
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • Neu

    @ZeHa: Prima, danke für deine tolle Idee und die Umsetzung der Compo!
    Und natürlich alles Gute (nachträglich) zum Geburtstag!

    Noch zur Erklärung meine Versionen (Wayne's interessiert ;) ...):
    • "drawthefrog 175.prg" - 175 Bytes (177 auf Diskette mit Ladeadresse) - abtippbares BASIC V2; läuft auch unter BASIC 3.5 und 7.0 (außer Konkurrenz).
      Die 76 gespeicherten Bytes im String sind die Längen der farbigen Abschnitte (untere 4 Bits) und die entsprechende Farbe (Bit 4+5).
    • "drawthefrog 156+.prg" - 156 Bytes (158 auf Diskette mit Ladeadresse) - abtippbares BASIC V2; läuft nicht unter BASIC 3.5 und 7.0.
      Die 76 Bytes sind hier in eine REM-Zeile gequetscht (Codierung wie oben). Die Farbe wird in 646 gePOKEt, daher nur noch am C64 lauffähig.
    • "drawthefrog 144.prg" - 144 Bytes (146 auf Diskette mit Ladeadresse) - nicht mehr abtippbares BASIC V2; kann aber normal geladen und mehrmals gestartet und auch wieder geSAVEd werden.
      Es sind 51 Bytes am Basic-Ende angehängt, die die Multicolor-"Sprite"- bzw. "Bitmap"-Daten der 24x17 Pixel repräsentieren; allerdings quasi in "Little-Endian" (= umgekehrter) Reihenfolge und aus zwei BASIC-Zeilen wurde künstlich eine gemacht (beide Modifikationen "zu Fuß" mit SMON).
    Die anderen "Ergüsse" im Unterverzeichnis meines Verzeichnisses sind evolutionäre Zwischenschritte. Auf deutsch: überflüssig. :D
    "Steve Jobs hat User hervorgebracht, Jack Tramiel Experten."
    (Quelle unbekannt)
  • Neu

    Danke ZeHa für diese spontane und schöne Compo - und sorry sowohl an Dich, als auch an die interessierten anderen User, weil ich Euch mit so vielen verschiedenen Versionen belästigt habe, die sich teilweise nur um ein Byte unterscheiden (und jetzt den YPS-Ordner im ZIP zumüllen).

    Interessant davon sind wahrscheinlich nur zwei Versionen:

    ypsfrog_dirty.prg
    (Dateigröße 131 Bytes) "dreckige" Lösung in einer einzelnen überlangen Zeile, endet mit Fehlermeldung (hat so noch ein Byte gespart ;)

    ypsfrog_purebasic2.prg
    (Dateigröße 169 Bytes) saubere Lösung (keine überlangen Zeilen, abtippbar)

    Das Durchsehen der verschiedenen Lösungen aller Teilnehmer war sehr interessant und auch inspirierend für mich - habe so auch gleich noch Verbesserungsmöglicheiten für meine Lösungen entdeckt.
    Also auch von mir vielen Dank für Eure Teilnahme!
  • Neu

    Meine Lösung "frosch-rnd3.prg" (199 Byte) war vor allem das Ergebnis von viel CPU-Zeit - wie vorher schon angedeutet, wird der Frosch aus den Ergebnissen von RND generiert:

    (editierte Version für bessere Lesbarkeit)

    Quellcode

    1. 1 read d, o : s=s+d : x=rnd(-s)
    2. 2 for x=-o to 20
    3. 3 poke646,rnd(1)*4
    4. 4 print left$("{rvon} ", (x>0)*-3);
    5. 5 next : goto 1
    6. 6 data 46083,83,41692,82,-61,279,,279,240046,85,87223,,,,,,874151,7,1226371,,,,170037,21,69018,8,335769,53,62267,9,7451,67,-778,395


    Die DATA-Zeilen spezifizieren jeweils paarweise den RND-Seed und die Anzahl der zu verwerfenden Ergebnisse nach dem Seed, die benötigt werden um eine Zeile des Frosches zu erzeugen. Um die doppelten Zeilen platzeffizienter codieren zu können, wird der Seed nicht direkt angegeben, sondern als Differenz zum vorherigen Seed. Die LEFT$-Anweisung im PRINT in Zeile 4 sorgt dafür, dass erst eine Ausgabe erfolgt, wenn genug Zahlen verworfen wurden.

    Die Seed-Suche erfordert etwas mehr Rechenaufwand - für Kleinkram wie in meiner Signatur habe ich das jeweils mit einem handgeschriebenen Programm erledigt, in diesem Fall wollte ich aber kein Dutzend Suchprogramme erstellen lassen. Stattdessen habe ich eine Textdatei erstellen lassen, die die ersten 10000 Ergebnisse von INT(RND(1)*4) mit unterschiedlichen Seeds auflistet:

    Quellcode

    1. 10 forr=1to3276700:a=rnd(-r)
    2. 15 print"===";r;"==="
    3. 20 forj=1to10000:c=int(rnd(1)*4)
    4. 30 printc;
    5. 40 next
    6. 50 print
    7. 60 next


    Damit waren dann schonmal die ersten 40 Stunden CPU-Zeit (ein Core eines 3.2GHz-Haswell-Xeons) verbraten. =) Der Grund für die Wahl von 4 als Faktor bei RND sollte klar sein, der Frosch besteht nur aus vier unterschiedlichen Farben. Man könnte jetzt auf die Idee kommen, mehr als ein Frosch-Pixel in einem RND-Ergebnis zu codieren, aber das würde das Programm nur vergrössern - zum einen braucht es dann noch etwas Code, um die Pixel wieder zu "entpacken", zum anderen reduziert es die Anzahl der nutzbaren Treffer in der RND-Ausgabe.

    Für jede Frosch-Zeile gibt es in meinem Datensatz mehr als einen Treffer - man könnte jetzt natürlich naiv immer das Paar auswählen, bei dem Seed und Offset zusammen die kürzeste Stringlänge erreichen, aber das wäre wegen der Seed-Differenz-Darstellung nicht optimal: Wenn man für eine frühe Zeile mehr Zeichen für die Differenz "investiert", kann man möglicherweise später durch kleinere Differenzen mehr Platz einsparen. Die Wahl der Zahlenpaare für jede Zeile wurde daher nochmal mit einem anderen Tool optimiert, welches zunächst per Greedy-Auswahl (immer die kürzeste Variante) eine 131 Byte lange Lösung erstellt und die dann durch randomisierte Änderungen gefolgt von erneuter Greedy-Optimierung weiter kürzt, was am Ende zu mehreren 125-Byte-Lösungen führte, von denen eine oben im Programm steht. Ich habe keine Ahnung, ob nicht doch noch eine kürzere Möglichkeit existiert, aber zumindest hat mein Suchtool trotz diverser Versuche keine gefunden.

    Ich hatte auch noch eine kürzere Lösung mit einem Ansatz, der den Frosch mit 6 Bit pro Zeichen in einen String codiert, aber die fand ich zu langweilig.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Neu

    Hi

    Habe mir jetzt so ziemlich alle Programme angeschaut. Mein persönlicher Favorit in Sachen Froschaufbau ist das Programm von EgonOlsen71. Ist echt klasse was man mit Basic alles machen kann.
    Apropo machen kann. Kann mir ein hier erklären was die ganzen Zahlen, Buchstaben, Zeichen in den Strings bewirken. Klar sie zeichnen den Frosch, ist mir schon klar. Aber warum gerate dann die Zahlen.
    z.B das von Hexworx

    Quellcode

    1. A$="610015510016"
    2. B$="555555555555"

    Ist vielleich ein blöde Frage, aber so tief bewege ich mich nicht im Basic. Mir haben immer die normalen Befehlen gelangt. Und ich würde es gerne wissen, damit ich in der nächsten Basic Compo kürzere Programme schreiben kann :D
    :D :D Ich liebe den Sound vom C64ér :thumbsup: :thumbsup: :thumbsup:
  • Neu

    Es sind wirklich interessante Lösungen dabei. Schön, dass so viele mitgemacht haben.

    Leider bin ich nach meiner ersten Version etwas abgestorben und hatte keine Zeit (trotz Ideen) noch etwas weiteres abzugeben. Aber an die besten Ergebnisse wäre ich eh nicht rangekommen :D

    @ZeHa: nachträglichen Glückwunsch noch zum Geburtstag!
    ______________________________________________
    Wenn ich posten will, werde ich Briefträger...
  • Neu

    @Drachen: keine blöde Frage.

    Schau dir mal F$ (nach der Ausführung) an, dann wirst du es sehen. Da steht der ganze Frosch drinne incl. Farben, die in 646 gepoked werden (hab ich auch so gemacht). In diesem Fall verbrät er natürlich recht viel für die Froschdaten.

    F$ ist auch genau 214 Bytes lang, was exakt die 'Froschgrösse' ist

    Gruß, Gerd

    PS: mich wundert, dass BIF nix eingereicht hat :lol33:
    Wer andern eine Bratwurst brät braucht ein Bratwurstbratgerät.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von ADAC ()

  • Neu

    Das liegt im wesentlichen daran, dass einige User die Daten in Form von "echten" Bytes abgelegt haben, und nicht z.B. in Form von DATA-Zeilen oder Strings. Hierbei kommt aber nun das C64-BASIC ins Stolpern, wenn er den Code auflisten soll, der ja dann an diesen Stellen kein gueltiger BASIC-Code ist. Ist aber an sich vom Ansatz her okay, es ging ja nur drum, dass das Programm selbst ein BASIC-Programm ist, welches vom BASIC-Interpreter abgespielt wird, und kein verstecktes Maschinensprache-Programm.
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • Neu

    Hey, da muß ich ja auch mal hallo sagen.
    Ich hatte mich vor vielen Monden hier angemeldet, weil ich irgendwo einen Anhang gesehen hatte den ich im Emulator mal ausprobieren wollte (glaube ich). Da ich zZ Krank geschrieben bin (Achillessehne gerissen) kommt man auf so Sachen wie einmal bei einer kleinen Basic compo mitmachen. Grundsätzlich hab ich in Richtung C64 absolut keinen Plan, aber es kam zumindest n Frosch bei raus. Was ihr aus ein paar zahlen alles herausholt ist echt erstaunlich! Und wie bei den meisten überhaupt ein Frosch herauskommen kann ist für mich zZ noch rätselhaft.

    Anbei noch alles Gute zum Geburtstag an ZeHa (33, fast noch n Teen)

    Gruß Rudi
  • Neu

    Also schön sind sie alle ;) Und einige haben auch schöne Gimmicks. Gewonnen hat auf jeden Fall ZeHa - so viele Frösche zum Geburtstag. Und dann teilt er sie auch noch mit uns :thumbup:

    ADAC schrieb:

    ...
    PS: mich wundert, dass BIF nix eingereicht hat :lol33:
    Vermutlich hat sich sein Frosch zwischen RAM und ROM verklemmt. Sowas kann passieren, wenn die Sortierung versagt :D
    Wissen ist das einzige Gut, das sich beim Teilen vermehrt. Also seid vorsichtig damit!
  • Neu

    Plus4Punk schrieb:

    Warum werfen manche Programme bei LIST nur unverständlichen Müll raus!?

    ZeHa schrieb:

    Das liegt im wesentlichen daran, dass einige User die Daten in Form von "echten" Bytes abgelegt haben, und nicht z.B. in Form von DATA-Zeilen oder Strings. Hierbei kommt aber nun das C64-BASIC ins Stolpern, wenn er den Code auflisten soll, der ja dann an diesen Stellen kein gueltiger BASIC-Code ist.
    Der Vollständigkeit halber: LIST-Probleme können auch auftreten, obwohl die Daten "gültig" in einem String codiert sind, das passiert z.B. bei meinem Entry. Man kann das Programm bzw. den String darin nicht in dieser Form eingeben, aber im Speicher ist das ein völlig konformes Basic-Programm: Die einzigen in einem String wirklich verbotenen Zeichen sind ja Anführungszeichen (die würden das Ende des Strings markieren) und Nullbytes (ein solches würde gleich das Ende der ganzen Zeile markieren).
    Einige Sonderzeichen wie z.B. Cursorbewegungen, HOME oder CLEAR kann man ja dank des Quote-Modus trotzdem direkt in einem String angeben. Andere Zeichen wie z.B. RETURN kann man zwar nicht direkt eingeben - aber wenn man sie trotzdem, z.B. durch POKEs, irgendwie in den String bekommt, passiert beim LISTen dies:
    LIST zeigt den String an und gibt das erste Anführungszeichen aus. Damit wird der Quote-Modus des Bildschirmtreibers aktiv, so dass z.B. folgende CLEARs als reverse Herzen erscheinen.
    ...nun steht da aber so ein RETURN-Zeichen im String. LIST gibt es aus. Dadurch wird aber der Quote-Modus deaktiviert! Wenn nun wieder ein CLEAR-Code folgt, wird er normal ausgegeben und es wird der Bildschirm gelöscht. Bei Änderungen der Textfarbe, Cursorbewegungen etc. passiert das auch, die Codes werden ausgeführt.
    Yes, I'm the guy responsible for the ACME cross assembler
  • Neu

    CommieSurfer schrieb:

    Ich bin im übrigen nicht dazu gekommen, .. Aber vlt. programmiere ich meine ursprüngliche Version bzw. Idee mind. für mich selber später irgendwann nochmal.., ohne irgendwo etwas hier abgeguckt zu haben.
    Meine Idee wäre btw. gewesen einfach in einer Datazeile die Start- und Endwerte für jede zu zeichnende Spalte des Frosches anzugeben. Da braucht man dann meistens fast nur zwei Datawerte je Spalte, manchmal auch vier oder sechs wenn leere Lücken (wie zwischen dem Körper und Füßen z.B.) in der jeweiligen Spalte vorhanden sind. Per nur einer For..Next Schleife im Prg das ganze dann Spalte für Spalte zeichnen lassen, mit einem (stink normalen / bekannten) Pokebefehl für den Bildschirmspeicher in der Mitte der Schleife. U. diversen Variablen für Spalte,.. natürlich noch.
    Spalte für Spalte und nicht Zeile für Zeile deswegen, weil Zeile für Zeile mehr leere Lücken (zwischen beiden Augen, und am Fuß pixelweise) vorhanden wären und ich somit mehr Datawerte benötigen würde.
    --
    Da macht mir fast das vermeintl. simpelste, das Zuweisen der weißen Augenfarbe und der schwarzen Pupille, noch die meisten "Sorgen", um da nicht unnötig viel Befehlskram ('Speicherplatz') nur wegen der anderen Farben des Auges zu verbraten.
    Wobei ich das (Farbwerte) auch in der einen Datazeile mit drinne dem Prg. mitteilen könnte, die würde dann halt leider ein paar Zahlen länger als vorgenommen ausfallen.
    ' war Anfang 2000 schonmal unter dem Kennnamen 'c64fan' hier unterwegs.
  • Neu

    Mac Bacon schrieb:

    LIST-Probleme können auch auftreten, obwohl die Daten "gültig" in einem String codiert sind
    Ich kann mich noch daran erinnern das es früher diesen "LIST Schutz" gab.
    Erste Zeile im Basic Program hiess dann REM {Shift}+L
    Der Spezialist ist ein Barbar, dessen Unwissenheit nicht allumfassend ist.
    Stanislav Lem 1995

    Ewig laufende Projekte ;) Click
  • Benutzer online 2

    2 Besucher