3 ms·

Author here. Surprised to see this show up. I did try a large variety of encodings and the best was delta encoding frames followed by RLE encoding similar to w

Author here. Surprised to see this show up. I did try a large variety of encodings and the best was delta encoding frames followed by RLE encoding similar to what you describe. It did pretty well. However, when things start to move, it only shaved ~10-20% off the size at a significant complexity and compute cost. This was before I allowed each client to have its own frame and it was more common for there to be significant areas of black.

cogman10 1y ago
> and compute cost It'd definitely be tricky to get the computational performance that you'd want out of it. I'd imagine it'd be pretty easy to accidentally bust caches. To solve for that, you could double your frame size and store the prev/next in an alternating fashion. IE [n, p, n, p, n, p] That way when you xor you are always working with highly local memory sets. You'd want to keep the frame basically global to avoid allocating. If you wanted to be super clever then you could probably SIMD this up doing something like [n, n, n, n, p, p, p, p]. I'm not sure how you'd turn that into RLE in SIMD. I'm not clever enough for that :D (but I'm sure someone has done it). But as you said, complexity would definitely increase rather than decrease even though you could get much better compute time.