6 ms·

This is fantastic. It would be interesting to have Claude Code export an engineering guide for doing similar ports, including descriptions of the tooling it bui

This is fantastic. It would be interesting to have Claude Code export an engineering guide for doing similar ports, including descriptions of the tooling it built to do it. I've done some reversing from binary but never with results this good.

rabahs 13d ago
This is a great idea. It could be a generic game porting skill to make the porting experience smoother. After my experience above. I have actually tried giving Claude binary files of games and it was able to reverse engineer to GoDot!
- sedawkgrep 13d ago
  > I have actually tried giving Claude binary files of games and it was able to reverse engineer to GoDot! Oh wow...I hadn't even thought of trying something like this. There are soooo many games from that era that I'd love to play again without the hackery of emulation.
  - ericd 13d ago
    Yeah, someone reverse engineered Red Alert 2 recently. Took Fable cranking for almost a month, but it's pretty amazing to see.
    - asimovDev 13d ago
      https://github.com/harshilmathur/openra2 https://github.com/harshilmathur/openra2 this is the closest thing I could find. do you have a link to the reverse engineered RA2? I am surprised I do not get any recent repositories or forum posts about this, you'd think it would be more talked about
  - rabahs 13d ago
    Just grab any game, especially old rom files form the 80s (I tried TimePilot and Road Fighter from MSX era). The model extracted the graphics, the sounds and then built the whole game. It takes less than 1 hour to port a 16kb rom file, in one shot. You will get a playable game, but you need a few follow up prompts to get it back to its original form. Usually some sprites or sounds issues, but very easy to fix, if you have played the original game.
    - WarcrimeActual 13d ago
      So by old ROM files, you mean still PC games or MSX, Sega, NES, SNES? And when you have them in place what do you specifically ask Claude? This is interesting and I'd love to see if it can get me porting old games with zero coding knowledge.
      - rabahs 13d ago
        Yes, you can try your game out. I tried with old msx rom files and it worked.
- hnlmorg 13d ago
  Dumb question this, but how do you load it into Claude? I’ve only seen APIs for text and image uploads. Not random files. Or maybe that’s a limitation of the SDK I’m using?
  - rabahs 13d ago
    With Claude Code command line, you can point to any directory you have in your file system. In this case, Claude Code was working across three directories: the original game in assembly, the 2010 port in C++, and the new Godot port.
- Steve16384 12d ago
  This is amazing. How long did that process take? Was it almost just a case of giving Claude the binary files and then prompting "please recreate this in Godot"?
  - rabahs 12d ago
    I tried it with 16k roms. It does take less than 1 hour but if you want to tweak and make playable, you will need half day
asimovDev 13d ago
session stored on the drive would also contain all of the tool calls , right? unless op changed the default settings it would've expired though by now, since the run was in July
- rabahs 13d ago
  That's a good point. I looked at the git history for my analysis. What is the best way to analyze claude sessions history? I definitely check if I still have them stored. Thanks
  - asimovDev 13d ago
    sessions are stored in the home folder somewhere but are deleted after 30 days by default. it won't be stored in the bash history, at least it does not for me on macOS with zsh + omz
    - b112 13d ago
      Of course is one does nightly, off site backups, all is well! A friendly note to all, always have backups!
ecliptik 13d ago
I'm doing something similar for DOS SDL ports. Repo isn't public yet, but idea is to have a repo with a knowledge base, skills and patches agents can use when porting to avoid having to bootstrap everything from scratch.
- 1313ed01 13d ago
  Porting to DOS sounds like a great plan for retro games, to only have to do the port once and know there are stable emulators to run it in, as opposed to porting to some modern OS and then have to port the game again and again to keep up with API changes.
  - ndiddy 12d ago
    I'm assuming they mean SDL ports of DOS games. SDL is actually one of the most stable libraries that a native game can use. They make breaking changes to the API once every 10-15 years, and they write a compatibility layer that implements the previous version's API using the current version's API as a backend. This has happened twice so far, so there's an SDL 1.2 implementation that uses SDL 2 and an SDL 2 implementation that uses SDL 3. These can be chained together, so for example you can run an SDL 1.2 game from the early 2000s on a modern Linux system and it'll have native Wayland and Pipewire support thanks to using SDL 3 behind the scenes.

