256-color views for SCI1.1 - a modest proposal of sorts

[Kawa]

Wonderful work!

Thank you! No it isn't.

To demonstrate how easy it can be to work with a template like this, here's me as of earlier today:

The hair took longest.

[troflip]

Nice progress!

... trying to think about how the "paper doll assembly system" could be incorporated into SCI companion...

[MusicallyInspired]

Make it a separate tool from the View editor. Or at least an optional add-on system like the polygon system.

[Kawa]

Make it a separate tool from the View editor. Or at least an optional add-on system like the polygon system.

Or just make sure there's a stable way to import sheets.

Or point me towards a document on the v56 format and I'll cover it myself as a little personal challenge

Edit: nvm I forgot about ScummVM's wiki.

[troflip]

I was more wondering about workflow and how the source information is stored. I agree for now, a separate tool is best (I have my hands full with just getting SCI Companion into a polished build).

Like how do you control the layering? Does each piece (hair/paints/shirt) have a layer (or does the layering need to be per pixel?), or does it just depend on you stack them? How do you change the color of things? Are there just presets, or can we do something smart with changing hues, etc...

SCI Companion can import gifs and or a sequence of image files, but only 1 loop at a time. Hotspot information is lost when you use a bunch of files. It's mostly retained using gifs (relative frame positioning is retained - export from SV.exe and import into SCI Companion to see), but the absolute hotspot information can be lost depending how the gif is set up.

The best way to get the SCI 1.1 view specs is to look at the ScummVM or SCI Companion source code (https://github.com/icefallgames/SCICompanion/blob/master/SCICompanionLib/Src/Resources/View.cpp).

[Kawa]

Haha sniped me Separate tool it is!

Layering
I'd probably have two layers per item, one in front and one in back. Thus long hair might have the bangs in the front layer for all but the (diagonal) back directions, where it's in the back layer instead, and the rest of the hair in the back layer, but in the front for the back directions if that makes sense.
Then, I might do a thing where, assuming the character is on layer 0, you can change the z-index of each part, where that part's back layer is automatically the inverse. So you might have a character with a jacket, shirt, and pants, and the shirt and pants overlap a bit:

3 Jacket
2 Shirt
1 Pants
0 Ego
-1 Pants
-2 Shirt
-3 Jacket

Then you shift the order for the pants to tuck in the shirt, and that'd set the pants to 2 and shirt to 1, and their back layers to -2 and -1 respectively, leaving the jacket on top of it all:

3 Jacket
2 Pants
1 Shirt
0 Ego
-1 Shirt
-2 Pants
-3 Jacket

bro where are your shoes

Colors
Each layer I would allow an arbitrary color remap. Imagine if you will the classic SCI palette, and look at the pics of Template and me that I posted. Boils down to remapping the pants layer as [ 2: 48, 3: 49, 4: 50 ] doesn't it?

Hotspots
This is why I wanted the v56 format spec. Instead of importing it all loop-by-loop or worse and redefining all the lost data, you'd just import a v56 file that my tool produces. I'll worry about the project file format myself

[troflip]

Colors
Each layer I would allow an arbitrary color remap. Imagine if you will the classic SCI palette, and look at the pics of Template and me that I posted. Boils down to remapping the pants layer as [ 2: 48, 3: 49, 4: 50 ] doesn't it?

Yeah, I think so. I was thinking you'd also want to lighten/darken stuff to, but you can achieve that by shifting things within a "color zone" in the palette, as long as the original isn't using the full range.

Hotspots
This is why I wanted the v56 format spec. Instead of importing it all loop-by-loop or worse and redefining all the lost data, you'd just import a v56 file that my tool produces. I'll worry about the project file format myself

Beware, it's pretty complicated. Mostly because of two things:
- there are a lot of offset and size fields within the format that need to point just at the right place, and many of them are redundant (but still need to be in sync with each other). This is somewhat simplified if you don't embed a palette.
- the cel image data uses a form of run length encoding. Although one of the "commands" in the encoding is "use the next 127 colors literally", so that would actually simplify things a bit if you just output it like that.

[Kawa]

Still a bit too much snap on the arm, maybe, but here's a tweak with proper hotspots:

[Cloudee1]

Uh oh. I just imported your gif... The transparency didn't follow through with the embedded palette import. Not that it matters right now, just thought I would give a heads up.

[Kawa]

Here we are now, with what's hopefully the final version of this particular loop. And if it really is, I'll move on to the front and back views.


And here's a little demonstration of versatility that may or may not have something to do with my main SCI11 project, The Dating Pool:

Template ego included for comparison.

[Kawa]

Turns out it was not the final version, as the dip went too deep. So here's what hopefully really really is the final version, and a first pass on front:

[Kawa]

Meanwhile, at the halfway point...

[MusicallyInspired]

I'd suggest not moving his head side to side like that for north/south animations. A little head bob up and down should suffice. Just my humble opinion.

[Kawa]

Yeah, I know. It's just that his head's width is divisible by two but the rest of his body isn't. So every time his legs switch...

[MusicallyInspired]

Ahh. #90sgraphicsproblems