"Hi there! I am a total amateur and don't know anything about coding but have been trying to learn blocky. I can't figure out why my sprite animation sheets are getting sliced incorrectly? Can some one shed some light? Here is the simplest example;"
The BitmapBuilder doesn't inherently have any support or understanding for Sprite frames for animations. The IMPORT SPRITE button seems to, but this isn't supported in Blockly as it is quite advanced. Perhaps supporting this in Blockly is a better approach than this proposed change, but it would still be nice to have animated sprites editable within the Code Editor itself.
There are two ways to make animated frames inside BitmapBuilder, one is stacking the frames horizontally, and one is stacking the frames vertically. The horizontal stacking approach works very well for MicroPython and Blockly only if the height is no greater than 8 pixels, otherwise the frames a spliced due to the way the the bytearrays are interpreted by the Sprite class inside the Thumby API.
The vertical stacking approach works very well for MicroPython if you manipulate the height of the Sprite to be the height of the frame rather than the height of the bitmap. This does not work for Blockly as the height of the Sprite is taken directly from the bitmap, providing no entry point for manipulation.
To be clear, this behaviour is consistent with the MicroPython interface, there is just a better workaround in MicroPython by manipulating the height value and stacking vertically. This proposed change should be considered in context of perhaps just allowing the height of Sprites to be manipulated in Blockly mode, but this would still require the user to be aware of the between-frame padding required when the frame height is not a multiple of 8.
This change proposal introduces an "awareness" of frames inside the Bitmap Builder. The SIZE button would now also ask the user for the number of frames (defaulting at 1):
If the user leaves this at the default of "1" frames, all current behaviour stays the same. Bitmap Builder exports to code won't specify anything to do with "frames" and the Bitmap Builder itself will look exactly the same as it usually does.
If, however, the user specifies a number of frames, a new set of functionality is activated:
The Bitmap Builder will arrange itself into vertically stacked frames. This is still internally one big bitmap. The internal frames are offset to the next starting byte (8th bit), the unused bits between frames are hidden, and a gap is shown between frames.
The Bitmap Builder title will get a suffix showing the number of frames "@xxx" e.g: "Bitmap Builder: 8 x 12 @2"
Blockly Sprite Exports (and subsequent Imports) from a Bitmap Builder in multi-frames mode will work elegantly when loaded onto a "load Sprite with frames" block, and fall back to the standard behaviour when loaded onto a "load Sprite" block.
MicroPython Exports (and subsequent Imports) from a Bitmap Builder in multi-frames mode will show "frames: " in the "BITMAP" comment line, leaving the "height" value being the height of the frame, rather than the height of the bitmap:
Here is an example of what everything looks like when multi-frames mode is activated:
The Grayscale Bitmap Builder does not get full support for multi-frames mode, since it isn't integrated with Blockly mode yet, but it gets support for "Import" from a multi-frames mode text or block. When that happens, it arranges the frames in a similar vertically stacked pattern, but just reverts to a single stacked bitmap without hiding any between-frame pixels. The user would need to manipulate the height in MicroPython after this process. The rationale behind this that if you are already on the learning curve where you are using Grayscale and MicroPython, it is a good time to understand how frames are stacked within bitmaps.
Here is what the Grayscale Bitmap Builder looks like after importing a multi-frames mode bitmap:
fuglaro
commented
1 year ago
These changes were pursued after the following question in the Discord chat: https://discord.com/channels/898292107289190461/898292174410612787/1137119035113361488
The BitmapBuilder doesn't inherently have any support or understanding for Sprite frames for animations. The IMPORT SPRITE button seems to, but this isn't supported in Blockly as it is quite advanced. Perhaps supporting this in Blockly is a better approach than this proposed change, but it would still be nice to have animated sprites editable within the Code Editor itself.
There are two ways to make animated frames inside BitmapBuilder, one is stacking the frames horizontally, and one is stacking the frames vertically. The horizontal stacking approach works very well for MicroPython and Blockly only if the height is no greater than 8 pixels, otherwise the frames a spliced due to the way the the bytearrays are interpreted by the Sprite class inside the Thumby API.
The vertical stacking approach works very well for MicroPython if you manipulate the height of the Sprite to be the height of the frame rather than the height of the bitmap. This does not work for Blockly as the height of the Sprite is taken directly from the bitmap, providing no entry point for manipulation.
To be clear, this behaviour is consistent with the MicroPython interface, there is just a better workaround in MicroPython by manipulating the height value and stacking vertically. This proposed change should be considered in context of perhaps just allowing the height of Sprites to be manipulated in Blockly mode, but this would still require the user to be aware of the between-frame padding required when the frame height is not a multiple of 8.
This change proposal introduces an "awareness" of frames inside the Bitmap Builder. The SIZE button would now also ask the user for the number of frames (defaulting at 1):
If the user leaves this at the default of "1" frames, all current behaviour stays the same. Bitmap Builder exports to code won't specify anything to do with "frames" and the Bitmap Builder itself will look exactly the same as it usually does.
If, however, the user specifies a number of frames, a new set of functionality is activated:
Here is an example of what everything looks like when multi-frames mode is activated:
The Grayscale Bitmap Builder does not get full support for multi-frames mode, since it isn't integrated with Blockly mode yet, but it gets support for "Import" from a multi-frames mode text or block. When that happens, it arranges the frames in a similar vertically stacked pattern, but just reverts to a single stacked bitmap without hiding any between-frame pixels. The user would need to manipulate the height in MicroPython after this process. The rationale behind this that if you are already on the learning curve where you are using Grayscale and MicroPython, it is a good time to understand how frames are stacked within bitmaps.
Here is what the Grayscale Bitmap Builder looks like after importing a multi-frames mode bitmap: