Converting Pics from SCI1 to SCI1.1 format

[cdb-boop]

Before I attempt to program a Pic converter or recreate each Pic manually, I wanted to know if anyone had other suggestions for approaching this.

I'm trying to convert a SCI1 game to SCI1.1. I decompiled and bootstrapped the scripts (more changes may be required later to properly handle audio). It was crashing on run and I narrowed down the immediate cause to the DrawPic function call. I had assumed that the SCI1.1 interpreter could handle SCI1 Pics, but perhaps it's not backward compatible? Unfortunately the internal developer tools have Pics editor builds (PE.EXE) that stop at 1992. PICTEST.EXE appears to test for SCI1.1 Pics and rejects SCI1 Pics. I also tried running PIC2NEW.EXE, but it kept asking for a palname.dat. Within SCICompanion, I'm not aware of an existing way to convert Pics between formats, only extracting all files, importing individual files but maintaining the format or exporting just the visual screen.

[lskovlun]

Yes, there is one in Omer's stash. (https://sciprogramming.com/community/index.php?topic=1631.0). It's called PIC2NEW (be aware that it generates output files with a .PN extension, and you'll need to rename them back to .P56 yourself).

[cdb-boop]

Hmm... I tried that but it kept telling me I needed a "palname.dat" file. Do you need to run it inside a project or something? I had copied a test file into the tool folder.

[lskovlun]

Come to think of it, I have a dummy palname.dat file in that directory. Just put the number 999 in there, and make sure 999.PAL exists (or use some other name if you prefer). PIC2NEW won't use it; I guess it's some common code that loads it.

EDIT: By the way, the 999.PAL file I put there is an SCI1.1 format palette.

[cdb-boop]

Thanks! That worked!

The only issue I had was that SCI1.1 palettes exported from SCICompanion didn't work for some reason. I had to use the SCI Viewer scripts to get a valid palette.

[lskovlun]

The palette file I used was converted, I think, from an SCI1 resource using another one of those programs. Sometime last year, so I can't remember exactly what I did.

[lskovlun]

Another thing you're probably going to run into (spuriously or not) is that the palette management strategy changed between SCI1 and SCI1.1 ("copying" and "merging" strategies, as they are called here. Games written for one are likely to glitch in the other. I am not sure how to fix that,

[cdb-boop]

I don't believe I've run into any palette related issues yet. I am running into a very familiar graphical glitch, which if recall correctly I think is because the class property definitions were incorrect and needed to be updated to match the template game. I'm trying to fix this now.

[cdb-boop]

I updated the Actor classes to match the template to fix the bug of rendering every View as View 0. Annoyingly that change caused Pic to use the palette of the last drawn View, as soon as the View adds itself to gCast.

[lskovlun]

Sounds like the property offset table (vocab.994) could be subtly broken...

EDIT: And I think you could be seeing the effects of the palette difference I mentioned already.

[cdb-boop]

I'm using the SCI1.1 template game as the base, so I'm not sure what would be wrong with the offset table... If I only render the Pic in an empty room it renders with the embedded palette correctly. Just for some reason it seems to be overriding the colors with a View's palette added to gCast. Could be a low level class code issue. I'm slowly transitioning the low level classes to match the template game.

In better news, the iconbar and cursors appear to render properly in an empty room. I had to manually recreate the cursors as Views, offsetting the cursor number by 1000, and factor in the offset in the non-kernel setCursor.

[doomlazer]

Isn't that the expected behavior? There should only be one palette available per room. Loading a pic and view with conflicting palettes is going to overwrite the previous colors.

That's why you can't transition between rooms with conflicting palettes without distortion or fading to black. This was often the case with EcoQuest where they would use checkerboard transitions between rooms with incompatible palettes and it looked terrible.

I believe it's also the reason most actors keep to the first 16 (or 32) colors so they can move between all rooms without issue. The rest of the colors are then used for pics or per room objects.

As an aside, with scummvm you can do some palette tricks, like overriding the static SCI0 palette. You're still limited to 16 colors, but you can assign them to any RGB value, allowing for a monochromatic effect with a dozen shades of a single color.

[Kawa]

I believe it's also the reason most actors keep to the first 16 (or 32) colors so they can move between all rooms without issue. The rest of the colors are then used for pics or per room objects.

The global palette tends to be 64 colors (0-63, plus 255). Other than that you're basically on the money.

[cdb-boop]

Thanks! I see now! 64 globally and the rest for the room. I'll have to reconvert the Pics because they have the wrong global palette embedded. And I can use the palette remap feature to align actors with the global palette.