Given the above, and taking into account the potential constraints you mentioned earlier in the thread, what are some current-gen AAA titles that would likely represent a "soft" ceiling for what's economically feasible in terms of Switch ports?
Honestly I don't really know. I'm less concerned about bandwidth than a lot of people seem to be, just as the software we've seen suggests it's not that big of a problem. I wouldn't expect games hitting XBO/PS4 levels, but at the same time there shouldn't really be much stopping any given XBO/PS4 game from running on Switch with some compromises here and there.
Very interesting writeup, thanks. This should bode quite well for first parties and exclusives but like you said, this type of coding requires a fair bit of optimization so I'm a bit concerned that it might be offputting to most big publishers.
Well, it depends on the developer/publisher. For any studio which already has a reasonably well-implemented Vulkan renderer (e.g. id, Epic, Croteam), there shouldn't be too much difficulty involved in tweaking it to run efficiently on Switch. Some other teams may also have the inclination, resources, and/or the expertise to put together a good Switch port, and I wouldn't be surprised to see, for example, Ubisoft, and the larger Japanese third parties, to put in a bit of effort on this front. Then of course there are going to be some publishers who just want to squeeze out a quick port regardless of quality, but that's going to be largely unrelated to the system's architecture.
Part of the issue is that PS4 and XBO are architecturally virtually identical, so it makes Switch seem a lot more exotic than it is. I have no doubt that Switch is much closer to them than, say, PS3 was to XB360, or GC and Xbox were to PS2, or pretty much any other gaming hardware was to its contemporaries. That's not to say producing well optimised Switch ports would be trivial, but I don't see it being a massive issue for any developer that's given a reasonable amount of time and resources to do the job.
When I use git bash on my Windows machine, I still have to use *nix notation, so I don't see why this would switch to Windows notation. I'd ask my boss (he uses PowerShell all the time), but he would just ask me why I'm not working instead.
Yeah, it's an odd one. I've never used Powershell, though, so I wouldn't know if it "translates" to *nix notation or something like that.
Depends, Ubisoft has switched to tile based rendering, vulkan should see more adoption on PC and we know nothing about how NVN works. Even watch dogs 2 was tile based.
Thraktor, why would they need tbr for those games? To hit 1080p @ 60fps with mk8 shouldn't be hard since the switch is much more powerful than the Wii U. Fast Racing RMX might use it just because it seems to be 1080p and 60fps in all docked modes, so probably isn't even maxing out the system.
I am just thinking we'd expect these resolutions and frame rates base on the hardware alone, tbr aside, switch should be capable of playing wii u games at 1080p at the same frames as 720p wii u games, heck they could very likely double the frame rate too.
Not to say your post didn't have insight, it was a great post, but I feel it gives the false impression that these games are definitely using vulkan and tiled base rendering.
Are you mistaking tile-based rendering (TBR) with checkerboard rendering? Checkerboard rendering is a software technique that has recently become popular to render at half-resolution, alternating the pixels used each frame in a checkerboard arrangement, and reconstructing the image to produce full-resolution output. It's up to developers to implement, and Ubisoft have used it in several titles, and Sony have been encouraging it as a way to get "4K" resolution from PS4 Pro.
Tile-based rendering, however, is a hardware technique where the screen is divided up into some number of tiles and each are rendered one by one, with the intention being that the tiles can sit in the GPU's cache while being operated on, reducing the amount of bandwidth required. This still renders every pixel as with a more traditional immediate-mode approach, it's really just optimising the order a frame is rendered to save bandwidth. This also isn't something developers would enable or disable for a particular game, it would simply automatically happen on the GPU. In fact, Maxwell GPUs were using TBR for about a year before anyone outside Nvidia even realised it.
We don't know what memory bandwidth the switch has, Nintendo's history is high memory bandwidth with a large low memory bandwidth pool. I see no reason for Nintendo to not do that here. I mean did their engineers just take a vacation throughout the design process? To be honest if this is a X1 with no customizations, it would be the first time any major hardware has come to market from the big 3 and not have changes.
Nintendo's recent history is a small, high-bandwidth pool of memory on-die, specifically to keep buffer accesses from hitting main memory. Nvidia's TBR implementation is actually a continuation of this, only instead of keeping the entire frame on-die, which would require 32MB+ and take up a huge amount of die area, it keeps only a small portion of the frame on-die at a time, cycling between them. This gives them most of the benefits of their preferred approach while being smaller, cheaper and simpler for developers (as they only have a single memory pool to manage).
