Hacker News new | ask | show | jobs
by ricardobeat 2729 days ago
Maybe it wasn't clear in the original article [1], but what you see inline are javascript implementations of the effect - there is a link to the source code at the end:

https://codepen.io/svkaiser/pen/xXmOvY

[1] http://fabiensanglard.net/doom_fire_psx/

2 comments

The blog post is sadly not easy to follow along to try to do an implementation due to what appear to be minor description mistakes or poor writing which confuses.

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.

I've addressed those semantic issues in the version I wrote. I also got very confused by the article explanation.