• Hey everyone, staff have documented a list of banned content and subject matter that we feel are not consistent with site values, and don't make sense to host discussion of on Famiboards. This list (and the relevant reasoning per item) is viewable here.

StarTopic Future Nintendo Hardware & Technology Speculation & Discussion |ST| (New Staff Post, Please read)

It did, but I agree with what he is saying. Consoles no longer need the holiday season for a successful launch. Consoles see a spike in sales for the holiday, no question, but at launch the console is always supply limited, so they are now compounding the issue combining the massive demand for new consoles at launch along with increased demand thanks to the holiday season. September would make for a good launch month. Get the initial wave of hardcore gamers out of the way and move on to the more mainstream audience they enter the holiday season in November. Even under this scenario, Nintendo will need to start manufacturing at the very beginning of 2024 in order to make sure adequate supply is available. I am convinced that they can move 20 million units very fast if they have supply.

This!

Releasing in November, having to supply day-one buyers and casuals, is a perfect setup for scalpers.

I would also add that releasing in Summer with one major launch title then releasing another every 2-3 months, they would reach the holidays with multiple major games, probably in very distinct genre, to maximize casual appeal.
I'd rather they release at the start of the financial year. Get the enthusiast day one buyers and scalpers out the way, a few times throughout the year, and leave the holidays for the casuals/etc. Plenty of time to stock up multiple times throughout the year.

It still won't completely eliminate the scalper issue, but it's still better than nothing.
 
The next CoD will be under MS management so the finding doesn't matter, it should come out on switch and switch 2.

Does it have to come out on Switch (1)? Didn’t think we had specifics of the contract. Reporting on the case often said Nintendo consoles and Switch interchangeably. Same as some reporting said they’ll bring games to PS5 and PlayStation interchangeably. This always bothered me as the two have very different meanings.

While there are going to be 150million Switch (1) devices in the wild by late next year, it still sounds like a questionable porting effort to bother once Switch 2 is in full swing.
 
Does it have to come out on Switch (1)? Didn’t think we had specifics of the contract. Reporting on the case often said Nintendo consoles and Switch interchangeably. Same as some reporting said they’ll bring games to PS5 and PlayStation interchangeably. This always bothered me as the two have very different meanings.

While there are going to be 150million Switch (1) devices in the wild by late next year, it still sounds like a questionable porting effort to bother once Switch 2 is in full swing.
If I remember correctly there was direct references to porting the games to Switch in the docs, how MS planned to overcome that challenge and other things
If it does launch on Switch though, it shouldn't be a surprise.
 
Page 1440!
Anyone else hoping for a 1440p 120hz mode for NG like PS5 and Xbox Series? I personally would much rather have the clearer motion of higher frame rates than an almost indistinguishably higher pixel density even if rendering quality has to be dropped, but CPU and memory bottlenecks could make it harder for T239 to push these high framerates similar to the issue developers are having with 120fps on Series S, as well as developers not being willing to port a game to a platform three times.

My opinion is totally not swayed by the fact that I'm looking to buy a new monitor with forwards compatibility for potential 4K on NG to replace my 1080p 75hz one and I'm totally not mad that good 4K 60hz monitors seem to cost over twice as much as a good 1440p 120hz display and are within the price range of 4K 120hz TVs, I don't want to spend more than the cost of my entire PC on a monitor with good specs but a mediocre panel that still gets beat by the 400dpi 120hz OLED panel in my $200 phone. (rant over)
 
0
If I remember correctly there was direct references to porting the games to Switch in the docs, how MS planned to overcome that challenge and other things
If it does launch on Switch though, it shouldn't be a surprise.
I suppose. But unless ABK was planning on a Switch version anyway, around a year to make that happen feels like a quick turn around. If it hits Switch in late 2024 I’d expect some kind of cloud offering.
 
I suppose. But unless ABK was planning on a Switch version anyway, around a year to make that happen feels like a quick turn around. If it hits Switch in late 2024 I’d expect some kind of cloud offering.
What I do know for sure that was mentioned is that the contract specified that they had to be native versions.

One year to port the game with, surely, a dedicated team from MS, I don't see it as unreasonable.
 
Court documents already said that there will be no COD on Switch before August 2024. So the expectation of the first COD on a Nintendo platform come 2024 has been set long ago.

