We need to convert color values back to Glk format before returning them
from glk_style_measure(). We do this by encoding the value as a string
and then to a long with strtol().
This fixes bug 13622 and the same problem (cyan background) in Magnetic
and Level9.
- Common: add wordWrap function to ustr.cpp
- Bladerunner: Explicitly state we have a U32String in subs (same as Subtitles::loadOuttakeSubsText)
- Don't use translations for engine specific "put strings", because they might not support.
- SCI: Use const references for showScummVMDialog
- SCUMM:
-- Don't use translation in md5 warning. left comments with the translated version.
-- Remove some redundant headers in help.cpp
-- Don't use translation in handleSaveload when printing to console
-- Also, display success transaction correctly via u32::format
- TESTBED: Use fake constructor when setting label of button
- SKY: Correctly use translation when using SaveStateDescription
- ULTIMA: Don't use translations when display_string
- ENGINES:
-- GenerateUnknownGameReport correctly, with proper translations.
-- There was an error, where a function had been declared twice, in a header file. Correct this.
After the initial changes just to scummvm/gui for u32, this commit includes the whole project
- Widget creations now always have u32 descriptions, labels, or tooltips
- Message dialogs make use of default arguments instead of providing the same argument explicitly
- encode String::format properly before passing on as argument where necessary
- Modify hugo utils (yesNoBox and notify box) to use u32
- Also provide fake constructors for the above which redirect to the u32 constructor
- Convert all keymap descriptions to u32 across all engines
- showConfirmationDialog in mohawk now uses u32
- showScummVMDialog also uses u32
- Scumm engine has dialogs now which use u32
- General fixes and wrapping convertToU32String for setLabels and related functions
- Add a fake constructor to MesssageDialog which redirects to the u32 constructor
The resource file format Hugo uses has named entries.
Because of this, the original Glk code added to Hugo
does a whole mess of reading in a picture, then copying
it to a dummy pic file with a dummy number, just so a
call to glk_image_draw could detect it.
Since this isn't the first time I've had to deal with
named resources, it ended up being cleaner to add a new
variation of glk_image_draw and glk_image_draw_scaled
that can take in a string image parameter. That way, I
was able to set up an archive class to represent the
resource file, and pass the resource name directly
without worrying about dummy picture numbers & files