Opened 15 years ago

Closed 15 years ago

Last modified 5 years ago

#8928 closed patch (fixed)

SDL: setWindowCaption() only works for ASCII

Reported by: eriktorbjorn Owned by: fingolfin
Priority: normal Component: Ports
Version: Keywords:
Cc: Game:


There was a recent forum post [1] which noted that ScummVM doesn't set the window caption properly if a game title contains characters outside of 7-bit ASCII. On some systems, it prints the wrong characters. On others, it simply fails.

Apparently, SDL_WM_SetCaption() expects the string to be encoded with UTF-8 [2], but ScummVM uses ISO 8859-1 ("Latin-1") internally. The attached patch translates the string if necessary. It seems to work fine on my Linux box, but I'd appreciate input and testing on other systems.

[1] [2]

Ticket imported from: #2167477. Ticket imported from: patches/1033.

Attachments (1)

sdl-caption.diff (1.1 KB ) - added by eriktorbjorn 15 years ago.
Patch against current SVN

Download all attachments as: .zip

Change History (18)

by eriktorbjorn, 15 years ago

Attachment: sdl-caption.diff added

Patch against current SVN

comment:1 by SF/mac_es, 15 years ago

Works as spected.

ScummVM 0.13.0svn (Oct 15 2008 09:44:54) Features compiled in: Vorbis FLAC MP3 zLib MPEG2 FluidSynth

WinXP SP2 Spanish

comment:2 by fingolfin, 15 years ago

Actually, the OSystem::setWindowCaption() documentation explicitly states that only *ASCII* (i.e. 7bit) characters are supported. Furtherermore, no encoding is specified. Hence the proper fix would be to filter out all non-7bit chars. And fix engines which incorrectly try to pass non-ASCII data to it.

*Or* we extend the OSystem API to accept ISO Latin 1 or UTF-8, but then all ports have to be adapted.

comment:3 by bluegr, 15 years ago

I've tried writing a Greek string to the game's description

Several warnings are thrown when ScummVM tries to manipulate the Greek string (in isctype.c, line 56 - it throws an assertion there). HOWEVER, when I launch the modified game directly, the Window's caption is set (almost) correctly to the Greek string with eriktorbjorn's patch (the caption has some junk in the end) - that's under Windows XP / Vista

But I agree with fingolfin here, non-ASCII data should be filtered out OR we could accept UTF-8 strings for the game's description

comment:4 by eriktorbjorn, 15 years ago

Ah, I didn't read the setWindowCaption() documentation. I just assumed that since the GUI uses Latin-1, setWindowCaption() did too.

I think the only game engine that calls setWindowCaption() is Broken Sword 2, and I've never been quite sure whether or not it was a good idea. The main use of the function, as far as I know, is to set the window title to whatever the user has entered as game description.

comment:5 by SF/mac_es, 15 years ago

Also, the problem exists ingame menus.

If you look into the forum url, you will see an ingame dialog which has problems whith non ASCII characters.

comment:6 by eriktorbjorn, 15 years ago

In-game dialogs is a different problem, though. That's about the game telling ScummVM what to draw. This is about ScummVM telling the operating system (or window manager) what to draw.

This made me curious to see what kind of data the various backends really expect as input to setWindowCaption(). I found it defined in the following files, though I may have missed some:

dc/dcmain.cpp - Needs further study. ds/arm9/source/osystem_ds.cpp - Does nothing iphone/osys_iphone.cpp - Does nothing null/null.cpp - Duuuhhhh... PalmOS/Src/be_os5.cpp - Needs further study. psp/osys_psp.cpp - Does nothing sdl/sdl.cpp - Expects UTF-8 symbian/src/SymbianOS.cpp - Calls the one in OSystem_SDL (UTF-8) wii/osystem.cpp - Calls printf() wince/wince-sdl.cpp - Calls the one in OSystem_SDL (UTF-8)

So in most cases it doesn't really matter, and in most of the rest of the cases we use SDL, which expects UTF-8. Of course, expecting UTF-8 means that ASCII is perfectly fine, but Latin-1 isn't.

But there are two ("dc" and "PalmOS") where I'm just not sure. The PalmOS documentation I found seems to implicate that characters can be either single-byte or multi-byte, which is frustratingly vague. The Dreamcast backend seems to store the window caption in save games, but I assume that text is displayed somewhere.

comment:7 by SF/mac_es, 15 years ago

Should I submit a new bug tracker for in-game dialogs?

comment:8 by eriktorbjorn, 15 years ago

> Should I submit a new bug tracker for in-game dialogs?

That's what I would do. (If I had any games that exhibited the bug myself.)

comment:9 by SF/mac_es, 15 years ago

>That's what I would do. (If I had any games that exhibited the bug myself.)

Done, Bug# 2171287


comment:10 by fingolfin, 15 years ago

The DC port seems to use the caption to augment the savegames (it writes it into each save). However, the data doesn't seem to be loaded. Well, maybe it is loaded by the DC OS, when browsing the memory unit. Best to ask Marcus to find out.

comment:11 by SF/mac_es, 15 years ago

FYI, The code makes the WinCE port crash when launching a game (the launcher starts though). Whith a special chars and whithout them...

comment:12 by sev-, 15 years ago

What is the status of this item?

comment:13 by eriktorbjorn, 15 years ago

Fingolfin changed the SDL backend to replace non-ASCII characters with question marks, but I don't know about the other backends. I believe ScummVM will still try to use non-ASCII characters.

comment:14 by sev-, 15 years ago

Then it is up to those backend authors. As I understand, rest of them do not use window captions except, perhaps WinCE. Thus I'm closing this tracker item.

comment:15 by sev-, 15 years ago

Owner: set to fingolfin
Resolution: fixed
Status: newclosed

comment:16 by fingolfin, 15 years ago

Well, the fact remains that we documented that API as taking ASCII only, yet our client code (i.e., launcher/main) passes non-ASCII data to it. Bad. So it's not just the porters who'd have to do something (and in any case, we should let them know, actively, if there's a problem here ;).

I'll email to scummvm-devel

comment:17 by digitall, 5 years ago

Component: Ports
Note: See TracTickets for help on using tickets.