WARNING: Flashing Patterns I've been experimenting with fast pixel rendering... this is a prototype that just prints plain noise with some blurring effect to smooth out the dizziness. But it should be able to draw images from a "framebuffer" (a list). Right now, it only supports black and white, surprisingly it supports gray scale, at the cost of performance (and thus resolution). Doing color would probably be a nightmare, you have to pick what color you'd use and stick with it in a per-block basis (a block is the minimum rendering unit, which is a 1 by 10 pixels unit in this engine). You _can_ mix colors, but using just two colors in one block cuts performance in half, since effectively the only way (for now) to mix colors is by rendering the same block twice or more. Note that if you're clever, you can get up to four different colors at once in a single block without requiring more than two render passes. But a _single_ render pass will only buy you two colors (*on* or *off*), and that's it. Also, note that pixels can be transparent, so, you can also add "static" backgrounds as full baked textures _behind_ the renderer's frame, thus creating a background + foreground effect where the foreground is dynamic, this allows for even more colors to be available! Doing it "the gameboy way" might be its most useful state for simple framebuffer logic, essentially you render the buffer twice, this gives you four shades per pixel. The "blocked" rendering is the key to making this engine run fast, each block is a state of precomputed pixel combinations that the code can draw in a single stamp call. Increasing the block size (from 1x10 to, say, 1x20) would definitely improve performance a bit, but just going from 1x10 to 1x12 becomes incredibly unmanageable due to the sheer number of possible combinations. The best I could do that felt practical is 1x10. 1x12 could be an option and would save on overhead for heigher resolutions, but if you're going hi-res, then why would you want a pixelart renderer like this one right? this code would be decent for (up to) 64x64 frames, this could be great for procedural effects in demoscenes maybe, perhaps for some effects in games too. Still, for the most part, there a probably close to none use cases for this setup. But it was fun to build. ...unless... you're planning on coding a Gameboy emulator or something, but if that's your plan, probably the emulator itself is way slower than the screen drawing routine anyways ;) This could be fun to use in a "Real" 3D ray-caster, albeit low res and limited coloration, but it would allow for the implementation of a true depth buffer, and true ray shooting, and even ray tracing at decent framerates (who wants 360x480 when 30x40 is just as good?) It *IS* possible to do quirky RGB mixing actually, and get fairly decent colors using sub-pixel masking, since a pixel in a block is not 1x1 Scratch pixels, but 10x10 Scratch pixels. Still, color is information, and there's only so much information you can put in a limited space and a limited timeframe. Think about it. TODO: Implement an actual frame buffer and experiment with some actual pixel art! Note: The width is actually devided by 10 (since it is the width in blocks), so Width: 17 is actually 170 pixels wide Did you know I love to express myself in text? Yeah... Also also, did you realise this rendering frame can be distorted along its X axis into 3D space? YES! You *can* do real-time procedural 3D textures! Imagine using this to overlay screen-space reflection effects onto 3D models
