Will post here my experiments with particle effects...
Experiment 1: Fireworks... basic explosions
version 1: very basic approach
version 2: added gravity pull and callback update/draw for particles to operate multiple particle types (f.e. rocket and spark in the test)
Experiment 2: Additive blit particle fire
version 1:
version 2: Supporting sprite-based blendop palettes (for now only partial additive palette included), next goal blit optimization
version 3: PEEK/POKE BLIT without great results... per-pixel blendops still kill it, updated color and added some toying controls
nice effect but you didn’t get the point of peek/poke.
Peek/poke is fast when operating on pixel pairs.
That pixel pair can then be used to look up a table of color pairs.
The modified byte is then written to backbuffer (not masked).
Left and right single pixels are then handled as edge cases (using pset/pget).
I know... Just wanted to see if there was some (enough...?) gain on just r/w operations but seems there's not. Memory space will be a bit prohibitive if storing multiple blend tables (additive, tinted glass, etc.) Maybe a different approach to store additive color ramps can help... Checking for combinations of the matching colors in the ramp, double same color pixels and partial l/r pixel can do the trick and restrict available colors. Need to think about it. Thnx for checking and commenting
Storing bytes of the multiple permutations is not that expansive - Pico as 2MB of RAM!!
[Please log in to post a comment]
