Included font goes missing: BYOND cache error?

ID:109833
 
Feb 20 2011, 9:56 pm
BYOND Version:479
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 3.6.13
Applies to:Dream Seeker
Status: Verified
A member of our crack team of bug testers has verified that this issue is reproducible, and has handed it off to the development team for investigation.
Descriptive Problem Summary:
When a font is included in a game but is not installed on the player's system, it sometimes completely disappears from buttons, labels etc. within the game's interface.

NEStalgia uses a custom font which we include in the compile by simply referencing it from within a DM file like so:

/var/NEStalgia_Font = 'NEStalgia.ttf'

That font is used for all of the interface labels and buttons, and usually works just fine:

Working example

However, the BYOND cache can apparently become corrupted and cause the text to disappear completely without defaulting to a backup font:

Broken example

This has happened in every version of BYOND released since NEStalgia development started a couple years ago. This bug has been reported before (but with less information provided).


Reproducing the Problem:
I've tried to create working demo to reproduce the problem, but I can't get the bug to trigger reliably. Although random, it does seem to happen much more often during remote server reboots and shut downs.

Most NEStalgia players get the bug when the game server shuts down or reboots. Upon occasion the bug can also be caused by logging into the game on two separate keys from the same computer and then closing one of the open DS windows. At that point the buttons/labels on the remaining DS window sometimes wipe immediately, and sometimes are just broken the next time the player logs in.

Operating system doesn't seem to be a factor: players using XP, Vista and 7 have all been hit.


When does the problem NOT occur?
The problem does not ever occur if the font in question is already installed on the player's system.


Workarounds:
When a player gets "bugged" with this issue, the only way to fix the problem is for them to clear their BYOND cache via the pager and then reboot their computer.
Feb 21 2011, 8:22 am
I'm not certain that 2565 is the same issue. Coldreaper was extremely vague about both the symptoms and causes of the problem, and included no information at all that would be needed to reproduce it, nor even a screenshot to see what he meant by "black text". There was a recently fixed bug with skin loading that could just as likely be the same problem.

Your issue on the other hand I've seen before in one of Android Data's projects, but it was just the one time. I'm seeing what I can find out about it.
Feb 22 2011, 7:51 am
Here is the information I have gathered so far:

I have managed to get an assertion failure in GetTextExtent() in debug builds, which I believe usually manifests as missing text in a release build, when opening a second window from the same server while the first is still open. (Exact sequence: 1) Open DS. 2) Host. 3) Join that session in a new DS window. 4) Do something in window #2 that uses the custom font.)

My research suggests that AddFontResource() doesn't like to play nice with other apps, but the solutions are limited and poor without using AddFontResourceEx() which may fix the problem--just not in a way that's particularly easy for us to do. The alternative I tried was using CreateScalableFontResource() with the read-only flag. This did not fix the assertion failure--though that may be solvable another way--but it also meant the usage of this font had to be handled in a special way, which also meant the output control could no longer use custom fonts.

The bottom line is we have to set this aside for the moment in the interest of expediency, but I hope to get back to it soon and come up with a true working solution. If AddFontResourceEx() is the solution however then this will only work for Win2K+, and the solution will leave 9x users in the cold. At this point though, I'm not sure that even matters.
Feb 22 2011, 9:45 am
Lummox JR wrote:
The bottom line is we have to set this aside for the moment in the interest of expediency, but I hope to get back to it soon and come up with a true working solution.

Right on. Thank you!