potato_hamster said:
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 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.
|
Considering that Vulkan is open source actually it means that anyone can use it and that includes Nintendo.
Yes Nintendo would get unfettered access to it. Vulkan is everything a developer could want in the way of an API, Low-Level, while also allowing for multi-core, Asynchronous/GPU Compute and it's supported by every major vendor, including AMD (the likely creator of NX's CPU and GPU Core Architecture). The performance of Vulkan in demos speaks for itself.
LOL no, an API is just a tool, now it can be more efficient or less, but in of itself it doesn't have power, because it's the hardware that crunches the numbers. If anything it's more how it's used that detemerines it's level of power. I'll argue over anything I choose, if I feel someone's being untruthful, you have no right to bark orders, like your the one in power in this debate LMFAO. There are no semantics here, you're wrong about this point.
LOL you're arguing over nothing, making new infrastructure isn't a problem, platform holders do it every generation and largely it's a matter of iteration and learning from the mistakes of past generation, or in the case of APIs, etc you can use a product that already exists and is freely available for you or anyone else to use. Hell being a contributor and Vulkan itself being open source means that anyone, be it a company or an independent programmer can re-write it or parts of it as they see fit, that's how it works with open source software.
You're acting like making tools for a single architecture is more complicated than it really is.
The hypothetical NX platform wouldn't have 2 separate architectures or 2 separate Operating Systems, one OS, one overall architecture, so all code runs natively on it, without issue.
It's so much more straight forward than making 2 separate architectures and 2 OS. You haven't even brought up a single point as to why this isn't true, you just keep on inventing stuff to try and support this fake point you keep on attempting to make.
Seriously what issue do you have with Nintendo taking this route? Because none of the things you keep insisting are true are.
Of course the PC example matters, because it's an outright example of a platform that has potentially infinite combinations of hardware, even with different architecture (because of different vendors making different types of core processing tech) and provided that Vendors update their drivers to incorporate new games those games work seamlessly.
The only difference between an API used on a PC and console is the language, because Sony and MS make them for their consoles, but that doesn't mean a platform holder can't use Vulkan or some other API that is also used on PC.
An API will work on any platform that it's been written to work on. Modern PC APIs are just as Low Level as Console ones, they do the exact same things as console APIs.
The whole point about this hypothetical NX is that it would use one OS, you ignoring this point doesn't change that fundemental point.
No resources needed don't get larger, because your making software for one architecture, the only difference between each device is power, the weaker platform can still run the code natively, it just runs less of it.
The engine doesn't have to translate a thing, because it's working on one architecture.
No multiplatform games made for PS4 and XBox One aren't practically identical, because they have different Operating Systems, they have different core languages made specifically by each platform holder, because the APIs are fundementally different, which is why games wouldn't run natively on each system.
This is why game developers have to port between each device or make different versions of games in tandem with the PC versions of titles (if a PC version is being developed). Your PS4 and XBox One example makes no sense in comparison to how NX platforms would work in this discussion we're having.
The reason NX handheld and console just run the same code is because it's written for the same API, that runs on the same architecture, hell even if the architecture was different it wouldn't matter, becaus the API would be written to work natively on both. Developers don't have to do anything, besides pick the settings they need to make it run on the weaker system.
It's just as easy as I'm saying, you inventing issues where there aren't any doesn't change that fact.
Ultimately making a single OS that incorporates two pieces of hardware is much simpler than making two Operating Systems, with two separate pieces of hardware. Each generation you make a new API, OS, etc anyway or you iterate on past technology and software.
