Since it's running on CryEngine 3, maybe if the GPU is SM 5.0 compatible it's automatically labeled as DX11? Because if you read the entire thing you can see the engine mentioning "DX11 Profile", not DX11 itself.

Allot of the GPU's "Direct X 11" class hardware capabilities would be extended to developers via OpenGL, the only console that has and will ever be able to use the Direct X API would be Microsoft's consoles.

Converesly, they could build a game which strictly uses the Direct X 11 API, then have the OpenGL API interface with that for other platforms, OpenGL being open allows developers that kind of flexibility.

Am i the only one who isnt all that impressed by cry engine 3?

p.s.

I'd be more concerned about the 15fps than the DX11.

Nothing to be concerned about; prior to optimization and debugging, games often run in at single digit framerates.

In all my years of game development, the only times a game has been single digit framerates is when developing an engine from scratch, never have i encountered a situation where taking an existing, externally developed third party engine has a text map without final textures, post processing, DOF or full lighting been considered "normal" to be under 23-25fps.

The WiiU is better hardware than the 360 and ps3, the wiiu devkit runs at slightly higher spec than the retail wiiu (to handle debugging overheads), i can tell you right now that, that 15fps right there, definitely IS something to worry about.

If anyone had hopes of this game being 60fps, theyre going to be awfully dissapointed, i would not be surprised if it releases bouncing around the 30fps mark.

Several dev interviews I've read describe incredibly low framerates in early development. 

From the recent interview at Digital Foundry on Titanfall 360: "with a single player, our average frame-rate in Fracture was around 5fps, and that's without any textures"

That generally happens when porting a game.

You know, since they took the source engine and modified it heavilly to work for the game they had in mind, and for the Xbox One, those modifications had to then be ported over to the 360 and scaled back to fit the specification. it's only natural in this sutation that the initial port is going to run like a dog until they optimize the existing assets to work as best they can on the new platform.

Sonic boom is using an engine that directly supports the hardware, and building resources specifically for the console, not porting over assets designed for a more powerful platform.

You're also dealing with a situation where a developer or publisher wants to give the best possible light to both the developers and the game while leaving enough room to obsolve them of any issues later on, if they were to say "we imported the engine and resource tree and spent a few weeks fixing up the code to get it to actually run, but since we still had high geometry models and maps and basically half the code was still utilizing methods and resource expectations of the original platform it ran like a piece of shit, but once we actually worked towards getting things more in line with what was going to be in the final release we easilly got it up to the mid 20s" what happens is people ten ask why if it was so easy to get it to the mid 20s, why isnt it 45fps-60fps, its always best to give the absolute worst case figures when dealing with PR, so even if the retail product falls short of the mark, you can circle back and say "we did our best, remember when it was running at only 5fps without textures? we got it to retail at 28fps!" that sounds like a much bigger achievement than it should be, and thats how PR works such information.

But when youre working with an engine that has its own support for the hardware, and building a game from that, theres no excuse for it to be single figures, none at all.

Sonic Boom is not using the vanilla Cryengine 3, it's modified.

You're catastrophizing. 

clearly we are not going to agree here, but you need to think about things a little more..

Define modified, what exactly would they modify?, "engine runs great stock, has a full feature set and more than enough graphical support for what we need".

Modifications for this sort of thing come in the form of modifying script to get the engine to handle the type of game you want to make, say you want to link a camera to a ped and the ped itself will be linked to a sprung set of bones that follows the player, you cant do that in the stock engine, you would have to modify the engine source to do it, but doing so wouldnt kill the fps from stock engine speeds down to single digits, if anything it would increase the speed because the number of tris in the camera FOV is now lower.

Best case scenario, they imported models without any optimization and are just testing with polycounts that are much higher than they will be at retail, and they will tone it down till they get better performance, but i stand by my analysis, this game will be 30fps at best.

If you disagree then fair enough, just don't get defensive when it turns out the game does release at that.

Indeed we will have to agree to disagree. If this was 15fps in a dev screen a month before launch I'd be worried, but given that I don't see this launching before October, I'm not worried.