Mkxp will be able to guess/handle any game resolution automatically as long is lower than 2048/1536,
without adding or editing the game resolution in "mkxp.conf".
The actual size of the window will be determined automatically from the "eventhread.cpp" during the initial launch of the game.
This breaks compilation with FLUID_SHARED against <2.0 versions,
which should be reasonable given that the default mode can still
dynamically load both variants.
Fixes#219.
Currently, the font enumeration callback erroneously stops searching if
it finds any files that aren't fonts. In the case that you have, say, a
desktop.ini or a .DS_Store or a license file, it may prevent all of the
fonts from being loaded. This commit resolves this.
Moved the windows-specific files into their own subdir for
cleanliness's sake and mesonbuild organization.
Signed-off-by: Marty Plummer <ntzrmtthihu777@gmail.com>
While the PingPong buffers were always texture-backed, currentScene
and transBuffer used to be backed by renderbuffers, which might have
been more optimized as render targets on older hardware; but since
all buffers in Graphics got switched to being texture backed to allow
blitting via rendering (when hardware blitting isn't available or broken,
eg. on mobile platforms), their reason to exist vanished.
For transBuffer, we can reuse the backbuffer of the PingPong structure,
while currentScene might have been useless from the start.
This was supposed to disappear shortly after To the Moon's release,
but it unfortunately survived a bit longer :)
The status of the mouse cursor being inside / outside the game window
is now properly exposed (in MRI) via MKXP.mouse_in_window.
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.
pk-2000
Jari Vetoniemi
Jonas Kulla
Luis Caceres
Eliza Velasquez
ReinUsesLisp
Carsten Teibes
Marty Plummer