By using this site, you agree to our Privacy Policy and our Terms of Use. Close

Forums - Nintendo Discussion - NX game price if the library is unified?

potato_hamster on 01 February 2016
JustBeingReal said:
 

 

LOL this is exactly how video game development works. Developers make one base game, then reduce assets down for the platforms that game is coming to, this is exactly how it happens for multiplatform titles, in the case of the PC version you turn settings down to fit within your hardware. Porting only entails writing code specific to a new OS, optimization of assets and streaming them to make the game "fit" within the constraints of the lower end platforms.

Console game development is no different, of course developers engines interact with the API, it's just iterating on it's features for that particular spec becomes more focused and over time more is possible within the constraints of that one system. In the case of the hypothetical NX family you only have on architecture and a few sets of hardware, as I've shown with pure math you only need to reduce resolution, if the platforms are within a reasonable ballpark of each other (6.75X power difference, going from 1080p down to 480p), the math is infallable.

APIs are what directly interacts with the hardware, you don't just build a game engine that runs without any layer between it and the hardware, it's just very thin from a coding perspective when comparing past generations of DX or Open and as uncomplicated as possible in the case of consoles, because you haven't got umpteen different architectures, core/memory counts and clock speeds. Writing that for 2 identical architectures, but different levels of performamce and the same OS is going to be easy and very quick.

Developers literally only need to reduce resolution in the case of a 1840GFlop console and down to a 273GFlop handheld (before you start acting like I'm saying these are NX's actual specs, this is an example, to show how the math scales, nothing more) to make the game fit within the weaker platform.

 

The one who doesn't understand all of this isn't me. Your core mistake is thinking that developers on consoles don't use an API and another is that you think that console development is that much different to PC. For one thing games are all made on PCs from the start, so that's where everything is built, even the APIs and engines developers use to run their games.

It's always a matter of hardware, then API, then engine, then game, you never miss the API step.

You do in console development. It's hardware - > engine for the most part (there are some exceptions). Skip the API. You don't seem to understand that.





Around the Network
zorg1000 on 01 February 2016
potato_hamster said:

You do in console development. It's hardware - > engine for the most part (there are some exceptions). Skip the API. You don't seem to understand that.

Why exactly do consoles have an API then?





When the herd loses its way, the shepard must kill the bull that leads them astray.

potato_hamster on 01 February 2016
zorg1000 said:
potato_hamster said:

You do in console development. It's hardware - > engine for the most part (there are some exceptions). Skip the API. You don't seem to understand that.

Why exactly do consoles have an API then?

My apologizes. I have been vague and bit misleading. Consoles do in fact use APIs in similar ways to PCs. However, consoles use two different kinds of APIs. There first kind are lower-level "to the metal" APIs that interact directly with the hardware in a way PCs do not. This is not what most people mean when they refer to APIs. These low-level APIs are more streamlined more effienct, and, are optimized specifically for the single hardware spec. The console also has higher level APIs, which interact with the OS, controllers, networking etc. this is what most people refer to when they talk about APIs.  You can still actually send commands to things like the processor or GPU directly, but this isn't as common as it used to be. I was trying to make it easier and I ended up complicating things.

It was disingenous for me to say that consoles don't use APIs to interact with the hardware. They do. But they're not the same as the APIs that PC engines use and work in a fundamentally different way that calling them APIs in my experience tends to confuse people more than it does when I say they don't really use APIs.

Here's a little blurb on exactly what I'm referring to:

http://www.psdevwiki.com/ps3/RSX#RSX_Libraries

PC APIs are equivalent to the PSGL. Consoles have layers below that, including the ability to program to directly interact with the hardware.





Alby_da_Wolf on 01 February 2016
zorg1000 said:
potato_hamster said:

You do in console development. It's hardware - > engine for the most part (there are some exceptions). Skip the API. You don't seem to understand that.

Why exactly do consoles have an API then?





Stwike him, Centuwion. Stwike him vewy wuffly! (Pontius Pilate, "Life of Brian")
A fart without stink is like a sky without stars.
TGS, Third Grade Shooter: brand new genre invented by Kevin Butler exclusively for Natal WiiToo Kinect. PEW! PEW-PEW-PEW!   


Soundwave on 01 February 2016
potato_hamster said:
zorg1000 said:
potato_hamster said:

You do in console development. It's hardware - > engine for the most part (there are some exceptions). Skip the API. You don't seem to understand that.

Why exactly do consoles have an API then?

