Atmos Duality said:
I'm just going to guess at what moon-logic lead to the coding that caused that performance hit.
Perhaps they intended to slow the menu down for a controller, which lacks the operating speed and precision of a mouse cursor. But instead of slowing it down via menu scaling/ticks, they just said "fuck it, lets slow EVERYTHING down just to be sure" by lazily reprogramming it in the menu's video renderer (instead of its handler, ie, the actual menu coding).
I honestly can't think of anything else.
One word:
Scaleform.
In modern gaming engines, the menu systems and HUDs are often coded in Flash, then overlaid on top of the ingame graphics by means of a piece of middlewhere called Scaleform.
It's wonderful for game pipelines because it means you have a huge pool of graphic designers, UI programmers, web designers, et cetera who are already familiar with flash and can use their visual talents and flash's customary vector graphics to make squeaky clean, visually appealing, super-nice menus.
On the other hand, the shit you have to do to actually get the Flash UI to talk to the ingame systems is a little bit crazy. In older systems, the engine has its own script for making menus, and it's one big script to make the visuals happen and get the interaction working. Here, it's an entire separate object essentially operating outside the game. You literally have scripts whose only purpose is to act as a middleman between the game and the UI, which can lead to awkward disconnects.
You also have to tell Flash how to interpret the gamepad. Because it doesn't know.
The game engine
itself knows, but where Flash can directly take mouse and keyboard, it actually has to receive gamepad data
from the engine first, then have it interpreted
into something it can actually use to navigate menus. Thus, when you have the Xbox 360 controller setting on, there's a whole extra stream of data and set of calculations being performed
every single frame that the menu operates just to make sure the damn thing works.
This is in addition to the fact that Flash is ungodly slow to begin with. Especially most forms of Scaleform pre-2011, which run on Flash Actionscript 2 (hundreds of times slower than the engine) as opposed to Actionscript 3 (dozens of times slower).
And, probably, there were priority issues when you had both the 360 controller and the mouse and keyboard in at the same time, and somebody... over-thought the thing and engineered in two modes, one of which assigns priority to the 360 controller and the bold-faced options in menus and the other of which assigns priority to the mouse clicks over that. Those extra modes were probably costly, and they probably couldn't think of a way of determining this automatically. Me, I'd have just taken a good look at what kind of input is coming in when the user hits "new game" and had the game check or un-check it based on that, but whatever.
That, I believe, is your explanation.
