Milona Games/Milona Software: "Project Scarlet" development

OK I can see from the 16, 16 at the start that the output is compatible with the Sprites library. However as the actual data below each 16x16 images is only 64 bytes, there is no mask information embedded in the array.

I do not believe any of the online tools generate image data for the Sprites::drawPlusMask() method. When I have used this function, I have created the data by hand - mixing the image and mask data one byte after another.

Can you change you code to use Sprites::drawOverwrite() or Sprites::drawSelfMasked() instead of Sprites::drawPlusMask().

Ypu can read about sprites and masks in the Arduboy Magazine, Volume 7, page 33.

Hang on, ((16 * 16) / 8) = 32, so surely 64 bytes does imply that the mask data is also there?

That and at least one of the sprites draws correctly using drawPlusMask (I haven’t tested the others):

Example.hex (21.3 KB)

I think there were some. I think Team ARG’s will be dead now though.

Holy crap, you are right! Something in my little brain was saying there is no mask here!

I am pretty sure the TeamARG version did not do it. Or if so, I am not sure how.

Excuse the double post but I was skimming through the code and noticed…

It probably isn’t causing the drawing issue, but = is the assignment operator, not the equality comparison operator.

That means instead of testing if direction is equal to 0 or 1, you’re actually assigning them, so the cases where direction = 0 is present will never actually be triggered.

To test for equality you need to use == instead.
E.g. if((direction == 0) && (ground >= 1))

I made the sprites before Team ARG’s supposed demise.

Oh its real.

Oh, yeah. The ATM tracker is down.

Quote myself here … have you tried this?

I think they had more than one converter, one did normal Sprites conversion and one did sprites plus mask conversion.
(But my memory isn’t the best, so I might have imagined it.)

Retirement rather than demise, though it’s very much reality.
Even their website is gone now. What remains is forks and copies of their code.

Back on topic, I’m beginning to lean towards “the drawPlusMask bug is back”.

But I can’t really confirm that without code that’s actually in a compileable state and can thus be probed…

Yes … for someone who wanted to collaborate at the start of the thread, he is being very secretive with the whole code.

Sorry about that…
Which other part do you need?
Here’s the GitHub I just made of it:

Does that code even compile? It doesn’t for me.

Isn’t there an option to download those files? You can remove the README file for that.

Adding #include "box.h" to player.h fixes the missing declarations.

But when I compile there’s no sign of the sprite rendering bug…

Oh. I commented the animation commands in the file I uploaded…

Your images render fine …

ArduboyCapture (1)

The whole thing works when you change …

    if(!arduboy.pressed(LEFT_BUTTON) || !arduboy.pressed(RIGHT_BUTTON))
      walkframe = -1;


    if(!arduboy.pressed(LEFT_BUTTON) && !arduboy.pressed(RIGHT_BUTTON))
      walkframe = -1;

Okay, that solves the frame part and the mirroring part, but that doesn’t fix the bottom half.
Except that it’s clear the images are not corrupted.


I am not sure what you mean as it appears to work fine.

This will be a lot easier of you simply tells us what you think is wrong with the code, what you have done to test it and publish working, compileable code.

This is getting weird. In your GIF the sprite looks like it’s working great but with the mirrored version rendered behind it.
Would you mind explaining what the “b” is about?

Ignore the b. It’s an artefact if my debugging.