Its to bad that they are considering NX when clearly this console wont be out this or next year, if they dont want to put so much effort in squeezing the Wii U specific features(fixed shaders most likely) there are other approaches they can take
Use SMAA isntead of MSAA or EQAA
1.-If THEY by chance are using MSAA or maybe EQAA like the ps4 and xbox one, they can replace it with SMAA which gives similar results to MSAA with less strain improving performance and doesnt blur as much as FXAA and can be used as a post-processing antialaising solution http://www.tweakguid.../Crysis3_6.html
Occlusion Culling may also be of big help:
Try Occlussion Culling
2.-Occlusion Culling is a feature that disables rendering of objects when they are not currently seen by the camera because they are obscured by other objects. This does not happen automatically in 3D computer graphics since most of the time objects farthest away from the camera are drawn first and closer objects are drawn over the top of them (this is called “overdraw”). Occlusion Culling is different from Frustum Culling. Frustum Culling only disables the renderers for objects that are outside the camera’s viewing area but does not disable anything hidden from view by overdraw. Note that when you use Occlusion Culling you will still benefit from Frustum Culling.
http://docs.unity3d....ionCulling.html
http://http.develope...ugems_ch29.html
3.-Some adjustments on the LOD(level of detail) for renders that are far away is also an option.
Try out a variable framebuffer so that resolution will change instead of the framerate (Wipe Out HD did this)
4.-Another approach is to use a variable resolution/framebuffer so that resolution will change isntead of the framerate during the gameplay, this way whenever there would be fps peaks the resolution will change isntead. This trick was used in Wipe Out HD for the ps3 tokeep the 60fps at variable 1080p(resolution could go as low as 1440×1080 certain times) and tricked many as is not very noticeable in race games http://www.eurogamer...sleight-of-hand
A, i almost forgot this other solution(reduces the number of draw calls)
http://docs.unity3d....llBatching.html
"
Draw Call Batching
To draw an object on the screen, the engine has to issue a draw call to the graphics API (e.g. OpenGL or Direct3D). The graphics API does significant work for every draw call, causing performance overhead on the CPU side.
Unity can combine a number of objects at runtime and draws them together with a single draw call. This operation is called “batching”. The more objects Unity can batch together, the better rendering performance (on the CPU side) you can get.
Built-in batching support in Unity has significant benefit over simply combining geometry in the modeling tool (or using theCombineChildren script from the Standard Assets package). Batching in Unity happens after the visibility determination step. The engine does culling on each object individually, and the amount of rendered geometry is going to be the same as without batching. Combining geometry in the modeling tool, on the other hand, prevents efficient culling and results in a much greater amount of geometry being rendered.
Static Batching
Static batching, on the other hand, allows the engine to reduce draw calls for geometry of any size (provided it does not move and shares the same material). Static batching is significantly more efficient than dynamic batching. You should choose static batching as it will require less CPU power.
"
Edited by megafenix, 28 May 2015 - 08:22 AM.
