ASM-Compo #6: Ideensammlung


  • syshack
  • 5501 Views 135 replies

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Sokrates wrote:

    Wie wäre es mit dem Thema Schiffe versenken?

    syshack wrote:

    Scheint mir aber auch komplex zu sein.
    Nicht wirklich. Am Ende dürfte es auf einen Algorithmus hinauslaufen wie in etwa

    Source Code

    1. TYPE
    2. t_feldtyp = ( WASSER,
    3. SCHIFF );
    4. VAR
    5. feld : ARRAY [0 .. 39, 0 .. 24] OF t_feldtyp;
    6. {========================================
    7. FUNKTION testen
    8. teste, ob ein Schiffteil vorhanden ist
    9. x = X-Koordinate
    10. y = Y-Koordinate
    11. ==> false = kein Schiffteil
    12. true = Schiff gefunden
    13. ========================================}
    14. FUNCTION testen(x, y : INTEGER) : BOOLEAN;
    15. BEGIN
    16. IF x < 0 THEN
    17. return false
    18. END;
    19. IF x > 39 THEN
    20. return false
    21. END;
    22. IF y < 0 THEN
    23. return false
    24. END;
    25. IF y > 24 THEN
    26. return false
    27. END;
    28. IF feld[x, y] = SCHIFF THEN
    29. return true
    30. END;
    31. return false
    32. END testen;
    33. {========================================
    34. FUNKTION prüfen
    35. teste, ob der Aufbau regelkonform ist
    36. ==> false = alles okay
    37. true = Fehler
    38. ========================================}
    39. FUNCTION prüfen : BOOLEAN;
    40. LABEL
    41. fehler;
    42. VAR
    43. x : INTEGER;
    44. y : INTEGER;
    45. y2 : INTEGER;
    46. länge : INTEGER;
    47. anzahl : ARRAY [0 .. 3] OF INTEGER;
    48. BEGIN
    49. anzahl[0] := 0; // U-Boote
    50. anzahl[1] := 0; // Zerstörer
    51. anzahl[2] := 0; // Kreuzer
    52. anzahl[3] := 0; // Schlachtschiff
    53. y := 0;
    54. x := 0;
    55. LOOP
    56. IF testen(x, y) THEN // Schiff vorhanden?
    57. IF NOT testen(x, y - 1) THEN // ignorieren, wenn oben bereits ein Schiffsteil ist
    58. länge := 0; // Schiffslänge auf 0 setzen
    59. IF testen(x + 1, y) THEN // waagerechtes Schiff
    60. REPEAT
    61. IF testen(x - 1, y - 1) THEN // teste die drei unteren Felder
    62. goto fehler
    63. END;
    64. IF testen(x, y - 1) THEN
    65. goto fehler
    66. END;
    67. IF testen(x + 1, y - 1) THEN
    68. goto fehler
    69. END;
    70. länge := länge + 1;
    71. x := x + 1
    72. UNTIL NOT testen(x, y) // solange bis Wasser erreicht wird
    73. ELSE
    74. y2 := y; // Y merken
    75. REPEAT
    76. IF testen(x - 1, y - 1) THEN // teste linke und rechte Felder
    77. goto fehler
    78. END;
    79. IF testen(x - 1, y ) THEN
    80. goto fehler
    81. END;
    82. IF testen(x - 1, y + 1) THEN
    83. goto fehler
    84. END;
    85. IF testen(x + 1, y - 1) THEN
    86. goto fehler
    87. END;
    88. IF testen(x + 1, y ) THEN
    89. goto fehler
    90. END;
    91. IF testen(x + 1, y + 1) THEN
    92. goto fehler
    93. END;
    94. länge := länge + 1;
    95. y := y + 1
    96. UNTIL NOT testen(x, y);
    97. y := y2; // Y wiederherstellen
    98. END;
    99. IF (länge < 2) OR (länge > 5) THEN // Schiff zu kurz oder zu lang?
    100. goto fehler
    101. END;
    102. anzahl[länge - 2] := anzahl[länge - 2] + 1
    103. END
    104. END;
    105. x := x + 1;
    106. IF x > 39 THEN
    107. x := 0;
    108. y := y + 1;
    109. IF y > 24 THEN
    110. break
    111. END
    112. END
    113. END; // loop
    114. IF (anzahl[0] <> 4) // 4 U-Boote
    115. OR (anzahl[1] <> 3) // 3 Zerstörer
    116. OR (anzahl[2] <> 2) // 2 Kreuzer
    117. OR (anzahl[3] <> 1) THEN // 1 Schlachtschiff
    118. meldung('Ups... Fehler in der Anzahl der Schiffe');
    119. return true
    120. END;
    121. return false; // alles in Ordnung
    122. fehler:
    123. meldung('Ups... Fehler in der Aufstellung');
    124. return true
    125. END prüfen;
    Display All

    enthusi wrote:

    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).

    daybyter wrote:

    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"?
  • M. J. wrote:

    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.
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki
  • syshack wrote:

    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 :)
    Sokrates - das F steht für Philosoph!
  • Aus der CBM3032-Asm-Compo 1:

    Mac Bacon wrote:

    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".
    Yes, I'm the guy responsible for the ACME cross assembler
  • peiselulli wrote:

    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 ...
  • GuNKeN wrote:

    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.
    - neue Spiele für den C64 -
    shotgun.drwuro.comfrogs.drwuro.comshadow.drwuro.com
  • syshack wrote:

    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.
  • Oder den besten Text-Screen-Dissolver. So manche Demos hatten da ja auch nette Ideen wie nach dem Start vom Textscreen zur Demo übergegangen wurde.
    "Sometimes I pretend to be normal, but it gets boring. So I go back to being me."
  • Tale-X wrote:

    Sokrates wrote:

    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 ;)
    Stimmt. Sowas kann leicht zu irreversiblen Verwirrungszuständen führen. :D
  • Tags