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
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:
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. ;)
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. :)
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.
Das wird! :jubelaola:
Welchen Reassembler hast Du verwendet?
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.
Bin aber grade dabei, mich in ghidra einzuarbeiten; da kann man alles schön mit GUI machen.
https://www.ghidra-sre.org/
Quote from: Fessor on 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/
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
Quote from: oobdoo on 17. November 2019, 16:55:58
Quote from: Fessor on 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/
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 ;)
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...
Doch besser alles neu machen mit anständiger Grafik?
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.
Eine neue Grafik kann man auch aus der 64er Version klauen. :zwinker0018:
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
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
Quote from: Fessor on 21. November 2019, 23:55:19
wenn alles durchgelabelt und der Code wieder assemblierbar ist
Das soll mein Disassembler unter Windows mal alles können und noch viel mehr.
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.
Gute Arbeit Fessor! Weiter so! :smiley027:
Quote from: Fessor on 26. November 2019, 23:27:42
So langsam krieg ich C# und die Designphilosophie von GTK in den Griff.
:jubelaola:
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...
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.
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...
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
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.
Weiter so! Scheint viel Arbeit "außen rum" zu sein. Trozdem super, dass Du weitermachst. :)
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
Quote from: Fessor on 15. December 2019, 23:13:55
... 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!
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):
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...
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.
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.
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)
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.
Eben im Forum64 gefunden. Könnte eine Anregung für Dich sein.
https://jonathan-cauldwell.itch.io/multi-platform-arcade-game-designer
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.
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.
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.
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...
Bei mir startet es unter W10 weder mit Doppelklick noch über cmd.exe. Die Ereignisanzeige meldet
.NET Runtime.
QuoteAnwendung: 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.
Quote from: oobdoo on 04. January 2020, 10:36:48
Bei mir startet es unter W10 weder mit Doppelklick noch über cmd.exe. Die Ereignisanzeige meldet .NET Runtime.
QuoteAnwendung: 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.
Keine Reaktion mit Doppelklick oder CMD.
QuoteAnwendung: 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[])
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.
Die letzte Antwort von Fessor war im Jannuar. Ich hoffe er halt bald wieder Zeit für sein Projekt.