https://github.com/fabiensanglard/DoomFirePSX/blob/master/fl...

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.

Still a little humorous that optimizing fire is still a topic that gathers attention and optimization despite the increase in computing power.