My apologizes. I have been vague and bit misleading. Consoles do in fact use APIs in similar ways to PCs. However, consoles use two different kinds of APIs. There first kind are lower-level "to the metal" APIs that interact directly with the hardware in a way PCs do not. This is not what most people mean when they refer to APIs. These low-level APIs are more streamlined more effienct, and, are optimized specifically for the single hardware spec. The console also has higher level APIs, which interact with the OS, controllers, networking etc. this is what most people refer to when they talk about APIs.  You can still actually send commands to things like the processor or GPU directly, but this isn't as common as it used to be. I was trying to make it easier and I ended up complicating things.

It was disingenous for me to say that consoles don't use APIs to interact with the hardware. They do. But they're not the same as the APIs that PC engines use and work in a fundamentally different way that calling them APIs in my experience tends to confuse people more than it does when I say they don't really use APIs.

Here's a little blurb on exactly what I'm referring to:

http://www.psdevwiki.com/ps3/RSX#RSX_Libraries

PC APIs are equivalent to the PSGL. Consoles have layers below that, including the ability to program to directly interact with the hardware.

 

The thing is though Nintendo is not beholden to make a platform just one way. Why can't a home platform have an API setup more like the PC if at the end of the day this serves Nintendo's needs of today better? It's not as if the world would stop turning. 

And the PC industry I imagine would be a pretty different place if there were literally just 2-3 different hardware congifurations from the same exact manufacturer too.



Around the Network
potato_hamster on 01 February 2016
Soundwave said:
potato_hamster said:
zorg1000 said:
potato_hamster said:

You do in console development. It's hardware - > engine for the most part (there are some exceptions). Skip the API. You don't seem to understand that.

Why exactly do consoles have an API then?

My apologizes. I have been vague and bit misleading. Consoles do in fact use APIs in similar ways to PCs. However, consoles use two different kinds of APIs. There first kind are lower-level "to the metal" APIs that interact directly with the hardware in a way PCs do not. This is not what most people mean when they refer to APIs. These low-level APIs are more streamlined more effienct, and, are optimized specifically for the single hardware spec. The console also has higher level APIs, which interact with the OS, controllers, networking etc. this is what most people refer to when they talk about APIs.  You can still actually send commands to things like the processor or GPU directly, but this isn't as common as it used to be. I was trying to make it easier and I ended up complicating things.

It was disingenous for me to say that consoles don't use APIs to interact with the hardware. They do. But they're not the same as the APIs that PC engines use and work in a fundamentally different way that calling them APIs in my experience tends to confuse people more than it does when I say they don't really use APIs.

Here's a little blurb on exactly what I'm referring to:

http://www.psdevwiki.com/ps3/RSX#RSX_Libraries

PC APIs are equivalent to the PSGL. Consoles have layers below that, including the ability to program to directly interact with the hardware.

 

The thing is though Nintendo is not beholden to make a platform just one way. Why can't a home platform have an API setup more like the PC if at the end of the day this serves Nintendo's needs of today better? It's not as if the world would stop turning. 

And the PC industry I imagine would be a pretty different place if there were literally just 2-3 different hardware congifurations from the same exact manufacturer, period. 

They can, but they would be throwing away very much needed performance, and limiting the capability of game and engine developers in doing so.

Just because technically can be done, but that doesn't mean it's a good idea to do so. If you have a console that's say 1.5x as poweful as the Wii U but from a development point of view it might barely more capable since their control over the device has to go through a relatively bloated API. Thus the games that come out for sucha  console, might look pretty much the same as Wii U games, aside from a few marginal improvements,  then consumers might have a hard time seeing the point of "upgrading".

Might not be the best move just to make development on multiple platforms easier when there are plenty of other things Nintendo can do to bridge that gap without pulling off such a dramatic move.



JustBeingReal on 01 February 2016
potato_hamster said:
zorg1000 said:
potato_hamster said:

You do in console development. It's hardware - > engine for the most part (there are some exceptions). Skip the API. You don't seem to understand that.

Why exactly do consoles have an API then?

My apologizes. I have been vague and bit misleading. Consoles do in fact use APIs in similar ways to PCs. However, consoles use two different kinds of APIs. There first kind are lower-level "to the metal" APIs that interact directly with the hardware in a way PCs do not. This is not what most people mean when they refer to APIs. These low-level APIs are more streamlined more effienct, and, are optimized specifically for the single hardware spec. The console also has higher level APIs, which interact with the OS, controllers, networking etc. this is what most people refer to when they talk about APIs.  You can still actually send commands to things like the processor or GPU directly, but this isn't as common as it used to be. I was trying to make it easier and I ended up complicating things.

It was disingenous for me to say that consoles don't use APIs to interact with the hardware. They do. But they're not the same as the APIs that PC engines use and work in a fundamentally different way that calling them APIs in my experience tends to confuse people more than it does when I say they don't really use APIs.

