Zum Warmlaufen, habe ich es in Excel VBA gelöst. ca. 12 Zeilen Code ohne "Optimierung".
Ja, lacht nur... 
OT: Neue C64 ASM/Basic Compo : Dreh' das Sprite [Alternative Systeme]
- syshack
- Thread is marked as Resolved.
-
Zum Warmlaufen, habe ich es in Excel VBA gelöst. ca. 12 Zeilen Code ohne "Optimierung".
Ja, lacht nur...
-
Und wieviel Bytes? Wie gut, dass der C64 serienmäßig VisualBasic kann
Es ging mir darum, das Prinzip und Problematik mal grundsätzlich zu verstehen. Da ich VB/VBA am besten kenne, macht das für meine Zwecke Sinn.
Jemand anders würde das vielleicht auch in Python o.ä. mit Arrays zu probieren. Oder halt direkt in 6502/Z80 ASM. Oder in Brainfuck.
Das könnt Ihr sehen wie Ihr wollt. -
Es ging mir darum, das Prinzip und Problematik mal grundsätzlich zu verstehen. Da ich VB/VBA am besten kenne, macht das für meine Zwecke Sinn.
Jemand anders würde das vielleicht auch in Python o.ä. mit Arrays zu probieren. Oder halt direkt in 6502/Z80 ASM. Oder in Brainfuck.
Das könnt Ihr sehen wie Ihr wollt.Sorry, war doch nur Spaß. Ich verstehe das gut. Um das Grundprinzip zu verstehen, nutzt man die Mittel, mit denen man sich am Besten zurechtfindet - oder die man eben gerade hat.
Und wirst Du Deine Erkenntnisse jetzt in Basic2.0 oder ASM umsetzen. Unabhängig von einem unmöglichen Sieg mit einer Basic-Variante interessieren mich die anderen Basic-Versuche ja auch - übrigens auch Dein VB-Code.
So... und jetzt habe ich mich gerade ertappt, dass ich beim Schreiben schon gucke, ob ich nicht hier und da ein paar Bytes einsparen kann. 
Ich beschäftige mich eindeutig zu viel mit der Compo!!! -
Es wird bunt auf dem Bildschirm.
Das Muster ist aber noch falsch. Ohne Optimierungen, aber mit selbstmodifizierenden Code bei 80 Bytes.
Aufm Z80 natürlich.
Damit kann ich offiziell nicht mitmachen, aber ich wollte mal sehen wie weit ich beim Z80 komme.
-
Ich habe mir vor Tagen mal in Excel was gebastelt, in der Hoffnung so dichter an eine Lösung zu kommen.
Ich bekomme zwar ein Sprite angezeigt, die Drehung geht aber völlig nach hinten los.
Vielleicht kann einer damit was anfangen oder es ist für die Tonne weil in der Tabelle schon einen Denkfehler gemacht habe.
-
Was auch immer dir diese Tabelle bringen soll: Ja, sie ist falsch.
- das Sprite hat nur 21 Zeilen
- B3_3 ff. muss nach 1000_3 ff. senkrecht
-
-
Eine Visualisierung kann man auch mit generierten Strings machen. Z.b. 1=* 0={SPACE}
-
Ob man das Sprite nennt, PlayerMissile, Shape, BlitterObject oder sonstwie. All diese grafischen Objekte liegen doch als Bitmuster im Speicher vor und können der Hardware entsprechend auf den Bildschirm gebracht werden.
Ich habe einfach einen Speicherbereich von 3x21 Byte mit Zufallswerten definiert, dargestellt und versucht das zu drehen und darunter nochmal darzustellen. Bisher kommt aber nur Müll dabei raus.
Das liegt daran, weil ich bisher immer noch keinen Plan habe wie ich das umrechnen soll. Alle bisherigen Versuche sind fehlgeschlagen. -
Nimm doch Drazils String Ansatz. Der ist plattformunabhängig und in Basic umsetzbar.
Ich interpretiere, dass du den Video Speicher des CPC mit Zufallswerten beschreibst im Wissen, wie diese Werte auf dem Video Display umgesetzt werden und wie sie gedreht aussehen müssen?Mach es doch erstmal mit strings in basic und dann erst in Hardware und asm.
-
Ich habe einfach einen Speicherbereich von 3x21 Byte mit Zufallswerten definiert, dargestellt und versucht das zu drehen und darunter nochmal darzustellen. Bisher kommt aber nur Müll dabei raus.
Das liegt daran, weil ich bisher immer noch keinen Plan habe wie ich das umrechnen soll. Alle bisherigen Versuche sind fehlgeschlagen.Der Trick/die Aufgabe liegt halt teils/vorrangig beim Carry-Flag.
Im Z80 wäre ich allerdings auch planlos.
-
Ob man das Sprite nennt, PlayerMissile, Shape, BlitterObject oder sonstwie. All diese grafischen Objekte liegen doch als Bitmuster im Speicher vor und können der Hardware entsprechend auf den Bildschirm gebracht werden.Ich habe einfach einen Speicherbereich von 3x21 Byte mit Zufallswerten definiert, dargestellt und versucht das zu drehen und darunter nochmal darzustellen. Bisher kommt aber nur Müll dabei raus.
Das liegt daran, weil ich bisher immer noch keinen Plan habe wie ich das umrechnen soll. Alle bisherigen Versuche sind fehlgeschlagen.Magst mal Sources posten? Evtl kommt mir ja eine Idee?
-
@ syshack
Ein String Array kann man aber besser plotten.Und es geht ohne bool. Es wäre einfacher.
-
@ syshack
Ein String Array kann man aber besser plotten.Und es geht ohne bool. Es wäre einfacher.
Genau, die Stringvisualisierung hatte ich ja auch erwähnt um VOR/NACH der byte/integer array rotation das Ganze platformunabhängig darstellen zu können.
-
Bitte hier Excel aus dem Spiel lassen
Dafuer gab es doch schon den 'Heute so gecodet' Thread. -
Mach es doch erstmal mit strings in basic und dann erst in Hardware und asm.Ich versteh nicht einmal die BASIC Version von drazil. Die Formeln 8000-8070 sind schon zu hoch für mich. Keine Ahnung wofür diese ganzen Z Variablen sein sollen.
-
Ich versteh nicht einmal die BASIC Version von drazil. Die Formeln 8000-8070 sind schon zu hoch für mich. Keine Ahnung wofür diese ganzen Z Variablen sein sollen.
Der Teil ist zur 3d->2d Transformation von Koordinaten.
-
Nimm mal ein Dame oder Mühle Spiel und leg Dir aus einer 3x3 Steoine Matrix ein einfaches asymmetrisches Muster auf den Tisch. Überlege, wie Du die Steine umgruppieren musst um für eine 90 Grad Drehung zu sorgen.
Überlege, wie man die Methode des Von hand Drehens in einen Algorithmus überführen kann.
Der Aufbau des CPC Video RAMs ist völlig anders als bei einem C64 Sprite und völlig anders als beim C64 VideoRAM. Du hast Sprites, Player Misslies und Co alle in einen Topf geworfen als wären sie überall gleich aufgebaut. Aber das ist nicht so. Daher hätte selbst ein korrekter Excel Algorithmus 1:1 auf CPC Speicher angewendet ein falsches Ergebnis erbracht.
Nach der Compo muss man mit Erklärungen nicht mehr groß hinterm Berg halten. Dann wird es sicher auch für Dich klarer.
