Images

It's out now ;)

The legacy drawBitmap function supported flipping and rotating. Is this also supported by drawImage, e.g. by specifying negative values for new width and/or height? If not, what is the recommended way to flip sprites? Use drawBitmap anyway, create flipped images at compile-time, create flipped images at run-time? Or will you also provide drawImage functions to support rotating and flipping?

P.S. I have yet to receive my Gamebuino so at the moment I am just reading up on the API in eager anticipation

Negative width / height on the re-scaling is the way to flip currently

Okay, thanks! Good to know that flipping is still supported. It would be good to update the image tutorial and/or drawImage API reference to document this.

What is the recommended way to draw images based on the same sprite that only vary in color? For example, the squares in the example Color Palette image. It's basically the same sprite, repeated 21 times with only color differences.

Some possible options:

1. Use functionality (yet to be?) provided by the Gamebuino library that supports this. I assume this is not there yet, as I could not find any documentation.

2. At run-time create multiple Image objects from the same Image Data array via a custom function that creates a new Image Data array based on an provided one, given a certain color remapping. This requires one (long-lived, static) Image Data array and multiple Image objects (one per color variation)

3. At compile-time provide a Image Data arrays for each color variation of the same sprite. (Or very similar, provide one large Image Data array that defines sprites with all color variations). Compared to Option 2, the size of the long-lived Image Data array(s) is X times as large, where X is the number of color variations.

My preference would be Option 1. It requires the least memory, and is also the easiest to maintain (source code and assets are the smallest, modifying sprites is the least effort). It assumes that the overhead of runtime color remapping while drawing images is negligible. This should be possible, for example by introducing a ColorMap class. This can be used to conveniently specify the remappings, yet use an internal presentation that is optimized for speed. Example of how this would work:

Image myImage; // Initialized elsewhere, using "hot" colors

// Maps "hot" colors to "cold" colors
ColorMap coolMap;
coolMap.map(RED, LIGHTBLUE);
coolMap.map(MAGENTA, BLUE);
coolMap.map(PURPLE, DARKBLUE);

if (isHot) {
  myImage.setColorMap(); // Reset to default
} else {
  myImage.setColorMap(coolMap);
}
gb.display.drawImage(0, 0, myImage); // Draws image using active color map

If Option 1 is not available, I will probably use Option 2. That could then look something like:

const uint8_t hotImageData[] = { .... };
Image hotImage = Image(hotImageData);

// Maps "hot" colors to "cold" colors
ColorMap coolMap;
coolMap.map(RED, LIGHTBLUE);
coolMap.map(MAGENTA, BLUE);
coolMap.map(PURPLE, DARKBLUE);

// Use custom function to create "cold" image from "hot" data
Image coldImage = createRecoloredImage(hotImageData, coolMap);

if (isHot) {
  gb.display.drawImage(0, 0, hotImage);
} else {
  gb.display.drawImage(0, 0, coldImage);
}

Any thoughts or recommendations?

You can used indexed color mode and dynamically change the palette before each draw function, the feature is already there :)

I'm not sure we have a function to set the indexed palette though, you'll have to access directly the Graphics' member.

Does that help ? ^^

Hi Aurélien. Thanks for your reply.

However, if I look at the Graphics API, I do not think it does what I am looking for. As far as I can see, Graphics supports setting a single color, which will be used by subsequent drawing operations.

What I am looking for is something like the following, a single "drawImage" invocation where I pass an image, but where the image is not drawn using its original colors but where one or more colors will be drawn using a different color. In my example, all RED pixels in the image should be drawn LIGHTBLUE, all MAGENTA pixels should be drawn BLUE, etc. Is that possible or not? If so, how exactly?

P.S. I received my Gamebuino in the mail today :-). Very much looking forward to the weekend, when I should have time to really start playing it.

When using drawImage and the source image you draw is an indexed image, and the destination image rgb565 (like the default gb.display), then you can switch before drawing the image the color palette to something else to achieve the result you are asking for. I am using that in my game Reuben Quest to create some fade effects, for reference, the source is here: https://github.com/Sorunome/reuben3-meta/blob/cbae251c07ddfce71f25997879658bf22a4e75f0/reuben3/misc.cpp#L613-L633

The important part is where i set gb.display.colorIndex to some other palette that i then modify before re-rendering, as in calling that (*r)()

Ah, thanks! That example code helped. This indeed enables me to do what I want.

Sorunome, i haven't well understood how to make a spritesheet from a bmp file.

Could you please make a little easy example of a little bmp with some sprites and how you declare and use them ? Sorry it's maybe easy for a curent dev but i'm not yet  ;)

I recommended to not use a BMP file as spritesheet, as that would be slow, and instead put the sprites in flash o.o

That being said, it's just an image with all sprites ontop of each other, stacked vertically

ok understood. I'll do it like that  ;)

Is the cropping feature broken? I can't get it to work properly in most cases.

From what I understand, cropping an rgb image of 80x64 via

gb.display.drawImage(0, 50, img, 0, 50, 80, 14);

Should put the bottom of the picture (from 0x50 to 80x64) on the bottom of the screen. But it doesn't. It shows 30 of the pixels (width), and 14 pixels (height). Trying different cropping options, some produce valid results

ie. gb.display.drawImage(0, 0, img, 0, 0, 80, 64);

prints the entire pictures,

but some I can't even figure out.

gb.display.drawImage(0, 0, image, 30, 0, 80, 64);

doesn't even crop the picture. It just wraps it around the screen and removes random pixels from the last line.

Am I just using it wrong?

(from 0x50 to 80x64)

nooo, it starts at 0x50 and is 80 pixels wide, 64 pixels high. So that is what your issue probably is, the last two parameters are crop width and crop height, NOT x/y coords

Yes, sorry, that is what I meant.

As you can see from my code, this is exactly how I use the function -- start at coordinates 0x50 and crop a picture 80 pixels wide, 16 pixels high:

gb.display.drawImage(0, 50, img, 0, 50, 80, 14);

The result should be a full width, 80x14 picture in the bottom left corner of the screen. This is not what I am seeing though. What I get is a picture of about 30x14 pixels in size. It starts from the left and then randomly cuts off. And I have no idea why it happens!

You can try this code with any 80x64 RGB picture (didn't try indexed). Tried a few, all with the same, unexpected result.