Previously, file lookup (ie. extension supplementing) would only
try out a few predetermined extensions based on the asset type.
This was not accurate in regard to RMXP's behavior, which will
happily match "some_asset" against "some_asset.abcef" and try
to open it.
Some games make use of this quirk and rename their ogg audio files
to "*.dat" or similar to thwart users from copying them.
This change also makes it easier to read arbitrary formats
supported by SDL_image without modifying mkxp.
MRI: Filesystem: A garbage collected SDL_RWops file handle
will call close on itself even if 'close' was explicitly
called on it on the script side before.
This removes the static dependency on fluidsynth being present
at buildtime (even headers aren't needed anymore).
Even though midi is a default format for the RPG XP/VX series,
it has fallen more and more out of use, with VX Ace completely
abandoning it from the RTP and making ogg vorbis the de facto
standard. Midi support is kept for legacy reasons, but isn't
encouraged. On top of all this, fluidsynth together with glib
is a heavy dependency that often times won't even be used.
Making it optional at build time is an attempt to unify and
keep build config fragmentation low.
In RGSS3, fluidsynth / midi is not initialized at all by
default, but rather on demand when either a midi track is
played back or Audio.setup_midi is called.
This adds a new dependency with libfuildsynth. MIDI support
is built by default, but can be disabled if not desired.
All RTP songs should work well, but there are known problems
with other files (see README). Also, the pitch shift implementation
is somewhat poor and doesn't match RMXP (at least subjectively).
A soundfont is not included and must be provided by
the user themself.
Previously, any font names requested by RGSS would be translated
directly to filenames by lowercasing and replacing spaces with
underscores (and finally doing some extension substitution).
To make this whole thing work smoother as well as get closer to
how font discovery is done in VX, we now scan the "Fonts/" folder
at startup and index all present font assets by their family name;
now, if an "Open Sans" font is present in "Fonts/", it will be
used regardless of filename.
Font assets with "Regular" style are preferred, but in their
absence, mkxp will make use of any other style it can find for
the respective family. This is not the exact same behavior as
VX, but it should cover 95% of use cases.
Previously, one could substitute fonts via filenames, ie. to
substitute "Arial" with "Open Sans", one would just rename
"OpenSans.ttf" to "arial.ttf" and put it in "Fonts/". With the
above change, this is no longer possible. As an alternative, one
can now explicitly specify font family substitutions via mkxp.conf;
eg. for the above case, one would add
fontSub=Arial>Open Sans
to the configuration file. Multiple such rules can be specified.
In the process, I also added the ability to provide
'Font.(default_)name' with an array of font families to search
for the first existing one instead of a plain string.
This makes the behavior closer to RMXP; however, it doesn't
work 100% the same: when a reference to the 'Font.name' array is
held and additional strings are added to it without re-assignig
the array to 'Font.name', those will be ignored.
Because Windows has case insensitive paths, this should
be turned on (which it is by default) for maximum
compatibility. Can be turned off as an optimization
(this will speed up startup a little depending on the
number of game assets).
This looks like a pretty major change, but in reality,
80% of it is just renames of types and corresponding
methods.
The config parsing code has been completely replaced
with a boost::program_options based version. This
means that the config file format slightly changed
(checkout the updated README).
I still expect there to be bugs / unforseen events.
Those should be fixed in follow up commits.
Also, finally reverted back to using pkg-config to
locate and link libruby. Yay for less hacks!
An exception is made of TexPool, which will need a
bit more testing before transitioning to std containers.
Also replace 'int' with 'size_t' where it is used only
as an array index.
The general rule I'm aiming for is to <> include
system wide / installed paths / generally everything
that's outside the git managed source tree (this means
mruby paths too!), and "" include everything else,
ie. local mkxp headers.
The only current exception are the mri headers, which
all have './' at their front as to not clash with
system wide ruby headers. I'm leaving them be for now
until I can come up with a better general solution.
This is a major change in the Audio module that comes with
many changes throughout the codebase and dependency list.
The main gist is that we're finally nuking the last pieces
of SFML from the project. sfml-audio brought with itself
unneeded and big dependencies (libsndfile, libvorbisenc)
while at the same time limiting the amount of audio formats
mkxp can support (eg. we now get mp3 for free, and wma/midi
can be implemented by extending SDL_sound directly).
The increased control gained by interfacing with OpenAL directly
will also allow for easy integration of a dedicated audio
stretcher (librubberband), as well as enable us to implement
looped ogg vorbis (via the 'LOOPSTART'/'LOOPLENGTH' tags),
as required by RGSS2, in the future.
The FileSystem class has had its SFML parts removed.
Aditionally, audio file extensions to be supplemented are
now automatically detected based on how SDL_sound was
built (ie. if no mp3 support was built, mkxp won't try
to look for *.mp3 files). The final used extension
can be optionally returned by 'openRead' calls so
SDL_sound and SDL2_image can immediately choose the
right decoder.
The OpenAL context is created and destroyed in main.cpp
along side the GL context.
Finally got around to nuking that ugly pile of shit that was
previously there for PhysFS file enumeration because filepath
cache generation with unencrypted game files + archive + RTP
has started taking around 6 seconds. Thank $DEITY.
This should be almost as fast as reading unencrypted
files from disk now. I also don't see any possible further
optimizations, so this is probably as fast as it gets.
Jonas Kulla
Mathew