If Activision has assigned a team to a Switch/Successor port, cool; but MS can't assign a team until ABK is under their control.
This time this is a nice find and he's right towards ABK not mentioning Nintendo platform since Wii U on any COD studio
Imo ABK was already planning COD on next Nintendo platform regardless of Microsoft acquisition success
 
Does it have to come out on Switch (1)? Didn’t think we had specifics of the contract. Reporting on the case often said Nintendo consoles and Switch interchangeably. Same as some reporting said they’ll bring games to PS5 and PlayStation interchangeably. This always bothered me as the two have very different meanings.

While there are going to be 150million Switch (1) devices in the wild by late next year, it still sounds like a questionable porting effort to bother once Switch 2 is in full swing.
They were very clear about bringing COD day and date to over 150 mi users (referring to native Switch + GForce Now) and the FTC even tried to argue that it would be too downgraded to count. But MS also said that the first entry might not be a day and date, because they won't have enough time to add it to the pipeline, IIRC.

That doesn't means that they're contractually binded to release on Switch after NG releases though. I wouldn't be surprised if Switch only get 1 late port before they drop it, and they blame regulators for delaying it for so long.
 
Last edited:
CoD on switch always struck me as an old port. I don't reasonably expect them to squeeze the newest game on Switch in the time between MS closing and late 2024. with Kotick talking about not wanting to make the same mistake by not having CoD on Nintendo, I think they're already making preparations for the next CoD on Drake
 
Court documents already said that there will be no COD on Switch before August 2024. So the expectation of the first COD on a Nintendo platform come 2024 has been set long ago.

If Activision has assigned a team to a Switch/Successor port, cool; but MS can't assign a team until ABK is under their control.
also for Call of Duty to come to Switch sucessor, they would need to have the console dev kit, Bobby Kotic testimony on the FTC trial, seen to imply Activision Blizzard dont have Switch sucessor dev kit.
 
also for Call of Duty to come to Switch sucessor, they would need to have the console dev kit, Bobby Kotic testimony on the FTC trial, seen to imply Activision Blizzard dont have Switch sucessor dev kit.
The job posting Doctre is discussing in the v ideo is the 2024 COD release, and dev kits are out now based on leaks so that's 1 year lead time. Besides Koticks response is weasly. I am sure Activision knew the general specs and or if their engines can handle it. The Switch 2 port will probably just involve engine modificaitons specific to the console rather than building a bespoke game.
 
also for Call of Duty to come to Switch sucessor, they would need to have the console dev kit, Bobby Kotic testimony on the FTC trial, seen to imply Activision Blizzard dont have Switch sucessor dev kit.
I think the period Kotick was referring to was the meetings he had with Nintendo back in 2022. so that could have changed since
 
The job posting Doctre is discussing in the v ideo is the 2024 COD release, and dev kits are out now based on leaks so that's 1 year lead time. Besides Koticks response is weasly. I am sure Activision knew the general specs and or if their engines can handle it. The Switch 2 port will probably just involve engine modificaitons specific to the console rather than building a bespoke game.
NG Switch is in the range where MOST 9th gen games will be possible with engine modifications rather than a rebuild or a dedicated port studio.

And given where silicon is going, or rather, isn't, I quite expect gen 9 to last a very, very long time.
 
Speaking of release timing and near-guaranteed sell outs regardless of when a new console launches:

VGC said the H2 launch was to build up stock. My theory is they want to launch the console with maybe double the stock ready to go compared to a typical console launch. I think one of the main reasons is this:
They personally plan to release multiple heavy hitters in the first few months. At the same time, they already know many 3rd parties are planning big games for the system for day 1 and shortly after, ultimately leading to a stronger than usual launch lineup.

If they release with just 2 - 3 million, sell out quickly, and the install base can't grow for a while cos of stock shortages, there's no way all the launch games will have a chance to sell well and despite many of them being high quality, some are guaranteed to underperform and risk burning their publishers, causing them to hesitate when considering Switch 2 for future games. They will wonder, was it the install base or is there a demographic mismatch? Shall we hold off on other games until the system has a much bigger install base?

Imagine the following not Impossible first 1 - 4 months, if every big publisher tries to release at least one big game on the system near launch:

Nintendo:
3D Mario
Yoshi / Kirby / DK / FE / Monolith
Pokemon cross gen

