Fix the inverted condition for USE_LEGACY_ZOOM_FACTOR

[HEIHUAa]

Fix the inverted condition for USE_LEGACY_ZOOM_FACTOR.
For nearly a year, the value set for USE_LEGACY_ZOOM_FACTOR has been correct, but the final code had the logic reversed. When USE_LEGACY_ZOOM_FACTOR was disabled, it actually used the 0.1.0 calculation method, while enabling it used the new one instead.

[HEIHUAa]

Additionally, I would like to check whether DEFAULT_SOUND_TIME_SCALED_PITCH seems to be inverted as well. In version 1.0.1, it was enabled by default to follow the pitch, while in the new version it is disabled. If this is confirmed to be a mistake, it could be changed to: if (DEFAULT_SOUND_TIME_SCALED_PITCH == null) DEFAULT_SOUND_TIME_SCALED_PITCH = MOD_API_VERSION < 3;

[Raltyro]

wait are you serious

[HEIHUAa]

wait are you serious

Yes, I'm serious. At least from what I remember, the behavior of the old 0.1.0 zoomfactor calculation appears in the current version when USE_LEGACY_ZOOM_FACTOR = false. Because when you add an object with a zoomfactor like 0.5, it produces a lot of offset during zoom scaling – that's clearly the same behavior as in 0.1.0. On the other hand, when USE_LEGACY_ZOOM_FACTOR = true, it scales relative to the camera's center point. Or is this the intended behavior? This is also why I initially thought API=2 was the old API.

[Raltyro]

Okay so further testing, the previous condition implementation was already okay, but apparently whatever i did to implement this zoom factor is basically the worst version of zoom factor, the legacy was already fine

In legacy, sprites with zoom factor of 2, whatever the sprite position is in, the anchor is in the center of the camera regardless of what scroll it is
Currently, in the same scenario, instead of the anchor in the center of the camera, it's the top left of the initial world position (0, 0) or the camera??

I don't know what i was thinking but i think i'll revert this buggy zoom factor later