Schneider / Amstrad CPC Forum

Amstrad / Schneider CPC => Programmierung => Thema gestartet von: Fessor am 13. November 2019, 23:07:58

Titel: Hacking Bruce Lee
Beitrag von: Fessor am 13. November 2019, 23:07:58
Das hier müsste der richtige Bereich sein, denke ich..
Irgendwie nerven mit die Meldungen auf indieretronews und anderen Seiten an, dass die anderen Plattformen (Atari, C64, ZX) erweiterte Bruce Lee-Fassungen bekommen haben.

Inspiriert von diesen beiden Threads bei Atariage:
https://atariage.com/forums/topic/288392-two-bruce-lee-sequels/#comments
https://atariage.com/forums/topic/292947-bruce-lee-retweaked-sprites/#comments

habe ich angefangen Bruce Lee mal mit nem Reassembler zu zerlegen und zu schauen, ob hiervon irgendwas übertragbar wäre.

Kartendaten sind unkomprimiert 40x11 Zeilen (440 Bytes). Die Tiles sind 8x8 Pixel groß und werden auf 8x16 gedehnt. (Atari lässt grüßen)
Die Verwaltungsstruktur sowie die RLE-Daten werden an Arbeitsadressen kopiert.

0x1500: Mode 0 Zeichen für Statuszeile
0x1800 - 0x27ff Grafiktiles (Mode 0)
0x2800 - 0x2cff Verwaltungsstrukturen für die 20 Karten zu je 64 bytes.
    16 bytes mit Farbdaten für Border und Ink 0 - 15
    1 Word mit Pointer auf rledata, 1 Word mit Pointer auf Overlaydaten, Vier Pointer auf Routinen für noch unbekannte Events.
    0x13-0x40 Verwendungszweck noch unbekannt

0x2d00, 0x2d01: 0xc9, 0xff - Markiert das Ende der Liste der Verwaltungsstrukturen; theoretisch wären noch mehr Karten möglich, wenn man denn genug Speicher hätte.

0x2d02 - 0x47ff: 20x (RLE-Daten, OVL-Daten)

0x4800 - 0x484b - Tabelle mit Pointern auf die Sprites

0x484c - 0x57ff: Spritedata (Mode 0)

0x5800: jp main
               ret
0x5804 - 0x58a3: Jumptabelle für die Kartenevents, wird bei Spielstart in die Kartenheader reinkopiert, je vier Routinen pro Raum.

0x58b3 - 0x58f2: Kopierziel für Kartenverwaltungsstruktur (64 Bytes)
0x5923 - 0x5ada: unkomprimierte Kartendaten (440 Bytes)
0x5adb - 0x5e12: Kopie der unkomprimierten Kartendaten (440 Bytes) (Karte für den zweiten Spieler)

0x9000 - 0x926f - Daten Zeichensatzdefinition
Bemerkenswert finde ich, dass Soundwiedergabe, Textausgabe, Tastaturabfrage etc alles sauber über Betriebssystemroutinen erfolgt.


Die Karten sind RLE-Kodiert und der Basic-Loader wurde kurzerhand mal umgehackt um Proof-of-Concept zu bekommen. Nächtes Schritte wären Export in ein Format für einen Mapeditor wie TILED oder RGAS um Level einfach editieren zu können.

10 REM Bruce Lee Map Viewer
20 MEMORY &14FF
30 MODE 1:BORDER 0:INK 0,0:INK 1,26
150 LOAD"bruce.n02
200 adr=&2D02
210 i=PEEK(adr):adr=adr+1
220 IF i=0 THEN END
230 IF i>127 THEN 300
240 j=i:i=PEEK(adr):adr=adr+1
250 PEN 1
260 PRINT CHR$(1)CHR$(i);
270 j=j-1:IF j>0 THEN GOTO 260
280 GOTO 210
290 i=PEEK(adr):adr=adr+1
300 z=i AND &7F
310 i=PEEK(adr):adr=adr+1
320 PEN 3
330 PRINT CHR$(1)CHR$(i);
340 z=z-1:IF z>0 THEN GOTO 310
350 GOTO 210


Soviel schon mal zum Auftakt...

30.12.19: Diskimage, Hackingguide angehängt
02.01.20: Hackingguide aktualisiert (Kapitel für Sprites ergänzt)
04.01.20: Hackingguide aktualisiert (Absatz zu den Aufzügen und der Farbanimation ergänzt
Titel: Re: Hacking Bruce Lee
Beitrag von: TFM am 14. November 2019, 15:21:29
Da hast Du Dir aber gut was vorgenommen. Vielleicht wäre "neu schreiben" ja einfacher. Wer weiß. In jedem Fall viel Glück und Erfolg dabei.  :smiley027:
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 14. November 2019, 16:28:22
Fürs Neuschreiben fehlt mir das know-how und hoffe durch die Analyse das ein oder andere zu lernen.

Das Kartenmaterial für Return of Fury und Tilesets wurden veröffentlicht, die Kommentare lassen aber drauf schliessen, das Eingriffe in den Code nötig sein werden. Sehr wahrscheinlich wg. hart kodierten Abhängigkeiten welche Lampe welchen Durch-/Ausgang beeinflusst...

Erweiterungen an der Engine erscheinen mir nicht unrealistisch. Hinter der Zeichensatzdefinition ist noch genug Platz für ein oder zwei weitere Tilesets, bzw Platz für Laderoutine um Material bei Bedarf nachladen zu können....

Kommt Zeit, kommt Rat, ich hab ja grad erst mit der Analyse angefangen. ;)


