NX game price if the library is unified?

[JustBeingReal]

potato_hamster said:

JustBeingReal said:

 

Nintendo wouldn't be throwing anything away, they'd be gaining so much more, because resources aren't dedicated to making games for 2 or more separate platforms.

Also you're ignoring DX12, Vulkan and Mantle, all of which are not bloated APIs, rather they're all low level and you know what? It's not necessarily the level of abstraction that brings performance gains anyway, it's the ability for all CPU cores to be able to freely talk to the GPU as and when they need to, rather than each core having to wait it's turn to speak or for all CPU cores to speak through a single thread.

Also there's the matter of a HSA set-up reducing the need for excess reads and writes, along with newer Asynchronous Compute tech allowing developers to make better use of GPU time.

Developers would literally only have to pick settings for each platform, when they optimize their game. No one is saying that Q&A testing isn't going to happen or that optimization to make sure things run as they should isn't going to happen here, but you're essentially trying to invent a problem where there isn't one.

Having to optimize for 2 platforms, with the same OS/API, development tools and architecture would be very easy. Hell Nintendo's own tools would likely undergo much quicker improvements because they're not having to divide their teams between 3DS and Wii U, with each existing in a vacuum.

I'm not inventing a problem where there isn't one. I'm taking a very pracitcal stance to this, and while none of what you're saying is false per se, it's very let's say "theoretical" in the sense that it looks good on paper, but not in the real world. This is a legit concern that you're completely undermining. You're downplaying how difficult such a thing would be to do. It absolutely isn't trivial. It certainly isn't "very easy". It might be "theoretically possible" but Nintendo has to execute this idea of yours. Nintendo has to develop an API that is not only super low-level, but incredibly powerful so that developers can just "pick the settings" (making it very high level) but all of the calculations that involve executing these settings have to be carried out on an a razor thin API using little to no processing time or resources (otherwise it's not low level). Are you seeing a problem here? Sure it might "be possible" but it certainly isn't practical.

On top of that, the team that would be doing it is Nintendo. Have you ever had to work with Nintendo? Used their Dev kits or test kits? Used their developer tools? Called up Nintendo developer support? I have. Let me tell you - They are about a decade behind where Sony and Microsoft are right now in terms of making developer tools that are actually useful compared to Sony and MS's offerings. I'm not joking - the original Xbox's developer tools are better and more powerful than the Wii U's in a lot of ways. And now you're going to take a team that for all intents and purposes has been mailing it in for generations, and now make the most advanced, sophisticated, yet light weight and easy to use API the video game development world has ever seen. And you tell me it will be "easy" for them? Sorry. It isn't easy. It's not trivial. Not for anyone, and not for Nintendo.

In an ideal world, sure developers would "only have to choose" x or y to get their game running on a different spec console, and the lightweight API would just make the magic happen, and *poof* game on new platform with minimal testing. But realistically, you and I both know that would be an incredible achievement, would likely win Nintendo dozens of engineering and desgin awards world-wide if they pulled it off. I do not have that confidence in them. Its fine that you think that Nintendo can pull that off, but I'm taking a far more realistic and grounded approach.

P.S. I also love how you act as if this isn't the funamental issue, but and then chalk it up to something that from what I can see, cannot be solved with an API. The ability for CPU core to send and recieve commands from the GPU simultaneously little to do with the API, and far more to do with the hardware design itself. No amount of API coding is going to get around a hardware bottleneck, and create new physical communcation channels where there are none. But I suppose you think that's trivial as well - making super lightweight ultra powerful APIs getting hardware to do something it's not designed to do. Maybe it's theoretically possible, but in the real world, a team actually has to program it to work that way, and that would not be trivial.

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/