SEND
How pixel encoding works
Each pixel is packed into the minimum number of bits for the selected mode. In B&W mode, one bit per pixel — 8 pixels fit in a single byte. At 4 gray levels, each pixel needs 2 bits (4 per byte). At 16 levels, 4 bits each (2 per byte).
The encoder compares raw bit-packing against RLE (run-length encoding) and sends whichever is smaller. RLE replaces repeated values with a count+value pair, which works well for images with large solid areas.
What is dithering?
Dithering simulates shades your display can't actually show by carefully placing dots of the available colors. Instead of rounding each pixel to the nearest level (which loses detail), dithering spreads the rounding error to neighboring pixels.
Floyd-Steinberg distributes error to 4 neighbors — smooth gradients, natural look. Atkinson spreads error to 6 neighbors but only 75% of it — higher contrast, great for pixel art. Try both on the same image to see the difference!
How fountain codes work
Fountain codes let the receiver reconstruct data from any sufficient subset of encoded blocks — no specific blocks are required. The sender generates more blocks than strictly needed (50% extra by default), so the receiver can tolerate lost blocks without retransmission.
Each parity block is the XOR of 2-3 source blocks. When a source block is lost, the receiver recovers it by XORing a parity block with the other known sources. The payload is compressed with DEFLATE first (3-5x for text), and a CRC-32 hash verifies integrity after reassembly.
The protocol: sender broadcasts a SYN (file metadata), receiver replies SYN_ACK, sender bursts all data blocks, receiver sends DONE when complete. Only 2 turn-arounds needed — the half-duplex audio channel stays efficient.
How compression strategies compare
Raw packs pixels into the minimum bits with no compression — fast but bulky. RLE (run-length encoding) replaces runs of identical values with count+value pairs — great for simple graphics with solid areas.
Palette mode finds the 16 most representative colors in your image, then stores each pixel as a 4-bit index. Each row is further RLE-compressed. The arena shows the byte count and chunk count for each strategy so you can see which wins for your image.
How the game protocol works
Battleship over sound uses a simple frame protocol. Each message starts with a type byte (0x05 = game) and a subtype: SETUP (hash of ship positions for turn order), SHOT (x,y coordinates), RESULT (hit/miss/sunk), and WIN.
Turn order is decided by comparing placement hashes — the lower hash goes first. Each shot-result exchange is a two-frame round trip sent via audio. The entire game typically uses about 20-40 audio transmissions.