noch ne frage muessen die sprites angezeigt werden?
Hallo Besucher, der Thread wurde 61k mal aufgerufen und enthält 482 Antworten
letzter Beitrag von Haubitze am
Neue C64 ASM/Basic Compo : Dreh' das Sprite.
- peiselulli
- Erledigt
-
-
Nein, die Sprites müssen nicht angezeigt werden.
Und sorry, ja 2017 ... GRRRR.Die 10 Minuten Begrenzung habe ich eingeführt, damit nicht irgendwelche Lösungen wie "ist superkurz, läuft aber 3 Tage" abegeben werden.
Nach 10 Minuten muss das Programm wieder im "ready" sein und die Daten dann korrekt rotiert.Ich werde dann danach mit einem "sys" ein vorher geladenes Programm starten, was die Korrektheit der Rotation überprüft.
-
Ich habe das mal versucht, grafisch etwas klarer darzustellen.
Hoffe, dass ich keinen Fehler gemacht habe.
Excel File liegt bei. -
Naja, stimmt FAST. Bei dem Linken Bild (Ausgangsbild) können im rosa Bereich Schmuddel-Pixel sein. Beim rechten Bild (Ausgabe) jedoch nicht.
-
Naja, stimmt FAST. Bei dem Linken Bild (Ausgangsbild) können im rosa Bereich Schmuddel-Pixel sein. Beim rechten Bild (Ausgabe) jedoch nicht.
Danke für den Hinweis. Ich habe es hier korrigiert:
-
Yay, endlich eine neue Compo!
Die derzeitige Aufgabenstellung verbietet übrigens nicht die Zerstörung des Original-Spritemusters in Block 13. Nur, damit alle von gleichen Voraussetzungen ausgehen...EDIT: Nach Regeländerung hinfällig.
-
Darf man das Programm auch in C schreiben? Oder ist nur Assembler bzw BASIC erlaubt?
-
Die Sprache spielt ja keine Rolle, aber es ging um das kuerzeste.
-
- Das Programm darf keine Adresse größer $c000 schreibend benutzen.
<Korinthenkacker>
Müsste wohl heissen:
- Das Programm darf keine Adresse größer $bfff schreibend benutzenSonst könnte Deine Prüfroutine im ersten Byte vermurxt werden.
Darf man das Programm auch in C schreiben? Oder ist nur Assembler bzw BASIC erlaubt?
Ich hab's auch so verstanden, dass nur die Anzahl Bytes des Programmes zählen wird ab $0801.
Heisst: Solange man keine Runtime benötigt, kannst Du es auch in COMAL oder Pascal proggen -
Ja müsste auf >$bfff geändert werden.
ZitatDie derzeitige Aufgabenstellung verbietet übrigens nicht die Zerstörung des Original-Spritemusters in Block 13. Nur, damit alle von gleichen Voraussetzungen ausgehen...
Wenn jemand das für mich noch korrigieren würde, würde ich gerne noch einen Punkt einfügen:
- Spriteblock 13 muß erhalten bleiben.Kann das jemand in den initialen Post einbauen ?
-
Ja müsste auf >$bfff geändert werden.
Wenn jemand das für mich noch korrigieren würde, würde ich gerne noch einen Punkt einfügen:- Spriteblock 13 muß erhalten bleiben.
Kann das jemand in den initialen Post einbauen ?
Habe den Punkt eingefügt und den Punkt mit >c000 korrigiert >bfff.
-
Besten Dank !
-
Darf man sich auf genullte Register und einen genullten Spriteblock 14, wie nach einem Reset, verlassen? Oder muss das Programm auch für andere Maschinenzustände funktionieren?
Ich hoffe letzteres... -
Spriteblock 14 soll unbestimmt sein. So dass man ein neues Sprite in den Block 13 kopiert und das Programm einfach nochmal laufen lässt.
Muss dann wohl auch noch ins Regelwerk rein ...
- Daten im Spriteblock 14 sind vor dem Anstarten des Programmes als zufällig zu betrachten.
-
DABEI !!!
-
Kaum angefangen - schon sieben Bytes gespart
-
Wie bekommen man eigenlich die Größe eines Programms raus? z.B ein Basic Programm, wenn es im Speicher liegt?
-
z. B. PRINT FRE(0)+26627
-
Ja, denn mein Prüfcode wird benutzt werden, ob die Lösung bei einem von mir gewähltem sprite korrekt ist. Sonst könnte man ja einfach den sprite einmal "von Hand" drehen und dann die 63 Bytes einfach nach $0380 kopieren.
Nur damit auch ich die Aufgabe richtig versteh...
Das wären die Ausgangsdaten...
a,b,c,d
e,f,g,h
i,j,k,l
m,n,o,p
q,r,s,t
u,v,w,x
und das hier das Ergebnis.d,h,l,p,x
c,g,k,o,w
b,f,j,n,v
a,e,i,m,u -
Programmstart ist immer $0801 (wenn man nich dran rumgefummelt hat). Programmende ligt in $2D/$2E (Low-/High-Byte), mit der Differenz hast die Programmgröße.
Gruß, Gerd