SCI Companion V3 - alpha build notes/bugs/feature requests

[AGKorson]

Andrew, are you still using the FastColoredTextBox class for your C# editor?

Yeah, that's still the plan. I forked it and added code page support to it so it will load/save files in DOS code pages. But now I'm wondering if I don't need to do that- maybe I leave the source files with Windows-1252 encoding, and then only convert to DOS code page when compiling. I'm still not sure which way is the best.

[Kawa]

I'd say leave the source files as Win-1252 so external tools can work with it.

...Though nowadays Unicode would be preferred, while some 32 characters in the middle don't match between Unicode and Win-1252, because the first 256 characters in Unicode match ISO-8859-1 instead. Oops.

(I found it was easier to write external tools of my own to handle SCI 1.1+ UTF-8 support than to convert SCI Companion. Go fig.)

[L@Zar0]

Sorry if this has been asked, I saw that you talk about codepages. Would it be possible to add codepage 850 to SCI Companion v3?

I say this because I think 850 is the multilingual old DOS codepage used for european countries like Spanish, Italy, France and German, and some characters like "?" (0xB5) (present in SQ5 for example, even here in the forums shows ?, not the unicode/win1252 char), are not correctly translated when exporting message file.

I want to try something with SCI Comp v3, and see if I can add that codepage, but I didn't want to modify the code.

You can see here a list of codepages:
https://www.aivosto.com/articles/charsets-codepages-dos.html

And here, 850 codepage:
https://www.aivosto.com/articles/charsets-codepages-dos.html#codepage850

Here is one of the character fonts, and you can see they match.

[Kawa]

CP-850 is the DOS Latin-1 codepage, used in Western Europe. I, being Dutch and old know it well, and it'd be a nice little challenge to try and extend things to support European games as well as American ones. (And Japanese if you know how, it's a trick.)

[L@Zar0]

Ok, I will download source and try to do something. I'm from Spain, so, in my old DOS days I had to use also codepage 850.

Maybe I will push a PR, if I remember how to do them and can reach some type of codepage 850 implementation. xD

[L@Zar0]

Mmm... using Codepage 850 in font editor...




But I'm having some issues yet in other places (like opening exclamation and question symbols not showing correctly in texts, but accents are ok):



I think that for the symbols exclamation and question, uses Codepage 437, but for the rest of symbols CP850 (at least in spanish). I don't know about other localized languages.

And here it is CP437 (after changing it in Settings, and reopening font tab, of course):

[L@Zar0]

Well, in any case, I have pushed a PR that adds Codepage 850 if you're interested (or add the code by yourself, now you have the needed changes).

The japanese/chinese characters uses a different encoding, and I don't think it will be as easy as add another language like could be Greek/Rusian or similars. I don't even know how we could achieve that giving that Kanji has thousands of logographics. Apart, the .fon files will be able to use all those characters?

[Kawa]

Supporting Japanese in SCI Companion is a hack and a half that won't cover SQ4, but it will work on for example PQ2, because all of them except SQ4 use Shift-JIS. So what you wanna do is claim the game uses Windows 1252 which bypasses the code page translation, then use AppLocale or some such to make SCI Companion itself run in Shift-JIS. Because it was never a Unicode application and for most of us can be assumed to run on Win-1252.

And that means the encoding used in PQ2-JP can match SCI Companion's... by making SCI Companion match PQ2's instead.

As for the font data: the Japanese games run on a system that has such beautiful features as "an entire Shift-JIS kanji character set in ROM" and "can display higher-res fonts on top of low-res graphics". The actual SCI font data only contains some katakana in the upper moby.

And then there's my SCI1.1+ which has UTF-8 support, entirely inspired by the fact that in the font data, it says "number of characters" instead of "highest character number". So "256 characters" instead of "up to #255". It's a 16-bit number and Unicode at the time hadn't developed into the astral planes yet. But I just said SCI Companion is not Unicode aware, so how do you use it with SCI1.1+? That's the best part: you don't! I wrote a command line tool to handle message resources in UTF-8. The only thing SCI Companion knows is that the max amount of characters isn't 256.

[L@Zar0]

Hi again,

I'm having problems when importing images -256 colors indexed bitmap (.bmp) images- into Space Quest 6. I used Photoshop (the worst for indexed images) and Paint Shop Pro 7. With Paint Shop Pro I understand that the indexes are correct.

I'm having the issue with picture: 150 and view: 150 (the main menu). Picture 150 seems to have a lot of black pixels with different black indexed colors, that cycle with the palette. When I import the picture, all this is deleted, it seems the indexes are lost. Can it be?

Also, after importing, when I export the file (150.p56) and use it, it causes an error in scummvm saying that there is not Cel 0 selected or something like this.

Do you know if there is any fix for this?

PD: Ok, after checking the image exported, it seems the indexed colored pixels are not correctly exported (at least when exported they seem to be index 0 (black color), but if you check in SCI Companion with mouse cursor, you will see in 150.p56, that all the black pixels, have different index.

[doomlazer]

SCICompanion seems to export this picture with the wrong header. See export.png attached below for a comparison of the same file exported in SCIViewer and SCICompanion. To fix scumm error, replace 0x8180000... with 0x8181

For the palette, make sure you're using the imported bmp palette instead of merging them (see 1.png). I used GIMP for this test, but I believe most translators prefer FotoSCIhop for some reason.

[L@Zar0]

This is very interesting. I didn't thought the header (when greater than 0x80) had any impact. In any case, I near always (98%) use "Map to current palette".

BTW, the stars of the menu are moving in your case? If I import the image that way SCI Companion always translates all black pixels to index 0, when the pixels have different indexes that makes in-game simulate you are flying among the stars. If you want see the stars, you can check it changing temporaly the palette with colors (this is a common issue of modern image editors, they use the nearest color and not the INDEXED color, you have to use a tool that supports 100% indexed colors or use a palette whose indexed colors are all different):



I will try FotoSCIhop. I'm having problems now with 150.v56. For some reason the rle part of the code leaves the bytes different from the beginning. For example, you can add a point to the cursor:



You can compare the original with this new 150.v56, and you will see that at least the rle part of the image is totatlly different:



If you use that 150.v56 modified with the game, there is a point where the drawings appear incorrectly drawn (like the own cursor).

[doomlazer]

...I didn't thought the header (when greater than 0x80) had any impact...

The problem is that there are extra bytes added to the SCICompanion export, so it can't read the cel count and other info that follows 0x8180 because it's not at the right offset.

I don't think the RLE is the problem; the image is correctly aligned. It looks like your image editor might be changing the palette. Everything looks correct (including moving stars) in the test i did using GIMP. I'd recommend trying a different editing program before anything else.

[L@Zar0]

I've finally been able to modify 150.v56, but I had to use FotoSCIhop with Paint Shop Pro 7.

I've been looking at the code of SCI Companion, but this is a bit more difficult than changing the CodePage. Apart, there is a possibility that changing something for solve this, breaks another thing in other images.

Anyway, let's try to advance.

Thanks a lot.