jorio
Missing support within Op.CompressedQuickTime
I was able to extract many additional image formats due to: https://github.com/jorio/rsrcdump/pull/9 However, there is still some missing formats.
I've attached the graphics files. The .rscs is an AppleDouble resource fork. I've included the files output from rsrcdump (updated with the above merge request).
1144 pict is corrupted.
1239 pict is corrupted.
4000 to 4004 show up as blank.
9850 and 9851 are corrupted (but show up almost correctly).
The linked MR did fix 30 of the images in the above zip file. Examples:
There's only a few that seem corrupted or not being parseable.
On a side note, thank you @jorio ! Rsrcdump and Pomme have been amazing to use. Saving a ton of time on reviving this old game.
Hi @MatthewFrench! That's a great addition to rsrcdump; thank you for the PR!
About PICT 1144: You're decoding the JPEG payload correctly. Here's what it looks like if we dump the payload of CompressedQuickTime straight to a JPEG file:
However, in that resource, CompressedQuickTime is followed by a PackBitsRect opcode for a 69x44 B&W image.
rsrcdump's current behavior is to try to superimpose the B&W image from PackBitsRect on top of the JPEG that was previously blitted to the 39x39 canvas, so that's why it looks corrupt.
Since ResEdit displays this PICT properly, rsrcdump is probably doing the wrong thing here. We should investigate...
And this is what PackBitsRect contains in PICT 1144. Fascinating! I'm guessing this is a fallback image that's supposed to show up if QuickTime wasn't installed?
Nice find!
I saw that image and didn't realize it was coming from the resource itself. That makes sense, I saw that all the time in old mac OSes.
I suppose one fix could be to not use PackBitsRect if CompressedQuickTime contains a parseable image. Another option could be to check specifically for that image in PackBitsRect and not draw it if it is there.
I suppose one fix could be to not use PackBitsRect if CompressedQuickTime contains a parseable image.
Indeed that's probably what QuickTime did according to Technical Note QD 535:
Is it my imagination, or does GetPictInfo return a bit depth of 1 on QuickTime compressed PICT files?
Yep! This is what's happening: The Picture Utilities Package doesn't know of the QuickTime Compressed Pixmap opcode (0x8200), so it just skips over the opcode's data; then it finds the PacksBitRect opcode containing the black-and-white pseudo-alert that you get when you draw the picture on a machine that doesn't have QuickTime installed, and GetPictInfo reports back this alert.
Trivia: When QuickTime is installed, it displays the compressed image and then ignores the following PacksBitRect since QuickTime knows it's only the black-and-white alert.
Technical note from 1993, impressive and thank you!
I'll do a follow MR with that change. Hopefully that resolves the remaining graphics.
On a side note, we've implemented these changes in Pomme for game rendering consistency as well (among other changes like adding SDL_TTF for same-as-old-mac text rendering with fonts). This is very tangential, would you be interested in a Pomme MR of what we've been adding support for? It may not be entirely up to standard with the Pomme design and it may be a while before we put it into a merge acceptable state (matching the standards of the Pomme codebase). We've also been working on lately is adding cross-platform multi-window and menu support. We're trying to get this old Mac game running as-is as possible without changing base code. We're getting really close! I'm so appreciative of all the work you have done and shared.