Titel: Re: Hacking Bruce Lee
Beitrag von: TFM am 14. November 2019, 16:34:49
Lernen kann man da sicher viel.  :) Allerdings gibt's auf dem CPC eben leider auch sehr viele Spectrum Portierungen, und die sind nun mal zu allermeist Flickschusterei. Aber mit etwas Glück wird's schon gut gehn.  :)
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 15. November 2019, 00:28:09
Spectrumports sind ne Sache für sich.
Ich glaub nicht, dass Bruce Lee ein Port von der Spectrumversion ist; die Fassung vom ZX hat eine andere/bessere KI und der dicke Yamo vermag es die erklimmbaren Objekte zu erklimmen und bleibt nicht einfach nur auf der untersten Ebene.


Proof-of-Concept funktioniert einigermaßen; Lampen (gesicherte Erkenntnis) und Ausgänge (muss noch verfolgt werden) werden in eigenen Strukturen gespeichert.
Titel: Re: Hacking Bruce Lee
Beitrag von: TFM am 15. November 2019, 18:07:02
Das wird!  :jubelaola:
Titel: Re: Hacking Bruce Lee
Beitrag von: oobdoo am 16. November 2019, 16:59:04
Welchen Reassembler hast Du verwendet?
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 16. November 2019, 22:29:40
yazd und dasmx. yazd ist open source und wird immer noch gepflegt, dasmx ist mittlerweile freeware.

In der Hauptsache aber dasmx, da man über ein "Symbolfile" lenken kann, wie die Binärdatei behandelt werden soll. Sprich: Codebereiche benennen, die er selbsttätig nicht finden konnte, Datenbereiche benennen, Label vergeben etc. Ist zwar ne Sysiphusarbeit, da man dieses Symbolfile manuell pflegen muss, aber das Ergebnis ist dann doch recht beeindruckend.

Meistens reicht es schon aus ihm als Startparameter die Ladeadresse und den Einstiegsadresse mitzugeben und er verfolgt dann den Code ziemlich gut automatisch nach und erstellt schon beim ersten Mal ein ziemlich gut brauchbares Assemblerlisting.

Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 16. November 2019, 23:04:00
Bin aber  grade dabei, mich in ghidra einzuarbeiten; da kann man alles schön mit GUI machen.
https://www.ghidra-sre.org/

Titel: Re: Hacking Bruce Lee
Beitrag von: oobdoo am 17. November 2019, 16:55:58
Bin aber  grade dabei, mich in ghidra einzuarbeiten; da kann man alles schön mit GUI machen.
https://www.ghidra-sre.org/
Ist das nicht gefährlich mit einer NSA Software?  :zwinker0018:

Naja, hat einen Vorteil. Man braucht sich um ein Backup seiner Daten nicht mehr kümmern.  :D
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 17. November 2019, 17:33:41
Bin aber  grade dabei, mich in ghidra einzuarbeiten; da kann man alles schön mit GUI machen.
https://www.ghidra-sre.org/
Ist das nicht gefährlich mit einer NSA Software?  :zwinker0018:

Naja, hat einen Vorteil. Man braucht sich um ein Backup seiner Daten nicht mehr kümmern.  :D

Nujo... deswegen hab ich auch mit NMAP geguckt ob die Software irgendwie "nach hause" telefonieren will. Tut sie nicht ;)
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 20. November 2019, 21:08:32
So.. Neues von der Analysefront:
So Merkwürdig, wie die Inks gesetzt sind und wie der Bildspeicher bei den Kollsionsroutinen mit Bitmasks verglichen wird, kommt Keith56s Beitrag hier: http://www.cpcwiki.eu/forum/programming/multiplatform-z80-asm-development-videos-with-vampires!/msg180560/#msg180560
genau zur rechten Zeit. Bei Bruce Lee scheint diese Technik auch angewendet worden zu sein. Was einigermaßen schade ist; hätte gehofft gehabt, dass man die Grafik farblich hätte aufhübschen können.


- Musikplayer (Über Jumptabelle: Call &8c00, direkt: Call &8d14)
- Soundeffekte (Zur Rückverfolgung interessant)
- Joytick/Keyboardabfrage (Zur Vorwärtsverfolgung interessant)
- Joytick/Keyboardabfrage (Zur Vorwärtsverfolgung interessant)
"AI" für die Demo - läuft praktisch auf eine aufgezeichnete Spielsession hinaus wo in ner Tabelle gespeichert wurde, wie lange in welche Richtung gelenkt wurde. Wird in die Joystick/Tastaturabfrage einspeist.

- Verwaltungsinformationen für die drei Sprites; ich hab immer noch nicht rausgefunden, wie die Spritedaten angesprochen werden; der Reassembler hat weder Label auf die Tabelle mit den Pointern zu den Sprites ermittelt, noch Referenzen bei den Spritedaten richtung Programmcode. Da ist wieder irgendwelches digitales Hexenwerk am Start und die die Adressen scheinen irgendwie errechnet zu werden, was der Reassembler natürlich nicht kann.

- Kollisionsroutine für begehbaren Untergrund
- Kollisionsroutine um kletterbare Objekte zu ermitteln

In den Kartenheadern ist Platz für eine kleine Jumptabelle für vier Funktionen enthalten. Unklar ist noch, wann welche Funktion aufgerufen wird.
Die Jumps werden beim initialisieren der Karte in die Strukturen reinkopiert; hier muss noch näher reingeschaut werden.

Kann man Winape eigentlich auch Symboltabellen unterschieben? Debuggen mit Hexadressen ist ein ziemlich mühseliges Geschäft...
Titel: Re: Hacking Bruce Lee
Beitrag von: TFM am 20. November 2019, 21:54:57
Doch besser alles neu machen mit anständiger Grafik?
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 20. November 2019, 23:53:15
Da fehlt mir das Know How für. Mein persönliches Ziel ist es die Engine zunächst einmal gut genug zu verstehen um zu gucken ob und wo Änderungen nötig sind um ihr andere Levels unterjubeln zu können.
Titel: Re: Hacking Bruce Lee
Beitrag von: oobdoo am 21. November 2019, 21:45:27
Eine neue Grafik kann man auch aus der 64er Version klauen.  :zwinker0018:
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 21. November 2019, 23:55:19
Das wir für Fury Road sogar ziemlich notwendig sein.

