[Scummvm-devel] Proposed modification to OSystem::displayMessageOnOSD()

Johannes Schickel lordhoto at scummvm.org
Mon May 16 15:48:42 CEST 2011


> a) Do we want to keep a separate font for OSD or would using the GUI or
> Console font be fine? Since those last two are already present in both
> built-in and localized fonts (in theme packages) that would be the easiest
> way to go. If we want to keep the ScummFont, is there any information on
> that font somewhere (e.g. where does it come from) to make it possible to
> generate localized fonts? A possibility would be to keep ScummFont for OSD
> if we don't use translations, but switched to the localized GUI (or
> Console) font if needed.
> 

Personally I always wondered myself why we still have that OSD font.

IMHO it would be fine to get rid of the OSD font and adapt the SDL and OpenGL 
backend and furthermore the MT-32 code not to use it, but the GUI font 
instead.

> b) According to your knowledge, is there any other backend (other than SDL,
> OpenGL, Android and PS2) that reimplement displayMessageOnOSD() and that I
> missed?
> 

A quick grep over backends/ didn't reveal anything else for me, so I guess no.

> c) Loading localized font is still handled by the ThemeEngine. I am fine
> with that since the fonts have to be loaded from the theme zip files
> anyway. But can this be a problem to use these fonts in classes not
> related to the GUI? I can't see one but maybe I missed something.
> 

In case code uses the font classes for custom purposes it will probably know 
itself what encoding it uses. It will furthermore probably either want an 
ISO-8859-1 font, which is what our default console/gui/etc. fonts use IIRC, or 
use a custom font.

> f) Finally (and the most important) is it fine to say that
> displayMessageOnOSD() should assume the message uses the current encoding
> of the TranslationManager and to implement the change I am proposing or is
> there any objections to it (or a better way to achieve the goal)?
> 

The better way would be still to use an Unicode encoding, since that way our 
client code could even display strings from the game data files correctly via 
our GUI/OSD. :-P

Apart I guess for now there isn't much of a better solution to this.

// Johannes




More information about the Scummvm-devel mailing list