Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456 Blog - Langur Monkey - Toni Sagristà Sellés
How I set up an old laptop as a persistent inference machine using LM Studio, system-level services, and systemd lingering.
3 minute read
The release of LM Studio 0.4.5 has introduced a much needed feature in this local LLM suite that has it much more attractive with respect to other similar projects. LM Link allows you to connect multiple LM Studio instances across your network to share models and perform inference seamlessly.
Play Kid update from SDL2 to a modern Rust stack using pixels, winit, and egui
3 minute read
Notice
This post is about Play Kid version 0.2.0, which uses pixels to create and manage the pixel frame buffer. Since then, versions 0.3.0 and 0.4.0 have been released, which dropped pixels in favor of rendering directly to a texture. See this write-up for more information.
In my previous post, I shared the journey of building Play Kid, my Game Boy emulator. At the time, I was using SDL2 to handle the “heavy lifting” of graphics, audio, and input. This was released as v0.1.0. It worked, and it worked well, but it always felt a bit like a “guest” in the Rust ecosystem. SDL2 is a C library at heart, and while the Rust wrappers are good, they bring along some baggage like shared library dependencies and difficult integration with Rust-native UI frameworks.
So I decided to perform a heart transplant on Play Kid. For version v0.2.0 I’ve moved away from SDL2 entirely, replacing it with a stack of modern, native Rust libraries: wgpu, pixels, egui, winit, rodio, and gilrs:
Write-up about Play Kid, my own homegrown Game Boy emulator.
35 minute read
Notice
This post is about Play Kid version 0.1.0, which works with SDL2. Since then, version 0.2.0 has been released. This new version uses Rust native crates like winit, egui, rodio, and pixels. See this write-up for more information on the new version.
When I was a kid my parents got me and my brothers a brand new Game Boy. I used to play it a lot, and I was mesmerized and amazed at how such a tiny brick could give life to so many wonderful worlds. Some of my favorite games were Super Mario Land (1, 2, and 3, Wario Land), The Amazing Spider-Man, and Kirby’s Dream Land. We also had some other games, like Bugs Bunny Crazy Castle or Tetris, that I also played quite a lot. I remember fondly too.
The latter post started with a quick support test:
“If you are browsing this page around 2023, chances are that your browser supports AVIF but does not support JPEG XL.”
Well, here we are at the end of 2025, and this very sentence still holds true. Unless you are one of the 17% of users using Safari3, or are adventurous enough to use a niche browser like Thorium, LibreWolf or the newer Zen Browser, chances are you see the AVIF banner in green and the JPEG XL image in black/red.
Vertex-based motion trails implementation using screen-space velocity
6 minute read
Astronomical scenes, especially those rendered interactively, often feature supraluminal camera motion over immense distances. Sometimes, these motions are rendered by applying trail effects to light-emitting objects to enhance the faster-than-light velocity sensation. Gaia Sky will get an implementation of motion trails in the next version (3.6.9). Motion trails are a visual effect that stretches stars, galaxies, and other light-emitting particles in the direction of the velocity vector of the camera, giving a sense of speed and enhancing the perception of motion through space. This technique is inspired by relativistic visualizations and classic star streak effects, but it is grounded in angular motion rather than raw velocity.
Vertex-based stretching of stars in supraluminal travel in Gaia Sky.
In this post, I describe the technical details that made implementing a performant, vertex-based solution into Gaia Sky possible.