Really grateful the costs were included - just shy of 5K USD. Really out of morbid curiosity. And they estimate it was the equivalent of 250-400k for human work.
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.
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.
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.
Not the GP but the experience of being on the wrong end of a vociferous false positive is not great, and there are enough readers to make that not an unlikely outcome.
If what you'd post are pages of obnoxious AI generated text that you yourself couldn't even be bothered to think/write about in the first place, then thank you for your restraint. A topic you think is worth your time to post about with your own words, sharing your thoughts, in your own voice could be interesting and worth our time too, but that's also not something you can just copy out of a chat bot.
Do you not see what you're doing? How do you know they don't think about things? You're attacking with unfounded accusations, and it's incredibly uncivil.
Ok, for future reference, the next couple months you see any port, you can be 99% sure it was done by ai given the recent REA news. So if you don't want to see ai posts, avoid the port posts
Yeah and some of the article wasn't proofread (by himself or a clanker) and the project is missing some of the due dilligence.
One striking example is "No debugger, no stdout" which is baffling considering I implemented a GDB stub in the very first version of Rosalina which I released like... 10 years ago?
Stdout redirection is supported by both 3dslink and GDB stuff on 3ds, too.
I don't mean to be a party pooper - and the projects fullfills its role as a showcase of how far pure vibecoding can take someone - but it's this can of thing that gives the "absolutely no AI" crowd grounds to stand on.
> I guess for those who are interested in an F Zero X port you assume they already know what platform it was on.
You assume wrong. I would be interested and I didn’t know by name what the platform was. I never played F-Zero but I’m familiar with it thanks to Super Smash Bros.
> If I ever talk about Ocarina of Time, I don't feel the need to specify what platform it was on
Considering there’s a remake with the same name on the Switch 2, you do need to specify.
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!
Cool. I wanted to let Claude port Zelda Link's Awakening DX from the GBC to the NES. That's a bit of the opposite problem to yours: for Zelda the target resolution is higher than the source, so the backgrounds have to be expanded or (not ideal) a border added.
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.
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.
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.
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
From what I understand if you take certain precautions like not doing piracy, installing anything to the homescreen or cheating in multiplayer games you can use homebrew online without being banned, I've been used it occasionally and not been banned at least
It seems to me that stereoscopic 3D is as much as "novelty" as is color. It's an objective improvement, because we perceive the real world in stereoscopic 3D. Of course the hardware implementation (not so much on the New 3DS) has various downsides, unlike color.
I'm saying that more colors are strictly better than fewer colors, not just a "gimmick", and that the same holds for stereoscopic 3D, modulo issues with implementing it in hardware via (auto)stereoscopic screens.
For example, if you play games on a virtual screen using a VR helmet, you pretty much always want the game to use stereoscopic 3D, because playing it without it would be strictly worse. (Okay, it would consume less GPU resources, which is good, but that would be the only difference, and this would also hold for things like lower resolution or frame rate.)
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.
I think there's currently a lot of nostalgia of the 3DS as the console people have grown up with. And the device has a good homebrew community around it, and is more interesting than something like the switch can definitely run it with enough horsepower
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.
It was, 15+ years ago, when porting N64 games to 3DS was a lucrative market for hired guns. We have the magic 'port' button and this tech just showed how easy it is with severely different architectures & constraints.
That's not true, companies pay humanies to develop ports and remasters of software all the time. Maybe not from one dead platform to another, but the same technology can be used to take a game like this from a dead platform to a living one.
On the stuff I have done (mostly Opus5.5) it came out at around 1/20 the cost, 95%. So a $20 subscription is around $1000 API. Somewhere in that ballpark.
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.
> Good instinct, the bottleneck is on the CPU side though.
Have you, or rather your agents, tried to identify which CPU functions were the bottlenecks (e.g. in citro3d, perhaps)?
I find it surprising that your stuff is CPU bound. Are you doing one command-list submission for _both_ eyes (with one drawcall for each)? This should be relatively simple, only require viewproj matrix changes and avoid CPU<>GPU roundtrips.
If not, you are going to hit IRQ dispatching costs as well as shardmem dispatching costs as well as other costs.
Bypassing Citro3D for raw PICA200 commands cut our per-draw CPU cost by 15x (11 µs to 0.7 µs). After that, there's no single hot function left.
The remaining bottleneck is the o3DS instruction cache. Our code is bigger than the 16KB L1, so the CPU spends a big chunk each frame waiting on instruction fetches.
We build the list for left eye, submit, and then re-submit the list offset for the right. Hadn't tried chaining both into one submission, it improved performance. Thanks so much for the suggestion!
Thanks for taking a look and the great questions. I really appreciate your contributions to the scene.
Really grateful the costs were included - just shy of 5K USD. Really out of morbid curiosity. And they estimate it was the equivalent of 250-400k for human work.
https://hypnotize.works/gdx-3ds/postmortem/cost.html
Just in case anybody get's scared by those numbers: A $20 Claude Pro subscription is worth around $1000 API tokens.
So it’s like paying $20 for a gym subscription but if you had just stayed there 24/7 paying hourly rates the whole month it would’ve cost $1000.
Except, nobody does that. So that’s not a real number.
?
People regularly blow through all their Claude Pro tokens every week. It’s relatively easy to do.
I spent $600. $200 a month for the last 3 months. Used for other projects too but this blew my token usage quite often.
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.
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.
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...
All your stuff is vibecoded these days? Or is this a general complaint about negativity in the comments?
Not the GP but the experience of being on the wrong end of a vociferous false positive is not great, and there are enough readers to make that not an unlikely outcome.
If what you'd post are pages of obnoxious AI generated text that you yourself couldn't even be bothered to think/write about in the first place, then thank you for your restraint. A topic you think is worth your time to post about with your own words, sharing your thoughts, in your own voice could be interesting and worth our time too, but that's also not something you can just copy out of a chat bot.
This is not cool.
Do you not see what you're doing? How do you know they don't think about things? You're attacking with unfounded accusations, and it's incredibly uncivil.
Why are you in this AI thread spewing hate?
Think about it a second.
This is an AI thread.
You do not have to be here.
This was a thread supposedly about a port of an N64 game to 3DS. It turned out that it’s just something LLM was told to do. Not interesting.
Ok, for future reference, the next couple months you see any port, you can be 99% sure it was done by ai given the recent REA news. So if you don't want to see ai posts, avoid the port posts
Yeah and some of the article wasn't proofread (by himself or a clanker) and the project is missing some of the due dilligence.
One striking example is "No debugger, no stdout" which is baffling considering I implemented a GDB stub in the very first version of Rosalina which I released like... 10 years ago?
Stdout redirection is supported by both 3dslink and GDB stuff on 3ds, too.
I don't mean to be a party pooper - and the projects fullfills its role as a showcase of how far pure vibecoding can take someone - but it's this can of thing that gives the "absolutely no AI" crowd grounds to stand on.
“Author” seems to be doing a lot of work. Probably not the right word to use for LLM wrangler.
You're coming across as rather unkind in this thread and it does the project that you mentioned that you are working on a disservice.
Did the poster “write” this? What does the word author mean to you?
The poster referred to themselves as the author. They created it, which is good enough for me.
For those who aren’t aware: The game was originally released on Nintendo 64 in 1998.
Yup.
Something that the bot overlord didn't even think to say in its superdense page intro.
That's the problem with AI-generated text. They have no idea of what proper context is.
I guess for those who are interested in an F Zero X port you assume they already know what platform it was on.
If I ever talk about Ocarina of Time, I don't feel the need to specify what platform it was on, or now that I realise, that it was even a Zelda game
> I guess for those who are interested in an F Zero X port you assume they already know what platform it was on.
You assume wrong. I would be interested and I didn’t know by name what the platform was. I never played F-Zero but I’m familiar with it thanks to Super Smash Bros.
> If I ever talk about Ocarina of Time, I don't feel the need to specify what platform it was on
Considering there’s a remake with the same name on the Switch 2, you do need to specify.
Multi player would be so dope, have multiple 3DS and friends willing to play
How much did you know about N64 and 3DS development/internals before starting this project?
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.
Author’s notes: https://github.com/cruxxxxxx/gdx-3ds#authors-notes
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
Amazing. I hope I can get around to testing it out and making a video.
Cool. I wanted to let Claude port Zelda Link's Awakening DX from the GBC to the NES. That's a bit of the opposite problem to yours: for Zelda the target resolution is higher than the source, so the backgrounds have to be expanded or (not ideal) a border added.
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.
I would guess the 3DS is far more "jailbroken" than the switch.
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.
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.
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
Most people use an EmuMMC to avoid bans. I think the bigger issue is that most Switch consoles need a hardmod.
From what I understand if you take certain precautions like not doing piracy, installing anything to the homescreen or cheating in multiplayer games you can use homebrew online without being banned, I've been used it occasionally and not been banned at least
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.
It seems to me that stereoscopic 3D is as much as "novelty" as is color. It's an objective improvement, because we perceive the real world in stereoscopic 3D. Of course the hardware implementation (not so much on the New 3DS) has various downsides, unlike color.
I don't think color is that different. E.g. older computers had limited color palettes, like 16 color EGA.
I'm saying that more colors are strictly better than fewer colors, not just a "gimmick", and that the same holds for stereoscopic 3D, modulo issues with implementing it in hardware via (auto)stereoscopic screens.
For example, if you play games on a virtual screen using a VR helmet, you pretty much always want the game to use stereoscopic 3D, because playing it without it would be strictly worse. (Okay, it would consume less GPU resources, which is good, but that would be the only difference, and this would also hold for things like lower resolution or frame rate.)
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.
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
They mean because the game originally ran at 320x240 of N64, so no scaling of 2d assets is required
I think there's currently a lot of nostalgia of the 3DS as the console people have grown up with. And the device has a good homebrew community around it, and is more interesting than something like the switch can definitely run it with enough horsepower
The 3DS has software jailbreaks, but the Switch requires a modchip to be soldered in.
I imagine that's a big part of it.
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.
Right, that's why the API pricing is a better metric than subscription pricing. It's probably still subsidized but not as much.
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 was done for peanuts
If you don't have a real dollar cost then can you tell us how much it actually cost in peanuts?
$20 can buy many peanuts
explanation: money can be exchanged for goods and services.
> 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).
It was, 15+ years ago, when porting N64 games to 3DS was a lucrative market for hired guns. We have the magic 'port' button and this tech just showed how easy it is with severely different architectures & constraints.
That's not true, companies pay humanies to develop ports and remasters of software all the time. Maybe not from one dead platform to another, but the same technology can be used to take a game like this from a dead platform to a living one.
I’ve found that subscription is ~98% cheaper than API pricing.
On the stuff I have done (mostly Opus5.5) it came out at around 1/20 the cost, 95%. So a $20 subscription is around $1000 API. Somewhere in that ballpark.
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.
AI slop port. The gaming world doesn't need any more of these.
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.
> Good instinct, the bottleneck is on the CPU side though.
Have you, or rather your agents, tried to identify which CPU functions were the bottlenecks (e.g. in citro3d, perhaps)?
I find it surprising that your stuff is CPU bound. Are you doing one command-list submission for _both_ eyes (with one drawcall for each)? This should be relatively simple, only require viewproj matrix changes and avoid CPU<>GPU roundtrips.
If not, you are going to hit IRQ dispatching costs as well as shardmem dispatching costs as well as other costs.
Bypassing Citro3D for raw PICA200 commands cut our per-draw CPU cost by 15x (11 µs to 0.7 µs). After that, there's no single hot function left.
The remaining bottleneck is the o3DS instruction cache. Our code is bigger than the 16KB L1, so the CPU spends a big chunk each frame waiting on instruction fetches.
We build the list for left eye, submit, and then re-submit the list offset for the right. Hadn't tried chaining both into one submission, it improved performance. Thanks so much for the suggestion!
Thanks for taking a look and the great questions. I really appreciate your contributions to the scene.