SCUMM: LOOM (EGA): font drop shadow changes over animation & unique drop shadows in certain scenes are not implemented

[ATMcashpoint]

In the EGA version of LOOM on the original interpreter, when text appears above the black part of the screen, many scenes have uniquely coded drop shadows around the fonts, none of which are implemented in ScummVM.

Sometimes this takes the form of a reversed shadow, which generally has two pixels, one up and one left, where the regular drop shadow has three (down, right, and diagonally down-right).

Whether the reverse drop shadows are present can depend on which screen the game is currently on, which puzzles have been solved, what character is speaking, and even what direction the player entered the screen from.

However, it also seems that overall, costume animations playing below text cause the individual pixels of any text right around them to change their drop shadows.

Generally, in such instances, regular three-pixel drop shadows switch to having only one pixel (diagonally down-right), while the reverse drop shadows with two pixels (up & left) now have the lowest vertical pixel of leftward shadows omitted, or the only leftward pixel omitted if there's just one.

It's also possible for drop shadows to be redrawn when a room object under them is redrawn, though I've only found one screen that does that, and it's a special case.

Here's a list of rooms with notable issues. This list may not be exhaustive.

Loom Chamber (room 9): has reverse shadows, but only after Hetchel hatches from the egg. Note that the reverse shadows don't appear if you skip the cutscene of Hetchel emerging from the egg before it first cuts to her close-up.

Waterspout (room 13): This room is an extremely special case. Only a few lines of dialogue are affected here, and only a couple of pixels in some words are changed.

When Bobbin says "Don't want to get any closer" there's a shadow pixel missing below the start of the D in "Don't", and one missing below the start of the T in "to". When the lightning flashes on the right of the waterspout (a room object rather than a costume), two other pixels disappear from the word "get", one from below the left side of the descender in the G and one from the top of the T.

If Bobbin says "That thread is too high for me! Guess I need more experience." there's a shadow pixel missing below the start of the G in "Guess".

When Bobbin says "Whew! Listen to that twisty wind!", when the lightning flashes on the right of the waterspout, a pixel disappears from the lower right end of the T in "that", as does one at the lower left end of the T in "twisty". These missing pixels are slightly higher than the ones in the other lines.

Crystalgard Graveyard (room 17): has reverse shadows if you come in from east or west exits. If you come in from the north exit, reverse shadows are normally absent. If the cutscene with Bobbin meeting Master Goodmold for the first time plays after coming in via the north, then reverse shadows are added after the cutscene, but go away if Bobbin leaves and re-enters from the north again. (They don't appear if the cutscene is skipped before cutting to Goodmold's close-up.)

Forest (room 23): has reverse shadows for the Shepherds' dialogue, but not for Bobbin's dialogue

Pasture (room 24): has reverse shadows for the Shepherd's dialogue, and sometimes for Bobbin's dialogue depending on where he is on screen and where he entered from. If Bobbin entered from the forest on the right, then he'll have reverse shadows only while standing to the right of the fence; if Bobbin entered from Fleece's hut, he'll have reverse shadows only while standing to the left of the fence.

Forge Sword Room (room 41): lines spoken by Mandible, the Foreman, and Edgewise have reverse shadows, but not Bobbin

Crystalgard Shattered Graveyard (room 49): regular shadows until Goodmold dies, then adds reverse shadows. The reverse shadows don't appear if you skip the cutscene of Goodmold's death before it cuts away to the Great Scythe. Also, they go away if you leave and re-enter after his death.

Loom Chamber, torn open (room 51): regular shadows except for Chaos' dialogue as Bobbin exits, which has reverse shadows

I've included a ZIP file of screenshots that illustrate this behavior in the original interpreter.

[AndywinXp]

Athrxx implemented the various missing shadow modes a while ago. The various glitches happening on the text shadows on the original (which we don't replicate) are probably happening because v3 draws costumes on the screen without checking for text clipping (which is something which began from MI1 EGA onwards). It seems we do things differently enough that we don't have any of these glitches but we can't replicate it either without rewriting a chunk of the costume drawing routines, which seems a bit overkill...

If you confirm that the main issue is solved, we can close this. Thanks for your ticket!

[ATMcashpoint]

I can confirm that the issues with reverse shadows in most rooms seem to have been fixed (aside from the unique issues in Room 15 in the original, which still mystify me).

I would strongly urge, however, that the transformation of the drop shadows (both regular and reversed versions) over animations be implemented if at all possible.

The way the original game manages that transformation is consistent enough that it seems intentional: the three-pixel regular drop shadow gives way to a one-pixel diagonal drop shadow, and the two-pixel reverse shadows have their leftward projections lose the lowest vertical pixel in each column. It's as if the fabric of the game text were wearing through and revealing another layer of cloth underneath. ;)

In fact, the various drop shadow designs also have a probable connection to the game characters. The regular three-pixel drop shadow fits well with the somewhat androgynous hooded figure of Bobbin, since weaving is after all a traditionally feminine profession. And the regular drop shadow contains both the alternate one-pixel drop shadow, which is "masculine" and could fit with Rusty (and is perhaps most visible in-game in the dragon's volcano lair), as well as the two-pixel reverse shadow, which is "feminine" and would fit Fleece if turned right-side-up (and is used prominently in the Shepherds' scenes).

Plus, the alternate reverse shadow, which drops the lowest pixels on its left edges, would lose its highest pixels on the right edges instead if turned right-side-up: perhaps suggesting the Glassmakers, and their motto "above all else, clarity". I do wonder if Moriarty was setting up symbolism for the sequels with the font shadow designs, since judging from pre-release screenshots he seems to have settled on the final versions quite late in production.

[AndywinXp]

Thanks for the response.

I understand the excitement behind these theories but please believe me: those glitches are not intentional, they are involuntary oversights; I read the assembly code, they literally forgot to take into consideration the clipping plane of text shadow when drawing the actor costumes and animations, so the animations overwrite the font shadows, wherever they are.

I know it's not poetic at all (and symbolism would have been neat), but this was the first time that they were continuously drawing text to the main screen from the first time (Indy3 only did this when there were no actors around) so they were not prepared with a properly working solution for sprites/subtitles overlapping, hence the glitches.

And as I said, our cel painting system is modeled in a different way in order to support all the various SPUTM versions, so it's a great deal of work to implement such an involuntary quirk (between disassembling, crossreferencing code, etc.) that it's probably not worth it, unless someone comes along and helps us with it. This would basically be a rewrite of the painting system. :-) and it's not worth it when we are drawing things accurately but without glitches...