rabahs 13d ago

This is a great idea. It could be a generic game porting skill to make the porting experience smoother. After my experience above. I have actually tried giving Claude binary files of games and it was able to reverse engineer to GoDot!

sedawkgrep 13d ago
> I have actually tried giving Claude binary files of games and it was able to reverse engineer to GoDot! Oh wow...I hadn't even thought of trying something like this. There are soooo many games from that era that I'd love to play again without the hackery of emulation.
- ericd 13d ago
  Yeah, someone reverse engineered Red Alert 2 recently. Took Fable cranking for almost a month, but it's pretty amazing to see.
  - asimovDev 13d ago
    https://github.com/harshilmathur/openra2 https://github.com/harshilmathur/openra2 this is the closest thing I could find. do you have a link to the reverse engineered RA2? I am surprised I do not get any recent repositories or forum posts about this, you'd think it would be more talked about
- rabahs 13d ago
  Just grab any game, especially old rom files form the 80s (I tried TimePilot and Road Fighter from MSX era). The model extracted the graphics, the sounds and then built the whole game. It takes less than 1 hour to port a 16kb rom file, in one shot. You will get a playable game, but you need a few follow up prompts to get it back to its original form. Usually some sprites or sounds issues, but very easy to fix, if you have played the original game.
  - WarcrimeActual 13d ago
    So by old ROM files, you mean still PC games or MSX, Sega, NES, SNES? And when you have them in place what do you specifically ask Claude? This is interesting and I'd love to see if it can get me porting old games with zero coding knowledge.
    - rabahs 13d ago
      Yes, you can try your game out. I tried with old msx rom files and it worked.
hnlmorg 13d ago
Dumb question this, but how do you load it into Claude? I’ve only seen APIs for text and image uploads. Not random files. Or maybe that’s a limitation of the SDK I’m using?
- rabahs 13d ago
  With Claude Code command line, you can point to any directory you have in your file system. In this case, Claude Code was working across three directories: the original game in assembly, the 2010 port in C++, and the new Godot port.
Steve16384 12d ago
This is amazing. How long did that process take? Was it almost just a case of giving Claude the binary files and then prompting "please recreate this in Godot"?
- rabahs 12d ago
  I tried it with 16k roms. It does take less than 1 hour but if you want to tweak and make playable, you will need half day

asimovDev 13d ago

session stored on the drive would also contain all of the tool calls , right? unless op changed the default settings it would've expired though by now, since the run was in July

rabahs 13d ago
That's a good point. I looked at the git history for my analysis. What is the best way to analyze claude sessions history? I definitely check if I still have them stored. Thanks
- asimovDev 13d ago
  sessions are stored in the home folder somewhere but are deleted after 30 days by default. it won't be stored in the bash history, at least it does not for me on macOS with zsh + omz
  - b112 13d ago
    Of course is one does nightly, off site backups, all is well! A friendly note to all, always have backups!

ecliptik 13d ago

I'm doing something similar for DOS SDL ports. Repo isn't public yet, but idea is to have a repo with a knowledge base, skills and patches agents can use when porting to avoid having to bootstrap everything from scratch.

1313ed01 13d ago
Porting to DOS sounds like a great plan for retro games, to only have to do the port once and know there are stable emulators to run it in, as opposed to porting to some modern OS and then have to port the game again and again to keep up with API changes.
- ndiddy 12d ago
  I'm assuming they mean SDL ports of DOS games. SDL is actually one of the most stable libraries that a native game can use. They make breaking changes to the API once every 10-15 years, and they write a compatibility layer that implements the previous version's API using the current version's API as a backend. This has happened twice so far, so there's an SDL 1.2 implementation that uses SDL 2 and an SDL 2 implementation that uses SDL 3. These can be chained together, so for example you can run an SDL 1.2 game from the early 2000s on a modern Linux system and it'll have native Wayland and Pipewire support thanks to using SDL 3 behind the scenes.