Raylib 6.0 ships a CPU-only software renderer (rlsw), three new platform backends, redesigned animation blending, and a consolidated filesystem/text API across 600 total API functions.
Key Takeaways
rlsw software renderer implements OpenGL 1.1+ in a single-header library, enabling raylib on GPU-less hardware like ESP32 and emerging RISC-V devices at 30-60 fps.
New platform backends include rcore_memory (headless framebuffer rendering, useful for servers), rcore_desktop_win32 (direct Win32 API, no GLFW/SDL dependency), and rcore_web_emscripten (drops libglfw.js, supports both WebGL and software canvas).
Skeletal animation redesign adds animation blending between frames and separate animations; GPU skinning optimized; Model, ModelSkeleton, and ModelAnimation structures updated.
Filesystem and text APIs consolidated into rcore (utils module removed); 40+ filesystem functions and 30+ text management functions now in one module, enabling raylib as a build system component.
Build config overhaul lets users disable features at compile time with simple flags like -DSUPPORT_FILEFORMAT_OBJ=0, previously not straightforward from external build systems.
Hacker News Comment Review
Consensus is enthusiastic: commenters cite raylib as the rare tool that enables project completion without forcing engine lock-in, with active use in Go, Swift, and Odin bindings.
The known sharp edge is text rendering performance: raylib has no cached Text object, so font glyph layout is recalculated every draw call, creating CPU bottlenecks in text-heavy or fast-paced UI scenes.
The rlsw addition is independently inspiring builders to explore software rendering fundamentals, with at least one commenter already prototyping a zero-dependency renderer to study the rlsw source.
Notable Comments
@diath: No Text object means font glyphs recalculate on every draw call – a real bottleneck for combat damage numbers or dense UI.
@forsalebypwner: Plans to test the new software renderer directly on an ESP32S3.
