Posts by KillBill_158

  • Splatterworld: Rick to Kyoufu no Daiou

    Super, danke an alle fürs Testen und für die Rückmeldungen! 👍

    Dann würde ich vorschlagen, dass wir die aktuelle Version jetzt erst einmal noch ein bisschen testen lassen – vor allem auf den verschiedenen Setups (Everdrive, Emulatoren, Handhelds usw.).

    Wenn noch kleinere Dinge auftauchen, können wir danach eventuell noch einen finalen Patch 1.21 nachschieben.

    Lasst uns dafür aber ungefähr eine Woche Zeit, damit jeder Gelegenheit hat, die aktuelle Version zu testen und hier Feedback zu posten.

    Wenn danach nichts Größeres mehr auftaucht, können wir das Projekt dann auch guten Gewissens abschließen.

  • SNES Releases und Neuerscheinungen

    Ich muss hier wirklich mal ein massives Respect-Packet ins Retro-Netzwerk broadcasten. 💾🔥

    Das Video zu Super Dragon’s Lair Arcade auf dem SNES fühlt sich an wie ein legitimer Exploit gegen die physikalischen Limits der 16-Bit-Hardware.

    Für Kontext:
    Das originale Dragon’s Lair aus den 80ern war kein normales Spiel – das war praktisch ein interaktiver Zeichentrickfilm mit Animationen in Kinoniveau von Don Bluth. In der Arcade liefen diese Szenen direkt von einer Laserdisc, während der Spieler im richtigen Moment die richtige Richtung drücken musste. Falscher Input bedeutete sofort eine der legendären Death-Animationen von Dirk dem Draufgänger.

    Und genau deshalb ist dieses Projekt so mindblowing.

    Das Ganze Konzept – ein animierter Film mit Quick-Time-Inputs – auf eine SNES-Cartridge-Hardware zu bringen, ist eigentlich komplett gegen die ursprüngliche Design-Philosophie der Konsole. Das SNES wurde für Sprites, Tilemaps und klassische Spielmechaniken gebaut – nicht dafür, riesige animierte Sequenzen zu streamen.

    Im Video sieht man aber, dass genau das hier passiert.

    Die klassischen Szenen laufen auf echter SNES-Hardware, Dirk stolpert durch die Fallen der Burg, falsche Richtungen triggern sofort die ikonischen Death-Sequenzen, und das Timing der Inputs fühlt sich erstaunlich nah am Arcade-Original an. Die Animationen wirken für eine 16-Bit-Konsole überraschend flüssig und zeigen, wie weit man Hardware treiben kann, wenn man sie wirklich versteht.

    Und jetzt kommt der vielleicht coolste Teil an der ganzen Sache:

    Diese geballte technische Power kommt aus der Retro-Homebrew-Szene – und hier haben zwei Entwickler ihre Skills kombiniert, um die SNES-Hardware ordentlich durch den Debugger zu jagen.

    Massiver Respekt an Mathias Nagler, besser bekannt als d4s, der in der Szene für seine tiefgehenden Hardware-Kenntnisse bekannt ist. Man merkt sofort, dass hier jemand am Werk war, der das SNES nicht einfach nur benutzt, sondern wirklich bis auf Register-Level versteht.

    Genauso darf man aber astrobleem, den Entwickler hinter dem Projekt-Repository und der Umsetzung des Homebrew-Releases, absolut nicht vergessen. Ohne diese Zusammenarbeit würde dieses Projekt in dieser Form wahrscheinlich gar nicht existieren.

    Das Ganze fühlt sich extrem nach klassischer Demoscene-Mentalität an:
    Man schaut sich die Limits der Hardware an, akzeptiert sie nicht einfach – und findet dann trotzdem einen Weg, etwas zu bauen, das laut Spezifikation eigentlich gar nicht möglich sein sollte.

    Während viele alte Heimkonsolen-Ports von Dragon’s Lair komplett andere Spiele werden mussten, weil die Filmsequenzen technisch nicht darstellbar waren, zeigt dieses Projekt eindrucksvoll, was mit genug Optimierung, Reverse-Engineering und Leidenschaft für Retro-Hardware möglich ist.

    Kurz gesagt:
    Das ist kein normales Homebrew-Spiel.
    Das ist 16-Bit-Engineering, Retro-Liebe und Hacker-Mindset in einem Projekt.

    Massiven Respekt an d4s und astrobleem für diese beeindruckende technische Leistung.

    Ganz klar: 10/10 – würde ich sofort auf echter Hardware booten und jedem Retro-Nerd weiterempfehlen. 🚀

  • Super Fanger

    Moin zusammen! Dass beakful_bits sein Projekt Super Fanger höchstpersönlich bei uns im Forum bewirbt, ist mal eine Ansage und zeigt, dass die Homebrew-Szene hier bei uns lebt und bebt! Nachdem das Game am 7. Januar 2026 im "Nintendo Triple Launch Trailer" offiziell angekündigt wurde, ist es seit dem 29. Januar 2026 endlich über den Shop von Mega Cat Studios am Start. Für alle, die es noch nicht auf dem Schirm haben: Das Teil ist ein absolut hektischer Maze-Chaser, der den klassischen Arcade-Vibe perfekt einfängt. Du hast die Wahl aus verschiedenen Charakteren mit einzigartigen Fähigkeiten und musst dich durch vier unterschiedliche Maps kämpfen, die jeweils ihre eigenen fiesen Twists haben. Das Gameplay lebt vom Momentum – wer stehen bleibt oder den Faden verliert, hat sofort verloren. Dass Mega Cat das Spiel zusammen mit Titeln wie Plyuk und Old Towers in einem "Triple Launch" rausgebracht hat, unterstreicht nur, wie viel Polishing in beakful_bits' Code steckt. Es ist kein billiger Abklatsch, sondern ein grundsolider Titel, der zeigt, was man 2026 noch aus der alten SNES-Hardware rauskitzeln kann, wenn man mit Herzblut dabei ist. Wer also Bock auf knackige Highscore-Jagden im Solo-Modus oder ein hitziges Versus-Match gegen Kumpels hat, sollte sich das Modul definitiv krallen. Fetten Respekt an beakful_bits für diesen Release – so was pusht die ganze Community!

    Cheers 🥂

  • Splatterworld: Rick to Kyoufu no Daiou

    Alter, was für ein Brett! Dass dieses Splatterworld-Ding nach über 30 Jahren im Giftschrank doch noch das Licht der Welt erblickt hat, war ja schon der Leak des Jahres, aber dass du dir die Kiste direkt ohne den Sourcecode von Gideon Zhi vorgenommen und die DTE-Kompression mit 120 Einträgen umgeschrieben hast – fetter Respekt für den Grind! Die Splatterhouse-Reihe ist eh Kult, und ein RPG-Spin-off ist genau der weirde Kram, auf den die Szene gewartet hat. Was den Disclaimer zu den Diktatoren und dem „besagten Schnurrbart-Typen“ angeht: Vollstes Verständnis. In den 80er/90er Jahren waren die japanischen Devs da schmerzfrei und haben alles in den Mixer geworfen, was irgendwie „böse“ oder „bedrohlich“ aussah. Das als Zeitdokument unzensiert zu lassen, ist in der Romhacking-Szene ja eh der Goldstandard für Authentizität, solange man sich klar davon distanziert – und das hast du ja mehr als deutlich gemacht.

    Zu deinem Speicher-Problem: Wenn der Emulator kein .sav-File ausspuckt, liegt das zu 99,9 % am iNES-Header. Emulatoren sind da strunzdumm: Wenn im Header das „Battery-backed RAM“-Flag nicht gesetzt ist, wird erst gar kein Speicher reserviert oder weggeschrieben. Check mal im Hex-Editor das Byte 6 deines Headers. Da müssen die Bits richtig sitzen. Konkret: Bit 1 (das zweite Bit von rechts) muss auf 1 stehen, damit der Emulator weiß: „Aha, hier ist eine Batterie für den SRAM verbaut.“ Wenn du das Byte zum Beispiel von 0x10 auf 0x12 (oder was auch immer da steht + 2) änderst, sollte der Emulator beim Schließen brav die Save-Datei anlegen. Falls das Mapping durch den Hack verschoben wurde, könnte es auch sein, dass der Mapper-Typ im Header nicht mehr zum Code passt, aber fang erst mal beim Battery-Flag an.

    Richtig geil, dass du das Projekt trotz des Zeitaufwands so entspannt durchziehst. Wenn der Beta-Test durch ist, sag Bescheid – das Teil will ich unbedingt auf Hardware (oder zumindest dem Emu) rotieren sehen.

    Cheers 🥂

  • Conker’s Bad Fur Day

    Man könnte ja so Sachen nehmen wie „Zum Selbst ist der Mann“, „Zum Hand anlegen“, „Zur Handarbeit“ oder „Zum Handgriff“ – klingt alles ein bisschen sprichwörtlich und subtil, ohne zu sehr in die Vollen zu gehen.

    Aber mal ehrlich: Wir wissen doch, worauf das Original hinauswill – „Cock Sucker“ oder „Cock Fucker“, also auf Deutsch etwa „Schwanzlutscher“ oder „Ficker“. Deshalb würde ich etwas wie „Zum Eichelputzer“ nehmen – mein absoluter Favorit da auch eine schöne Anspielung auf das Eichhörnchen. Eindeutig, witzig und trotzdem pub-tauglich.

    Wenn man es dagegen wirklich harmlos nehmen wollte, könnte man fast wörtlich übersetzen: „Zum Hühnchen rupfen“ (Cock = Hahn, Plucker = zupfen). Aber seien wir ehrlich – beim Spiel ist das wohl kaum gemeint. 😏

  • (PS2) Berwick Saga deutsches Übersetzungsprojekt (ROMhack)

    Es fehlen noch die Hash-Werte der ISO. Auch wenn der Delta-Patcher später ohnehin eine vollständige und passende ISO voraussetzt, sind die Hash-Werte hilfreich, um die richtige Version schneller zu finden und eindeutig zu identifizieren. Mit dem Hash kann man sicherstellen, dass man genau die ISO nutzt, für die der Patch vorgesehen ist, und so mögliche Fehler oder Inkompatibilitäten von Anfang an ausschließt.  :red_heart:

  • Huffman-Komprimierung im Detail

    0.) Allgemeine Info (kurz)


    Huffman-Coding ist eine verlustfreie, präfixfreie Kompression: häufige Zeichen bekommen kürzere Bitfolgen – perfekt zum effizienten Speichern und Dekomprimieren. 


    1.) Beispiel-Eingabe:

    "ABRACADABRA"

    • Länge: 11 Zeichen → ursprünglich 11 × 8 Bit = 88 Bit.
    • Zählen der Häufigkeiten:
      • A: 5, B: 2, R: 2, C: 1, D: 1

    2.) Sortieren & Baum bauen

    1. Lege jede Zeichen-Frequenz als Blatt an und sortiere (Priority Queue):
      [C:1, D:1, B:2, R:2, A:5]
    2. Nimm die beiden geringsten → C(1)+D(1)=2 → neuer Knoten [CD:2].
    3. Queue neu sortiert: [B:2, R:2, CD:2, A:5]
    4. Weiter so: B(2)+R(2)=4 → [BR:4]
    5. Nochmals: CD(2)+BR(4)=6 → [CD/BR:6]
    6. Schließlich: A(5)+6=11 → Root [gesamt:11]
      So entsteht der Huffman-Baum.

    3.) Bitcodes zuweisen

    • Linker Zweig = 0, rechter = 1.
    • Lauf durch den Baum zum Blatt = Code:

    Zeichen

    Code

    A

    0

    R

    10

    B

    111

    C

    1100

    D

    1101

    4.) Kodieren des Strings


    Original: A B R A C A D A B R A

    Bitfolgen ersetzen:

    Ergebnis:


    🎯 Was ist Canonical Huffman- Codierung?


    Beim Standard-Huffman müssen Baumstruktur und Codewörter übertragen werden – das kostet Platz. Bei der kanonischen Version reicht es, nur Code‑Längen zu speichern. Der Empfänger kann dann die Codes selbst rekonstruiert erzeugen .


    🔄 1. Ausgangslage: Normale Huffman-Codes

    Aus dem Standard-Huffman-Prozess für “ABRACADABRA” haben wir z. B. folgende Code-Längen:

    Code
    Symbol : Häufigkeit : Länge