Was die Engine angeht, hab mal bei einigen Karten alle PEN-Farben durchdefiniert und es entstehen keine OR/XOR-Farbeffekte beim Zeichnen der Sprites.
Jetzt muss ich mal ausfindig machen, welche PENs für Spezialzwecke reserviert sind, und ob und welche für Aufhübschung der Grafik zur Verfügung stehen könnten. Vier PENs sind zur Animation der Kletterwände (oder wie man die auch nennen will) vorgesehen; aber die hat man auch nicht in jedem Raum, wäre also beim Raumdesign zu berücksichtigen, das man einige Grafiktiles nicht nutzen dürfte...

Theoretisch, wenn alles durchgelabelt und der Code wieder assemblierbar ist, könnte man die Grafiktiles von 8x8 auf 8x16 vergrößern um die Auflösung der Hintergrundgrafik von 160x100 auf 160x200 zu erhöhen.

Aber das ist alles Zukunftsmusik
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 23. November 2019, 23:35:51
Erste Schritte mit C# und Monodevelop unter Linux, GTK... viele Crashes, viel Gefluche, viel Haargeraufe...

Kann:
Lädt BRUCE.N02
Tiles darstellen
Maps dekodieren und darstellen...


Kann nicht:
Noch ganz viel... Kartenauswahl, Farbauswahl, Tabelle für Objekte (Lampen, Hindernisse) auswerten usw. usf....


Version: 0.0.0.0.0.0.0.0.0.1 superalpha
Titel: Re: Hacking Bruce Lee
Beitrag von: oobdoo am 24. November 2019, 17:27:27
wenn alles durchgelabelt und der Code wieder assemblierbar ist
Das soll mein Disassembler unter Windows mal alles können und noch viel mehr.
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 26. November 2019, 23:27:42
So langsam krieg ich C# und die Designphilosophie von GTK in den Griff.

Allerdings habe ich noch nicht herausgefunden, wie man die Assets als Indexed-Bitmaps behandeln kann um einfach nur die Inks der Pens switchen zu können wie am CPC. Momentan müssen die Grafiken immer komplett neu Aufgebaut werden weil sie in anderen Farben gezeichnet werden müssen.
Die Pen-Buttons mögen auch noch nicht die gesetzen Farben darstellen; ein Auswahldialog für die CPC-Farbpalette fehlt auch noch.

Das gibt aber auch leider kein Beispiel wie man das in C# mit GTK/GDK hinkriegt.
Eigentlich wäre es nur eine Frage der "Colormap", aber es gibt keinerlei Beispiel wie sie aufgebaut ist und wie man eine für 8Bit-Farbtiefe erzeugt.

Desweiteren reagieren die Tiles und Maptiles überhaupt nicht auf Mausklicks oder sonstige UI-Events; das muss ich auch noch ausfindig machen, damit das ganze zu einem Editor ausgebaut werden kann.

Ein RLE-Kompressor für die Raumdaten ist auch auszutüfteln.
Titel: Re: Hacking Bruce Lee
Beitrag von: TFM am 27. November 2019, 11:48:59
Gute Arbeit Fessor! Weiter so!  :smiley027:
Titel: Re: Hacking Bruce Lee
Beitrag von: oobdoo am 29. November 2019, 16:34:38
So langsam krieg ich C# und die Designphilosophie von GTK in den Griff.
:jubelaola:
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 29. November 2019, 16:57:29
Man kommt sich in die 90er Jahre zurückversetzt vor. Beim Atari-GEM musste das, was der Standard für das Interface-Design nicht mitbrachte, auch selbst geschrieben werden. Die Tiles schmeissen mir nun Rückmeldungen aus, wenn man mit der Maus über sie fährt; jetzt muss noch ausgetüftelt werden, dass das überstrichene Tile auch hervorgehoben dargestellt wird. Klickselektion und Drag n Drop dürften dann (hoffentlich) ziemlich einfach werden.

Um das Debuggen zu erleichtern, werden nun weitere Informationen dargestellt, die für eine spätere Erweiterung zu einem Editor wahrscheinlich auch nötig sein werden.

Ohne den Code relozieren zu müssen, ist da ein kleiner Buffer hinter der letzten Overlaytabelle des letzten Raums von 244 Bytes.
Die Kartendaten liegen im 0x2800 - 0x47ff
20x Verwaltungstabellen zu 64Bytes und dann in Reihenfolge RLE-Data,  OVL-Data, RLE-Data, OVL-Data...

Für den Viewer/Editor wird es ein einfaches sein, diese Daten im Speicher vorzuhalten, das sind ja nur 20 Arrays zu 64 Bytes, 20 Arrays zu 440 Bytes für unkomprimierte Karten, 20 Arrays zur Aufnahme der rekomprimierten Karten und 20 Arrays zur Aufnahme der Karten-Overlays. Da müsste sich auf Knopfdruck oder on-the-fly berechnen lassen, ob man beim Designen den zur Verfügung stehenden Speicher überschreitet...




Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 01. Dezember 2019, 02:45:24
Wieder Etappenziele/Meilensteine erreicht.
- GitBucket auf dem NAS eingerichtet um den Code zu versionieren.
- Custom-Widgets für Tiles und Farbbuttons
Tiles werden nun beim überstreichen mit der Maus optisch hervorgehoben; Farbbuttons sind nun auch auf dem Weg.

Nächstes Ziel: Viewer zu nem Editor ausbauen und Bruce-Lee patchen.

