By using fill, you can definitely choose certain pixels of the 8x8 (or bigger) sprite to be fully transparent instead of opaque white or black. However, semi-transparency is not possible unless you fake it with some sort of flickering (also possible with the fill bug where it uses anti-aliasing).
All the code is inside the JSON file attached, but here is the code to draw the player at (px, py) in the player's draw event:
// draw player
fill "black" at px,py,8,8
x = px
x++
y = py
y++
fill "white" at x,y,6,6
x++
y++
fill "black" at x,y,4,4
y++
fill "white" at x,y,4,1
x++
y--
fill "white" at x,y,2,3
The four parameters after at represent the X position, Y position, width, and height, respectively, each one in terms of pixels instead of tiles.
You don't have to do anything special with the tiles behind the player; they're already drawn on their own. fill just draws over everything else in the game.
fill also doesn't really target anything—it really just draws a rectangle where you tell it to. It doesn't know or care what you're trying to draw. You could use it to draw a progress bar, or a box, or the player (as in this case).
It looks like redrawing the background tiles behind the player addresses a bug where the dirty rects behind the fill rect are not updated properly. This is what it looks like if you comment out those calls:
Yup, that will appear on the hardware as well since it’s a runtime bug. When you use fill to draw a rectangle, it (is supposed to anyway ) mark all the cells that you are drawing on top of as dirty so on the next frame they can be redrawn (this way we’re not redrawing the entire screen every frame). Because it’s not working as intended Yousurname is redrawing the dirtied tiles manually.
You can see the problem clearly here (the red overlays are tiles that were identified as dirtied on the previous frame):
And this is what it should look like:
I made the mistake of assuming that the width of the rect divided by the tileWidth was the number of dirty tiles but that can’t be assumed to be true when they are the same width.
Except even this is wrong, it’s too greedy. Even when perfectly aligned to a tile it still dirties the next column and row.
Here we go:
When the player is perfectly aligned with the tile grid (like when they’re against the left side of the screen) they only dirty a single tile as expected. We got there!
And that fix is now live. If you add n = name tx,ty to the collect_coin handler you can delete the calls to draw_tiles. (Note that you’ll need to download a new pdx in order to pick up the runtime fix for this.)