Thanks for understanding, and thanks for this ticket which allowed us to assist with drop shadows! Closing...

[ATMcashpoint]

So why do the "decayed" designs have their own internal consistency, rather than just being garbage or having the drop shadows disappear wherever animation plays beneath them?

[ATMcashpoint]

BTW, one reason I wouldn't put this past Moriarty at all is that the drop shadows were even more complicated in pre-release versions. Early screenshots show text with three-pixel drop shadows, but also an *anti-shadow* on the left side: that is, for each pixel of text, the pixel immediately to its left could NOT have a drop shadow, regardless of what other characters with drop shadows preceded it.

[AndywinXp]

I wouldn't really know what to tell you. As I said it's a matter of code design differences between what's in loom and what's in everything else following it up. I'll go into details so I can explain myself better:

• When text is drawn, the exact coordinates at which each of their pixels is drawn needs to be saved in a buffer -> the text z-plane
• Whenever the screen is drawn (and the actors with it) all the z-planes available in the scene are taken into consideration so that they will stay on top of the screen and not get overdrawn on top by something else
• As I said, the text z-plane has to be calculated for each pixel of the subtitle line, and while later version of SPUTM do this correctly, in the early days they did not take into account font shadows (they just "protected" the core part of the font characters)
• This means that anything that will be drawn on top of the text (actors, and animations) will avoid drawing any single pixels on anything that is protected by the z-plane... but the font shadows are not protected by it. :-)

Sometimes mistakes are just that: mistakes. No symbolism and no secret intentions. Just mistakes.

If you happen to talk with Aric Wilmunder about this, he might be able to shed some light on this. But until this happens this thing, looking at the code (so no strange guessing) seems like a mistake.

[ATMcashpoint]

But from the behavior in-game in the original interpreter, aspects of the drop shadow z-plane are indeed also protected, in such a way as to produce genuinely different shadow designs. It isn't just losing every single pixel of the drop shadows where animation plays under them, as would follow from the way you describe it.

This behavior does seem intentional, and is significant enough that it really should be emulated.

[AndywinXp]

Look, and I mean this in the best way possible, so without being rude or anything: I'm not rewriting the entire painting/text clipping system just to support a glitch. It takes time, lots of time which I could employ fixing other stuff.

Let's have a laugh though: contact Aric and let him assess if this was intentional or not :-) If this was really intentional, I'll bite the bullet and try implementing the thing ;-)

[ATMcashpoint]

I seriously doubt Aric Wilmunder remembers such an obscure detail after all this time.

I am extremely disappointed in the refusal to support documented original behavior. If you look at the screenshots of the dragon's lair in the ZIP I posted, you can clearly see the alternate drop shadows at work, where your analysis of a "glitch" would say they should disappear entirely. Quite frankly, with such a response, I find it difficult to see the point of submitting bug tickets.

[AndywinXp]

Look, let's not bring bad blood into this. It's really not needed.

I think your bug reports are very useful (and as a matter of fact I did employ my time as a voluntary developer to respond and act upon them, didn't I?). I would have let this discussion go a long time ago if I didn't care.

I have seen the images on the zip, multiple times.

I just want you to realize that:

• I have taken the time (half my morning to be exact) to look at the assembly code, the actual code that the game is executing to make this work
• I have taken time to crossreference why this effect that you talk about is not happening in other games (the other half of my morning, crossreferencing LucasArts and Humongous Entertainment games)
• I have assessed that, given our actual code structure we can't implement this unless someone rewrites how text is drawn on the screen and how it interacts with every single graphic entity in the screen. We just can't! We draw the text by blitting it on a secondary surface (the text surface) which we superimpose on the rest of the screen at the end of the frame generation phase. That's a completely different approach!

This is because I care about every single ticket we get here 😅 and when I say it's unfeasible it's not some kind of tantrum, it's because I believe it really is unfeasible unless we rewrite everything I said above.

And every piece of the system I mentioned above is not rewritable by me, just like everyone I have a job, I have other hobbies, a life outside the web, and I can't spend the entire day working on something which gives so little benefits. I'm sure you understand that, you're certainly not stupid and you understand the value of both of our time.

And just don't want to be told that this is reluctancy to "support documented original behavior", when I spent quite a lot of time just to assess that it currently can't be done. And neither I want to hear "with such a response", when I'm spending so much time trying to inform you about my findings and let you know why such a thing can't be done. And the only response I'm getting after each of these responses is "look at the images". I looked at the images :-)

I hope that you can continue submitting issues without rancor, have a nice day :-)