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.
Most of them were in Pascal, but the fire one was in asm (http://archive.gamedev.net/archive/reference/articles/articl...) - it was the first time that assembler really clicked for me!
Wonder what he (?) is doing today.
Still a little humorous that optimizing fire is still a topic that gathers attention and optimization despite the increase in computing power.
There were different tabs for things like "wood", "gas", "cryptonite" which changed the overall colour of the effect.