Kann mal jemand mit Windows testen ob der Viewer dort überhaupt funktioniert? Die IDE sollte eigentlich alle notwendigen Dateien bereitgestellt haben.
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 05. Dezember 2019, 00:41:51
Nachdem ich halbwegs rausgefunden hab, wie man Dialoge aufrufen und Return-Werte bekommt funktioniert nun rudimentär ein INK-Selector, wenn man mit rechter Maustaste im Hauptfenster auf einen der PENs klickt.
Ich habe die Hoffnung noch nicht aufgegeben, die Grafiken als Indexed-Images hinzubekommen um wie beim CPC einfach auch nur die INK zu setzen. Mit den ganzen Arrays und Tabellen und der Neuerstellung der Grafiken aufgrund anderer Farbwerte ist die Performance des Viewers doch arg in den Keller gegangen. Da gibts also noch reichlich was zu optimieren; aber das ganze ist eh noch in der Konzeptphase und ein mehr oder weniger heftiges Neuschreiben der Routinen ist eh eingeplant.
1st: Make it Run. 2nd: Make it Fast. 3rd. Make it Nice.

Mit dem Programmcode hab ich mich auch mal wieder beschäftigt und rückwärts durch einige schon identifizierte Routinen getraced um weitere Routinen belabeln zu können.
Von den vier Eventroutinen ist dabei das Funktionsprinzip von dreien identifiziert.

Das erste Event wird beim Betreten eines Raums gefeuert und dient der Initialisierung einiger Raumabhängiger Variablen.
Das zweite Event wird im Interrupt des Gameloops aufgerufen und dient der Platzierung/Animation der "Missiles"
Drittes Event: Unbekannt
Das vierte Event wird nach dem Einsammeln einer Lampe aufgerufen und hier wird dann Raumabhängig die Abarbeitung der Einträge der Overlaytabelle gesteuert.
Anhand der Raumnummer und der x und y-Koordinate wird der entsprechende Tabelleneintrag ausfindig gemacht und das Tile aus der Karte entfernt oder eingesetzt.
Sprich: Steuerung der Hindernisse.

Die Sprites: Für jedes der drei Sprites existiert ein Offscreen-Buffer von 384 Bytes (4*3 Tiles => 8 * 48 Bytes) in dem sich die Action eigentlich abspielt. Hier wird eine Blase der Umwelt gezeichnet und das Sprite hineinplaziert und dann die Blase in den Bildspeicher kopiert. Keine Ahnung warum. Eventuell hätten Sie es nicht anders hinbekommen die Sprites flackerfrei auf den Schirm zu bekommen. Das Blitten so einer "Blase" auf den Screen sieht jedenfalls einigermaßen Effizient aus, da sie nicht viel Adressen zu kalkulieren haben. (Die Routine geht von 0x685e bis 0x68a1)

0x5c93: Szene vom Ninja,
0x5e7a: Szene von Yamo
0x6065: Szene von Bruce
Hinter den Offscreenbuffern sind jeweils 15 Bytes für Verwaltungsinformationen abgelegt, die noch größtenteils unidentifiziert sind.
Hierauf folgen dann (Interleaved) Pointer auf die Grafikdaten der Einzelsprites/Animationsphase der Sprites und (zugehörige?) Adresse auf eine Programmroutine.
Da diese Datentabelle größer ist als die Anzahl der Einzelsprites scheint das in Animationsphasen unterteilt zu sein, die sich ja aus mehreren Sprites zusammensetzen; aber das ist erstmal eine Arbeitshypothese.

Das ganze ist mal wieder eine Sammlung von Springteufeln. Hat man was entdeckt, taucht was frisches unbekanntes auf...

Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 10. Dezember 2019, 00:00:00
Die Arbeitshypothese scheint aufzugehen.
Hinter den jeweiligen Verwaltungsinformationen der drei Sprites (Ninja, Yamo und Bruce) existiert jeweils eine hübsche kleine Liste an Pointern zu Spritegrafik und zugehöriger Routine.
Ich weiß noch nicht, ob ich das als Phasen oder Aktionen bezeichnen soll.
In den Verwaltungsinformationen der Sprites ist u.a. hinterlegt, welcher Listeneintrag beim aktuellen Programmdurchlauf zu verwenden ist.
Die Routinen werden angesprungen, lustige magische Sachen ausgeführt, die Spritegrafik dargestellt und als Rückgabewert die Nummer für den Tabelleneintrag geliefert, welcher beim nächsten Durchlauf zu verwenden ist.

Ich finde den Ansatz mal interessant, da da die Routinen somit praktisch miteinander verknüpfbar sind und damit eigentlich auch relativ einfach erweiterbar sein sollten.
Bei den Fangame-Nachfolgern kann Bruce ja u.a. schwimmen. Das Feature müsste recht einfach einzubauen sein, in dem man bei der Fall-Phase eine Prüfung einbaut, ob Bruce in Wasser gelandet wäre und beim nächsten Durchlauf dann zu Listeneinträgen mit Routinen und Sprites fürs Schwimmen springt. Mit Glück ist da noch ein Pen über den man für "Wasser" reservieren kann... (Auf der imaginären in ferner Zukunft liegender To-Do Liste)

Eine Größenbegrenzung der Listen exisitiert nicht, ich hab dahingehend nix finden können. Wenn einer der Gegner etwas nicht können soll, ist das entweder in der Unterroutine selbst berücksichtig und/oder der Tabelleneintrag in der Liste ist ausgenullt. Bei Yamo existiert noch eine weitere Aktion, beim Ninja und Bruce ist Aktion 0x12 ausgenullt...