Ubisoft: Star Wars Outlaws / AC
MS: CoD
EA: FIFA, Star Wars Jedi Survivor
Take Two: RDR2 / GTA V
Bandai: DBZ Tenkaichi / Tekken 8
Square: FFXIV
Capcom: Dragons Dogma 2 / RE
Atlus: Metaphor
Koei Tecmo: something
THQ: something
WB: something

Plus a bunch of others including updates to Switch games:

Test drive unlimited solar crown, Apex, Fortnite, Minecraft, Fall Guys, No Man's Sky, Ark Survival, Warframe, Sparks of Hope.

I feel like Nintendo wants the install base to jump quickly so these titles can all have maximum chance to succeed alongside each other, make 3rd parties as happy as possible, and set a strong precedent for continued support throughout the rest of the systems life.
 
So I know the BC conversation has been done to death, but my question is related more specifically to what exactly would be necessary for those pesky pre-compiled Switch shaders. We know the CPU of fully compatible, so that’s all taken care of. And when BC options are brought up for the shaders, one of the top ones suggested has been emulation/translation.

We know the shaders can’t natively run…but what about the rest of the GPU? Is it “just the shaders” that don’t work? Is the TX1 GPU BC with with Drake’s GPU in any way? And if it is “just the shaders”, can they opt to only translate those specific parts or emulate the HW responsible for them?

And I guess as a general question, where are shaders? Like I learned a bit about TPCs and GPCs and the different parts of the GPU that make up the organism, but where do shaders live in all of that? Are they at the very top and surface level? Or are they deeper at the equivalent microscopic level? And if they are do they still need to emulate the whole GPU or translate the entire “GPU portion of the game” (whatever that means, I’m not sure).

Sorry for the long, simple question, just curious on the nitty gritty that I feel hasn’t been answered or dug in to.
 
VGC said the H2 launch was to build up stock. My theory is they want to launch the console with maybe double the stock ready to go compared to a typical console launch. I think one of the main reasons is this:
They personally plan to release multiple heavy hitters in the first few months. At the same time, they already know many 3rd parties are planning big games for the system for day 1 and shortly after, ultimately leading to a stronger than usual launch lineup.

If they release with just 2 - 3 million, sell out quickly, and the install base can't grow for a while cos of stock shortages, there's no way all the launch games will have a chance to sell well and despite many of them being high quality, some are guaranteed to underperform and risk burning their publishers, causing them to hesitate when considering Switch 2 for future games. They will wonder, was it the install base or is there a demographic mismatch? Shall we hold off on other games until the system has a much bigger install base?
This... seems like a pretty unreal problem to have. So worried about having only a regular amount of launch userbase limiting launch game sales, that instead you choose to have 0 sales for that time period, then launch later when there would be even more games competing against each other during the launch frenzy.
 
Speaking of 3rd parties - the more things change the more they stay the same.

From November 2017. Third party games won't sell on Switch!


Edit: video link fixed

This... seems like a pretty unreal problem to have. So worried about having only a regular amount of launch userbase limiting launch game sales, that instead you choose to have 0 sales for that time period, then launch later when there would be even more games competing against each other during the launch frenzy.
Nintendo can give any excuse, but rather than trying to avoid shortages, which i think will happen anyways, Nintendo may be aiming for a huge launch, like 15 million in 6-9 months ending FY 2025, and another 20 + million in its first full year to build up the installed base so quickly that they avoid problems with their previous generational transitions where they stumble while building up the installed base.

It makes sense to me and lines up with the general glut and oversupply of chips right now, it's the perfect time for them.
 
Last edited:
So I know the BC conversation has been done to death, but my question is related more specifically to what exactly would be necessary for those pesky pre-compiled Switch shaders. We know the CPU of fully compatible, so that’s all taken care of. And when BC options are brought up for the shaders, one of the top ones suggested has been emulation/translation.

We know the shaders can’t natively run…but what about the rest of the GPU? Is it “just the shaders” that don’t work? Is the TX1 GPU BC with with Drake’s GPU in any way? And if it is “just the shaders”, can they opt to only translate those specific parts or emulate the HW responsible for them?
it's the whole stack, it's just that shaders are the hard part. The rest of the stack could be handled through some combination of high level emulation/monkey patching/ABI combatbility/API redirection.


And I guess as a general question, where are shaders? Like I learned a bit about TPCs and GPCs and the different parts of the GPU that make up the organism, but where do shaders live in all of that? Are they at the very top and surface level? Or are they deeper at the equivalent microscopic level? And if they are do they still need to emulate the whole GPU or translate the entire “GPU portion of the game” (whatever that means, I’m not sure).

