I could understand if they cancelled it considering the user base not large enough, but doing it for graphics is dumb, it's quite obvious that most existing Wii U users have no problems with its HW performances. Just turn down a little either resolution or FX or both, 30fps, enough for casuals, shouldn't be an unreachable goal, while hardcore gamers would get the PC version anyway.

Well, since 7 fps is what they are missing to reach the 30fps, just ask yourself, how many times can you fit 7fps in 30fps?

30/7=4.2857

so, if 30fps=100% and 7fps can fit 4.2857 in 30fps then 100%/4.2857 is?

x=23.33%, this is what they are missing, 23fps is what they already got wich is 76.66% out of 30fps

No offense but i have also met people with problems for calculations as well

Use this logic for 30fps and 60 fps, ho many times you can fit 30fps in 60fps?

60/30=2

meaning that if 60fps is 100%, then 100%/2 and you get 50%

As for the antialaising, yea is probably that they have already either disabled AA or implemented the SMAA, they may have been using batching as well and maybe frustrum culling but doubt that they have used occlussion culling since its more tricky than the first one and requires more effort and time to implement and seeing how amny games have been released these generation with so many perfromance issues i doubt Slighly mad studios hasnt followed the same path as ubisoft,cd project, capcom, etc

Frsutrum culling may be almost automatic since its description of what it does makes it look easy, but if you read the occlussion culling documentations you can conclude that is not that automatic and requires programmer to think over how to implement it, even if the engine can implement it automatically is never gonna give the same performance as manual, not to mention that the technique is a double edge sword and if not used correctly its gonna give less performance than if you handt implemented it since there are situations when occlussion culling is not necessary as it takes more effort from the cpu than not using it

here is an example

http://http.developer.nvidia.com/GPUGems/gpugems_ch29.html

"

29.3 Beginning to Use Occlusion Queries

The real problem is the GPU pipeline flush. Normally the CPU and GPU work in parallel: When the CPU issues a command to the GPU (for example, "render some triangles"), it doesn't wait for the GPU to finish. Instead, the CPU's driver feeds the commands and triangles to the GPU command queue, which lets the CPU continue with other tasks. When the GPU is ready to process the stored commands, the triangles are rendered on screen.

However, the rendering process differs for occlusion queries. The GPU needs to tell the CPU how many pixels were drawn on-screen, which means it must render them first. The problem? The CPU must wait until the GPU finishes rendering triangles used for the occlusion query—and not only those triangles, but all triangles given to the GPU before the occlusion test.

This is not good. Trying to "save" the GPU from rendering the occluded object doesn't speed up the rendering process. The truth is that even when most tested objects are occluded, rendering is much slower because the CPU and GPU no longer work in parallel.

It's clear that the naive approach isn't going to work very well. So, the real question is. . .

29.3.1 How to Use Occlusion Queries Properly

29.6.1 CPU Overhead Too High

We need to account for the CPU overhead incurred when we send rendering requests to the GPU. If an object is easy to render, then it may be cheaper to simply render it than to draw the bounding box and perform the occlusion test. For example, rendering 12 triangles (a bounding box) and rendering around 200 triangles (or more!) takes almost the same time on today's GPUs. The CPU is the one that takes most of the time just by preparing the objects for rendering.

However, testing the object's bounding box is sometimes a must, no matter how many polygons the actual object has. What if the rendered object has a very complex pixel shader and occupies a notable portion of the screen? In such a case, even though the bounding box has more pixels to be drawn, the pixels can be rendered much faster (especially because they are rendered only to the depth buffer!) than an object itself, which would tax the GPU with many operations per pixel.

29.7 A Little Reminder

Keep in mind that occlusion culling works best when objects have lots of polygons. An occlusion query won't accomplish much for objects of, say, 300 triangles, even if there are hundreds of them on-screen. Speed might improve moderately, but it depends on the CPU load and the speed ratio between the CPU and the GPU. A fast GPU, coupled with a slow CPU, makes an application CPU-bound, and occlusion testing won't help much.