Die Labels sind so erstmal nur Provisorien, die sich durch Rückverfolgung der Spritegrafiken ergeben haben. (Da ist ziemlich viel Dual-Use und mehrfachverwendung der Grafiken vorhanden, und bei Yamo sogar zwei Sprites falsch verknüpft...


                             spr_Fall                                        XREF[3]:     ram:5e38(*), ram:601f(*),
                                                                                          ram:620a(*) 
        ram:7253 cdd374          CALL       CheckForGroundtile
        ram:7256 cd276f          CALL       CheckForEnemysprite
        ram:7259 300e            JR         NC,keepFalling
        ram:725b fd21135e        LD         IY,sprDataNinja                                  =
        ram:725f cd6c72          CALL       chkLandedOnEnemy
        ram:7262 fd21fa5f        LD         IY,sprDataYamo                                   =
        ram:7266 cd6c72          CALL       chkLandedOnEnemy
                             keepFalling                                     XREF[1]:     ram:7259(j) 
        ram:7269 3e09            LD         A,0x9
        ram:726b c9              RET


           ram:61f4 0048            addr      PTR1_BruceStand         field_0xf     Action 0 Sprite
           ram:61f6 7d70            addr      spr_StandPhase1         field_0x11    Action 0 Routine
           ram:61f8 0048            addr      PTR1_BruceStand         field_0x13    Action 1 Sprite
           ram:61fa df70            addr      spr_StandPhase2         field_0x15    Action 1 Routine
           ram:61fc 0048            addr      PTR1_BruceStand         field_0x17    2 Sprite
           ram:61fe e670            addr      spr_StandPhase3         field_0x19    2 Routine
           ram:6200 0248            addr      PTR2_BruceRun1          field_0x1b    3 Sprite
           ram:6202 b271            addr      spr_RunAnim1            field_0x1d    3 Routine
           ram:6204 0448            addr      PTR3_BruceRun2          field_0x1f    4 Sprite
           ram:6206 dc71            addr      spr_RunAnim2            field_0x21    4 Routine
           ram:6208 0648            addr      PTR4_BruceFallorJump    field_0x23    5 Sprite
           ram:620a 5372            addr      spr_Fall                field_0x25    5 Routine
           ram:620c 0a48            addr      PTR6_BruceJumpRight1    field_0x27    6 Sprite
           ram:620e 9472            addr      spr_InitJumpright       field_0x29    6 Routine
           ram:6210 0c48            addr      PTR7_BruceJumpRight2    field_0x2b    7 Sprite
           ram:6212 a672            addr      spr_Jumpright           field_0x2d    7 Routine
           ram:6214 1248            addr      PTR10_BrucePunchRight   field_0x2f    8 Sprite
           ram:6216 a872            addr      spr_Punch               field_0x31    8 Routine
           ram:6218 0848            addr      PTR5_BruceJumpUp        field_0x33    9 Sprite
           ram:621a bc72            addr      spr_Landed              field_0x35    9 Routine
           ram:621c 0848            addr      PTR5_BruceJumpUp        field_0x37    0xA Sprite
           ram:621e c872            addr      spr_JumpUpPhase2        field_0x39    0xA Routine
           ram:6220 0648            addr      PTR4_BruceFallorJump    field_0x3b    0xB Sprite
           ram:6222 ed72            addr      spr_FallJump            field_0x3d    0xB Routine
           ram:6224 1a48            addr      PTR14_BruceClimbing     field_0x3f    0xC Sprite
           ram:6226 ef72            addr      spr_Climb               field_0x41    0xC Routine
           ram:6228 0e48            addr      PTR8_BruceFlyKick1      field_0x43    0xD Sprite
           ram:622a 5f73            addr      spr_InitFlykick1        field_0x45    0xD Routine
           ram:622c 0e48            addr      PTR8_BruceFlyKick1      field_0x47    0xE Sprite
           ram:622e 9773            addr      spr_InitFlykick2        field_0x49    0xE Routine
           ram:6230 1048            addr      PTR9_BruceFlykick2      field_0x4b    0xF Sprite
           ram:6232 9a73            addr      spr_Flykick             field_0x4d    0xF Routine
           ram:6234 1448            addr      PTR11_BruceDuck         field_0x4f    0x10 Sprite
           ram:6236 d273            addr      spr_Duck                field_0x51    0x10 Routine
           ram:6238 4248            addr      PTR34_BruceFlying       field_0x53    0x11 Sprite
           ram:623a dc73            addr      spr_RunAnim3            field_0x55    0x11 Routine
           ram:623c 0000            addr      ram:0000                field_0x57    0x12 Sprite
           ram:623e 0000            addr      ram:0000                field_0x59    0x12 Routine
           ram:6240 1248            addr      PTR10_BrucePunchRight   field_0x5b    0x13 Sprite
           ram:6242 0c74            addr      spr_Punch2              field_0x5d    0x13 Routine
           ram:6244 1848            addr      PTR13_BruceGotHit       field_0x5f    0x14 Sprite
           ram:6246 1a74            addr      spr_forHitnLyingdown    field_0x61    0x14 Routine
           ram:6248 1648            addr      PTR12_BruceLyingonGround field_0x63    0x15 Sprite
           ram:624a 1a74            addr      spr_forHitnLyingdown    field_0x65    0x15 Routine
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 11. Dezember 2019, 22:44:49
Habe mal ausgetüftelt, welche Einstellungen in Ghidra nötig sind um den Quelltext rauszubekommen und welche Nachbearbeitungsschritte dann noch mit einem Texteditor nötig sind, damit WinApe den Code auch versteht. Ghidra verwendet für die Darstellung von hex- und binärwerten leider ein Format, welches Winape nicht versteht, und die Repräsentation lässt sich leider auch nicht konfigurieren. Sie liessen sich wenigstens so konfigurieren dass immer zwei Stellen bei Bytes und vier Stellen bei Words angezeigt werden, was das erstellen für Regex-Replace vereinfachte.
Das hat sauber funktioniert und Bruce-Lee lässt sich an andere Adresslagen assemblieren.



Titel: Re: Hacking Bruce Lee
Beitrag von: TFM am 12. Dezember 2019, 12:56:12
Weiter so! Scheint viel Arbeit "außen rum" zu sein. Trozdem super, dass Du weitermachst.  :)
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 15. Dezember 2019, 23:13:55
Nun, mit zunehmender Komplexität wirds zunehmend mehr Arbeit, da mehr zu bedenken ist, grade beim Viewer/Editor. Es nervt mich zunehmend an, dass ich nicht ausgetüftelt bekomme, wie das mit indizierten Farben funktioniert. Man kann nun den Pens in den Räumen andere Inks zuweisen, aber es ist unglaublich träge, da die einzelnen Tiles komplett neu gepixelt werden müssen, nur weil sich eine Ink geändert hat. Sprich die Mode 0-Pixel von den 256 Tiles werden ausgelesen in Pens zurück-kodiert und in neue 4x8 Pixel-Grafiken gepixelt und auf 16x32 gezoomt (Zumindest dafür gibts ne eingebaute Funktion). Dann wird die Tiletabelle neu aufgebaut und danach die Raumkarte... Zwischen Farbwahl und Darstellung des Krams mit geänderten Farben liegen mehrere Sekunden... (Ist schon Interessant, dass man einen Gigaherz-Prozessor mit sowas profranem in die Knie zwingen kann). 
Dem Spaß an der Sache tut das aber keinen Abbruch, da es mit dem Assemblercode dafür nun um so besser vorangeht, da man nun besser experimentieren kann und das debuggen mit Symboltabelle viel einfacher ist. Ist fast wie das englisch lernen mit Textadventures und Langenscheidt anno dunnemal, nur diesemal mit Rodey Zaks z80-Buch und dem Schneider Systemhandbuch...