A GPU is sort of a mess. It's a combination of general purpose "mini cpus" (Nvidia calls these CUDA cores) and specialized hardware for managing textures and geometry. In the old days, you gave the GPU high level commands - draw a cube. Turn it 45 degrees. Slap a texture on one side.

But eventually folks realized there was all this compute power in the GPU, and that graphics programmers could do a lot more if given direct control over those operations - specifically, they could light and "shade" objects in more elaborate ways. This became a set of programs you could send to the GPU for it to run - "shaders" which eventually became more generic than just lighting. Those shaders get broken down and farmed out to the CUDA cores - or the tensor cores, or even ray tracing cores.

Shaders and the basic "here is the geometry, here are the texture" operations are both used by a modern game. The basic operations are easy (ish) - you can pretty easily trap a TX1 operation, and map it on to a Drake operation, in real time.

Shaders are tricky because they're programs, but you can't use traditional emulation. A traditional emulator for a CPU also runs on the CPU, so it can work one instruction at a time. For a shader, since the emulator runs on the CPU, but the shader programs run on the GPU, you have to trap the whole TX1 shader, translate it all at once into a format that Drake speaks, then ship it over to the Drake GPU.

This actually isn't a particularly hard problem. Emulators do it all the time. But it introduces stutter. A native Switch game has a compiled shader, sends it to the GPU, it executes immediately. In emulation the game has to stop while the shader gets recompiled.

Getting that stutter cut down to nothing is the trickiest problem of shader emulation.
 
A GPU is sort of a mess. It's a combination of general purpose "mini cpus" (Nvidia calls these CUDA cores) and specialized hardware for managing textures and geometry. In the old days, you gave the GPU high level commands - draw a cube. Turn it 45 degrees. Slap a texture on one side.

But eventually folks realized there was all this compute power in the GPU, and that graphics programmers could do a lot more if given direct control over those operations - specifically, they could light and "shade" objects in more elaborate ways. This became a set of programs you could send to the GPU for it to run - "shaders" which eventually became more generic than just lighting. Those shaders get broken down and farmed out to the CUDA cores - or the tensor cores, or even ray tracing cores.

Shaders and the basic "here is the geometry, here are the texture" operations are both used by a modern game. The basic operations are easy (ish) - you can pretty easily trap a TX1 operation, and map it on to a Drake operation, in real time.

Shaders are tricky because they're programs, but you can't use traditional emulation. A traditional emulator for a CPU also runs on the CPU, so it can work one instruction at a time. For a shader, since the emulator runs on the CPU, but the shader programs run on the GPU, you have to trap the whole TX1 shader, translate it all at once into a format that Drake speaks, then ship it over to the Drake GPU.

This actually isn't a particularly hard problem. Emulators do it all the time. But it introduces stutter. A native Switch game has a compiled shader, sends it to the GPU, it executes immediately. In emulation the game has to stop while the shader gets recompiled.

Getting that stutter cut down to nothing is the trickiest problem of shader emulation.
Thanks for this straightforward explanation. I never fully understood shaders. Like I’d start looking them up then…

IMG-0348.jpg
 
So I know the BC conversation has been done to death, but my question is related more specifically to what exactly would be necessary for those pesky pre-compiled Switch shaders. We know the CPU of fully compatible, so that’s all taken care of. And when BC options are brought up for the shaders, one of the top ones suggested has been emulation/translation.

We know the shaders can’t natively run…but what about the rest of the GPU? Is it “just the shaders” that don’t work? Is the TX1 GPU BC with with Drake’s GPU in any way? And if it is “just the shaders”, can they opt to only translate those specific parts or emulate the HW responsible for them?

And I guess as a general question, where are shaders? Like I learned a bit about TPCs and GPCs and the different parts of the GPU that make up the organism, but where do shaders live in all of that? Are they at the very top and surface level? Or are they deeper at the equivalent microscopic level? And if they are do they still need to emulate the whole GPU or translate the entire “GPU portion of the game” (whatever that means, I’m not sure).

Sorry for the long, simple question, just curious on the nitty gritty that I feel hasn’t been answered or dug in to.
"Shader" is basically a general term for any program that runs on the GPU. I believe originally they were exclusively used for shading pixels, but the name stuck even as the usage expanded. They run in the programmable portion of the GPU, which I believe is what Nvidia refers to as the SMs.

