SCI1 View Format

[doomlazer]

I'm trying to convert SCI0 Views to SCI1. If there is an existing tool, please let me know. It can be done by exporting each cell in SC then importing as an image sequence, but it's tedious to do.

The SCI0 view format is straightforward enough. I can parse the file and export all loops and cels which gets me most of the way there, but it would be nice to convert to .v56 instead of having to rebuild the view by hand in SC.

Here's the problem. A comment in Scummvm's repo says the SCI1 view should be:

// LoopCount:WORD MirrorMask:WORD Version:WORD PaletteOffset:WORD LoopOffset0:WORD LoopOffset1:WORD...

but when looking at 0.v56 from KQ5, I can find the loop count [8] at 0x26, but nothing else seems correct. Loop 1 should mirror loop 0, and since that's the only mirrored loop, the mirror mask should be 0x0200. The Palette seems to be tacked on to the end of the file and is nowhere near the supposed palette offset. Loop offsets also appear incorrect.

For VGA11 is formatted a bit different, but I'm still having the same problem - I can find the loop count, but nothing else seems to match up.

Any thoughts as to where I'm going wrong here?

[lskovlun]

Are you taking the view compression into account? SCI1 does this weird thing where the parts of a view (and pic) file get moved around to improve locality, and thus the compression factor. Compression type 3 and 4. This should have been removed by resource extractors, but you never know.

[doomlazer]

Hmm... that would make sense. Is there any documentation on those algorithms? FreeSCI's documentation lists SCI1.0's compression types as:

3   UNKNOWN-0
4   UNKNOWN-1

I suppose the answer is in the SVM or SC code, but I'd prefer not having to learn C++ to be able to reverse engineer the algorithm.

Strangely, SCI Viewer shows all the KQ5 views as type 0 (uncompressed), so maybe that isn't the problem IDK.

[lskovlun]

Funny that all your views use compression type 0. Maybe that's because you extracted them? All the views in my KQ5 use compression type 3 (which SCI Companion calls LZW_View). Similarly, all the pics use type 4 (LZW_Pic). One way to tell whether the file is compressed or not is to look for the signature bytes 'PAL' followed by 256 bytes: 00 01 02 etc. This doesn't compress very well and is constant anyway, so the decompressor simply inserts it in the right spot.

[doomlazer]

You must be using the Floppy version as I see all those views are compressed with type 3. The CD version has uncompressed views though. SCI Viewer does remove the compression when exporting as they are identical except for the palette, which does differ between CD and Floppy.

I realized I made a stupid mistake. I assumed there was a 26 byte header for SCI1 views because that's were I found the first word that matched the loop count. This is incorrect. It's just like SCI0 and the loop count is at 0x02.

What threw me off is that bytes 0x02 and 0x03 for KQ5 view 0.v56 are 0x0880, which would be 32k loops, but the following word matches the expected mirror mask of 2 and the palette offset does indeed point right to the start of 0x0001020304...

Kind of frustrating that byte 0x03 threw me off so much. Guess I should have realized it was crazy to think it had a 26 byte header. Still, it's confusing that 0x03 isn't zero. Perhaps it's ignored because there shouldn't really be 256 loops in a view? Or maybe the comment in SVM is inaccurate (which has bitten me before).

Anyway, having realized my mistake, I should be able to figure things out from here. TY

[doomlazer]

I finished the first phase of my SCI View converter. No SCI1.1 support yet, but you can still get there thanks to a SCICompanion hack Kawa added awhile back (which is described in the help info).

[Collector]

Any chance for a stand alone version instead of Javascript? Perhaps in C#?

[doomlazer]

Whats wrong with JS? I plan to learn C# or C++ in the near future, but I'd like to figure out the SCI1.1 view format first.

[Collector]

Your work is certainly appreciated, but it is not so much being against Javascript itself, I just would rather have an independent program than having to rely on a browser to run it. Also, if it was just an executable it could be made into a plugin for companion. Then you could call it from Companion. If it were a stand alone command line EXE I could easily do a GUI for it.

[doomlazer]

Probably wouldn't be too difficult to port things over. I'll look into it this week when I get a chance.

[cosmicr]

I am curious, are you converting an EGA game to VGA?

Otherwise, what's just stopping you from copying and pasting a few times in SCI Companion?

Or was it just an exercise "because you can"?

[doomlazer]

I realize this isn't exactly groundbreaking stuff, but the need to convert views has come up pretty frequently for me. I'm very slowly working on a clone of the arcade game Crossbow in SCI and I have no qualms about reusing Sierra's assets.

Moving a view from one SCI version to another usually requires copy/pasting each cel then manually adjust the origin points for each as well. If your walking animation has 6-8 cels times 4 loops it can get annoying fast.

Also, yes, it's a learning exercise for me.

I managed to get SCI1.1 views to import today, so now I just need to write the SCI1.1 export function and I'll be able to quickly convert between SCI0 and SCI1.1 in any direction.