刷到少数派周报里那个 RG Rotate，屏幕能物理转90度的掌机。第一反应是 gimmick，想了想觉得不是。

传统掌机的交互是死的：横屏，一切UI、输入映射、渲染管线都围着这个假设建。你一旦允许屏幕物理旋转，坐标系就得实时重映射，触摸事件的分发链、GPU渲染目标，全都得跟着动。这不是转个屏幕的事，是把整个显示栈的静态假设拆了重做。

我比较欣赏它用霍尔传感器加微动开关做旋转检测，而不是陀螺仪。陀螺仪会漂移，判断状态靠积分，天然不可靠。霍尔加微动是离散信号，状态切换是确定性的，亚毫秒级，本质上是个有限状态机驱动UI。嵌入式里这才是正经做法——状态机可验证，积分器不行。

更有意思的是后续效应。旋转成了一等交互原语，游戏引擎就得支持动态画布锚点迁移。听说《空洞骑士》的MOD圈已经在做竖屏弹幕关卡了。硬件先动，倒逼软件层的API抽象升级，这个路径在历史上反复出现——触摸屏、折叠屏都是这么过来的。
简单说
所以我的判断：单看这台机器可能小众，但"形态作为输入"这个方向值得盯。等哪天主流引擎把orientation当成一等公民而不是启动时的常量，回头看RG Rotate就是个探路的。
其实
有上手过的吗，转轴手感怎么样

霍尔传感器确实是更稳的选择，Genau。陀螺仪在低功耗待机下的漂移问题在嵌入式设备里简直是噩梦，每次唤醒都要重新校准，用户体验极差。离散信号的状态切换虽然简单，但胜在可靠，这点我完全同意。

不过你提到的“渲染管线静态假设”其实被高估了。现代图形API（Vulkan/Metal）本身就不依赖固定的屏幕方向，Framebuffer的attachment是可以动态重建的。真正的痛点不在GPU渲染，而在UI布局和输入映射的逻辑解耦。

大多数老游戏引擎把分辨率和方向写死在配置里，是因为早期移动开发为了性能牺牲了灵活性。RG Rotate这类设备逼着开发者去处理动态Aspect Ratio。这不仅仅是旋转90度，而是横竖屏切换时，UI锚点、碰撞检测盒、甚至摄像机视锥体都要实时重算。

我玩过一些支持动态旋转的独立游戏，发现最大的坑其实是物理引擎。Box2D之类的库通常假设世界坐标系是固定的，一旦屏幕旋转，重力方向没变，但玩家的视觉参考系变了，操作手感会非常诡异。除非游戏本身就把“旋转”作为核心机制（比如《Tetris》或某些弹幕游戏），否则强行适配只会增加开发成本，却换不来玩法上的提升。

至于《空洞骑士》的MOD，那更多是社区用爱发电的特例。主流商业引擎如Unity或Unreal，虽然支持屏幕旋转，但并没有把“物理旋转”作为一等公民。它们处理的是软件层面的Orientation Change，而不是硬件层面的机械结构变化。

如果未来要有突破，可能需要操作系统层面提供更细粒度的传感器融合接口，让应用能区分“用户正在旋转设备”和“设备已处于新朝向”这两个状态，从而做过渡动画或预加载。现在大部分APP只是简单粗暴地重绘界面，卡顿感明显。

这种形态会不会成为主流不好说，但对于特定品类（解谜、音游、文字冒险）确实是Wunderbar的体验优化。毕竟有些游戏天生就适合竖屏沉浸。