The rest of the GPU is mostly fixed function, and I suspect probably hasn't changed a ton (at least in breaking ways), so interaction with it shouldn't be as complicated to translate. I think most likely what it will look like in practice is a special virtual GPU microservice that spins up when you boot a BC game that intercepts all the calls the game level driver makes to the system level graphics driver and handles all the translation. Possibly Vulkan (paired with a Drake-native copy of the game level driver) will be how it makes the native GPU calls, since that's the trendy thing to do and Nintendo's recent investments into Vulkan are suspicious.
 
it's the whole stack, it's just that shaders are the hard part. The rest of the stack could be handled through some combination of high level emulation/monkey patching/ABI combatbility/API redirection.




A GPU is sort of a mess. It's a combination of general purpose "mini cpus" (Nvidia calls these CUDA cores) and specialized hardware for managing textures and geometry. In the old days, you gave the GPU high level commands - draw a cube. Turn it 45 degrees. Slap a texture on one side.

But eventually folks realized there was all this compute power in the GPU, and that graphics programmers could do a lot more if given direct control over those operations - specifically, they could light and "shade" objects in more elaborate ways. This became a set of programs you could send to the GPU for it to run - "shaders" which eventually became more generic than just lighting. Those shaders get broken down and farmed out to the CUDA cores - or the tensor cores, or even ray tracing cores.

Shaders and the basic "here is the geometry, here are the texture" operations are both used by a modern game. The basic operations are easy (ish) - you can pretty easily trap a TX1 operation, and map it on to a Drake operation, in real time.

Shaders are tricky because they're programs, but you can't use traditional emulation. A traditional emulator for a CPU also runs on the CPU, so it can work one instruction at a time. For a shader, since the emulator runs on the CPU, but the shader programs run on the GPU, you have to trap the whole TX1 shader, translate it all at once into a format that Drake speaks, then ship it over to the Drake GPU.

This actually isn't a particularly hard problem. Emulators do it all the time. But it introduces stutter. A native Switch game has a compiled shader, sends it to the GPU, it executes immediately. In emulation the game has to stop while the shader gets recompiled.

Getting that stutter cut down to nothing is the trickiest problem of shader emulation.
Thanks for the in depth reply! You also went ahead and answered my follow up question, which was: why do shaders exist in the first place if they cause this much trouble going forward?

Edit: Thanks to you too, @Pokemaniac ! Very interesting bit about the Vulkan investment...
 
Thanks for the in depth reply! You also went ahead and answered my follow up question, which was: why do shaders exist in the first place if they cause this much trouble going forward?

Edit: Thanks to you too, @Pokemaniac ! Very interesting bit about the Vulkan investment...
The thing with shader compatibility is that, in most contexts, it just isn't something you need to concern yourself with. On a PC there are multiple layers of indirection between the game and the GPU that handle compiling the shaders from a generic form to one specialized for your particular GPU and dealing with the particularities of how to communicate with the GPU. The problems come in because console games tend to ship their shaders already precompiled into the specialized form as a performance optimization, and the Switch in particular ships much of those layers of indirection with the game itself (ironically, probably to mitigate the risk of firmware updates breaking compatibility) so they won't get swapped out with hardware appropriate ones. These differences render most of the hardware abstraction that would be in place on a PC completely ineffective, necessitating emulation to be involved.
 
The thing with shader compatibility is that, in most contexts, it just isn't something you need to concern yourself with. On a PC there are multiple layers of indirection between the game and the GPU that handle compiling the shaders from a generic form to one specialized for your particular GPU and dealing with the particularities of how to communicate with the GPU. The problems come in because console games tend to ship their shaders already precompiled into the specialized form as a performance optimization, and the Switch in particular ships much of those layers of indirection with the game itself (ironically, probably to mitigate the risk of firmware updates breaking compatibility) so they won't get swapped out with hardware appropriate ones. These differences render most of the hardware abstraction that would be in place on a PC completely ineffective, necessitating emulation to be involved.
I'm still puzzlerd as to why MVG is so down on BC on Switch 2, if by all acocunts, its not an unsolvable problem. Perhaps requiring some effort, but not unsolvable and it's notl ike Nintendo is doing this on their own. If NVN2 is for Switch2, then nvidia is involved, and they have plenty of expertise.
 
