Create a fully interactive 90s digital camera simulator — a loving, deeply detailed recreation of a late-1990s consumer digital camera experience running in the browser. Think of the era of the Kodak DC-series, the Sony Mavica that saved to floppy disks, the Nikon Coolpix, the Casio QV cameras: chunky LCD screens, heavy JPEG compression, tiny resolutions, and the peculiar charm of images that feel half-photograph, half-digital artifact.
The heart of the experience is the camera itself, presented as a physical device on screen: a rendered camera body with a shutter button, mode dial or control buttons, a small LCD live viewfinder showing the "scene," a status display panel (the little top LCD with battery bars, shots remaining, resolution indicator), and a flash. Visitors should be able to aim the camera, choose a scene, adjust camera settings, and take photos. When the shutter fires, the screen should flash, a satisfying mechanical-bleep shutter sound should play (synthesized audio is fine), the camera should "process" the shot with a visible busy/writing indicator (the red LED by the card slot, a "PROCESSING..." message), and the finished photo should be committed to the camera's internal memory or removable card, with the shots-remaining counter decrementing.
The scene being photographed must be a real, living subject: build an explorable 3D environment (or several selectable environments) that the camera views through its viewfinder. The visitor pans/tilts/zooms the camera to compose shots. The viewfinder renders this scene continuously through the camera's optical pipeline at low, period-accurate resolution (e.g., 640×480 VGA class, or a "low" mode at 320×240), with the distinctive look of a cheap CCD sensor: slightly washed colors, visible noise in shadows, halation around bright lights, soft focus at the edges, chromatic fringing.
The post-processing pipeline is the soul of this simulator and must be genuinely shader-based, not a CSS filter. Implement custom post-processing shaders that run on the live scene and on captured photos, including at minimum:
- CCD sensor simulation: color matrix with slight channel imbalance, read noise that increases in shadows, Bayer-pattern demosaicing softness, bloom/halation from overexposed highlights, fixed-pattern noise.
- Heavy, era-appropriate compression artifacts: a convincing JPEG-crunch approximation with visible 8×8 blocking, mosquito noise around edges, and chroma subsampling smear — with adjustable "quality" tied to the camera's Fine/Normal/Basic menu setting.
- Dithering: multiple dither modes the user can select from the camera's menu — ordered Bayer dithering (2×2, 4×4, 8×8), Floyd–Steinberg error diffusion, and halftone-style dot dithering — applied with a reducible palette (full color, 256-color, 16-color, and monochrome), so photos can be crushed down to look like they came off an early-90s framebuffer. The dithering must be implemented in shaders working on pixel neighborhoods (error diffusion may use a multi-pass approach), not canvas per-pixel JS loops in the render path.
- Glitch effects: datamosh-style block displacement, RGB channel split/chromatic aberration, scanline jitter and horizontal sync slips, row/column corruption, bit-depth crush, and a "card error" corruption mode that mangles parts of the image into smeared macroblocks and noise bands. Glitch intensity should be adjustable and also triggerable as random "camera malfunction" events.
- Era look options: monochrome, sepia, and a washed "VHS still" tone; timestamp overlay burned into the corner of photos in the classic orange/yellow dot-matrix style (with a real working clock, and an option to toggle it).
The camera must have a believable on-device menu system navigated with on-body buttons: settings for resolution (Hi/Fine 640×480, Low 320×240), compression quality, flash mode (auto/on/off, with the flash actually affecting exposure of the scene — washed-out foregrounds at close range, falloff with distance), white balance presets (daylight/cloudy/tungsten/fluorescent) that visibly shift color temperature, exposure compensation, dither mode and palette depth, timestamp on/off, and the date/time setting screen where visitors can set the clock that appears on burned-in timestamps. Include the classic clunky multi-level menu UI with highlight bars and beep feedback.
A review/playback mode is essential: press the play button to browse the photos stored in the camera's memory with the little LCD showing them full-screen, page through them with the camera's arrow buttons, see each photo's index number (e.g., "DSC_0007"), zoom in, and delete shots (with a confirm prompt) to free up memory. Storage is finite — a simulated memory card of limited capacity (e.g., ~8MB class) where each photo's size varies realistically by resolution and compression setting, and taking a photo on a full card produces the era-authentic "CARD FULL" error state.
The EXIF viewer is a named requirement: every captured photo carries plausible, internally consistent EXIF metadata — camera make and model, date/time (from the in-camera clock), resolution, exposure simulation details (simulated shutter speed, aperture, ISO that respond believably to scene brightness, flash use, and the exposure compensation setting), white balance, focal length, dither/palette settings recorded as maker-note-style custom fields. In playback mode, an "INFO" or similar control opens a panel displaying the full EXIF block for the current photo in a clean, readable layout — the period-appropriate way would be the camera showing basic info, but provide a full detailed view (all fields, hex-ish raw flavor optional) as if the card had been plugged into a PC. The metadata must genuinely match the shot: a photo taken with flash at night shows different values than a daylight shot, and the timestamps match the camera clock when the shot was taken.
Photos must be exportable: let visitors download selected photos as actual image files (with the dithering/glitch/compression baked in), ideally with the EXIF data genuinely embedded in the exported file or at minimum displayed accurately in the viewer. A gallery or "copy to computer" flow that shows all shots as thumbnails would complete the fantasy of offloading the card.
Pay attention to the whole atmosphere: the UI outside the camera can lean into a retro-computing aesthetic if it serves the experience (a desktop-from-1998 framing, a serif-and-bevk manual page, or similar), but the camera itself is the star. Sound design matters — synthesized shutter clicks, beeps, card-write whirs, and button ticks elevate it enormously; keep a mute control. The experience must be fully usable and legible at desktop and smaller viewport sizes, with the camera body and its screen scaling sensibly.
Everything must work offline from static files: no external CDN dependencies at runtime, no network calls. All assets (fonts, sounds, textures) must be generated or self-contained.
Do not take shortcuts or settle for a recognizable shell: a static picture of a camera with a couple of CSS filters would be a failure. This skill imposes no token budget limit, so pursue the full depth of the experience — the living 3D scene, the real shader pipeline with dithering and glitch modes, the working camera menu and playback system, finite card storage with realistic file sizes, the accurate per-photo EXIF viewer, exporting, sound, and all the small era-authentic states (card full, processing delay, low battery, flash charging) — and keep refining until the simulator feels like the actual object someone in 1998 would have spent $900 on.
