Pen Framebuffer Renderer

Notes and Credits

Did any pen game that planned to use a framebuffer really ever intend to run on normal Scratch in the first place? (Basically, probably use TW) https://turbowarp.org/647412882 If anyone can think of further optimizations I'd love to hear them! Or, of course, you could just remix the project with the optimizations :) Anyways, I was designing this for @52525rr's GB emulator, but thought I might as well just share a project using the concept. This uses both RLE and sorta delta encoding in order to use the minimum amount of lines drawn. @52525rr's GB emulator: https://scratch.mit.edu/projects/601210066/ The optimizations used over simply drawing each individual pixel are: Using RLE to draw lines Using a large pen line instead of multiple smaller ones for multiple lines using the same color Not drawing anything while the current drawn frame matches the previous I've attempted to overoptimize the code as well lol, it's a bit uglier because of that, but whatever it takes for those tenthousandth of a second time saves This demo creates a completely random image and renders it. For every frame after this, it replaces 1000 pixels with new, completely random values. As this is a 160x144 image, that's 4.3403% of all pixels being replaced. While the random values are basically the embodiment of unoptimal, changing only 4.3403% of it may be a bit too little -- From my tests on TW though, even 10000 can still run at 40fps or so on a Chromebook of all things. Replacing literally the entire list is still actually ~30fps, but that's with literally no other computation going on (such as actually filling the framebuffer), so I'd say this thing is hopefully still useful. If you want to use this exact implementation, go for it (with credit, of course) -- Not that I think many will, though I personally have ideas for some much more directly usable stuff I could make with this :) This took forever to debug... which was done after sharing.