Lofi graphics bitstream
so, software engineering challenge:
- you have a normal C90 audio cassette tape, it holds 4x45 minute tracks, 45 minutes of stereo audio on each side.
- let’s use one of the tracks on each side for mono audio, and the other track for data
- we’ll use the data for some syncronised multimedia presentation displayed on say, some 1980’s ish 8-bit micro, pick your poison with whatever ram or graphics upgrades you want
- assume the most naive modem scheme: 300 baud: 300 bits per second.
300 / 6 = 50 6-bit.symbols per second.
300 / 5 = 60 5-bit symbols per second.
2400 / 8 = 300 bytes per second
300 / 60 = 5 bytes per frame
300 / 50 = 6 bytes per frame
300 / 30 = 10 bytes per frame
300 / 25 = 12 bytes per frame
300 / 24 = 12.5 bytes per frame
300 / 15 = 20 bytes per frame
300 / 12 = 25 bytes per frame
but some is lost on error correction codes so effective rates are 72.29% of those.
idea 1: stack based language where stack serves as buffer, and each symbol its a command in the stack., with “push this symbol onto the stack” being the usual meaning, with a few commands reserved for doing side effects to the effect of “pop from stack”.
can we start with something like postscript and wittle it down?
so, each of the 64 symbols can represent a command with either a known number of parameters, or the number of expected parameters as the first argument.
Suppose I have a virtual machine that has a canvas that is 512x512 pixels, 4 bits per pixel. Much of this is used as scratch, typically divided into four areas. (or, perhaps, 256x1024
map buffer, draw state buffer
stealing from pico 8
name changed by
print cursor position,
cursor() or print()
map cursor/print cursor
command stack pointer
pico state keeps this in an addressable memory region for easy save/restore. (zero page?)
- request buffer width, height, depth cls()
- request view width, height, depth [camera([x,] [y])]
- cursor(x, y)
- [clip([x,] [y,] [w,] [h])](https://pico-8.fandom.com/wiki/Clip)
- push pattern pattern.
- draw pattern i with xor at coordinates x,y [print(str, [x,] [y,] [col])](https://pico-8.fandom.com/wiki/Print)
- draw pattern over at coordinate, pattern chars [print(str, [x,] [y,] [col])](https://pico-8.fandom.com/wiki/Print) [spr(n, x, y, [w,] [h,] [flip_x,] [flip_y])](https://pico-8.fandom.com/wiki/Spr) [sspr(sx, sy, sw, sh, dx, dy, [dw,] [dh,] [flip_x,] [flip_y])](https://pico-8.fandom.com/wiki/Sspr)
- fillRect (pattern i) [rect(x0, y0, x1, y1, [col])](https://pico-8.fandom.com/wiki/Rect)
- copyRect, drawmap
- [circ(x, y, r, [col])](https://pico-8.fandom.com/wiki/Circ)
- [circfill(x, y, r, [col])](https://pico-8.fandom.com/wiki/Circfill)
- set palette, [pal([c0,] [c1,] [p])](https://pico-8.fandom.com/wiki/Pal)
- draw line
- clear screen
- pset pixel set [pset(x, y, [c])](https://pico-8.fandom.com/wiki/Pset)
- mset map set
- move cursor
- line( [x0,] [y0,] [x1,] [y1,] [color] )
- tline( x0, y0, x1, y1, mx, my, [mdx,] [mdy] ) textured line from map
- [fset(n, [f,] [v])](https://pico-8.fandom.com/wiki/Fset)
- [sset(x, y, [c])](https://pico-8.fandom.com/wiki/Sset)
- stroke path
- skip frame
- define pure function of time, random, scroll.
- undefine function
- fill line
- inc/dec palette index
- push palette
- pop palette
The NES uses a custom-made Picture Processing Unit (PPU) developed by Ricoh . All variations of the PPU feature 2 kB of video RAM, 256 bytes of on-die “object attribute memory” (OAM) to store the positions, colors, and tile indices of up to 64 [sprites](https://en.wikipedia.org/wiki/Sprite_(computer_graphics)) on the screen, and 28 bytes of on-die palette RAM to allow selection of background and sprite colors. The console’s 2 kB of onboard RAM may be used for tile maps and attributes on the NES board and 8 kB of tile pattern ROM or RAM may be included on a cartridge.
GitHub - dpt/MotionMasks: Investigating using RLE-compressed masks for animation
steps for adding images to cycling image stack progressively.
make new paletteSet
make new imageIndexes
make new colorLUT
for each x,y in new image
- look up index for x,y in old imageIndexes
- look index up in oldPalette for oldColor
- add color to end of oldColor to make newColor
- add newColor to newPaletteSet
- add newColor to colorLUT- returns index from instances of newColor Value
- get index from colorLUT
- record newIndex in newImageIndexes
- convert paletteSet to sortablePalette
- return new sortablePalette,newImageIndexes,
motion vector algorithm between two pairs of images
- for each 8x8 pixel block
- for each offset against previous image
- try offsets of neighbouring blocks first
- build shared palette between this 8x8 block and 8x8 block in previous frame (palette of “cycles”)
- count unique indexes in shared palette
- optimise all offsets to minimise unique colors, difference from neighbouring offsets, distance from starting point.
- store offsets
- store xor of difference, if there is a difference.
- also store the palette for the new block, against the shared indexes? yes. because those are what we’re generating with xoring the diff.
Retro Game Fantasy Computer Framework - GameCreators Forum
Idea for cell-shaded FMV on the NES - nesdev.com