Opened 15 years ago
Closed 15 years ago
#4459 closed defect
CRUISE: Missing font data for Spanish
| Reported by: | SF/mac_es | Owned by: | dreammaster |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Cruise |
| Version: | Keywords: | ||
| Cc: | Game: | Cruise for a Corpse |
Description
The special characters of spanish version (á,é,í,ó,ú,ñ..) aren't drawn at all. The system.fnt file is present, and it doesn't throw any error .
Cruise for Corpse 256 colors spanish, ScummVM 1.0.0svn42673 (Jul 23 2009 14:51:25), Windows Vista SP2
As I have seen in the commits, is missing the character lookup for spanish font in staticres.
Ticket imported from: #2826014. Ticket imported from: bugs/4459.
Attachments (2)
Change History (13)
comment:1 by , 15 years ago
| Owner: | set to |
|---|---|
| Summary: | Missing font data → CRUISE: Missing font data for Spanish |
comment:2 by , 15 years ago
comment:4 by , 15 years ago
Okay, the first step is to download the executable unpacker I've attached to this bug report. If you run it on the delphine.exe in your game directory, it will take care of unpacking the executable. This is important to be able to successfully locate the necessary data.
Once the executable is unpacked, you'll need to load it in a hex editor. Any should do - I personally use xvi32, but it's up to you. The important thing is that it has the ability to search a given file for a given series of bytes.
The series you'll be looking for is represented using a series of 2-byte values for each entry in the list - so it will be 512 bytes in total. Since the first 33 entries are all -1, the first 66 bytes of this sequence will be 'ffh'. Following this will be a sequence like '00 00 01 00 02 00 03 00..'
With xvi32, you can select the first byte of the 'ffh' sequence and use the 'Block Mark' functionality, then move to a point 512 bytes beyond it as use 'Block Mark' again. You can then use the 'Clipboard -> Copy As Hex String' to copy all the byte values as hex to the clipboard. With that, if you could paste it into a text file, save it, and then attach it to this bug report.
That'll be all I need to add support for the Spanish version font. Thanks.
comment:6 by , 15 years ago
Thanks for that. I've added in the data. If I could get you to give it a quick test to confirm it works, then I'll close this bug.
comment:7 by , 15 years ago
It works partiatly, now it shows characters but not allways the correct ones.
For 'ñ' it shows 'ñ' For 'í' it shows 'ó' For ó' it shows 'ú' For 'á' it shows 'í'
comment:8 by , 15 years ago
Well, I double-checked the list, and it seems to be correct based on what you provided. So unless the original had some extra code for mucking around with strings as they're loaded, the differences are probably in the original as well.
In which case, there's no easy solution. If you wanted to take the effort, and know how to compile the code, you could try figuring out which ASCII value represent each of the characters, and try fiddling with the values in the lookup table to make sure the characters are correct. The only trouble with that is with such poor translations, whilst doing so may fix some text messages, some other text may be relying on the current mappings, and will thus become broken.
comment:9 by , 15 years ago
Could you elaborate more?
I can compile, I know the ascii codes, My C++ is quite obsolote (I do JAVA)...
How is the table working? I can try to fix it
comment:10 by , 15 years ago
The table basically acts as indexes to a reduced font set. A lot of positions in the ASCII table don't actually have displayable characters, so you'll notice that's why the first 33 entries in this list are all '-1' - that represents that the 32 control characters, and the space character (ascii 32) don't have any representation.
After that, the indexes specify what index in the raw font data a given ASCII character corresponds to. The biggest number used in the lookup table is 0x76 (decimal 118), which means the Spanish font data has 118 distinct characters - most of these will be the standard ASCII characters from 33 - 127, but the remainder will be the special accented characters.
Some things you can try:
* Go to the start of the renderText method and hardcode the 'string' parameter to any given sequence of accented characters, in particular the ones you're interested in. You can then easily locate the positions of their ASCII characters in the lookup table and try fiddling with the indexes until what gets displayed matches the characters in your string. Just remember that the lookup table has *256* entries, which means it includes 'ASCII 0' as it's first entry. So for a given accented character which is, say, ASCII 150, you'll be counting up to find the 151st position in the lookup list.
Just remember, if you decide to make the changes, then afterwards we'd need you to do a full play-through of the game to ensure that the changes you made to the font apply everywhere, and there aren't other messages within the game that actually relied on the incorrect font mapping to display their strings correctly.
I'm going to close this bug entry now, since the Spanish font has been uploaded. If you can sucessfully create some workable changes to the translation list, you can post it to the patch tracker.
comment:11 by , 15 years ago
| Status: | new → closed |
|---|
Unfortunately, I'll need the direct assistance of someone with a PC Spanish version of the game to extract the necessary data for this table.