| JustBeingReal said: Yes you are. There's no problem here because Nintendo would be making their own lives much easier, because they only have to develop for one architecture and OS. The whole platform shares this, the only differences between the handheld and the console are power. They go from supporting 2 separate architectures and 2 separate operating systems, to one of each, with one part of the physical hardware being less powerful than the other. Also for your information Nintendo doesn't have to create a new API, because they're already a part of the Khronos initiative that makes Vulkan, in fact they're one of the contributors and it's likely for this very reason why they joined this group. Vulkan already allows for everything I'm talking about, it does all of this, with a low level of abstraction. An API doesn't need to be thick to allow for multiple pieces of hardware or even multiple architectures to work across more than one. FYI it's not an API that is "powerful", but rather the hardware that provides the actual power, the API just uses the resources at hand to communicate data between the higher level software and the physical hardware.
As I said there is no problem at all, you are inventing issues where there are none and you continue to do so, for no good reasons. You want Nintendo continue on the same path that is failing them? Optimizing for one architecture, one OS is much more efficient than having to do all of that for 2 separate platforms, this is undeniable. PC has already shown that there are no issues in making games run on thousands of different hardware configurations, not to the extent of having to build entirely new versions of a game for each one and in the case of this hypothetical NX family of systems there would be even less of a complicated environment, because Nintendo would only have to worry about the few devices they release, as NX hardware evolves.
There is no fundemental issue here, Nintendo goes from supporting two seperate platforms, to one that has different form factors and a single OS that works on 2 or more devices. They go from dividing resources, to unifying them and as a result can optimize for each device much easier. You're making this out to have issues where there aren't any and it's downright ridiculous. Now you start talking about made up bottlenecks for hardware, which would be designed to work as well as possible. Nintendo wouldn't just slap together tech randomly, but build each device with a set idea in mind and a specific audience, like Handheld gamers and Console gamers or whatever (I can't really think of any more audiences). You're ignoring that the processing architecture would be the same, have the same CPU Core design, the same GPU Core design, the same kind of memory, which means code works natively when it's made for that architecture, there can't be any issues when this is the case. If architecture changes, then new code is written to incorporate that new architecture into the overall NX OS/API and it just works, because that architecture has been taken into consideration and incorporated into the development environment. This fundemental fact is why the issues you're trying to invent don't exist and why developers could literally just choose different settinngs for their games to make them work easily without needing to port them.
As for your talk about Nintendo making mistakes in the past and messing up their development tools, well they're a part of Khronos now, they joined last year: http://www.theregister.co.uk/2015/09/23/nintendo_joins_khronos_vid_api_standards_body/ |
Great. Nintendo joined Khronos. What exactly does that mean for Nintendo? Does it mean they have unfettered access to everything Khronos creates, for them to use how they see fit? Probably not. That's not how it works. But if it did, you're assuming the Kronos API as it stands does exactly what Nintendo needs it to do, and has a resource footprint that meets the demands of Nintendo. Sure it might be low-level, but it might not be low enough, and it might be nowhere near the level Nintendo needs it to be. I can almost guarantee it does not meet Nintendo's needs as it stands, and Nintendo will have to modify it dramatically to meet their needs. That's if they're even using this technology in the NX. They might have just joined the group to evaluate the technology. You should see all the groups Sony and Microsot is a part of. It doesn't necessarily mean anything.
And FYI, it is the API that is "powerful" in the sense that any piece of software can be more powerful than similar software. Some APIs that are more capable and have more functionality could be considered to be more "powerful" than others. This should be obvious. Don't argue over semantics.
Also you're failing to understand the fundamental issue that creating the infrasture ( the APIs, the development kits, the developer tools etc.) is extremely difficult, and you continuously trivialize this. Making all of this work they way you picture it is an very very very difficullt task. Of course this is theortically possible, but is isn't practical - especially not for Nintendo as I've outlined above. And you just kinda shurg and say "Nintendo will benefit by doing so so they'll just do it". They have to actually be able to execute this!
You keep bringing up PCs as if that really matters, and I'm not sure why. Sure PC games run on thousands of different hardware configurations, using engines running on APIs and OSs that are vastly different than what is used on consoles. You can deny that all you want but those are still the facts. Console OSs and APIS are still take a fraction of the system resources PC OSes and APIs do, so it is not the same as comparing apples to apples. Optimizing for one architecture, and one OS might much more efficient than having to do all of that for 2 separate platforms, but optimizing for one architecture and one OS, and one specification is much more effiicent than optimizing for two similar archtectures, two similar OSs, and two similar specifications. The resources required to do so might be magnitudes bigger than optimizing for a single specification - don't forget that.
Also the code will only work natively if the engine that's actually translating the code (you know, one of the dificult part I'm discussing) makes it so. Do you know that for multi-platform games the PS4 and the Xbox One are actually running practically identical code, just compiled differently and running on engines customized for each console? It doesn't "just work" on it's own! People have to put a lot of time and effort making the engines and APIs, and developer kits and tools and all of the other stuff that's needed for it to "just work" and it's the "just work" part that the topic of this discussion.
It is not easy to implement the solution you continue to brush off as trivial no matter what the huge benefit is. Sure the upside is huge, but only if you make it happen, that that if, no matter how much you deny it, is a huge one.
