Falling back to OS fonts

[mook]

Hi! This is a spinoff of the fontconfig discussion from #136; I want to avoid having this bog down that. It's largely independent.

What I want to do is to have optional things that try to locate a font file on the system if we can't locate it from the normal asset directories. On Linux, this would be via fontconfig; on Windows, something like GetFontFileInfo might work, but I haven't tested that yet. I don't know enough about OSX to do anything there.

Note that this code would basically be platform-specific :( - at least in the fontconfig case, it would involve asking pkg-config for it and just not using that code if it's not available. (So if you manage to get it in Windows or OSX, it'd would still try to do something.)

Things I plan on changing:

• When the font resource is not found, make (compile-time optional) calls to attempt to locate fonts.
  • When successful, this should insert the newly found font into the existing mapping, possibly mount things into PhysFS as needed, and return the font name / style. (This is to catch the case that the requested font name is family + style, e.g. "Arial Black" -> "Arial", "Black".)
• Font locations will need to be a {filepath, index} (since we can no longer assume that we only need to look at index 0).
• Actually try to handle font styles instead of "Regular" vs everything else.

Opening this issue before I waste your time with code if doing something platform-specific like this isn't desirable :)

(Side note: What are the targeted platforms for this? I assume C++11 is not required? Anything like compiler version assumptions or OS versions? How acceptable is, for example, std::tuple or std::map? Trying to understand why BoostHash<K, V> exists.)

[Ancurio]

(Sorry for the late reply, university + moving is sucking up all my time..)

One of the earlier design decisions I made when I started working on mkxp was to specifically not replicate RMXP's behavior of sourcing fonts installed on the user's system. Even though I try to replicate RMXP/Player's behavior as close as possible, this was just too horrible of a design to carry over.

Let's look at it from the point of view of a normal game engine: engine and game behavior is realized in code (compiled or interpreted), and this code processes data to display stuff on screen and play sounds. This non-code data is what we call "assets". In this scenario, fonts are just as much an asset as are bitmaps, as they are used to compute the final image (ie. text) displayed on the screen. And any proper game ships all its required code and assets together for one specific reason: To achieve a uniform game experience across any system. It wouldn't make much sense to have different images displayed or sounds played based on the users system; same thing with text. Now, if all you're targeting is Win32 platforms, you can actually make that guarantee even while sourcing system fonts. But when thinking in a cross-platform way, this is just not feasible. In a way, I'm prioritizing the "looks the same everywhere" aspect of RMXP over its technical implementation..

In order to alleviate this obvious problem in the context of RMXP/RGSS1, I enabled the local font sourcing from Fonts/ (normally only available in RGSS2+) in RGSS1, and also added the fontSub mechanism, in case fonts cannot be bundled due to licensing issues (Arial, New Times Roman etc. are all proprietary), without having to fixup all the game scripts.

What you are suggesting not being implementable in a cross-platform matter without introducing platform-specifc code is another obvious reason why this is problematic, but my former point is enough for me to NACK this. Sorry.

(Side note: What are the targeted platforms for this? I assume C++11 is not required? Anything like compiler version assumptions or OS versions? How acceptable is, for example, std::tuple or std::map? Trying to understand why BoostHash<K, V> exists.)

As for compiler/C++ version, I started this project back when C++11 wasn't all that ubiquitous, and don't see any major benefits to switching now. I do require some form of gcc though, as I'm not willing to put up with MSVC's bullshit (gcc-compatible like clang is fine too). So if you write code, it should compile as C++98 (ie. not passing any special flags to g++).

Edit: The "platform" I'm targeting is any desktop OS with SDL2/OpenAL and OpenGL support. I also did experiment with mobile/Android in the past, with varying degrees of success..

[mook]

Thanks for the feedback! Knowing the intent of the project was useful; I was attempting to use it as a cross-platform runtime for RGSS, but it sounds like you envision it more as a cross-platform engine that happens to use game assets that are built with RPG Maker. That is, you value being the same across platforms and being self-contained more than compatibility with existing unmodified games. That seems like a totally valid position to take, so I'll close this as being counter to your goals.

[Ancurio]

I was attempting to use it as a cross-platform runtime for RGSS, but it sounds like you envision it more as a cross-platform engine that happens to use game assets that are built with RPG Maker.

You make it sound as if I intentionally break RMXP behavior and mkxp just happens to tangentially run RMXP games. That is not the case. This font thing is a big exception to the rule, which is to reimplement the original RGSS behavior as close as possible, in a cross-platform manner. If you read through the RGSS specification/documentation, you will find that 99% of it is already formulated that way, there's little to no mentioning of Windows functions. Even the Win32API module isn't mentioned AFAIK.

My intention with mkxp was to make it possible to preserve games and make them available on as many platforms (with adequate hardware) as possible.

Here's an example: A simple test game, freshly created with RMXP, will display text in messages using Arial (in the English version, at least). How do you replicate this behavior on other platforms? Maybe on OSX you'll still be able to, but in general, you cannot reproduce it on any free platform that doesn't ship proprietary fonts. So I'm forced into a compromise from the very get-go. Your solution doesn't address this at all, instead, it just makes the current behavior even more inconsistent.

That is, you value being the same across platforms and being self-contained more than compatibility with existing unmodified games.

I value this because this is what RMXP already offers. All RMXP games are self-contained (as long as you properly add the dll and any RTP assets you used into the folder), and run on a fresh, unmodified WinXP install. The example with the generic engine was just to clarify that this is something every (good) engine/game adheres to, so it's a good mentality to follow regardless.