This looks very similar to the Doom fire algorithm (later), except that one is applied to a fixed buffer over and over again every frame.
> it is tempting to view the algorithm as based on cellular automata (Sarkar 2000), yet the lack of parallelism and the strange shape of the 'neighbourhood' of cells surrounding X makes the cellular-automata notion contrived.
If you consider rows as time then dependence is local rather than global. It looks like a 2D automata with a temporal neighbourhood component. And IMO asymmetric or nonuniform neighbourhoods dont necessarily exlude it from the definition, but affects its classification.
Does anyone with deeper academic overview of CA have any insight here? I find many things can look like CA if you stare at it right, but am never sure where to draw the line (maybe there isnt one)
Ah yes, Lode's raycaster tutorial, the classic writeup keeps generating interesting projects. Such as this one.
The human ingenuity never ceases to amaze me. Take what's essentially a pong machine with a few extraneous bits and almost no memory, what you can do with it? Apparently racing games, building games, maze games, even honest to god space sims.
The 2600 VCS is really interesting. It didn't even have a framebuffer, so painting pixels was done scanline by scanline and you had to be done with your scanline in a certain amount of CPU cycles, which meant you had to count them and know which instruction took how long.
It only had 128 bytes RAM, that's bytes, not KB.
A real technical marvel is the chess game for the 2600. Since the sprite capabilities were so primitive, they couldn't even draw all pieces in a single scanline, they had to alternate scanlines so that they could even draw all chess pieces, and that's not even mentioning the fact that they somehow made a chess playing algorithm work in 128 Bytes of RAM.
the 128 bytes thing breaks my brain every time. I'm building a city in three.js with ~30k buildings and I get annoyed when a frame takes 20ms on a laptop with gigabytes to spare. counting cycles per scanline is a different sport.
I wish someone would remake this weird game from the C64 that has stayed in my head since forever: Scarabaeus https://www.youtube.com/watch?v=FusuIst21E4
I remember being blown away by this game. It was a taste of 3D on the C64 years before The Eidolon and Rescue on Fractalus...
This looks very similar to the Doom fire algorithm (later), except that one is applied to a fixed buffer over and over again every frame.
> it is tempting to view the algorithm as based on cellular automata (Sarkar 2000), yet the lack of parallelism and the strange shape of the 'neighbourhood' of cells surrounding X makes the cellular-automata notion contrived.
If you consider rows as time then dependence is local rather than global. It looks like a 2D automata with a temporal neighbourhood component. And IMO asymmetric or nonuniform neighbourhoods dont necessarily exlude it from the definition, but affects its classification.
Does anyone with deeper academic overview of CA have any insight here? I find many things can look like CA if you stare at it right, but am never sure where to draw the line (maybe there isnt one)
Ah yes, Lode's raycaster tutorial, the classic writeup keeps generating interesting projects. Such as this one.
The human ingenuity never ceases to amaze me. Take what's essentially a pong machine with a few extraneous bits and almost no memory, what you can do with it? Apparently racing games, building games, maze games, even honest to god space sims.
The 2600 VCS is really interesting. It didn't even have a framebuffer, so painting pixels was done scanline by scanline and you had to be done with your scanline in a certain amount of CPU cycles, which meant you had to count them and know which instruction took how long.
It only had 128 bytes RAM, that's bytes, not KB.
A real technical marvel is the chess game for the 2600. Since the sprite capabilities were so primitive, they couldn't even draw all pieces in a single scanline, they had to alternate scanlines so that they could even draw all chess pieces, and that's not even mentioning the fact that they somehow made a chess playing algorithm work in 128 Bytes of RAM.
the 128 bytes thing breaks my brain every time. I'm building a city in three.js with ~30k buildings and I get annoyed when a frame takes 20ms on a laptop with gigabytes to spare. counting cycles per scanline is a different sport.