Here's a little blurb on exactly what I'm referring to:

http://www.psdevwiki.com/ps3/RSX#RSX_Libraries

PC APIs are equivalent to the PSGL. Consoles have layers below that, including the ability to program to directly interact with the hardware.

 

So you intentially mislead the situation to attempt to red herring your way through a debate. Interesting, I'm not shocked.

For the record I've always been genuine, which is why I give specific and legitimate examples to prove my point. Also the level of abstraction has closed with the creation of newer APIs like Mantle, Vulkan and DX12, which will all run on Windows 10 and all but definitely onwards. Games are going to be made for that, to work across the very complex environment that I used as my example of why multiple types of hardware and performance scaling of games is not going to be an issue for Nintendo and NX.

PC would actually be a more worse case scenario and it's already outright proven to not require porting between X spec to Y PC spec, it just works, provided vendors for processing tech support those games. In the case of NX it would be Nintendo adding their own devices and drivers for that into the OS.

It would actually be simpler than supporting individual platforms as they do now, because these devices and their one OS are made to work this way from day one and not built with their own development environments. No porting is needed, just driver updates and within those driver updates Nintendo optimizes their own software features for the API.

With DX11 developers can interact with the hardware on a much closer level to the hardware, if they choose, it's just that this introduces issues for the developers, like giving them tonnes of extra work, because it's not an automated thing and DX11 wasn't designed to make this easy for all developers, DX12 and others like it change this by the API being written to be much thinner and include dedicated libraries to basically do this extra work for developers. No specific writing is needed to take advantage of more efficient programming techniques and as a result performance is gained.

 

Using a PS3 comparison to PC doesn't work for the here and now, because things have changed this generation and new APIs were designed to close the gap in API efficiency.

Anyway having a few specs, with the same architecture doesn't prevent optimization to get the most out of those platforms. Hell platform holders have to optimize their APIs and work on their development tools anyway. Bringing the handheld and console together basically makes this easier because the API developers are working with the same architecture. The handheld is using the same type of CPU and GPU core tech, it's just a portion of it's bigger brother. The OS incorporates both devices or any others Nintendo adds to it. Nintendo's API developers remove any roadblocks for game developers to make their games simply to work unimpeded on both and they just finalize the end settings that feel fits best for each game.



Soundwave on 01 February 2016
potato_hamster said:
Soundwave said:
potato_hamster said:
zorg1000 said:
potato_hamster said:

You do in console development. It's hardware - > engine for the most part (there are some exceptions). Skip the API. You don't seem to understand that.

Why exactly do consoles have an API then?

My apologizes. I have been vague and bit misleading. Consoles do in fact use APIs in similar ways to PCs. However, consoles use two different kinds of APIs. There first kind are lower-level "to the metal" APIs that interact directly with the hardware in a way PCs do not. This is not what most people mean when they refer to APIs. These low-level APIs are more streamlined more effienct, and, are optimized specifically for the single hardware spec. The console also has higher level APIs, which interact with the OS, controllers, networking etc. this is what most people refer to when they talk about APIs.  You can still actually send commands to things like the processor or GPU directly, but this isn't as common as it used to be. I was trying to make it easier and I ended up complicating things.

It was disingenous for me to say that consoles don't use APIs to interact with the hardware. They do. But they're not the same as the APIs that PC engines use and work in a fundamentally different way that calling them APIs in my experience tends to confuse people more than it does when I say they don't really use APIs.

Here's a little blurb on exactly what I'm referring to:

http://www.psdevwiki.com/ps3/RSX#RSX_Libraries

PC APIs are equivalent to the PSGL. Consoles have layers below that, including the ability to program to directly interact with the hardware.

 

The thing is though Nintendo is not beholden to make a platform just one way. Why can't a home platform have an API setup more like the PC if at the end of the day this serves Nintendo's needs of today better? It's not as if the world would stop turning. 

And the PC industry I imagine would be a pretty different place if there were literally just 2-3 different hardware congifurations from the same exact manufacturer, period. 

They can, but they would be throwing away very much needed performance, and limiting the capability of game and engine developers in doing so.

Just because technically can be done, but that doesn't mean it's a good idea to do so. If you have a console that's say 1.5x as poweful as the Wii U but from a development point of view it might barely more capable since their control over the device has to go through a relatively bloated API. Thus the games that come out for sucha  console, might look pretty much the same as Wii U games, aside from a few marginal improvements,  then consumers might have a hard time seeing the point of "upgrading".

Might not be the best move just to make development on multiple platforms easier when there are plenty of other things Nintendo can do to bridge that gap without pulling off such a dramatic move.

 

