Support NeoGAF

[JonnyDBrit]

Yes, there is one level lower (Low). I can grab a screenshot from this a bit later.

Please and thank you, much appreciated. It's useful for providing context, especially with how the forum minimises this stuff.

 

[Skittzo0413]

I can check the framerates, but I have a i7 6700k and a 980ti, I don't know how relevant it can be?

I think the difference in framerates (unlocked) would be interesting information to know. Even if it's like >300FPS average on medium settings, it would still hopefully give us somewhere to start for comparing framerates between the three settings.

 

[Tain]

I get the curiosity, but don't get carried away and put too much weight into screens from a project meant to showcase small-scale detailed static scenes, especially when you don't know what the scalability groups stand for.

 

[fernoca]

I guess if anything, it could be something like Mortal Kombat on Vita (portable) vs. Mortal Kombat on PS3 (docked).

Which is great anyway. Plus Switch has not only better specs than the Vita, but official UE support. So more like a prettier MK Vita vs. prettier MK PS3. XD

 

[10k]

Street Fighter V on low settings running at a glorious 1062x598 (66% of 720p).

The edges on those shadows look like saw blades. Jesus....

 

[M3d10n]

Scaling up 50% and scaling right back down seems like it would be pretty bad on top of wasteful. Trying something similar with a bit of SNES,

though it would differ based on how the scaling is done.

That's a bad comparison. We are talking about a 720p image that is going to be displayed on a 6" screen, not a 240p image that's zoomed 4x on a large monitor. Here are two MK8 screenshots, one with and the other without the scaling:

 

[LordKano]

I can check the framerates, but I have a i7 6700k and a 980ti, I don't know how relevant it can be?



Materials are set to High on Epic and High and Medium on Medium. I don't know if that will work on Switch, we don't have info about it.





This isn't how it will look on Switch, this is just to reflect the differences between the different effects settings.

I know, that's why I just mentionned jaggies and reflexions.

 

[MrCunningham]

Someone dumb it down.

They are basically the engine scalability settings for Unreal Engine 4. I haven't used the UE4 editor much TBH, I have only poked around with it a few times, so I have no idea what "2" is for say +CVars=sg.ViewDistanceQuality in relation to what the setting options are. I'm sure there are a few UE4 experts lurking here who knows what that means.


But here is a much more detailed article from Epic's own website: https://docs.unrealengine.com/lates...ity/ScalabilityReference/#scalabilitysettings



EDIT
+CVars=sg.AntiAliasingQuality=1 (handheld)
+CVars=sg.AntiAliasingQuality=2 (docked)

(From the left: r.PostProcessAAQuality 0 to 6. The first 3 equal the Low, Medium, High, Epic settings. Handheld falls between image 1 and 2. Docked is image 2.)


+CVars=sg.ViewDistanceQuality=1 (handheld)
+CVars=sg.ViewDistanceQuality=2 (docked)

