View Full Version : Engine assuming fixed-width font?
I think Healeth illustrated it in a news entitled "2005.3.26 — De impossibilitas collocationis versuum", most vn engines just allow/assume using only fixed width fonts, but it turns out rather poorly for Western text.
In RealLive, it's been solved by plugging an extension DLL (IIRC?), but how would you do otherwise?
Haeleth mentionned intercepting GetGlyphOutline calls, but all I've got is a single call to GetTextExtentPoint32 for obtaining the bbox of a single character; otherwise it's TextOut all the way...
Most straight-forward way would be to just patch their text engine. Find where it's incrementing the x position, and replace the constant by the width of the current character being processed (which you should be able to get from a Win32 function call). Some assembly required...
Just for reference, rlBabel's GetGlyphOutline interception is used for applying custom mappings between the CP932 codespace and Unicode -- i.e. as a way of supporting non-Japanese text in an engine that was designed only to use Japanese text. It's a separate issue from proportional text.
To zalas: Alas, this is not exactly how it is done.
Basically, the layout engine sees the rendering surface (whole screen in vn mode, message box otherwise) as a grid whose coordinates, and therefore dimensions, are determined once for all at game init using the aforementioned method. I'll see if patching that call and hardcode a constant instead works (CreateFont uses hardcoded "MS Gothic", a font with fixed metrics).
I'm not convinced this is a really good idea though, only by considering people might run Windows with different dpi settings than those commonly used.
To Haeleth: Let's see, if I still follow you, this means possibility to render "out of locale" text? Hmm, sounds interesting.
I'm having a look at the rlBabel source at the moment, it seems it performs a hook on GGO; I suppose I could just hook my call and perform magic tricks (UTF-8>WCHAR, etc.)...
Yes, by intercepting requests for Shift_JIS character codes, converting them to Unicode via a custom transformation, requesting the Unicode characters, and returning the results to the game - which has no way of realising that it's been given a totally different character from the one it asked for. :)
As for the original problem: if the message window is unavoidably a grid of squares, you might be able to adapt the technique used in rlBabel's tiled_string module (basically, replace the calls that print characters in the grid with calls that render the entire text to a bitmap and then copy squares of that to the grid).
How feasible that would be depends on a lot of factors, of course.
Given that the call to TextOutA acts on a SJIS string (well, narrow would be a proper term) as a whole and not char by char, it looks clearer now.
There are several references to the import but drawing VN text is centralized at one spot; it seems fairly logical to patch that particular call rather than hooking.
Since I'm not very inclined to distributing a modified executable, I'll enquire into ways of injecting alien code into the process (the CreateProcess/VirtualAllocEx/VirtualProtect etc. gig).
If it's calling TextOutA on a complete string, then you may be in luck - simply hooking the call to CreateFontA and having it request Arial or whatever instead of MS Gothic might work.
vBulletin® v3.8.6, Copyright ©2000-2017, Jelsoft Enterprises Ltd.