Die Bedeutung der Felder der Verwaltungsstruktur der Räume ist nun vollständig bekannt, neben zwei Spawnzonen für die gegnerischen Sprites wird über 3x3 Einträge definiert, wie die Räume miteinander verkettet werden. Sprich, welcher der 9 möglichen Ausgänge zu welchem Raum führt und an welcher Stelle dort der Spawnpunkt liegt, sowie zwei Bytes für Hilfswerte um die Listenposition des Eintrags korrekt errechnen zu können.
Die Bedeutung der einzelnen Pens für die Kollisionserkennung/verwaltung ist nun auch vollständig bekannt; damit steht dann auch fest, welche Einschränkungen man beim erstellen neuer Grafiken berücksichtigen muss.


Um schon mal das Pseudo-Amstrad-Bruce Lee 2 auf Windows zu bewerten: Die Multi-Color-Sprites der neuen Gegner sind auf dem CPC nicht möglich da nur drei Farben zur Verfügung stehen.
Die Zugschalter für die Hebebrücke ist unnötige Mechanik und kann über Lampensammeln realisiert werden. Die Hebebrücke scheint auf den ersten Blick problemlos möglich. Die Schwebeplattform scheint auch möglich, sieht nach der Feuerballmechanik aus, nur wird statt nem Feuerball ein begehbares Tiles bewegt.
28 Räume... könnte funktionieren. die jetzigen zwanzig nehmen &2000 Bytes in Anspruch. Das Programm beginnt bei &1500 und endet bei &9200. Mit verlegen auf &500 müsste sich das ausgehen...
Das Schwimmen wird so eine Sache. Sieht nach der Klettermechanik, nur mit anderen Sprites, aus - leider wäre dafür kein Pen frei. Eventuell könnte man einen aus der vier-farben-Animation der "Aufzüge" klauen, wenn es gelingt, die Auf-Abwärtsbewegung der Sprites mit einem drei-Farben-Cycle zu synchronisieren, damits nicht beschissen aussieht. Für die "Aufzüge" werden Pens 4,6,12 und 14 verwendet und die "kletterfähigkeit" der Tiles mit Mode-0-Pen-Bitmasken-Magie eingegrenzt. Pen 10 gehört mit seiner Bitmaske in diesen Kreis und wird für das statische Klettergerüst verwendet.
 
                             chcl_leftpixel                                  XREF[1]:     ram:6f16(j) 
        ram:6efa 7e              LD         A,(HL)
        ram:6efb e6aa            AND        10101010b                                        ; l. Pixel BM Pen 15: BruceYellow
        ram:6efd fe0a            CP         00001010b                                        ; l. Pixel BM Pen 10: Climbable
        ram:6eff 3806            JR         C,chcl_rightpixel                                ; filters Bitmasks for PEN 2 and 8 out                                                                                           
        ram:6f01 281a            JR         Z,chcl_isclimbable                               ; PEN = 10 -> Climbable, lets pass Bitmasks for PENs 4,6,12,14
        ram:6f03 fe2b            CP         00101011b                                        ; and filters them out
        ram:6f05 381b            JR         C,chcl_iselevator                           
                             chcl_rightpixel                                 XREF[1]:     ram:6eff(j) 
        ram:6f07 23              INC        HL
        ram:6f08 7e              LD         A,(HL)
        ram:6f09 e655            AND        01010101b
        ram:6f0b fe05            CP         00000101b
        ram:6f0d 3806            JR         C,chcl_getnext
        ram:6f0f 280c            JR         Z,chcl_isclimbable
        ram:6f11 fe16            CP         00010110b
        ram:6f13 380d            JR         C,chcl_iselevator
                             chcl_getnext                                    XREF[1]:     ram:6f0d(j) 
        ram:6f15 19              ADD        HL,DE
        ram:6f16 10e2            DJNZ       chcl_leftpixel
        ram:6f18 dd360d00        LD         (IX+0xd),0x0
        ram:6f1c c9              RET
                             chcl_isclimbable                                XREF[2]:     ram:6f01(j), ram:6f0f(j) 
        ram:6f1d dd360d01        LD         (IX+0xd),0x1
        ram:6f21 c9              RET
                             chcl_iselevator                                 XREF[2]:     ram:6f05(j), ram:6f13(j) 
        ram:6f22 dd360d02        LD         (IX+0xd),0x2
        ram:6f26 c9              RET
