Hey, author of the project here! Thanks for posting! It's been a really fun project to work on, and a great way to learn about how to use Claude more efficiently. I'm just a few hours away from posting a big update with:
64dd on original 3DS
Local & Online Multiplayer
QR Code sharing for Custom Courses
I hope ya'll check out the authors notes, post-morterm, and give it a try on your 3DS.
Look, I'm gonna say what's been said a lot of times, but bears repeating: when the very first two or three sentences I read are mind-blanketing AI prose breathlessly em-dashing together fragments of stuff I don't care about, it makes me skeptical that there's value perusing the rest of the project. Like, you can't even be bothered to make your lede some form of human-to-human communication.
In the "Read On" section at the bottom it says "Author's notes: The one page written by a human." Seems they're pretty open about everything being written with Claude.
Appreciate it, but the info is there for anyone (or their LLM) to learn about the project in a technical sense. Like others have kindly stated, my notes (written by a human, for humans) are in a separate section.
The technical notes are dense and interesting in their own right, but I don't expect anyone not already familiar with the N64 to 3DS port scene to care.
Haven't had a chance to check the project out yet, but wanted to say I love the idea of having a section dedicated to your human-written thoughts. It's the best of both worlds, with as much detail as possible throughout, but also still getting to hear from you personally. Congrats!
Thanks! As fun as the project is, the scope of it is not lost on me. I wanted it to serve as evidence of the frightening power these recent models have, and make it clear.
I’m curious why people have started using the 3DS as the gateway device for ports of games, like Melee and F-Zero X.
Don’t get me wrong, the 3DS is a gem of a console, and it harks back to when Nintendo put more thought into what they released instead of just another Mario sports game; but since the Switch is so much more powerful, I’d expect ports to that be more of a priority.
Not sure why others are doing it, but the switch is kind of a boring console imo. You may as well just use one of the million PC handhelds with the same form factor, and persistent hacks require a hardware mod.
The 3DS is a fun pocketable form factor which a lot of people already own and easy to permanently mod on any firmware version or hardware revision.
I'm surprised no one has mentioned online: most people don't want to risk console bans, and that immediately makes jailbreaking their Switch a non-starter
At this point most people getting a 3DS are probably doing so specifically to jailbreak it
The Switch is powerful enough it could just straight emulate an N64 game if it needed to. It has a huge back catalog of games where it does this. It's basically a computer on the level of a mobile phone or tablet, or a laptop from 15 years ago.
The 3DS is still a _console_, purpose built and limited in what it can do. It is also approachably easy to find a good one in working order, and still has the vibe of a retro console.
One non-obvious reason might be that it's the only handheld console with a natively 240p height screen. This means all the 2d ui elements will remain crisp at the same size as they would be on original hardware.
Jailbroken 3DS scene is usually for modding the console OS itself given how easy it is to run custom firmware. And for ports, and emulation. While the GBA has a pretty dedicated community for custom games and romhacks, people often create games for the platform at gamejams because of how great the dev tooling is. It's a bit lackluster on the 3DS, but I did find the Love Brew[0] framework to be really nice. Even has simulator support[1] for testing your builds locally, though fonts will look much different on real hardware, with likely a bunch of other gotchas. Running out of RAM being a big one.
edit: compared it to the GBA homebrew scene since it's a large dedicated community to derive pros and cons between the two from. Switch is still receiving updates from Nintendo to brick your system.
It is. Any 3DS can be jailbroken with CFW with a simple Internet guide and no physical modifications. As far as I know, the Switch CFW is locked to only V1 motherboards or modchips, making it far less accessible even if it is more powerful.
The costings here are based on API pricing, but my understanding is that no one is paying the API pricing and everyone uses the subscription pricing, or even multiple accounts with a subscription each. I'd be interested to know the actual cost incurred here.
I think the API pricing is a good proxy for "what was the actual physical cost of doing this," but even if you increase it from 5k to 30k or even 100k, it's a huge savings over getting a human to do it, AND it was faster.
I don't think the productivity gains from AI can be ignored for contexts like this. It's what they're best at.
I just hope it goes to good uses (more ports of fun games, more interoperability and opennesS) instead of bad ones (firing humans instead of retasking them), and that hope feels faint.
In no way am I suggesting that doing this without AI would be more practical. What I want to know is roughly how much is Anthropic subsidizing this stuff through the subscriptions currently and how much we can expect the real price paid to go up in the future.
Yep, I agree. Further in the notes it's mentioned this probably would've taken a handful of Senior Engineers anywhere from 6 months to 2 years. The range of budget on the project is like $200 to $500k. This was done for peanuts in my spare time. I share both your optimism and pessimism, depending on the day, lol.
This is so cool! I've been working on trying to minimize the F-zero render loop to fit on gameboy and multiplayer over the link cable...it's been a journey. (I rushed the writeup cus of this article--still polishing the text), but give the game a try on the in-browser emulator: https://fireflyk64.github.io/makingfsub/
I love that idea! Please let me know if it's of any help :-)
Since the Playdate doesn't have any of the sprite rendering hardware that made the gameboy both underpowered in compute and overpowered in graphics at the time, some of the tricks may be unnecessary.
I suppose you could do some kind of shift of a whole row of the framebuffer easily with a memmove sort of operation. The gameboy's shift registers and the per sprite drawing are what really made this both difficult and possible at such a slow CPU clock speed. The playdate CPU is about 40x faster than that on the gameboy, so probably all these kinds of tricks and more would work just fine.
I had been working on getting claude to port Super Metroid to the Gameboy Advance. Was mostly curious if the GBA could run it at full speed. Looks like, yes!
I’m almost done with a port of two games from the original Xbox to modern platforms. While having a good background in assembly and understand of why x87 is problematic and SSE makes life a little easier to understand what it’s doing. And I’ve offered a few suggestions that I thought were useful but it’s been shockingly hands off
Well this is interesting to see. I was thinking of porting my game to 3DS which is based on my memories of playing F-Zero X (mainly trying to make it as fast as possible!)
Now I’ll have to do it and see how they compare. I purposefully avoided playing it again during development so it’ll be most curious.
It's already done. The race sim is fully deterministic so the consoles exchange controller inputs and run off the same seed. It uses the underlying VS. mode for the scaffolding but changes the screen render to full for each player.
The 3DS fillrate budget is the interesting constraint here. F-Zero X was already doing a lot with the N64 T&L pipeline; mapping that onto a tiled GPU without dropping the 60fps target is the part I'd want more numbers on.
Good instinct, the bottleneck is on the CPU side though. The PICA200 is an immediate-mode GPU not a tiler.
Other F-Zero X ports feed the N64 display lists to an interpreter, command by command, with the T&L on CPU. Pre-v1.0 of this port took that approach but did some double buffering on another CPU core.
When porting to Old 3DS, that other core wasn't an option, so we had to make better batch calls to the GPU. It ended up being that now we walk that list the first time and group triangles that share the same material, and moved the position & rotation transformations to the GPU too.
Rather than creating the mesh for tracks out of the spline on the fly, it also precomputes at the start of the race.
I'm fairly certain this is a pretty novel implementation for a N64 to 3DS port.
Most of these optimizations are just for race elements, which is why some of the menus are still pretty laggy.
Hey, author of the project here! Thanks for posting! It's been a really fun project to work on, and a great way to learn about how to use Claude more efficiently. I'm just a few hours away from posting a big update with:
64dd on original 3DS
Local & Online Multiplayer
QR Code sharing for Custom Courses
I hope ya'll check out the authors notes, post-morterm, and give it a try on your 3DS.
Look, I'm gonna say what's been said a lot of times, but bears repeating: when the very first two or three sentences I read are mind-blanketing AI prose breathlessly em-dashing together fragments of stuff I don't care about, it makes me skeptical that there's value perusing the rest of the project. Like, you can't even be bothered to make your lede some form of human-to-human communication.
In the "Read On" section at the bottom it says "Author's notes: The one page written by a human." Seems they're pretty open about everything being written with Claude.
Appreciate it, but the info is there for anyone (or their LLM) to learn about the project in a technical sense. Like others have kindly stated, my notes (written by a human, for humans) are in a separate section.
The technical notes are dense and interesting in their own right, but I don't expect anyone not already familiar with the N64 to 3DS port scene to care.
this is why i don’t post anything here anymore...
Get used to it. This is the future. It's okay.
Haven't had a chance to check the project out yet, but wanted to say I love the idea of having a section dedicated to your human-written thoughts. It's the best of both worlds, with as much detail as possible throughout, but also still getting to hear from you personally. Congrats!
Thanks! As fun as the project is, the scope of it is not lost on me. I wanted it to serve as evidence of the frightening power these recent models have, and make it clear.
For those who aren’t aware: The game was originally released on Nintendo 64 in 1998.
I’m curious why people have started using the 3DS as the gateway device for ports of games, like Melee and F-Zero X.
Don’t get me wrong, the 3DS is a gem of a console, and it harks back to when Nintendo put more thought into what they released instead of just another Mario sports game; but since the Switch is so much more powerful, I’d expect ports to that be more of a priority.
Not sure why others are doing it, but the switch is kind of a boring console imo. You may as well just use one of the million PC handhelds with the same form factor, and persistent hacks require a hardware mod.
The 3DS is a fun pocketable form factor which a lot of people already own and easy to permanently mod on any firmware version or hardware revision.
I'm surprised no one has mentioned online: most people don't want to risk console bans, and that immediately makes jailbreaking their Switch a non-starter
At this point most people getting a 3DS are probably doing so specifically to jailbreak it
The Switch is powerful enough it could just straight emulate an N64 game if it needed to. It has a huge back catalog of games where it does this. It's basically a computer on the level of a mobile phone or tablet, or a laptop from 15 years ago.
The 3DS is still a _console_, purpose built and limited in what it can do. It is also approachably easy to find a good one in working order, and still has the vibe of a retro console.
Also, for fun, I suspect.
One non-obvious reason might be that it's the only handheld console with a natively 240p height screen. This means all the 2d ui elements will remain crisp at the same size as they would be on original hardware.
The PS Vita has a sweet 960x544 OLED
The 3DS has the novelty of 3D. I always wanted to play F-Zero in this form factor and it seemed like a reasonable port to accomplish.
I would guess the 3DS is far more "jailbroken" than the switch.
Jailbroken 3DS scene is usually for modding the console OS itself given how easy it is to run custom firmware. And for ports, and emulation. While the GBA has a pretty dedicated community for custom games and romhacks, people often create games for the platform at gamejams because of how great the dev tooling is. It's a bit lackluster on the 3DS, but I did find the Love Brew[0] framework to be really nice. Even has simulator support[1] for testing your builds locally, though fonts will look much different on real hardware, with likely a bunch of other gotchas. Running out of RAM being a big one.
[0] https://lovebrew.org/
[1] https://github.com/lovebrew/nest
edit: compared it to the GBA homebrew scene since it's a large dedicated community to derive pros and cons between the two from. Switch is still receiving updates from Nintendo to brick your system.
It is. Any 3DS can be jailbroken with CFW with a simple Internet guide and no physical modifications. As far as I know, the Switch CFW is locked to only V1 motherboards or modchips, making it far less accessible even if it is more powerful.
The N64 dev scene seems to be taking off too. If I had to guess, working around limitations in hardware are the fun part for a lot of people.
Author’s notes: https://github.com/cruxxxxxx/gdx-3ds#authors-notes
The costings here are based on API pricing, but my understanding is that no one is paying the API pricing and everyone uses the subscription pricing, or even multiple accounts with a subscription each. I'd be interested to know the actual cost incurred here.
I’ve found that subscription is ~98% cheaper than API pricing.
I think the API pricing is a good proxy for "what was the actual physical cost of doing this," but even if you increase it from 5k to 30k or even 100k, it's a huge savings over getting a human to do it, AND it was faster.
I don't think the productivity gains from AI can be ignored for contexts like this. It's what they're best at.
I just hope it goes to good uses (more ports of fun games, more interoperability and opennesS) instead of bad ones (firing humans instead of retasking them), and that hope feels faint.
In no way am I suggesting that doing this without AI would be more practical. What I want to know is roughly how much is Anthropic subsidizing this stuff through the subscriptions currently and how much we can expect the real price paid to go up in the future.
Yep, I agree. Further in the notes it's mentioned this probably would've taken a handful of Senior Engineers anywhere from 6 months to 2 years. The range of budget on the project is like $200 to $500k. This was done for peanuts in my spare time. I share both your optimism and pessimism, depending on the day, lol.
> it's a huge savings over getting a human to do it
This of course assumes it's something anyone would consider worth paying a human to do (it's not).
This is so cool! I've been working on trying to minimize the F-zero render loop to fit on gameboy and multiplayer over the link cable...it's been a journey. (I rushed the writeup cus of this article--still polishing the text), but give the game a try on the in-browser emulator: https://fireflyk64.github.io/makingfsub/
This is really great, thank you for sharing. I may borrow this technique for a Playdate project in the future.
I love that idea! Please let me know if it's of any help :-)
Since the Playdate doesn't have any of the sprite rendering hardware that made the gameboy both underpowered in compute and overpowered in graphics at the time, some of the tricks may be unnecessary.
I suppose you could do some kind of shift of a whole row of the framebuffer easily with a memmove sort of operation. The gameboy's shift registers and the per sprite drawing are what really made this both difficult and possible at such a slow CPU clock speed. The playdate CPU is about 40x faster than that on the gameboy, so probably all these kinds of tricks and more would work just fine.
This is cool!
I had been working on getting claude to port Super Metroid to the Gameboy Advance. Was mostly curious if the GBA could run it at full speed. Looks like, yes!
https://github.com/nickdesaulniers/sm/tree/gba-port
I’m almost done with a port of two games from the original Xbox to modern platforms. While having a good background in assembly and understand of why x87 is problematic and SSE makes life a little easier to understand what it’s doing. And I’ve offered a few suggestions that I thought were useful but it’s been shockingly hands off
Well this is interesting to see. I was thinking of porting my game to 3DS which is based on my memories of playing F-Zero X (mainly trying to make it as fast as possible!)
Now I’ll have to do it and see how they compare. I purposefully avoided playing it again during development so it’ll be most curious.
how are u planning to handle netcode for online muktiplayer on the 3ds?
It's already done. The race sim is fully deterministic so the consoles exchange controller inputs and run off the same seed. It uses the underlying VS. mode for the scaffolding but changes the screen render to full for each player.
The 3DS fillrate budget is the interesting constraint here. F-Zero X was already doing a lot with the N64 T&L pipeline; mapping that onto a tiled GPU without dropping the 60fps target is the part I'd want more numbers on.
Good instinct, the bottleneck is on the CPU side though. The PICA200 is an immediate-mode GPU not a tiler.
Other F-Zero X ports feed the N64 display lists to an interpreter, command by command, with the T&L on CPU. Pre-v1.0 of this port took that approach but did some double buffering on another CPU core.
When porting to Old 3DS, that other core wasn't an option, so we had to make better batch calls to the GPU. It ended up being that now we walk that list the first time and group triangles that share the same material, and moved the position & rotation transformations to the GPU too.
Rather than creating the mesh for tracks out of the spline on the fly, it also precomputes at the start of the race.
I'm fairly certain this is a pretty novel implementation for a N64 to 3DS port.
Most of these optimizations are just for race elements, which is why some of the menus are still pretty laggy.