I don't think this was mentioned (?), but another reason for Nintendo to launch outside the holiday season is the following:
Whether they launch during the holidays or not, they will initially sell out. But by launching outside the holiday season, far more of the purchases will be by the less casual crowd, consisting of the early adopters, and these buy more games per console. So by launching outside the holiday season, Nintendo will be in a superior revenue position right from the start, and any game coming in that period has an even better chance of succeeding (+this gives more games more room to breath).

All imo of course.
 
I'm still puzzlerd as to why MVG is so down on BC on Switch 2, if by all acocunts, its not an unsolvable problem. Perhaps requiring some effort, but not unsolvable and it's notl ike Nintendo is doing this on their own. If NVN2 is for Switch2, then nvidia is involved, and they have plenty of expertise.
My understanding of MVGs view (based on his Nate podcast and own video) is that BC is a solvable, but non trivial, problem. He’s discussed at a high level different hardware and software options for Nintendo, including the option of Nintendo not bothering with BC. I guess the last option is what has upset some people. Along with MVGs catch phrase of “prepare for disappointment”, it seems to me like this has led him being painted as being against BC in some corners of the internet.
I don’t think MVG has gone into the depths of the software issues and possible solutions like @oldpuck and @Pokemaniac have just done on this page. I thought hardware was the way forward from 18 months ago, but if the LCD rumour for NG is true, and due to cost vs OLED, then I now think hardware based solutions (eg a Maxwell GPU or even a whole TX1) are probably off the table. Personally I’m confident that there will be some form of BC, and Nvidia will help (possibly collaborate with NERD?), but it seems this debate is still live in the industry (ie Take2’s recent quoted comments)

Edit: For reference, these are the podcast and video I was referring to above. I know a lot of people will have seen them already, but I think it's good to source references :geek:

 
Last edited:
I'm still puzzlerd as to why MVG is so down on BC on Switch 2, if by all acocunts, its not an unsolvable problem. Perhaps requiring some effort, but not unsolvable and it's notl ike Nintendo is doing this on their own. If NVN2 is for Switch2, then nvidia is involved, and they have plenty of expertise.
Gotta be down about something, I guess.
Slightly off topic, but I'm having trouble finding the posts that were about the internal storage standard likely for T239. Would appreciate someone linking me the post!
OMG, which one? There's been so many! LOL

To Cliff Notes it for you, if new hardware is expected in 2024 and is meant to last 6-8 years, eMMC probably won't be in production for that long to begin with as it's already being phased out (the first and most likely victim of whittling down NAND production due to a 4-year-long over-supply), which makes it a complete dead end from an engineering perspective. eUFS is where things are going; it's got the highest production volumes, it's the cheaper option in terms of cost per GB once you get above 32GB and, on top of everything else, it's faster than any eMMC you can currently get, is far more power efficient than other options and the Orin that T239 is based on already supports the use of it. The only questions left are what version it will use and how many lanes it will have to transmit data, which will determine the actual real-world speed of it.
Do it Nintendo....

If one of these can be got cheaper than 2x 6GB or 2x 8GB, then maybe? From my understanding, a gaming device doesn't really benefit from multi-channel RAM except it terms of cost as a general rule. It seems pretty unlikely considering this is brand-new tech being mass-produced, but DRAM prices are in the hole right now, so who knows. My money's still on 2x 6GB or 2x 8GB, personally.
 
From November 2017. Third party games won't sell on Switch!


Edit: video link fixed
Never found out where the hell whole "third parties don't sell on Nintendo systems" coming from. On DS, Nintendo's most successful system, 139 games passed 1m mark. 38 of them were from Nintendo and the remaining 101 were third party games (Square had the most followed by EA). I mean, there's no example to prove this theory right. Nintendo had had problems with third parties but that was mainly because their systems were notoriously difficult to port games to. Rockstar refused to cut content from their games to bring them to GCN.
 
Never found out where the hell whole "third parties don't sell on Nintendo systems" coming from. On DS, Nintendo's most successful system, 139 games passed 1m mark. 38 of them were from Nintendo and the remaining 101 were third party games (Square had the most followed by EA). I mean, there's no example to prove this theory right. Nintendo had had problems with third parties but that was mainly because their systems were notoriously difficult to port games to. Rockstar refused to cut content from their games to bring them to GCN.
It comes from people who look at things like JP sales charts and only see 8 of the top ten be Nintendo games and make conclusions from that
 
