megafenix

4 reasons:

Xenoblade

Fast Racing Neo

Fatal Frame V

star fox

https://www.youtube.com/watch?v=gXP0UCh2-NE

https://www.youtube.com/watch?v=vbex7PQ8XYs

I am not sure that NX(if its a home console of course) will keep backward compatibility via hardware since it could be said that IBM is out of the semiconductor market after selling its fabs to GlobalFoundaries;although IBM has a contract with GlobalFoundaries so that they will keep making chips for IBM(contract seems to be for 10 years since 2014), it seems that will only cover the new power pc designs like watson or chips for super computers and not desktops; IBM seems to be interested only in high end supercomputers and in cloud, mobile, analytics and other technologies, so it could be said that desktop chips are no longer in their plans

http://www.pcworld.c...end-design.html

It seems nintendo has two reasons for moving into the x86 design, developers need and no one to make powerpc chips for them or at least in the line for desktop pruposes

As for the GPU, i feel it will be just a little above ps4 in terms of raw power, but there is one thing i am almost certain, NX will use HBM/HBM2 technology(i feel it will be HBM2 since HBM has a limit of 4 gigabytes), with this the power consumption will be lower and edram will not be any longer necessary for GPU bandwidth needs, with this the development process will be easier, specially for third parties

4 local multiplayers at 60fps?

mm, i am a little sceptic but i will give them the benefit of the doubt, the reason for having doubts is that mario kart achieved 60fps but with 1 or two players, for a split screen of 3 or 4 framerate drops to 30fps so i would imagine that this game might do that as well

Looks bad ass, cant wait for a gameplay video to see it in motion, hope they can show us somethign on the E3 at treehouse but since its still in alpha stage that might not happen and maybe the game will not make it for this year

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

"

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, 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.

"