(ViewDistanceScale 0.4, middle: r.ViewDistanceScale 0.7, right: r.ViewDistanceScale 1.0 (default) The switch's handheld mode is set to default, while the docked mode is higher than any image seen above.)

+CVars=sg.PostProcessQuality=1 (handheld)
+CVars=sg.PostProcessQuality=2 (docked)

(PostProcessQuality set from 0 on the left to 3 on the right. Handheld mode: Image 2, docked mode: Image 3)


+CVars=sg.ShadowQuality=1 (handheld)
+CVars=sg.ShadowQuality=2 (docked)

(ShadowQuality set from 0 on the left to 3 on the right. Handheld mode: Image 2, docked mode: Image 3)


+CVars=r.ScreenPercentage=66 (handheld)
+CVars=r.ScreenPercentage=100 (docked)

(Left: 50% no AA, Middle: 50% with AA, Right: 100% (no resolution scale) with AA. The Switch handled mode falls between the middle and the far right mage. )

 

[KingSnake]

Getting a bit off topic, here, but I find it quite interesting that the material properties change so much from one setting to the other (eg the reflectivity of the doors). I'd expect some differences in how things like this are implemented (eg cube maps on low settings, SSR on higher settings), but the general material properties should be roughly the same regardless of settings, and it's certainly odd that the door on the left goes from diffuse to reflective and back to diffuse again as you go up the settings.

I will check again and look a bit more into the details a bit later. Maybe I missed something.

 

[tkscz]

Street Fighter V on low settings running at a glorious 1062x598 (66% of 720p).

Confused on why you have it at 66% of 720p.

 

[JonnyDBrit]

I get the curiosity, but don't get carried away and put too much weight into screens from a project meant to showcase small-scale detailed static scenes, especially when you don't know what the scalability groups stand for.

A fair enough point, and again, apologies for my ignorance on the matter. Still, I feel like it help visualises something which can be a bit abstract, particularly at sizes and settings that I imagine most Gaffers would rather avoid in their own experiences.

 

[tkscz]

They are basically the engine scalability settings for UE4. I haven't used the UE4 editor much TBH, I have only poked around with it a few times, so I have no idea what "2" is for say +CVars=sg.ViewDistanceQuality in relation to what the setting options are. I'm sure there are a few UE4 experts lurking here who knows what that means.


But here is a much more detailed article from Epic's own website: https://docs.unrealengine.com/lates...ity/ScalabilityReference/#scalabilitysettings

Now put them all together into one image. Also is this just for scaling? Could someone sacrifice on thing to heighten another?

 

[Thraktor]

No? I'm not sure if you actually got what we meant, but here's an example setup:

The engine output resolution (as in the final framebuffer the engine delivers to the API or directly to the screen) in both cases is 1080p and the internal resolution refers to the render resolution of the 3D camera projection:
Docked: Internal Resolution is 1920x1080 and SlateUI is 1920x1080, so both are natively rendered in the output resolution.
Handheld: Internal Resolution is 1062x598 (66% of the engine output resolution) and SlateUI is 1920x1080.

The "twice scaling" should by all means be a non-issue (the engine doesn't handle downscaling the 1080p framebuffer for the handheld screen) and keeping the internal resolution the same can simply be an easier way of keeping things in line (especially when it comes to creating a pixel perfect, single-configuration UI in UMG).

Okay, fair enough, so the engine is still presenting a 1080p framebuffer for output in each scenario, and then the Switch hardware would scale down to 720p if in portable mode. I can understand that from a point of view of UI management, although I would imagine you'd still have to put some effort (simply from a design, rather than technical point of view) into making sure the UI still "reads" properly at 720p?

I will check again and look a bit more into the details a bit later. Maybe I missed something.

I don't think there's necessarily anything wrong with the settings, I just find it kind of curious that it happens, and would be interested to know how UE4 handles material properties and what's enabled/disabled/changed that causes these different looks. I don't really know anything about UE4 (as can be seen from the discussion above!), so I was just wondering what the cause is.

 

[M3d10n]

Ah, I stand corrected. Isn't that a bit... odd? You're basically losing detail by scaling twice, but getting a supersampled UI. It doesn't seem like a worthwhile trade-off, even ignoring any performance impact from the scaling itself. Is this just the simplest way of implementing the resolution difference (from a UE4 config point of view), or are these just dummy variables for the sake of dummy variables, as they expect every developer to choose all these settings manually, anyway?

It allows the game to switch between modes without having to change the output resolution or recreate the display surface, so I suppose the change between modes would be as fast as possible. The Switch will probably allow devs to actually do that, but seems Epic has, so far, decided to keep things simple. It helps with UI design as well, since the UI canvas will always 1080p and you don't have to bother with setting up UI scale curves.

Also, I doubt the Switch enforces games to undergo a resolution change, it's an alien concept on consoles (I think the PS3 was the only one where devs *had* to react to resolution changes or risk nothing showing up on the screen). The OS most likely takes the display surface created by the game, whatever its resolution is, and stretches it to fill the actual output framebuffer (all modern consoles do this - they have to in order to draw OS widgets on top of the games).

Getting a bit off topic, here, but I find it quite interesting that the material properties change so much from one setting to the other (eg the reflectivity of the doors). I'd expect some differences in how things like this are implemented (eg cube maps on low settings, SSR on higher settings), but the general material properties should be roughly the same regardless of settings, and it's certainly odd that the door on the left goes from diffuse to reflective and back to diffuse again as you go up the settings.

I think what happened there was that it uses only the cubemaps in low settings (which support pre-generated blurring), then goes into "fast SSR" (which doesn't supports blurring), then goes to "high quality SSR" (which does support blurring).

 

[Donnie]

They are basically the engine scalability settings for UE4. I haven't used the UE4 editor much TBH, I have only poked around with it a few times, so I have no idea what "2" is for say +CVars=sg.ViewDistanceQuality in relation to what the setting options are. I'm sure there are a few UE4 experts lurking here who knows what that means.
+CVars=sg.PostProcessQuality=2

(second setting from left)

Isn't 2 the third from left? It goes 0,1,2,3 doesn't it?

 

[M3d10n]

No? I'm not sure if you actually got what we meant, but here's an example setup:

The engine output resolution (as in the final framebuffer the engine delivers to the API or directly to the screen) in both cases is 1080p and the internal resolution refers to the render resolution of the 3D camera projection:
Docked: Internal Resolution is 1920x1080 and SlateUI is 1920x1080, so both are natively rendered in the output resolution.
Handheld: Internal Resolution is 1062x598 (66% of the engine output resolution) and SlateUI is 1920x1080.

The "twice scaling" should by all means be a non-issue (the engine doesn't handle downscaling the 1080p framebuffer for the handheld screen) and keeping the internal resolution the same can simply be an easier way of keeping things in line (especially when it comes to creating a pixel perfect, single-configuration UI in UMG).

In UE4, 66% screen percentage means 66% of the output resolution dimensions, not the area. So it renders at 720p (66% of 1080p).

 

[MrCunningham]

Isn't 2 the third from left? It goes 0,1,2,3 doesn't it?

Yeah it is, I made a mistake. I edited my post to change that. The handheld setting should be image number two and the docked mode should be image number three.

Now put them all together into one image. Also is this just for scaling? Could someone sacrifice on thing to heighten another?

Yeah of course the settings could be balanced differently to favor one feature over another. These just seem to be some sort of generic optimal Switch settings for both of the system's game modes I would imagine.

As for one large image... I will leave that up to somebody else

 

[2+2=5]

Street Fighter V on low settings running at a glorious 1062x598 (66% of 720p).

On Switch models will probably be downgraded too.

 

[_machine]

In UE4, 66% screen percentage means 66% of the output resolution dimensions, not the area. So it renders at 720p (66% of 1080p).

Ah right, sorry. It's indeed 1280x720p, rather than one I copied from someone else's post

 

[Oregano]

Well, I mean, I don't know if it's a technical marvel or anything, but UMvC3 on Vita is quite an impressive port.

You can even cross play with PS3 people iirc. Considering the Vita hardware and how superior the Switch will be to it, I wouldn't discard anything.

UMvC3 was running on <3 MT Framework <3 though.

Those Tekken 6 ports are bespoke versions specifically made for that hardware. If they make a Tekken game on the Switch they aren't just gonna take the arcade game and flip a few settings.

True but I meant it more that the Tekken team is absolutely willing to put that work in.

 

[Donnie]

Yeah it is, I made a mistake. I edited my post to change that. The handheld setting should be image number two and the docked mode should be image number three.

Ah right thought so from looking at the UE4 documentation earlier. Very useful post giving a idea about the difference between mobile and docked. Might I suggest you keep the info about which is which at the bottom of each image though (second/third from left ect).

 

[Shpeshal Nick]

So almost every part of the game will get scaled down? Not purely the resolution?

Sounds complicated.

 

[MrCunningham]

Ah right thought so from looking at the UE4 documentation earlier. Very useful post giving a idea about the difference between mobile and docked. Might I suggest you keep the info about which is which at the bottom of each image though (second/third from left ect).

Updated my post again.

 

[AlStrong]

So almost every part of the game will get scaled down? Not purely the resolution?

Yes, the geometry setup or front end of the render pipe is directly tied to the clock.

 

[Xdrive05]

UE4 layman here. So what are the actual differences between UE4's mobile vs. full rendering? How is the Switch's use of lower settings on the full renderer better than if it was just using the mobile one?

 

[MrCunningham]

UE4 layman here. So what are the actual differences between UE4's mobile vs. full rendering? How is the Switch's use of lower settings on the full renderer better than if it was just using the mobile one?

I just posted a few comparison's a few posts up: http://www.neogaf.com/forum/showpost.php?p=226982423&postcount=259

It should give you some basic ideas between the differences between the two modes.

 

[TyMiles2012]

From what I can tell it seems all of those settings along with resolution (ScreenPercentage) will scale between handheld mode and console mode. Rather than just resolution as some thought.

That's what I expected. Rendering resolution is very scaleable and has just as much of a performance impact rather than exclusive resolution. This gen definitely uses this to take advantage of scaleable resolutions in games like Doom and The Division.

Xbox One and PS4, if the resolution in the system is set to 1080p, everything is 1080p, as you can tell more commonly with Xbox One due to lower resolution games, even though the game is 900p, press the guide button and the Xbox interface is still 1080p.

That makes me wonder if the Switch screen is 1080p, and just scales rendering resolution between modes. Makes sense since the transition between both modes is supposed to be as seamless as possible. If both modes used exclusive resolutions, you would get a black screen for several seconds when you switch. The dock will always output a blank frame buffer at very low power, as soon as you put the device in, it quickly throws the console's display to the TV almost immediately.

 

[Two Pikachus]

So almost every part of the game will get scaled down? Not purely the resolution?

You could do purely resolution if you wanted to. These aren't hard, unchangeable numbers. They're part of an ini file, you can change the numbers however you want. You just have to design around your choices.

UE4 layman here. So what are the actual differences between UE4's mobile vs. full rendering? How is the Switch's use of lower settings on the full renderer better than if it was just using the mobile one?

The mobile renderer has a number of missing features. I don't know them off the top of my head right now but the mobile renderer just recently got shadows from dynamic lights and light info from emissive surfaces. It still looks great but can't take full advantage of all the rendering features as of right now. On Switch, there are no restrictions.

 

[Oregano]

UE4 layman here. So what are the actual differences between UE4's mobile vs. full rendering? How is the Switch's use of lower settings on the full renderer better than if it was just using the mobile one?

To add to this is there any evidence whatsoever that UE4 will take advantage of the FP16 secret sauce?

UE4 is apparently optimized for it.

 

[Father_Brain]

I just posted a few comparison's a few posts up: http://www.neogaf.com/forum/showpost.php?p=226982423&postcount=259

It should give you some basic ideas between the differences between the two modes.

You seem to be confusing "handheld" with "mobile." UE4 has a separate renderer specifically for mobile devices (someone more tech-adept than me can better explain how exactly how it's different), whereas even in handheld mode, Switch is apparently using the same high-end renderer that PS4/XB1/PC use, albeit on reduced settings.

 

[Two Pikachus]

You seem to be confusing "handheld" with "mobile." UE4 has a separate renderer specifically for mobile devices (someone more tech-adept than me can better explain how exactly how it's different), whereas even in handheld mode, Switch is apparently using the same high-end renderer that PS4/XB1/PC use, albeit on reduced settings.

He knows, he was answering someone asking what the difference was between the full renderer and mobile renderer and why it's better to use the downscaled full renderer instead of the mobile renderer.

 

[lwilliams3]

Yes, the geometry setup or front end of the render pipe is directly tied to the clock.

That makes sense. On a related note, does 2nd-gen Maxwell/Pascal render polygons 1 polygon/Hz or 2 polygons/Hz like GCN GPUs?

 

[Cerium]

So is this good news or bad news?

 

[MrCunningham]

You seem to be confusing "handheld" with "mobile." UE4 has a separate renderer specifically for mobile devices (someone more tech-adept than me can better explain how exactly how it's different), whereas even in handheld mode, Switch is apparently using the same high-end renderer that PS4/XB1/PC use, albeit on reduced settings.

That was bad wording on my part by calling the Switch's handheld mode "mobile".

But I had no idea that UE4 had a completely different renderer for just mobile devices. I have only made a few small demo's in UE4 and I never really learned much about the engine other than basic things. But that is fascinating though, neat info. Could the Switch be using the mobile renderer as well? It might be using the Android Vulkan Mobile Renderer and the handheld mode might just use a lower settings profile?

 

[sir_bumble_bee]

So is this good news or bad news?

It puts an end to "UE4 runs on mobile too so Switch isn't that impressive" counter arguments

 

[M3d10n]

To add to this is there any evidence whatsoever that UE4 will take advantage of the FP16 secret sauce?

UE4 is apparently optimized for it.

Yes, there's support for FP16 due to mobile support, where it's pretty much mandatory.

You seem to be confusing "handheld" with "mobile." UE4 has a separate renderer specifically for mobile devices (someone more tech-adept than me can better explain how exactly how it's different), whereas even in handheld mode, Switch is apparently using the same high-end renderer that PS4/XB1/PC use, albeit on reduced settings.

The full renderer is available on mobile too, but it's restricted to Metal on iOS, OpenGL ES 3.1 and Vulkan devices. The limited renderer is intended for OpenGL ES 2 and WebGL.

There have been demos of UE4 using the "full" renderer on Shield devices since its inception, so UE4 is no strange to Tegra.

 

[MrCunningham]

The full renderer is available on mobile too, but it's restricted to Metal on iOS, OpenGL ES 3.1 and Vulkan devices. The limited renderer is intended for OpenGL ES 2 and WebGL.

Ah yeah, that makes sense now. I bet the Switch is going to be using the full UE4 renderer through Vulkan. Though it probably also supports OpenGL ES 3.1 too.

 

[Ushay]

It's probably 720p for docked mode.

 

[AlStrong]

That makes sense. On a related note, does 2nd-gen Maxwell/Pascal render polygons 1 polygon/Hz or 2 polygons/Hz like GCN GPUs?

On paper, GCN is 1 tri/clk per geometry engine. Tahiti is 2/clk because it has 2, Hawaii/Tonga/Polaris 10 are 4 because they have 4 engines.

Anyways, a paper comparison doesn't help because of culling rates. nV has generally done a better job there, so the rates are somewhat higher per raster engine on Maxwell/Pascal.

 

[TwilightPrincess]

Ah yeah, that makes sense now. I bet the Switch is going to be using the full renderer through Vulkan. Though it probably also supports OpenGL ES 3.1 too.

The OS is listed as "Nintendo OS" and it passes the Vulkan 1.0.1.0 CTS.

The certification passing was yesterday, 18 December. Additionally, the Nintendo Switch is also listed as hitting OpenGL 4.5 and OpenGL ES 3.2 conformance.

http://www.phoronix.com/scan.php?page=news_item&px=Nintendo-Switch-Vulkan-Conform

 

[Oregano]

Yes, there's support for FP16 due to mobile support, where it's pretty much mandatory.



The full renderer is available on mobile too, but it's restricted to Metal on iOS, OpenGL ES 3.1 and Vulkan devices. The limited renderer is intended for OpenGL ES 2 and WebGL.

There have been demos of UE4 using the "full" renderer on Shield devices since its inception, so UE4 is no strange to Tegra.

That's definitely good then. Should help if devs want to take advantage of that then.

 

[Blam]

Oh this is good it goes from high (docked) to medium (undocked), and drops the screen resolution by 66% from 100%

 

[Smurfman256]

So I was trying to downclock my GPU to match rumored performance levels, but it requires a downclock so low that my card literally refuses to go down that far (it's a GTX 1070 and, in order to reach the 393GFLOPS target proposed, I would have to bring the clockspeed down to a paltry 102.3MHz).

 

[2+2=5]

Oh this is good it goes from high (docked) to medium (undocked), and drops the screen resolution by 66% from 100%

More like from medium(docked) to low(undocked), but take into account that there could be more downgrades.

 

[Father_Brain]

Yes, there's support for FP16 due to mobile support, where it's pretty much mandatory.



The full renderer is available on mobile too, but it's restricted to Metal on iOS, OpenGL ES 3.1 and Vulkan devices. The limited renderer is intended for OpenGL ES 2 and WebGL.

There have been demos of UE4 using the "full" renderer on Shield devices since its inception, so UE4 is no strange to Tegra.

Ah, I didn't realize that high-end mobile UE4 demos like ProtoStar used the full renderer. Interesting.

 

[TunaLover]

This is exactly what I wanted, lower the settings in portable mode instead to lower everything to keep parity between both modes. I think it's great that they seems to work with the docked mode as base, and then lowering settings to fit portable mode.

In before people saying but they should just call it a next gen handhled.

 

[LordOcidax]

So is this good news or bad news?

I think is good... But is a Nintendo+Technical thread....so.. is not going to end well, just watch.

 

[MrCunningham]

http://www.phoronix.com/scan.php?page=news_item&px=Nintendo-Switch-Vulkan-Conform

Oh thanks for answering that question. UE4's full renderer running through the Vulkan API should allow for some easy ports between iOS, Android and the Switch that support Vulkan. Probably even Windows/ Linux/ OSX as well.

 

[lwilliams3]

On paper, GCN is 1 tri/clk per geometry engine. Tahiti is 2/clk because it has 2, Hawaii/Tonga/Polaris 10 are 4 because they have 4 engines.

Anyways, a paper comparison doesn't help because of culling rates. nV has generally done a better job there, so the rates are somewhat higher per raster engine on Maxwell/Pascal.

Oh ok. Thanks for the explanation. Assuming that the Switch has a 256 Core GPU, how will the undocked/ docked geometry performance compare to the Wii U's ? How about the others?

IIRC, the geometry performance for the Wii U on paper was just a little higher than the 360/PS3, and it didn't have an efficient tesselation unit like what the newer console have.

 

[AlStrong]

Oh ok. Thanks for the explanation. Assuming that the Switch has a 256 Core GPU, how will the undocked/ docked geometry performance compare to the Wii U's ? How about the others?

IIRC, the geometry performance for the Wii U on paper was just a little higher than the 360/PS3, and it didn't have an efficient tesselation unit like what the newer console have.

RSX was particularly bad there (1tri/2clks on paper) hence all the work done via SPEs for culling, but WiiU also had a slightly faster core clock than PS360.

Switch likely only has one raster engine (it's a relatively big area cost), and WiiU's probably isn't that great coming from an earlier generation than GCN, which itself isn't particularly great (pre-GCN4/Polaris), so it wouldn't surprise me if the mobile mode was fine there.