On the other hand, if there are a lot of polygons per model (more than 1,000 is a good start), occlusion culling shows all its glory. Speed-ups can be more than double (depending on the scene, of course), plus it's almost free. And rendering is not noticeably slower—even if all the tested objects end up visible!

29.9 Conclusion

At first sight, occlusion query looks like a really powerful tool—and it definitely is. However, like any other tool, it requires a certain degree of skill and knowledge to use effectively. You need to be able to recognize the situations in which it can be helpful.

In this chapter, we gave just two examples of how to use this technique efficiently. Of course, you don't have to stop here: there are many more things you can do with it. For example, occlusion query can be used for determining geometric level of detail based on the number of pixels occupied by an object. Or you can even use it in a visible-surface-determination algorithm.

Like any other technique, occlusion query will evolve. In the beginning, it will be used for rather simple tasks. But over time, we expect programmers to find amazing new applications for it as various obstacles are removed. With a little luck, this chapter has helped you to get started. Now the real exploration is up to you.

"

You see?

No engine is gonna solve that automatically, the programmer must make sure that occlussion culling is used properly if not then you get more performance drops than gain

Then again, the easiest option is variable resolution like in Wipe Out HD if they dont want to do this

Well, since 7 fps is what they are missing to reach the 30fps, just ask yourself, how many times can you fit 7fps in 30fps?

30/7=4.2857

Now, that is the decrease!

Please calculate the increase from 23!

Like that:

Use this logic for 30fps and 60 fps, ho many times you can fit 30fps in 60fps?

60/30=2

meaning that if 60fps is 100%, then 100%/2 and you get 50%

60fps is 200% of 30 fps then. You agree?

So going from 30fps to 60fps is a 100% increase.

Still going from 60fps to 30fps is a 50% decrease.

Now the baseline is 23fps. So you have to get from 23 fps to 30 fps. Not from 30 fps to 23 fps.

For the rest, what do you know the Madness Engine does and does not? Everything about culling/hidden surface removel in general, batching etc. is just speculation.

Getting the resolution down reduces the GPU-load. Not the CPU load. That doesn't help as long as the GPU isn't limiting.

Nope, 30fps to 60fps is 50% increase if the 100% is 60fps, is a simple rule of three, never heard aboiut it?

the baseline is 23fps has already been reached, menaing you need 7fps to reach the 30fps, so how much is 7fps to 30fps since 30fps is the 100% we want to reach?

Rule of three

30fps=100%

7fps=x

thats all, that will give you the porcentage that we are missing to get 100%, the 23fps is the porcentage that alreaqdy has been achieved

Yea, could be speculation but also your commensta are speculation as well, not to mention that if it results true that the engine was set up to do occlussion culling automatically that means there are high possibilities that there could be lots of cases where the culling is not necessary and instead of releasing stress it does the opposite just like how the documents of nvidia tell us.

As for the resolution decrease solution, i have two words for you, compute shaders, go and check yourself what they are good for and then you will get the idea behind

hype doesnt equal sales

no problem?! lol Ninty owners have been complaining about "gimped" versions of games for year. you think all of a sudden they wouldnt mind this game? naw

if every person on this site who actually WANTED to play the game on WIi u chips in five it still wouldnt come close to covering the cost.

What? 30 to 60 is a 100% increase. A 50% increase from 30 is 45.  

You're doing your maths wrong.

Fixed.

Read accurately, if the 60fps is the 100% that we want to reach, then 30fps is 50% of that goal, meaning that if we increase 30fps again that would be another 50%

the same applies for 23fps to 30fps

how much is 23fps from 30fps(100% we want to reach), then the 7fps that we are missing are the ?% we still have to accomplish to get the 100%(30fps) since the 23fps percentage has already been achieved