performance(Drawable): Rework for IterateDrawablesInRegion Functions for both GameClient and W3DView to be more Efficient

[IamInnocent3X]

To use the features, RETAIL_COMPATIBLE_DRAWUPDATE must be set to 0. The feature is Retail Xfer Compatible, but might require checking. RETAIL_COMPATIBLE_DRAWUPDATE can be removed once the check is done.

• GameClient: Informs whenever a New Drawable has been registered or a Drawable has Moved. If the Drawable is within the Screen Region, it will be registered onto a Drawable List. The List is reset everytime the Camera Moves or a Stealthed Object has been Detected, or a Unit has Transitioned a Disguise. Resetting means it will reiterate the Drawable List from the first and registers Drawables that fits within the Screen onto the List.

Above directly addresses the Issue - #1502

• W3DView: Used for Selecting. Edited Function converts the Selection Region onto a Radius and gets its Center, then uses Partition Manager to find List of Drawables within the Region. Has a configured minimum Iterate Radius of 200.0f units as a Requirement to Select Airborne Units when selecting with a small region.

[xezon]

I glanced over it and I see it does add quite a bit of complexity and GameClient is now at the mercy of other systems properly registering and unregistering drawables. The first question here is, does the Game (and WorldBuilder?) still work normal? The second question is, how big are the performance gains here? If you can, please provide frame ms time comparison.

Code needs cleaning. No commented and compiled out code should be left.

[xezon]

Better keep the (Real) cast.

[IamInnocent3X]

The code is tested playing against multiple AIs in Skirmish on both Vanilla and Contra Mod with both Saving and Loading, so it should be fine in game.

I haven't tested on WorldBuilder, but it should not have any issues. Moving the camera or Adjusting the Positions should account whether an object is within the screen region for iteration.

I will have to check for the performance gains, but I do notice it being a bit lag-free during the testing sessions.

[xezon]

Needs performance results to check if the direction and added complexity is worth it to begin with.

[Mauller]

The partition manager in general is very inefficient and can do with an overhaul.

It seems to be one of the main bottlenecks in AI games due to the repeated calls to getClosestObject

[IamInnocent3X]

The partition manager in general is very inefficient and can do with an overhaul.

It seems to be one of the main bottlenecks in AI games due to the repeated calls to getClosestObject

Seconded, PartitionManager could really use some caching implementation to prevent repeated checks.
Several things I could think of include: Collision occurring within the same cell, whether or not objects collided, etc. These things that are not oneshot, or are checked every frame could be implemented better.