Nur Debugging / Optimierung (Mensch hat geschrieben, KI hat analysiert/korrigiert)
Keine (Nur Code oder rein menschliche Assets)
Space Harrier 2.
Claude hat es zwar schneller gemacht, aber leider immer noch nicht besonders gut.
space_harrier_2_fast.dsk (195 KB)
Schön, danke! Das muss bedeuten, dass der Code bereits optimiert war, obwohl ich beim kurzen Drüberschauen noch ein paar Versäumnisse entdeckt habe.
Bei Offset 2981 gibt es ein call &0836:ret, das durch ein jp &0836 ersetzt werden könnte.
Ein paar Zeilen darunter, bei Offset 2992, sehen wir: ld de ,&9C00:add hl,de. Es macht natürlich keinen Sinn, 0 zum Register L zu addieren! Besser wäre also: ld a,h:add &9C:ld h,a, was den 16-Bit-Overhead vermeidet. Es sei denn natürlich, es handelt sich um selbstmodifizierenden Code, aber das scheint hier nicht der Fall zu sein.
Ich frage mich, ob deine Modelle richtig auf Optimierung trainiert sind, aber ich gebe zu, dass ich mich mit alldem nicht wirklich auskenne.
Danke!
Ich werde diese Info an Claude weiterleiten und sehen, was es dazu sagt.
[EDIT] Ja, es stimmt zu, meinte aber Folgendes:
Beide haben recht; sie würden höchstens etwa 7 µs pro Spielschleife einsparen, was viel zu wenig ist, um es zu bemerken.
#2981, call #0836 : ret → jp #0836: spart 5 µs (call 5 + ret 3 gegenüber jp 3). Dieser Endabschnitt wird nur für die ursprüngliche Kopie ausgeführt, die während des Spiels jetzt nur noch gelegentlich vollständig kopiert wird; Menüs, Titel und Übergänge nutzen ihn weiterhin. Meine Kopie der Spielschleife endet bereits mit jp music.#2992, ld de,#9C00 : add hl,de → ld a,h : add a,#9C : ld h,a: spart 2 µs (6 gegenüber 4). Das ist sicher: Das addierte untere Byte ist 0, daher gibt es nie einen Übertrag aus L. A ist an diesem Punkt frei, da die nächsten Befehle es mit ld a,(#316B) neu laden, und es wird nicht selbst modifiziert. Das ist die Adressberechnung des ursprünglichen Löschvorgangs, die nur bei Löschvorgängen außerhalb der Spielschleife läuft; mein Löschvorgang in der Spielschleife holt sich die Adresse stattdessen aus der Zeilentabelle #E600.Bei einer Spielschleife von etwa 80–95 ms liegt das unter 0,01 %. Das Spiel ist voll von solchen Mustern; sie befinden sich größtenteils außerhalb der Routinen, die Frames kosten.
Ja, ich hatte einen Haltepunkt bei 2981 gesetzt, und der wird nur aufgerufen, wenn der Spieler getroffen wird, aber er wird viele Male aufgerufen und das ist Code aus der Game-Loop. Sag diesem Claude-Typen, er muss sich mehr anstrengen 
LOL ja, aber meiner Meinung nach wird Claude langsam zu gut darin.
Das Spiel, an dem ich gerade arbeite, wird zwar ganz klassisch auf die alte Art geschrieben, aber die Optimierung von alten Spielen übersteigt einfach mein Können. Und es macht irgendwie Spaß, Claude dafür zu nutzen. 
Haha, das fand ich klasse 