-
Notifications
You must be signed in to change notification settings - Fork 3
Pictograph_Box
The picture frame buffer storage for Link's current Pictograph Box capture does not have any known attachments to the debug ROM at this time, but it does serve as an interesting thing to modify.
-
zs $filepath -+-- Exports current Pictograph Box snapshot topicture.bmp. -
zs $filepath -+ (const char *)-- Interprets the extra string parameter as a file path to a Microsoft Bitmap image file and, if certain conditions are satisfied, packs the contents of said file's pixel array into the relevant bits of the Pictograph Box frame buffer.
There are no special requirements to exporting the existing Pictograph Box frame buffer to the built-in file path ./picture.bmp, apart from having enough writable disk space for exactly a 53786-byte bitmap file (which should be compatible with any old application supporting any version of the BMP specifications). This can even be done from a game file which has no owl state data or was saved by the Song of Time, but the resulting BMP will probably be a black screen in that case.
There are, however, several rules to replace the buffer in flash RAM with a custom picture:
- The specified source path must point to a readable file in Microsoft's Bitmap image format. It can have any extension (
.bmp,.dib,.blahrandom, etc.), but it must conform to BITMAPCOREHEADER specifications. - The bitmap file must be 24 bits per pixel, 8 bits per channel. Either RGB or BGR is fine, since all channels must converge regardless into an averaged 5-bit-per-pixel gray-scale image.
- The bitmap file's header must store an offset less than 256 bytes to the first pixel.
- The bitmap image should be exactly 160 pixels wide, to meet game requirements. This rule can be ignored, but no attempts will be made by the program to downscale, upscale, or jump over calculated pixel rows in the bitmap's format.
- Any height is probably fine, but the target is 112 scan-lines. If the source image is more than that, only the top 112 scan-lines will get prebuffered to the C application for encoding, anyway. A source image that is smaller than 160x112 pixels may raise some internal FILE stream error to the C library, but the program should probably still function without complaint, with the bottom remainder of the 112 scan-lines filled to black.
file[0x10E0:0x3C9F]
Who cares?