Hello, Guest the thread was called6.5k times and contains 135 replays

last post from detlef at the

ASM-Compo #6: Ideensammlung

  • Wie wäre es mit dem Thema Schiffe versenken?

    Scheint mir aber auch komplex zu sein.

    Nicht wirklich. Am Ende dürfte es auf einen Algorithmus hinauslaufen wie in etwa

    Ausserdem bietet sich eine Kategorie 'klein' und eine 'schnell' unmittelbar an

    Das ist das grundlegende Problem bei der Aufgabenstellung: Die Bedingungen "klein" und "schnell" widersprechen sich zumeist heftig. Dabei ist die Bedingung "klein" eher akademischer, weil kaum praxisrelevanter Natur, wohingegen sich in "schnell" der Nutzen der Assemblerprogrammierung widerspiegelt. Beides unter einen Hut zu bringen, dürfte schwierig werden. Im Falle der Programmierung von Graphikroutinen würde ich jedenfalls bevorzugt in die Richtung "schnell" gehen. Hier könnte es sich vielleicht anbieten, andere Bedingungen zu stellen, z. B. das Programm darf (neben dem Bildschirmspeicher) nur den Speicher zwischen $c000 und $cfff belegen (inklusive Tabellen).

    Wie wäre es, wenn eine ganz minimale CPU (mit 2 oder 3 Befehlen) vorgegeben wird, und man muss einen Emulator dafür schreiben?

    An sowas hatte ich auch schon gedacht. Dabei könnten es aber ruhig ein paar Befehle mehr sein. In dem Thread zu virtuellen Maschinen auf dem C64 wurde diesbezüglich einiges vorgestellt wie z. B. Sweet16.


    Die Frage wäre: Wie umfangreich darf eine Programmieraufgabe generell sein? Soll es sich "nur" auf einen Algorithmus beziehen (Sprite drehen, Text komprimieren, Kreis zeichnen) oder darf es auch eine größere Herausforderung sein wie "Textadventure in 3,5 kb"?

  • Die Frage wäre: Wie umfangreich darf eine Programmieraufgabe generell sein? Soll es sich "nur" auf einen Algorithmus beziehen (Sprite drehen, Text komprimieren, Kreis zeichnen) oder darf es auch eine größere Herausforderung sein wie "Textadventure in 3,5 kb"?

    Da möchte ich aber einbringen, dass die "Tradition" dieser ASM-Compos eben überschaubare Häppchen waren, so quasi für zwischendurch den "grossen" Compos wie Spiele Compos.
    Ein "Textadventure in 3.5" wäre sicherlich interessant als spezielle Spiele-Compo, aber ich glaube weniger in dieser "ASM Compo" Serie.

  • Da möchte ich aber einbringen, dass die "Tradition" dieser ASM-Compos eben überschaubare Häppchen waren

    Kein Problem, denn die Frage ist ja nur "Wie groß dürfen diese Häppchen maximal sein?" Eine Graphikbibliothek für Blockgraphik wäre sicherlich ebenso zu groß. Aber selbst bei der Aufgabe "Male einen Kreis und einen ausgefüllten Kreis" handelt es sich de facto schon um zwei Aufgaben, da die Routinen hierfür getrennt geschrieben werden müssen. (Beim Füllen von Kreisen wird der Randpunkt nicht sieben Mal gespiegelt. Außerdem muß eine Routine zum Ziehen von waagerechten Linien ergänzt werden.)

  • Wie wäre es mit einem praxisnäheren Problem: Kollisionserkennung zweier Sprites. Sind Objekte zu schnell kann es passieren, dass sie sich in der Anzeige auf dem Bildschirm nicht überschneiden. Das kann also in Hardware nicht detektiert werden und muss in Software gerechnet werden.


    Nachteil: Enthusi hätte aus aktuellem Anlaß da evtl. einen Vorteil :-)

  • Aus der CBM3032-Asm-Compo 1:

    Falls das Beibehalten der "clean screen"-Aufgabe keine Zustimmung findet, würde ich "Überblende zwischen zwei Screens" vorschlagen

    Wie wäre es mit "Überblende zwischen zwei Koala-Bildern"?
    Statt Codegröße/Laufzeit müsste man den Gewinner dann wieder per Voting ermitteln, aber dafür könnte man zum Schluss dann sämtliche Entries zusammenlinken und hintereinander "abspielen".

  • Fleißiger Bieber mit graphischer Ausgabe? Das dürfte bei 5 Zuständen für bekannte Lösungen schon ein paar Minuten dauern.

    Ich befürchte, die Teilnehmer werden mit dieser Aufgabenstellung in Zustände gestürzt, die länger andauern ;)

  • zwei 32 Bit Zahlen (oder größer) möglichst schnell miteinander multiplizieren oder sowas ...


    Da fiele mir eher das Multiplizieren von richtig großen Ganzzahlen ein. Z.B. mit fester Stellenanzahl 256 oder mehr Stellen (Eingabe liegt beispielsweise im ASCII-Format vor).
    Auch hier bietet sich eine außer der der Konkurrenz eine BASIC-Fraktion an ...

  • Idee: Ein Pong Spiel ohne Sprites, aber mit Joystick Steuerung für 2 Spieler ;-)

    Wenn man sowas machen wuerde, waere ich dafuer, dass man das loesen darf wie man will - also mit oder ohne Sprites. Und es zaehlt das kuerzeste Programm. Aber auch das ist natuerlich ein wenig was anderes als das wofuer die ASM-Compo wohl eigentlich gedacht ist. Waere aber fuer mein Empfinden noch ok/passend.

  • Ich weiss ja nicht wie praktikabel das ist, auch von der Komplexität, aber ich habe noch nichts gelesen in Sachen Diskettenlaufwerk.
    z.B. ein festgelegtes Directory neu sortieren.

    Solche Sachen erfordern aber sehr viel Spezialwissen, das eigenlich mit Assembler nichts zu tun hat.
    Die Aufgabenstellung könnte man genauso gut in einer Basic-Combo machen. Und wäre vermutlich kaum langsamer.