Endlich geht die Zeit zu Ende und ich kann die anderen Versionen sehen.
Bin auch gespannt auf die anderen Lösungen. Eine ist schon mal sicher besser als meine. Mal schauen ob da noch mehr geht.
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Haubitze am
Endlich geht die Zeit zu Ende und ich kann die anderen Versionen sehen.
Bin auch gespannt auf die anderen Lösungen. Eine ist schon mal sicher besser als meine. Mal schauen ob da noch mehr geht.
Man das ist ja wie eine Sucht, jetzt bastel ich doch an einer dritten Version. Im Kopf schiebe ich die ganze Zeit Bits und Bytes hin und her, da ich ja weiß dass es eine viel einfachere Lösung als die meine gibt. Na mal schauen ob ich vor Abgabetermin noch fertig werde.
C64 hat echtes Suchpotential, is ja schlimm.
Man das ist ja wie eine Sucht, jetzt bastel ich doch an einer dritten Version. Im Kopf schiebe ich die ganze Zeit Bits und Bytes hin und her, da ich ja weiß dass es eine viel einfachere Lösung als die meine gibt. Na mal schauen ob ich vor Abgabetermin noch fertig werde.
C64 hat echtes Suchpotential, is ja schlimm.
Kenne ich zu gut, ich habe hier irgendwann angefangen bei meinen Texten zu überlegen, ob ich das nicht kürzer hinbekomme.
Cool, dass es Dich gepackt hat!
Finde die Compo auch echt klasse. ASM war bei mir dieses mal nix, aber vielleicht nächstes mal.
Finde die Compo auch echt klasse. ASM war bei mir dieses mal nix, aber vielleicht nächstes mal.
Du hast noch >24 Stunden Zeit dafür. Ich wollte auch schon ein paar mal hinwerfen. Auch wenn ich "nur" ne Z80 Version versuche, komme ich nicht los davon.
Du hast noch >24 Stunden Zeit dafür. Ich wollte auch schon ein paar mal hinwerfen. Auch wenn ich "nur" ne Z80 Version versuche, komme ich nicht los davon.
Ach, so lange noch... na dann mach ich mich mal dran.
Und wie weit ist Deine Version? Ich sehe in Deinem Footer ja c64, aber der ist für Dich nur Ausstellungsstück oder wie?
Und wie weit ist Deine Version? Ich sehe in Deinem Footer ja c64, aber der ist für Dich nur Ausstellungsstück oder wie?
Ich mach bei der 6502 Version nicht mit. Habe schon genug mit Z80 zu tun.
Sollte ich fertig werden, dann steht das im ausgelagerten Thread zur Compo.
So, ich mach jetzt auch Schluss. Ich habe noch eine Version probiert in dem ich den Stack als Umsortierungshilfe verwenden wollte, aber habe mich dann doch total verhaspelt. Morgen habe ich leider nicht so viel Zeit. Ich bin sehr auf die anderen Lösungen gespannt.
Das war auf alle Fälle ein schöner Einstieg in 6502 Assembler für mich.
So, ich mach jetzt auch Schluss. Ich habe noch eine Version probiert in dem ich den Stack als Umsortierungshilfe verwenden wollte, aber habe mich dann doch total verhaspelt. Morgen habe ich leider nicht so viel Zeit. Ich bin sehr auf die anderen Lösungen gespannt.
Das war auf alle Fälle ein schöner Einstieg in 6502 Assembler für mich.
Du wirst dich wundern was da so alles geht wenn man nur den richtigen Grundgedanken hat.
Ich habe nach über 25 Jahren mich wieder mal mit dem C64 und Assembler versucht und bin auch bei meiner ersten Lösung geblieben. Egal ob ich Gewinne, es war geil wieder mal an die Zeit damals zurückzudenken.
Und wer weiss, ich habe mich VICE + TurboAss besorgt und es hat richtig Spaß gemacht. Mal sehen was die nächste Compo bringt
Ich bin auch neugierig wie die Profis das hier gelöst haben. Damals in den 80er wollte ich auch Assembler am C64 lernen, aber mehr als ein bissle Basic ist es dann doch nicht geworden. Jetzt gebe ich aber nicht so schnell auf wie früher.
Hab' grad auch noch schnell was abgegeben .
Für's Treppchen reicht's sicher nicht. Hoffe ich hab' nicht noch was übersehen und werde sogar disqualifiziert .
Egal .
So, hier die eingereichten Beiträge der Größe nach ...
43 /Acorn/68k-coder.prg
45 /m.j./Compo.prg
47 /thomasjentsch/thomasjentzsch3.prg
47 /MacBacon/mb7-64.prg
47 /Merlin/rota-spr(brk)mln.prg
49 /yps/drehdassprite_yps.prg
49 /mafiosino/sprite2.prg
50 /JeeK/sda-1.prg
52 /ssda/drehsprite-ssdsa-asm-20170205.prg
53 /Hoogo/Sprite_drehen.prg
54 /Gold_Breaver/cssprrot.prg
56 /TheRealWanderer/SpriteRot8.prg
57 /td1334/compo44.prg
58 /kbr/sprite13.prg
63 /alx/rot-sprite-alx-v4.prg
63 /lvr/spriterot-lvr.prg
73 /Haubitze/asm-combo-rolror.prg
89 /Endurion/rotate.prg
91 /ssda/drehsprite-ssdsa-basic-20170203.prg
95 /JeeK/sd-basic-3.prg
97 /Chagizz/dds-chagizzz.prg
99 /Tale-X/drehsprite5.prg
165 /phasengleich/phasengleich2.prg
366 /ByteBreaker/bbdreh2.prg
Und hier die Programme dazu, alle zusammengepackt:
drehsprite.zip
Damit :
1. Platz Acorn (tätä !!!) mit 43 Bytes
2. Platz M.J. mit 45 Bytes
3. Platz Thomas Jentsch (aka thrust2600), da das Programm im Gegensatz zu den beiden anderen 47er Lösungen mit RTS statt BRK beeendet wird.
Beste reine Basic Lösung : ssda mit 91 Bytes
43! Wow! Will sehen!
Wow, 91 Byte Länge (89 Byte in Basic). Kaum zu glauben
Herzlichen Glückwunsch an Acorn und vielen Dank an Peiselulli für die Ausrichtung dieser ASM-Compo!
Hätte ich eine Sprite-Dreh Routine für ein Demo oder Spiel benötigt, hätte ich wahrscheinlich die erste funktionierende Lösung verwendet und keine weitere Zeit in eine Optimierung in Laufzeit oder Code-Größe vorgenommen (es sei denn, es wäre irgendwie nötig gewesen).
Aber es hat mir viel Spaß gemacht, verschiedene Ansätze auszuprobieren und die Code-Größe immer weiter zu reduzieren.
Ich freue mich auch schon auf die Lösungen der anderen Teilnehmer - mal schauen, welche Wege Ihr so beschritten habt und was ich daraus lernen kann.
Hier nun mein Beitrag mit Erläuterung, extra ausführlich und hoffentlich für alle verständlich:
Grundsätzliche Herangehensweise: Sprite 1 wird Zeilenweise von oben links nach unten rechts auf die Spalten von Sprite 2 übertragen (von links unten nach rechts oben).
Die gelesenen Bits einer Zeile werden dabei als Spalte grundsätzlich vom rechten(!) Rand in das Zielsprite reinge-"shiftet" - und zwar über die gesamte Sprite-Breite, also über 3 Bytes. Wenn dann 24 (Spalten) mal 21 (Zeilen) Bits reingeschoben wurden, liegt die zuerst reingeschobene Spalte dann am linken Rand und auch alle anderen Bits da, wo sie hin sollen.
Meine Lösung nutzt keine Selbstmodifikation, keine Illegalen Opcodes - und es kann auch (auf Kosten von 1 Byte) auf Zeropageadressen verzichtet werden. Das Programm ist beliebig im Speicher verschiebbar und immer wieder erneut aufrufbar, (ev. müssen A und Y initialisiert sein).
Sprite 1 wird während des Drehens nicht verändert. Da das Auslesen zeilenweise erfolgt, reicht ein LDA für 8 Bits. Mittels ROL gelangen die Bits dann ins Carry-Flag und von da aus über drei ROLs in die jeweilige Zielzeile von Sprite 2. Nach 8 Bits muss zum nächsten Byte von Sprite 1 gewechselt werden. Um den Zeitpunkt abzupassen, verwende ich keinen zusätzlichen Zähler, sondern nutze den Akku selbst dafür: Vor dem ersten ROL wird das Carry-Flag gesetzt, so dass danach Bit 0 gesetzt ist. Vor allen weiteren ROLs wird das Carry-Flag gelöscht, so dass nach genau 8 Durchgängen A=0, und damit das Zero-Flag gesetzt ist. Dann wird das nächste Byte geholt.
Damit im Zielsprite nur 21 Zeilen beschrieben werden (und nicht noch wohlmöglich Sprite 1 beschädigt wird), prüfe ich den X-Offset, der von 62 in Dreierschritten runterzählt, auf sein Vorzeichen. Bei X<0 wird für die nächste Spalte X wieder auf 62 gesetzt und das nächste Byte von Sprite 1 gelesen.
Endbedingung ist erfüllt, wenn nach Sprite 1 noch 3x3 Bytes (drei zusätzliche zeilen a drei Bytes für die drei Leerspalten am rechten Rand) gelesen wurden. Konkret hier also 254+9 das entspricht 7 (Low-Byte von 263).
Um einen benötigten Pointer ohne zusätzliche Initialisierung in der Zeropage vorliegen zu haben, nutze ich die Adressen $39/$3A, in der die aktuelle BASIC-Zeilennummer steht. Die Zeilennummer wird dann einfach so gewählt, dass in $39/$3A die gewünschte Adresse ($0340-192) zum Lesen von Sprite 1 steht.
Für den Lesezugriff auf Sprite 1 benutze ich einen Offset von 192 (also $340-192=$280), damit das Sprite für 192<=Y<=254 ausgelesen wird. So wird automatisch das Carry Flag im relevanten Bereich (wo ich es brauche) mit der Endbedingungsprüfung CPY #07 gesetzt und man spart sich ein SEC. Zusätzlich ist beim erreichen der Leerspalten das Vorzeichen-Flag positiv (statt vorher negativ), so spart man sich einen Vergleichsbefehl und kann gleich BPL verwenden.
Allerdings wird hierbei das ('unsichtbare') Byte nach dem auszulesenden Sprite (quasi Byte 64) für den Anfang der Leerspalten mit ausgelesen und muss deshalb zwingend 0 sein. Das ist es meistens sowieso, aber man kann (speziell hier bei der Compo) nicht davon ausgehen.
Daher wird bei Programmstart das betreffende Byte ($037F) auf 0 gesetzt.
Wenn das Byte sowieo garantiert 0 ist, kann man sich diese 3 Bytes sparen und hätte eine 46 Byte Lösung - aber wie gesagt, für die Compo kann ich leider nicht davon ausgehen, dass in $037F garantiert eine 0 steht.
Das Verschieben des Offsets um eins, um das Lesen von Byte $037F zu umgehen, funktioniert übrigens leider nicht so ohne Weiteres, da sonst bei Y=0 sowohl Carry=1, als auch A=1 gesetzt wird, was in einem einzelnen Stör-Pixel in den Leerspalten resultiert. Aber vielleicht findet ja jemand anderes hierfür noch eine elegante Lösung.
Je nach Startwert von Y wird vor dem eigentlichen Sprite noch mehr oder weniger Datenmüll durch das Zielsprite geshiftet. Das macht aber ja nichts, solange am Ende das richtige Ergebnis vorliegt.
Wow, 91 Byte Länge (89 Byte in Basic). Kaum zu glauben
Ich bin mit Z80 bei der 3-fachen Länge und das Ding funktioniert noch nicht einmal.
Tolle Leistung.
Ich hoffe es lag nicht nur an der Basic-Zeile das es 43 Bytes geworden sind.
Und hier das Programm.
Herzlichen Glückwunsch auch von mir, Acorn!
Ich hoffe es lag nicht nur an der Basic-Zeile das es 43 Bytes geworden sind.
Definitiv nicht.
Hab' mal kurz 'drüber geguckt und das is bei den anderen vorne platzierten Lösungen auch so. (Meine startet sogar mit SYS 2051)
Interessant auch, daß die vordersten 3 Lösungen recht ähnlich sind (zeilenweise lesen und Spalten schreiben).
Ich machs genau umgekehrt und kam so nich unter 47 Bytes. (ist aber auch 'ne schöne Lösung, denke ich.) Poste den Quellcode später noch.
43 Bytes? Wow
Meine Version hat 56 Bytes. Mehr war nicht drin.
Der Code sollte (hoffentlich) relativ selbsterklärend sein. Einen Illegalen Opcode habe ich verwendet (DCP), mit diesem wird ein CMP gespart.
Kurzerklärung zum Code:
Im Prinzip Frage ich Spalteweise die Bits des Ursprungssprites ab und schiebe die Bits dann in das neue (Ziel-)Sprite. Das ganze beginnt in Spalte 21 und geht rückwärts bis Spalte 1, so lasse ich die 3 rechten Spalten (Pixel) von Anfang an raus. Sobald 21 Zeilen abgearbeitet wurden, werden 3 0-Bits ins Zielsprite geschoben. Damit sind später im Zielsprite die rechten 3 Pixel leer (0).
Herzlichen Glückwunsch an den Gewinner und alle die mitgemacht haben.
Und vielen Dank an @peiselulli für die tolle Compo. Das Thema hat mich total gefesselt und etliche Stunden meiner Freizeit gekostet
Klasse! Ich bin es irgendwie zu kompliziert angegangen, aber es funktioniert
Zum Spaß hier meine Variante im sauberen Code:
Ich hoffe es lag nicht nur an der Basic-Zeile das es 43 Bytes geworden sind.
Öh... Doch. Meine Lösung ist nahezu identisch, aber sie enthält zusätzlich drei (46) bzw. zwei (45) Bytes für ein korrektes, definiertes Ende des Basicprogranms:
Zur Strafe darf Acorn jetzt die nächste Compo abhalten.
An dieser Stelle nochmal vielen Dank an peiselulli für das Ausrichten der Compo und die interessante Aufgabe. Und an alle, die auf diesem Wege zum C64 oder Assembler gefunden haben: Bitte bleibt dabei. Es macht viel Spaß.