Titel: Re: Hacking Bruce Lee
Beitrag von: TFM am 16. Dezember 2019, 14:10:58
... aber es ist unglaublich träge, da die einzelnen Tiles komplett neu gepixelt werden müssen, nur weil sich eine Ink geändert hat. Sprich die Mode 0-Pixel von den 256 Tiles werden ausgelesen in Pens zurück-kodiert und in neue 4x8 Pixel-Grafiken gepixelt und auf 16x32 gezoomt ...
Das ist wirklich bitter!
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 17. Dezember 2019, 00:32:31
Tja... ich hab die Hoffnung nicht aufgegeben, das noch performanter hinzubekommen.
Ich werd wohl ne VM mit Windows aufsetzen müssen um zu gucken, wie sich das mit Winform-Ojekten ausgeht.
Mühsam nährt sich das Eichhörnchen... ;)

Aus Spaß an der Freude hab ich mal einen Dump erstellt und geguckt, ob im Tileset ungenutzte Tiles vorhanden sind. Zwei freie Tiles sind auf jeden Fall vorhanden und die Auswertung ergab, das da noch drei, vier weitere sind, die sie nicht verwendet haben.

Damit wäre folgender Eyecandy in den vier Räumen möglich (muss da noch ein paar Tiles umdefinieren und in die Räume reinhacken):
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 18. Dezember 2019, 17:11:23
Entscheidungen, Entscheidungen...
Mit ETO.Forms existiert ein Betriebssystemübergreifendes Framework für das User-Interface womit es sich auf dem jeweiligem Host integriert nahtlos in das Oberflächendesign integriert und wie eine typische Anwendung des Host-Systems erscheint. Den API-Beschreibungen der Grafikbibliothek nach beherrscht es auch indexed Bitmaps.
Riesengroßes Manko: Es hat keinen grafischen Interface-Designer. Weder auf Windows, noch auf dem Mac noch unter Linux.
Interfacedesign in Handarbeit per XAML (kenn ich nicht), JSON (kenn ich nochweniger) oder aus c# heraus....

Ich werd wohl also erstmal gucken, ob das mit den indexed Bitmapimages funktioniert wie erhofft...

Neuprogrammierung war eingeplant, aber dass sooo weit ausgeholt werden müsste dass auch das Interface programmiert werden muss, war eigentlich nicht auf dem Zettel...
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 22. Dezember 2019, 00:25:44
Eto.Forms will nich so wie ich wohl will. Bei den indexed-Bitmaps dort werden die Pixel per Pointerzugriff angesprochen, was in C# "unsafe" ist. Scheinbar hat Monodevelop beim Aufruf des Compilers einen Bug und der Parameter scheint fehlerhaft übergeben zu werden, so daß das Programm nicht compiliert werden kann. Damit hat sich das Experimentieren in diese Richtung erstmal erledigt.

Also gehts mit der Ursprünglichen Fassung weiter und der Code wurde weiter in Richtung eines Editor getrimmt; es wird nun nicht mehr direkt auf das Binary zugegriffen sondern alles relevante in Arrays verfrachtet um ein Abspeichern/Exportieren sowie ein Laden der Änderungen zu ermöglichen.

Ein Primitiver Tileeditor funktioniert nun auch, nun werd ich mal schauen, das man die Räume auch editieren kann.
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 22. Dezember 2019, 19:05:50
So. Die Performancebremse wurde auch gefunden. Die Custom-Widgets sind schuld und gehören nochmal überdacht.
Das Programm wurde richtig langsam als ich die 440 Tiles der Raumkarte mit Custom-Widgets darstellen wollte damit sie auf Klickereignisse reagieren können.
Also habe ich die selbsterstellten Widgets mal rausgenommen und das Programm reagiert praktisch verzögerungsfrei wenn man die Inks neu zuweist.

Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 26. Dezember 2019, 22:52:30
Die Performancebremse ist nun eliminiert und die Oberfläche gibt wieder optisch Feedback, über welchem Tile der Mauszeiger grade schwebt; dieses sowohl in der Raumkarte als auch der Tilebox. Als nächstes steht nun an, ein Tile selektieren zu können und dieses per Mausklick in die Raumkarte einzubringen bzw. bei gedrückter Maustaste kontinuierlich bei Mausbewegung einzuzeichnen.

Übernächster Schritt ist dann ein RLE-Kompressor und das Speichern der Raumkarte(n) als Ascii-File für Winape und als Binärfile für den Editor (um arbeiten zu späteren Zeitpunkten fortsetzen zu können bzw. Sicherheitskopien erzeugen zu können, da ich noch keine Idee habe, wie eine Undo-Funktion zu realisieren wäre)

Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 28. Dezember 2019, 18:26:23
Es läuft grade beim Coden.
Änderungen werden bemerkt und erzeugen bei einigen Funktionen Rückfragen. (Programmende und Laderoutinen)
Funktionen für "Neues Projekt", "Projekt öffnen" und "Projekt sichern" integriert um mehrere Levelsets verwalten zu können.
Die Environtmentvariable "HOME" wird ausgelesen und dort ein Basisverzeichnis für den Editor zur Verwaltung der Projekte erzeugt.
(Unter Windows müsste es die Variable eigentlich auch geben)

Bei den Overlays bin ich noch nicht ganz zufrieden; durch die Buttons für "Eintrag hinzufügen"/"Eintrag löschen" sieht das Layout der Tabelle nun unhübsch aus.
Ähnliches gilt für die Radio-Buttons unterhalb der Raumkarte. Mit denen bin ich auch noch nicht ganz zufrieden.
Das kommt mal zum Themenkomplex die OVLs bearbeiten/anzeigen zu können.
Titel: Re: Hacking Bruce Lee
Beitrag von: oobdoo am 29. Dezember 2019, 11:22:11
Eben im Forum64 gefunden. Könnte eine Anregung für Dich sein.

