>>5157651
Yes. This was done in game.
I used an level editor to move the block over (and the goomba away.)
Then I drew the graphics, 4 tiles for both states. Since the brick uses only two tiles, I placed the "This Post" graphics over the pipe graphics, and the "Bump" tiles over the beetle ones (as the hit block is a sprite and the game uses 8x8px tiles, the sprites can only use the sprite half of the tiles.)
The available documentation had the tile makeup of the brick, so that was easy to change. But there is a routine that changes the tiles to make the block disappear when hit, spawns a sprite version of the brick block to do the bouncing part, then changes the tile back to the brick graphics after it's done. So even if you change the tiles, they just turn back to normal after you hit the block.
To fix this, I set a write breakpoint on the PPU memory for that tile (hovering over the tile in the Name Table Viewer tells me what address it lives at.) The break triggered in the middle of a generic write_these_tiles_here function, so I repeated the process. I looked at where it got the value it was trying to write, checked out that memory address, and set a breakpoint there. When that one triggered, I looked at where it was coming from. At this chunk of memory, I noticed a "45 47 45 47" which was the tiles of the brick block I was looking for. I changed it and it worked, the graphics changed to the new tiles after being hit.
For the sprite, I took decided to try searching for "85 86 85 86", the tiles for the sprite version of the brick block. Unfortunately there were no results found. However I tried changing the order, "85 85 86 86" and found only one result. I changed it and it was what I hoped it was.
After a screen capture and trimming the footage, the result was this webm.
If you would like to try doing something of similar scope, feel free to ask and maybe we can walk you through how to do it.