drawPlusMask artifacts, frequent bricking after upload

Development
#1

I’m having a strange issue with artifacts being displayed on the screen while using drawPlusMask(). If I call a “void noop() {}” function after the call to drawPlusMask() the artifacts are not displayed.

So I’m thinking this might be an Arduboy assembly drawing routine bug. Would appreciate if someone could take a look.

My current sketch is here: https://github.com/alivesay/starfire

If you uncomment https://github.com/alivesay/starfire/blob/master/starfire-game/sprite.h#L50 you’ll notice the artifacts no longer display!

Another issue I’m having with this sketch is that frequently the sketch will brick the Arduboy after upload, requiring me to reupload in flashlight mode. Related? I have no idea. :confused:

Thanks!

1 Like
#2

have you tried “void loop”? and try putting it in the loop.

#3

I didn’t see anyt artifacts here. But I’m also using a different version of arduboy2 lib. Could you compile both versions and share the hex and .elf files?

#4

Here’s the hex: https://raw.githubusercontent.com/alivesay/starfire/master/starfire-game/starfire-game.ino.leonardo.hex

Not sure how to generate a .elf with the Arduino IDE.

Cody17, I’ll try putting the draw call straight into loop and see if that makes a difference.

Another interesting thing is that the noop() has to be a function from the base class. If I use a global noop() function instead the artifacts remain… so something with register issues? Or function stack?

#5

Thanks.

Is that hex file with or without artifacts? I don’t see artifacts yet or do I have to look at a specific area? there’s lots of stars flying around :smile:

Go to preferences in Arduino IDE and at the show verbose output during option make sure there is a check at compilation

Now when you compile at the bottom of the screen there will be lots of output. somewhere in there is the temporary location of the build where you can find the starfire-game.ino.elf copy the path and open the location to find the elf file

1 Like
#6

Thanks. Here’s the elf: https://raw.githubusercontent.com/alivesay/starfire/master/starfire-game/starfire-game.ino.elf

Are you even seeing the little ship sprite? The artifacts appear under the ship, and the data displayed changes as you move the ship around the screen. At one spot you can even see the ship being redrawn in the wrong location.

If you’re not seeing the artifacts, it makes me think something is wrong my Arduboy hardware… yet I’ve been able to run six other community games without any issues…

1 Like
#7

And, yes. That .hex is WITH artifacts.

#8

The advanced drawing features use memory registers directly. @MLXXXp or @Dreamer3 is this related to the glitches we saw before with this function?

The issue with it bricking is certainly related we’ve seen it happen elsewhere and it’s related to the use of ram which is overriding the “magic number” that is a bit flipped in ram that lets the bootloader know it’s been activated.

This is some what of a mysterious bug that’s effecting “advanced” users that seems to involve when you hit around 70% ram usage.

1 Like
#9

I’ve uploaded it to my official Arduboy now too and still see no artifacts.

What I see is a little ship with an little afterburner in a flashing circle. when I move it zig zagging around all looks smootly. sometimes I see a pixel or two moving along inside the circle. but those are starfield pixels to me as when I stop moving the ship the pixel moves along to the left as starfield pixels do.

Is you’re Arduboy fully charged or powered by USB power? I can imagine Arduboy may start behave oodly when the battery is (almost) fully drained

#10

@Mr.Blinky Yes fully charged and powered by USB.

@bateske Would this issue manifest differently on different Arduboys? @Mr.Blinky isn’t seeing the artifacts using the same .hex on his device.

#11

I just realize my Arduboy is a bit different though as it uses my custom bootloader which clears more ram (for the display buffer) then the stock bootloader. I wonder if that is related. Has anybody else tried it and seen the artifacts?

@Kevin I saw the Assembly code with the workarounds and decided not to touch it in the moment. is there any info about those glitches?

#12

Here’s the thread that sparked the rewrite of the assembly code for drawPlusMask.

There’s a fair bit of info towards the end as well as a bit about the failed attempts and their behaviours.

@alivesay What version of the Arduboy2 library are you using?

And what do the artefacts look like?

2 Likes
#13

Could this have anything to do with the lock bits being set incorrectly on production Arduboys and that @Mr.Blinky reflashed a bootloader with the bits locked correctly?

1 Like
#14

No, Lock bits don’t have an influence.

#15

@Pharap I’m using Arduboy2 4.1.0. Have also tried with 4.0.2 and 4.0.1. Here’s what the artifacts look like (under the ship):

1119171319
1119171319.jpg1654×2941 1.63 MB

2 Likes
#16

Is the right of the screen meant to look like that or is it an artifact too?

#17

The rest of the screen is fine. The trails/ghosting are just from the photo.

1 Like
#18

So is it the large blob of white beneath the ship?

#19

Correct. The artifacts only appear in the “dead space” of the bitmap (height is 16).

If I move the ship (changing the x/y values of drawPlusMask(x,y)) the artifacts change.

It mostly appears random but at some locations the artifacts are actually a mirror of the ship sprite itself.

1 Like
#20

Have you checked the defined size of the sprites in the Progmem section

Did you use a png converter?