Re:Show HN: I've re-implemented the Doom fire effect in plai...
by filipedeschamps on Saturday January 05, 2019 @05:51PM
(#18834827)
I've addressed those semantic issues in the version I wrote. I also got very confused by the article explanation.
It switches from saying that 0 in the map represents white, to saying it is black, and then in the loop it states that the first row isn't changed but the loop pseudo-code skips over the first row only to then overwrite that first row in the code:
> firePixels[src - FIRE_WIDTH] = firePixels[src] - 1;
The comment, "Notice that line 0 is not updated" doesn't make clear it's not talking about the start of the buffer: It clearly changes index 0. In fact if line 0 is the 'generator' row it is in fact the last line in the buffer and the description of why it doesn't change is wrong: It's not unchanged because the loop starts at 1, it's unchanged because the loop is modifying 'src-FIRE_WIDTH'.
Maybe some of the description or pseudo-code described are describing two different implementations one of which maybe is working with a reversed buffer.
The principle however is clear, and it is interesting to see in the browser, although I'm sticking to just loading it into a canvas directly with CanvasRenderingContext2D.putImageData which lets you directly write an image buffer (noting that it is RGBA so 4 bytes per drawn pixel).
In fact the 'cleaned up' version linked at the bottom appears to do the same.