https://jonathan-cauldwell.itch.io/multi-platform-arcade-game-designer
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 30. Dezember 2019, 19:09:37
Danke, auf den ersten Blick sieht das aber nicht aus wie etwas, für das ich mich begeistern könnte.

Habe die Architektur im Editor mal von fixen byte-Arrays auf flexible Listen umgestellt um die Begrenzung auf 20 Räume aufzuheben. Ein RLE-Enkoder ist nun auch fertig sowie eine Exportfunktion von allen Daten für Winapes Assembler.

Also fix mal Assembliert und Yamo beim Fallen ein anderes Sprite zugewiesen...
Und das Ergebnis stimmt optimistisch.
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 30. Dezember 2019, 19:55:21
So, im ersten Beitrag ist nun ein Diskimage und ein erster Entwurf für einen Hackinguide zu finden. Das "neue" Spiel wird mit run"brucerev" gestarted.
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 02. Januar 2020, 00:50:24
Frohes neues Jahr 2020.

Wieder ein Etappenziel erreicht: Overlays können nun per Mausklick platziert oder entfernt werden sowie die Tabelleneinträge editiert werden.

Müssen nur noch die Buttons im UI für "Raum Hinzufügen", "Eintrag hinzufügen" und "Eintrag löschen" gangbar gemacht werden und die Tabelleneinträge im Mapheader für die Verlinkung der Räume editierbar gemacht werden und der Editor wäre, von einigen noch wenigen kosmetischen Änderungen abgesehen, fertig.
Im Tileeditor muss ich noch hervorheben, welche INK grade ausgewählt ist und das Layout noch ein bischen aufhübschen.

Ein Spriteeditor ist erstmal nicht so wichtig, der kann per Update nachgereicht werden. Ebenso bin ich am noch am Überlegen ob ich einen kleinen Texteditor einbaue, mit dem man im Editor kleine Assemblerroutinen für die Events programmieren kann, die dann auch  mit Exportiert werden, oder ob ich es einfach nur beim Ausgeben von Labeln in den Headern belasse und man programmiert dann die Raumabhängigen Routinen in Winape.
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 04. Januar 2020, 02:37:36
Eigentlich ist der Editor nun für eine erste Veröffentlichung bereit. Alle Funktionen und Szenarien sind durchgetestet. Er erkennt nun auch das  Betriebssystem auf dem er läuft  und fragt das Environment nach dem jeweiligem Home-Verzeichnis ab um seine Dateistrukturen anzulegen aber uneigentlich liegen wieder Steine im Weg - unter Windows will er nicht starten obwohl die benötigten DLLs beiliegen.
Alles mögliche schon durchgetestet. Path gesetzt - nope; Gtk#-Librarys installiert - nope; mono installiert - nope...
Aus der CMD.EXE gestartet - Keine Fehlermeldung.
Im Anwendungsprotokoll sind Einträge getriggert und man landet wieder in der Googlehölle mit zigtausend Meldungen zu ähnlichen Problemen aber keinen Lösungen weil das wieder viel zu generisch ist...


Titel: Re: Hacking Bruce Lee
Beitrag von: oobdoo am 04. Januar 2020, 10:36:48
Bei mir startet es unter W10 weder mit Doppelklick noch über cmd.exe. Die Ereignisanzeige meldet .NET Runtime.

Zitat
Anwendung: BruceLeeEditor.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.IO.FileNotFoundException
   bei BruceLeeEditor.MainClass.Main(System.String[])

Demnach fehlt irgend eine Datei. https://www.heise.de/download/product/process-monitor-38423 sollte unter Windows in solchen Fällen weiterhelfen.
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 04. Januar 2020, 14:13:29
Bei mir startet es unter W10 weder mit Doppelklick noch über cmd.exe. Die Ereignisanzeige meldet .NET Runtime.

Zitat
Anwendung: BruceLeeEditor.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.IO.FileNotFoundException
   bei BruceLeeEditor.MainClass.Main(System.String[])

Demnach fehlt irgend eine Datei. https://www.heise.de/download/product/process-monitor-38423 sollte unter Windows in solchen Fällen weiterhelfen.

Bei der Fassung liegen die nötigen DLLs nicht bei, insofern war das zu erwarten.

In einem Mailinglist-Posting von 2009 habe ich scheinbar die Lösung gefunden, da es auf meinem Virtual-Box-Window nun durchstartet.
Neue Fassung im Anhang anbei.

Titel: Re: Hacking Bruce Lee
Beitrag von: oobdoo am 04. Januar 2020, 17:13:20
Keine Reaktion mit Doppelklick oder CMD.

Zitat
Anwendung: BruceLeeEditor.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: System.DllNotFoundException
   bei GLib.Marshaller.g_utf16_to_utf8(Char*, IntPtr, IntPtr, IntPtr, IntPtr ByRef)
   bei GLib.Marshaller.StringToPtrGStrdup(System.String)
   bei GLib.Global.set_ProgramName(System.String)
   bei Gtk.Application.SetPrgname()
   bei Gtk.Application.Init()
   bei BruceLeeEditor.MainClass.Main(System.String[])
Titel: Re: Hacking Bruce Lee
Beitrag von: Fessor am 04. Januar 2020, 18:22:15
Das ist schon eine Fehlermeldung aus dem Programminneren. Die beiliegenden DLLs taugen offenkundig nur für Linux. Bei mir war gtk# noch vom experimentieren installiert. Wenn ichs deinstalliere krieg ich die gleiche Fehlermeldung.

Bei Windows müssen die Libs also offenbar extra installiert werden: https://xamarin.azureedge.net/GTKforWindows/Windows/gtk-sharp-2.12.45.msi

Ich werds beim nächsten Release beilegen.