A      : 5           : 1
B      : 2           : 3
R      : 2           : 3
C      : 1           : 4
D      : 1           : 4

    (Details wie im bisherigen Beispiel mit dem Baum.)


    📊 2. Kanonischer Prozess: Sortieren

    Sortiere nach Code-Länge, dann alphabetisch:

    Code
    1 bit: A
3 bit: B, R
4 bit: C, D

    🧮 3. Kanonische Codes berechnen

    • Erstes Symbol jeder Länge bekommt den kleinstmöglichen Code (alles Nullen).
    • Danach: vorheriger Code + 1, dann bei Längensprung nach links shift bis zur neuen Länge.

    Schritt-für-Schritt:

    1. A (1 Bit)
      • Start bei 0 → Code: 0
      • nextCode = 0 + 1 = 1
    2. B (3 Bit)
      • Längensprung von 1 auf 3 → shift left um (3−1)=2 → 1<<2 = 4 (100)
      • Code für B = 100
      • nextCode = 4 + 1 = 5
    3. R (3 Bit)
      • gleiche Länge → kein shift → nextCode = 5 (101) → Code 101
      • nextCode = 5 + 1 = 6
    4. C (4 Bit)
      • Längensprung von 3 auf 4 → 6<<1 = 12 (1100) → Code 1100
      • nextCode = 12 + 1 = 13
    5. D (4 Bit)
      • gleiche Länge → nextCode = 13 (1101) → Code 1101
      • nextCode = 13 + 1 = 14

    Kanonische Codes:

    Code
    A = 0
