Compact native runtime.
Raylib gives us fast iteration, small native builds, predictable rendering paths, and Python-accessible game development without a full engine dependency.
Technology · Graphics Stack
Linux-first rendering, cameras, shaders, and game runtime craft.
The graphics stack is where the studio’s game work becomes visible: raylib, OpenGL, shader discipline, camera feel, input handling, and asset constraints.
A game can be technically correct and still feel wrong.
Graphics engineering is not just drawing models. It is camera timing, input latency, shader cost, texture discipline, asset scale, physics perception, and performance on real target hardware.
GRAPHICS STACK AREAS
Controlled visual pipeline.
Shaders carry the expensive visual decisions: post effects, lighting, tone, glow, anti-aliasing, and the balance between quality and GPU cost.
Feel before decoration.
Camera code decides feel: one-frame lag removal, stable perspective, tuned zoom, and movement that reads across desktop and mobile-like Linux devices.
Scale and constraint.
Asset handling covers GLB models, fallbacks, collision blockers, texture choices, material limits, and the gap between generated assets and gameplay needs.
Desktop and mobile-like targets.
Used with attention to x86, ARM, integrated GPUs, Wayland/X11 reality, HiDPI, Steam Deck style hardware, and Linux distributions.
Visual clarity under motion.
Effects must read as part of the scene: clear feedback, protected color, and no cheap overlays pasted onto the surface.
Boundary
Technology explains the graphics craft. Games show the result.
This page should not become a game product page. It should explain the rendering and runtime decisions that make the games possible.
- raylib
- OpenGL
- GLSL
- GLB
- camera systems
- input latency
# Graphics decision order
feel
-> camera timing
-> readability
-> shader budget
-> asset scale
-> target hardware profiling