Extracting sprites from bitmap data?

[CoolieCoolster]

As a means of learning one or two things about Python, I've begun to try implementing my calculator idea, hopefully one I can manage after a bit of trial and error despite my lacking Python abilities. As using the default font wouldn't allow me to fit nearly enough characters on screen at once, I added bitmaps for each of the 25 or so three pixel wide characters that could be used in an operation. While I considered just drawing all of these to the screen in addition to avoid having to take up extra space with a fullscreen bitmap, I realized that the text needed to add all the characters to the screen would eliminate any saved space. Therefore, I was wondering if there were a way to instead define sprites based on their coordinates in the 72x40 bitmap image, as it doesn't seem that coordinate data is directly included in the bitmap data, other than the fact that each column has its own entry for up to eight rows. If it's possible, I imagine not having the character set icons defined twice might save some space.

Attached is my latest "version" of NanoCalc, with nearly all graphics I intend to use included. Next I intend to try to figure out how to add in logic so that it knows which box is currently selected and flicker the white rectangle of that box, so if anyone has suggestions for that, that would also be appreciated!

[Jason]

The sprite arrays only define the pixels of the sprite, not any positional data.

The Thumby blit function allows you to draw sprites anywhere on the screen:

Code: [Select]

thumby.display.blit(bitmapData, x, y, width, height, key) where x and y are relative to the top-left of the screen at 0,0 (left to right is +x and top to bottom is +y) but I think you already know that.

One way to do this in a compact way is to make a function that takes a string and position and then draws/blits each character in the string to the screen based on the position. Each character's width would have to be accounted for too, unless it is monospaced and each character is the same width in which case you draw each character at the same offset from the last. We've done some testing and found that this is slow, now we're looking into building a smaller font into the firmware.