Also quasi 'runde'-Fenster
Hallo Besucher, der Thread wurde 21k mal aufgerufen und enthält 135 Antworten
letzter Beitrag von detlef am
ASM-Compo #6: Ideensammlung
- syshack
- Erledigt
-
-
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. -
Weitere Ideen
- Sortieren
- Suchen und ersetzen
- Zählen und zusammenfassen (wieviel wo von ist da drin und was ergibt das zusammengerechnet)
Edit
- Flood fill (der Vorschlag kam schon in Zsh. mit Kreis)
-
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
Code- TYPE
- t_feldtyp = ( WASSER,
- SCHIFF );
- VAR
- feld : ARRAY [0 .. 39, 0 .. 24] OF t_feldtyp;
- {========================================
- FUNKTION testen
- teste, ob ein Schiffteil vorhanden ist
- x = X-Koordinate
- y = Y-Koordinate
- ==> false = kein Schiffteil
- true = Schiff gefunden
- ========================================}
- FUNCTION testen(x, y : INTEGER) : BOOLEAN;
- BEGIN
- IF x < 0 THEN
- return false
- END;
- IF x > 39 THEN
- return false
- END;
- IF y < 0 THEN
- return false
- END;
- IF y > 24 THEN
- return false
- END;
- IF feld[x, y] = SCHIFF THEN
- return true
- END;
- return false
- END testen;
- {========================================
- FUNKTION prüfen
- teste, ob der Aufbau regelkonform ist
- ==> false = alles okay
- true = Fehler
- ========================================}
- FUNCTION prüfen : BOOLEAN;
- LABEL
- fehler;
- VAR
- x : INTEGER;
- y : INTEGER;
- y2 : INTEGER;
- länge : INTEGER;
- anzahl : ARRAY [0 .. 3] OF INTEGER;
- BEGIN
- anzahl[0] := 0; // U-Boote
- anzahl[1] := 0; // Zerstörer
- anzahl[2] := 0; // Kreuzer
- anzahl[3] := 0; // Schlachtschiff
- y := 0;
- x := 0;
- LOOP
- IF testen(x, y) THEN // Schiff vorhanden?
- IF NOT testen(x, y - 1) THEN // ignorieren, wenn oben bereits ein Schiffsteil ist
- länge := 0; // Schiffslänge auf 0 setzen
- IF testen(x + 1, y) THEN // waagerechtes Schiff
- REPEAT
- IF testen(x - 1, y - 1) THEN // teste die drei unteren Felder
- goto fehler
- END;
- IF testen(x, y - 1) THEN
- goto fehler
- END;
- IF testen(x + 1, y - 1) THEN
- goto fehler
- END;
- länge := länge + 1;
- x := x + 1
- UNTIL NOT testen(x, y) // solange bis Wasser erreicht wird
- ELSE
- y2 := y; // Y merken
- REPEAT
- IF testen(x - 1, y - 1) THEN // teste linke und rechte Felder
- goto fehler
- END;
- IF testen(x - 1, y ) THEN
- goto fehler
- END;
- IF testen(x - 1, y + 1) THEN
- goto fehler
- END;
- IF testen(x + 1, y - 1) THEN
- goto fehler
- END;
- IF testen(x + 1, y ) THEN
- goto fehler
- END;
- IF testen(x + 1, y + 1) THEN
- goto fehler
- END;
- länge := länge + 1;
- y := y + 1
- UNTIL NOT testen(x, y);
- y := y2; // Y wiederherstellen
- END;
- IF (länge < 2) OR (länge > 5) THEN // Schiff zu kurz oder zu lang?
- goto fehler
- END;
- anzahl[länge - 2] := anzahl[länge - 2] + 1
- END
- END;
- x := x + 1;
- IF x > 39 THEN
- x := 0;
- y := y + 1;
- IF y > 24 THEN
- break
- END
- END
- END; // loop
- IF (anzahl[0] <> 4) // 4 U-Boote
- OR (anzahl[1] <> 3) // 3 Zerstörer
- OR (anzahl[2] <> 2) // 2 Kreuzer
- OR (anzahl[3] <> 1) THEN // 1 Schlachtschiff
- meldung('Ups... Fehler in der Anzahl der Schiffe');
- return true
- END;
- return false; // alles in Ordnung
- fehler:
- meldung('Ups... Fehler in der Aufstellung');
- return true
- END prüfen;
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.)
-
Idee: Ein Pong Spiel ohne Sprites, aber mit Joystick Steuerung für 2 Spieler
-
ich schrieb ja es bietet sich eine fuer klein an und eine fuer schnell. Eben gerade nicht eine fuer beides natuerlich.
-
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". -
So?
[Externes Medium: https://www.youtube.com/watch?v=mE1T4nidrdI]Aber wie man schon in demos auch sah, geht da natuerlich noch mehr.
-
Fleißiger Bieber mit graphischer Ausgabe? Das dürfte bei 5 Zuständen für bekannte Lösungen schon ein paar Minuten dauern.
-
Ich hätte eine Compo, die es bestimmt noch nie gegeben hat:
Wer schafft es mit dem VIC als erstes das Lied "Alle meine Enten" zu realisieren?
-
zwei 32 Bit Zahlen (oder größer) möglichst schnell miteinander multiplizieren oder sowas ...
-
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. -
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.
-
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.