touchpadder

The game uses DEM data and OSM maps to generate in a worker: 3D roads, intersections and tunnels. Everything is created in real time around you as you drive. The link takes you straight to a high speed race on a motorway in France. You can create your own races anywhere in the world and share the link with your friends. Press X to reset the car, long press X to return to the road. Press J for Nitro and long press to jump with the car.

Hop Earth combines DEM data with OpenStreetMap to generate roads, intersections, tunnels, bridges and their physical meshes. It creates 1:1 scale world where you can drive anywhere on the planet. It's all generated in real time on your device as you drive. Early Access is now live.

This one is actually an SVG not a font. There was no such font but I really wanted to make this flaming Diablo logo. As a side effect now any SVG can be dragged and dropped onto the editor and all paths and shapes will be automatically extracted and flattened.

Until now such rich text effects required manual animation in programs like After Effects and exporting to videos.

Font.skin connects GPU shaders with webfonts to allow creating real-time, browser-based animated text effects never seen before on the web.

Global uniforms are compatible with Shadertoy i.e. iTime, iResolution etc. to allow pasting parts of shaders from ST.

Font skins can be exported to pure HTML or React and have no dependencies. Text transitions are scriptable in GLSL which is transpiled to JS. This is to allow exporting to game engines in the nearest future as transpiling from GLSL to other strongly typed languages is simpler than from arbitrary JS. The resulting code together with all required glyphs, gzipped often takes less space than a screenshot of itself or the font it's based on i.e. 30KB

The premiere was just last night so you can't find these anywhere else!

This is all very random but also fun to watch. I like the song in demo 33. Some demos are very high-effort and others....no effort at all :)

For simple devices like IOT etc to be able to keep using the short 32bit date format. Also for databases that may store dates as integers to save the space. There are plenty of cases that may want to keep using a short 32bit date format. After 2038 anyone will be able to count 32bit time from any arbitrary point of time so before that happens I'm simply suggesting a standardized way of reliably restarting it for centuries to come

Using negative values would only complicate things and the goal is to have a simple solution for not losing convenience of having a unix timestamp that fits in 32bits and is very straightforward.

In 99.9% cases there will be no need to keep track of the epoch just like the current computers don't look before 1970. In rare cases if its required the epoch can obviously be stored in another byte.

How does it require less implementation? It's just another arbitrary point in time and 2106 is too late.