I think Nintendo is well past the point of needing the make dramatic changes to their hardware, and unifying the portable and console is no longer even a choice. They can't support two distinct platforms like that any longer (nor would Sony or MS be able to do it, Sony basically bailed on the Vita and MS isn't even trying to make a portable, both have huge problems getting PS4/X1 games "finished" on time and unlike Nintendo they don't have a portable to support). 

Developers can make the game for the portable first and foremost, those devs that want to take greater advantage of the console's higher specs can do so, but this can be done on a case by case basis. 

Why does the console have to be "only" 1.5x a Wii U? There are mobile chips today that likely have performance beyond a 1.5x Wii U already. 



JustBeingReal on 01 February 2016
potato_hamster said:
Soundwave said:
potato_hamster said:
zorg1000 said:
potato_hamster said:

You do in console development. It's hardware - > engine for the most part (there are some exceptions). Skip the API. You don't seem to understand that.

Why exactly do consoles have an API then?

My apologizes. I have been vague and bit misleading. Consoles do in fact use APIs in similar ways to PCs. However, consoles use two different kinds of APIs. There first kind are lower-level "to the metal" APIs that interact directly with the hardware in a way PCs do not. This is not what most people mean when they refer to APIs. These low-level APIs are more streamlined more effienct, and, are optimized specifically for the single hardware spec. The console also has higher level APIs, which interact with the OS, controllers, networking etc. this is what most people refer to when they talk about APIs.  You can still actually send commands to things like the processor or GPU directly, but this isn't as common as it used to be. I was trying to make it easier and I ended up complicating things.

It was disingenous for me to say that consoles don't use APIs to interact with the hardware. They do. But they're not the same as the APIs that PC engines use and work in a fundamentally different way that calling them APIs in my experience tends to confuse people more than it does when I say they don't really use APIs.

Here's a little blurb on exactly what I'm referring to:

http://www.psdevwiki.com/ps3/RSX#RSX_Libraries

PC APIs are equivalent to the PSGL. Consoles have layers below that, including the ability to program to directly interact with the hardware.

 

The thing is though Nintendo is not beholden to make a platform just one way. Why can't a home platform have an API setup more like the PC if at the end of the day this serves Nintendo's needs of today better? It's not as if the world would stop turning. 

And the PC industry I imagine would be a pretty different place if there were literally just 2-3 different hardware congifurations from the same exact manufacturer, period. 

They can, but they would be throwing away very much needed performance, and limiting the capability of game and engine developers in doing so.

Just because technically can be done, but that doesn't mean it's a good idea to do so. If you have a console that's say 1.5x as poweful as the Wii U but from a development point of view it might barely more capable since their control over the device has to go through a relatively bloated API. Thus the games that come out for sucha  console, might look pretty much the same as Wii U games, aside from a few marginal improvements,  then consumers might have a hard time seeing the point of "upgrading".

Might not be the best move just to make development on multiple platforms easier when there are plenty of other things Nintendo can do to bridge that gap without pulling off such a dramatic move.

 

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.



OneTwoThree on 01 February 2016

Please, can someone explain to me what's exciting about a "unified library". Nintendo never had a problem supporting 3DS, because handheld games are cheap to make: smaller, less ambitous, less cutting edge technically. The platform they struggled making content for is Wii U. So if that's the problem a unified library is supposed to fix, it can only mean we're getting more handheld quality games for the next home console. Yaay?

I don't even get what's in it for Nintendo. This industry has always been about software sales, the hardware being just a vehicle. So in the future they won't sell 1x Mario Land + 1x Mario Bros to you, but 1x Universal Mario. That's half the software sales. Yay?

Then Nintendo has always argued that they prefer tailor-making games to the strengths of each system. Scratch that, too.

Really, I'm puzzled. But I am puzzled about most of what Nintendo is doing recently.
Slightly off-topic, anybody care to hear what IMO is the one big mistake they made with Wii U, which led to all the other issues we always talk about?

It's the one year headstart. Iwata panicked and preponed the launch. As a result they didn't have a system seller, no decent launch lineup, 3rd parties didn't have time to prepare anything and decided to wait instead. Nintendo caught 3rd parties one year before they were ready to transition to the next gen, so there was no chance of receiving crucial multiplatform titles. Miyamoto's ideas were still tech demos - many still not released today, some of them became the anemic joke that is Nintendoland. So as Nintendo's own sparse lineup bombed and 3rd parties waited before even starting any projects, Wii U was done within a few months. The headstart was an awful, awful decision.

So here we are, Nintendo makes DLC figurines, announces F2P smartphone games, covers up the most barren release schedule ever with re-releases, NX looks like a cost-cutting measure... and you're excited about that?