0
I believe Nintendo, like other developers out there, play the waiting game, sit in the wings, and observe what others are doing before they act on how to get the most out of hardware. But since they’ve been “behind” in power since the PS3 era, it would seem the initial impression are Nintendo have no idea how HD development works, let alone 4K, DLSS, or Ray Tracing development.

I personally believe it’s not so clear cut as evidenced by what they can develop under such limited hardware; case in point TOTK as you mentioned earlier. The physics system alone is probably a masterclass in game development, and how you can really optimize, and polish the game's code to simply make things work. We're talking about a physics systems that operates within only THREE physical CPU cores (that’s on top of everything else the CPU has to calculate, and operate), and there’s a possibility they’re using some of the GPUs silicon to help assist with that too. I can’t remember a time outside of Nintendo's own IPs when a massively large open world title simply just “worked.” Now in fairness, a lot of that is due to Nintendo's commitment for polish, and only launching a game when it’s ready rather than being subjected to beancounters upstairs who are trying to meet some deadline or quota for their end of the year bonus.

That said, we know from others out there either directly in the industry, or even enthusiasts that new techniques are always being discovered and utilized. Take for example, Randy Linden, the man responsible for reverse engineering the source code of Doom 1993, built his own game engine for the SNES, and using the power of the SuperFX 2 chip, managed to get the game running on it. There’s a fantastic interview with Digital Foundry almost a year ago that is a great deep dive into game development, plus he even mentions how he heard of a new technique from a programmer that may actually give you more performance today with Doom on SNES (Skip to before the 15min for that relevant part)



Of course, that was in the 90s during the height of the SNES' popularity. We’ve seen since the 90s that enthusiasts are finding new ways to either optimize an existing game on a platform, or simply develop a brand new title so it works on native hardware. As for the latter, there was Micro Mages for the NES, which for an actual NES title looks absolutely incredible for 8-bit.



As for the former though, there is the wizard that is Kaze Emanuar who “fixed” Super Mario 64's source code to get it running on real hardware at a full 60 fps. He has since worked on building his own levels that'll work on real hardware using the techniques he's worked on over time, but here’s the one with him explaining him achieving triple the FPS for Mario 64:



I know you’ve seen these videos before, GT, but for others, this is a great way to kill an hour of your time to show what was possible back then, and what is possible now given new discoveries after the fact.

I suppose what I’m getting at is just because Nintendo, or other developers for that matter don’t have the latest and greatest hardware, doesn’t mean they’re necessarily behind the competition. More than likely, they’re discovering new ways and techniques in the background on how to optimize their games even further than what most developers were working on back in the day. We’ve seen what Zelda TOTK can be with hardware that is effectively a PS3.5. Imagine what they can do with a PS4.5.

As a side note, had the GCN been more popular for example, I think a game like GTA3 would’ve been possible under the limited storage requirements, either by using multiple game discs, or even a single disc. Same goes I believe with other games that at the time were deemed too large to fit within the constraints of the GCN's 1.5GB disc. And who knows, maybe some enthusiast has thought of that very thing. Same is true for the Wii U. Yes, it’s hardware was “outdated” by the time it launched, but that doesn’t mean it was particularly slow. It did not have the grunt of the PS4, but I think through some optimizations, even a game like Doom 2016 for example would’ve been theoretically possible, say the Doom SNES of the Wii U. But that’s just me saying this without any programming experience. Since the Wii U is now more of a system for the homebrew community, I wonder if we may see certain games, or demos down the road. It’s interesting how many late gen PS3 titles really were too much for those systems, but I’d be curious how with a more modern GPU, more available ram, plus the EDRAM pool, how some of these titles would’ve faired.

Agree with most of what you said. The reason Breath of the Wild's physics systems are as impressive as they are is mainly down to them designing the game around them from the start then making smart and efficient choices to make them viable on a Wii U with it's near Gamecube level CPU. IF Nintendo had wanted to they could have made a very traditional, more linear 3D Zelda that looked very close to the famous Twilight Princess artstyle demo they showed off at E3 2011. But they wanted a massive open World filled with freedom, discovery and a very robust physics system.

So much of what games are is down to developer decisions and priorities and budget limitations made very early on (usually in the planning stages) not hardware limitations.

