The previously YIQ-based algorithm turned out to be both slow,
and horribly inaccurate.
Another algorithm based on rotating the color value in the
RGB cube along the diagonal axis was also considered, which was
acceptable in terms of accuracy, and very fast.
In the end, I decided on a HSV-based one, because it is by far
the most accurate one, while still being a tad faster than the
YIQ solution.
Algorithm source: gamedev.stackexchange.com/a/59808/24839
A very simple GPU time benchmark when shifting a 2048^2 bitmap:
YIQ rot RGB rot HSV shift
radeon 13.4 ms 2.8 ms 11.4 ms
intel 13.0 ms 6.0 ms 10.5 ms
radeon: HD 3650 mobility
intel: N3540 integrated (Baytrail)
However hue shifting has never shown up as a bottleneck before,
so these are more academic.
Instead, update the surface with the same change. For many
consecutive getPixel() -> setPixel() calls on the same bitmap,
this avoids calling glReadPixels at every iteration.
More accurate behavior, such as Font objects properly inheriting
their name attributes, and centralization of code for picking
the first existing name from a passed string array.
Also centralizes initial default_name population in core.
Note: This currently breaks the mruby binding build.
Calculation was completely off as it didn't take into
account the imposed viewport origin.
All in all, similar fixes as the previous ones to TilemapVX.
Before, even though we did match all possible extensions,
we only took the first match and tried opening it.
If we were looking for a .png image, but there was an unrelated
.txt file with the same name (as it actually happens in RTPs),
we would potentially see the .txt first, try opening it,
and fail alltogether, even though the image file existed.
Now we try opening all matching files until we find one that
we can parse.
This fixes#101.
The default value is an empty string, which triggers the simple
transition. Passing null is not legal (and wasn't possible in
mkxp from Ruby side anyway).
Fixes#108.
Jonas Kulla
Mook
cremno