B = 100
R = 101
C = 1100
D = 1101

    📦 4. Kodieren mit kanonischen Codes

    String: A B R A C A D A B R A

    Ersetzungen:

    Code
    A → 0
B → 100
R → 101
C → 1100
D → 1101

    Resultierende Bitfolge:

    Code
    0 100 101 0 1100 0 1101 0 100 101 0
= 0|100|101|0|1100|0|1101|0|100|101|0

    Gesamtlänge: 1 + 3 + 3 + 1 + 4 + 1 + 4 + 1 + 3 + 3 + 1 = 25 Bit

    Minimal über Standard-Huffman (23 Bit), aber nur Code-Längen sind kodiert – also sparen wir Baum-Overhead.

    🎯 Vorteile

    • Du speicherst nur [1,3,3,4,4] statt ganzer Baumstruktur.
    • Empfänger baut Codes neu auf, spart Bytes.
    • Schnelle Decodierung durch einfache Inkremente und Shifts.

    ✅ Zusammenfassung

    1. Normale Huffman-Codes errechnen & Längen speichern
    2. Sortieren nach Länge/Alphabet
    3. Kanonische Codes mit Sequenz, Shifts & Inkrementen erzeugen
    4. Nur Längen mitsenden, Empfänger rekonstruiert Codes

    Cheers 🥂