Nintendo games would look absolutely phenomenal right now using their current asset library if every single game was 1920x1080 with TXAA while running at 60fps. With Switch 2 we will get not only that but a new hardware base which will be 4-5x what Switch currently is then they will take that 1920x1080 image and use DLSS to make it look like it's 2160p with TXAA :p

I imagine they will use RT GI, shadows and reflections on the next Zelda mainly because it's one of their only franchises left that targets 30fps instead of 60fps. Hopefully there's the option to go for 60fps if you so desire which I think will be present on most cross gen games at least due to Switch being unable to render real time RT and having baked fall backs instead.
 
Re: Shader talk,
How complicated or trivial would it be for developers to recompile for a new target?
And if it is trivial, wouldn't Nintendo go that route on the basis that:
1. They don't need to expand engineering effort in figuring out a solution that is seamless and doesn't hurt performance or compatibility.
2. Throwing the ball entirely into the third party's court could be a political win, especially as we're hearing that some devs aren't keen on backcomp
 
Re: Shader talk,
How complicated or trivial would it be for developers to recompile for a new target?
And if it is trivial, wouldn't Nintendo go that route on the basis that:
1. They don't need to expand engineering effort in figuring out a solution that is seamless and doesn't hurt performance or compatibility.
2. Throwing the ball entirely into the third party's court could be a political win, especially as we're hearing that some devs aren't keen on backcomp
The problem with this solution is that publishers would just make you rebuy your games, which defeats the purpose of BC. And even with BC, there's nothing stopping them from doing this if they want to do bigger upgrades to visuals.
 
0
Re: Shader talk,
How complicated or trivial would it be for developers to recompile for a new target?
And if it is trivial, wouldn't Nintendo go that route on the basis that:
1. They don't need to expand engineering effort in figuring out a solution that is seamless and doesn't hurt performance or compatibility.
2. Throwing the ball entirely into the third party's court could be a political win, especially as we're hearing that some devs aren't keen on backcomp
Really rather difficult. Emulators aren't exactly some impossible task, there's at least two for Switch, one of which is internal at Nvidia. The expectation for me would be that every game works out of the box at current performance levels, and Devs can build up from there. Allow TV Mode settings in handheld mode to suit the bigger, better screen with a small update, or a patch with recompiled shaders and/or optimisations to let it run at a higher resolution on the new device with few other changes. On the high end there's always a full scale next gen patch with new models, higher resolution textures and the possibility of DLSS. There's a lot of flexibility.

For games like Mario Kart 8 Deluxe, a "simple" shader recompilation could reveal enough leftover grunt to get it to a solid, native 4K60.

There IS a possibility that Nintendo DOESN'T go with an emulation solution, and opts for something crazy like mandatory shader patches for every game, but then automatically provides them. They keep the source code for every published game, it's possible, though not immediately practical, for them to set up a system to automate recompiling every single one and forcing an update before a Switch 1 game will launch on Switch 2.
 
0
I don't think this was mentioned (?), but another reason for Nintendo to launch outside the holiday season is the following:
Whether they launch during the holidays or not, they will initially sell out. But by launching outside the holiday season, far more of the purchases will be by the less casual crowd, consisting of the early adopters, and these buy more games per console. So by launching outside the holiday season, Nintendo will be in a superior revenue position right from the start, and any game coming in that period has an even better chance of succeeding (+this gives more games more room to breath).

All imo of course.
Completely agree.

I think it's safe to assume early adopters (in general) are more passionate and avid gamers who are willing to spend more and are far less influenced by seasonality.

Since with every new launch, there's a high possibility of facing supply issues there's no need to have then "compete with" the broader crowd purchasing holiday gifts.

This has also the potential advantage (assuming you have a strong lineup) to let word spread out and build even more hype the holiday season.
 
Last edited:
From my understanding, a gaming device doesn't really benefit from multi-channel RAM except it terms of cost as a general rule.
That RAM is 64-bit, meaning just 68GB/s of bandwidth, half of what 2x modules would achieve.

It would be another story if we were comparing a 128-bit module to 2x 64-bit in dual channel, but phones only use 32 and 64-bit modules, AFAIK, so I wouldn't count on a 128-bit module being cheaper.
 
Please read this new, consolidated staff post before posting.

Furthermore, according to this follow-up post, all off-topic chat will be moderated.
Last edited by a moderator:


Back
Top Bottom