Welcome to Schneider / Amstrad CPC Forum. Please login or sign up.

28. March 2024, 18:35:43

Login with username, password and session length

Shoutbox

TFM

2024-01-15, 17:06:57
Momentan billige Farbbänder auf Ebay für PCW

Devilmarkus

2023-07-09, 10:37:40
Zweiter 👋😂🤣

TFM

2023-06-13, 14:21:49
Sommerloch!

TFM

2023-05-30, 17:00:20
Erster ;-)

Recent

Members
Stats
  • Total Posts: 11,654
  • Total Topics: 1,328
  • Online today: 101
  • Online ever: 1,724
  • (16. January 2020, 00:18:45)
Users Online
Users: 2
Guests: 100
Total: 102

100 Guests, 2 Users
xesrjb, Rennert

Hacking Bruce Lee

Started by Fessor, 13. November 2019, 23:07:58

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Fessor

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

Fessor

#16
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

oobdoo

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.
CPC 464/6128, 464/6128+, GX4000 | Atari 2600, 600XL, 800XL/XE, Portfolio | C64/II/G/R/SX, VC20, TC64 | LC 80, MPF-I | ZX81, AX81, ZX Spectrum 48k, ZX Spectrum+2 | Amiga 500/600/2000, A2630, A2088

Fessor

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.

TFM

Gute Arbeit Fessor! Weiter so!  :smiley027:
TFM of FutureSoft
http://www.futureos.de --> Das Betriebssystem FutureOS (Update: 20.12.2023)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> RSX ROM für LambdaSpeak (Update: 26.12.2021)

oobdoo

Quote from: Fessor on 26. November 2019, 23:27:42
So langsam krieg ich C# und die Designphilosophie von GTK in den Griff.
:jubelaola:
CPC 464/6128, 464/6128+, GX4000 | Atari 2600, 600XL, 800XL/XE, Portfolio | C64/II/G/R/SX, VC20, TC64 | LC 80, MPF-I | ZX81, AX81, ZX Spectrum 48k, ZX Spectrum+2 | Amiga 500/600/2000, A2630, A2088

Fessor

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...





Fessor

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.

Fessor

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...


Fessor

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


Fessor

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.




TFM

Weiter so! Scheint viel Arbeit "außen rum" zu sein. Trozdem super, dass Du weitermachst.  :)
TFM of FutureSoft
http://www.futureos.de --> Das Betriebssystem FutureOS (Update: 20.12.2023)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> RSX ROM für LambdaSpeak (Update: 26.12.2021)

Fessor

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


TFM

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!
TFM of FutureSoft
http://www.futureos.de --> Das Betriebssystem FutureOS (Update: 20.12.2023)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> RSX ROM für LambdaSpeak (Update: 26.12.2021)

Fessor

#29
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):