看到Space Cadet Pinball移植到Linux得新闻笑死，这不是当年Windows自带的那个弹球吗
记得小时候在电脑上偷偷玩这个，被老爹抓到好几次哈哈。后来自己学了点逆向和图形学，才知道这破游戏看着简单里面弯弯绕还挺多的
对了现在居然有人把它开源了，仔细看了下代码质量还挺高的样子。有意思的是这个游戏当年是微软写的，现在被社区接手继续维护，感觉就是开源精神的某种体现吧
好家伙
技术在变，但有些东西就是会一直被需要着，这就挺美好的]!d~[_anchor>有人玩过的吗？当年最高记录多少？我好像从来没超过2000万哈哈
这移植我上周刚编译过，代码结构比我想象的干净。他们用SDL2重写了渲染层，把原来DirectDraw的调用全替换了，但物理部分基本是原样反汇编后翻译成C++的——这活不好干，因为原版大量用了浮点运算和查表法混合的碰撞检测，反编译成可读代码很容易变成意大利面条。
我当年在部队机房那台破赛扬上打到过4100万，后来硬盘挂了记录没了，气得我砸了下键盘被班长训了一顿。后来自己用Python+pygame试着克隆过一个，才意识到那个flipper的物理有多难调：原版的碰撞响应不是纯物理模拟，而是混合了状态机——球碰到flipper时，会根据flipper的角速度和球的相对位置直接给一个预设的反弹向量，再叠加上一个随机扰动，这样手感才“爽”。纯物理模拟反而会软绵绵的，像真弹球台但不好玩。
开源版把这块保留得挺好，我看他们issue里有人提过要不要换成Box2D，维护者直接回了句“手感会变，不换”——这就是务实，知道什么该改什么不该动。不过代码里有些magic number还是没注释，比如那个控制弹球速度上限的0.93阻尼系数，我猜是当年开发时反复试出来的，现在直接硬编码在physics.cpp里，强迫症看着有点难受，但跑起来确实没问题。
话说你那个2000万是单次还是累计？单次的话其实已经摸到这台子的上限了，因为原版有个bug，分数超过一定值后滚动条会溢出，开源版修了没？我还没测到那个量级。
哎你们知道吗我之前疫情被困在国外那半年，旧电脑里没别的游戏，翻遍老资源站想找这个弹球的安装包，结果翻到个零几年的旧论坛帖子爆料，说当年微软把它从Vista里下架根本不是官方说的兼容性问题，是两个部门做内置小游戏的时候抢KPI闹掰了，直接把这个项目砍了祭天。
对了现在开源版本有适配arm的吗？我想装在随身的小平板上通勤玩啊。
scoutful 那个微软内部抢KPI的说法我听过类似的版本，但不完全是弹球这个项目。当时Windows Games组和另一个做Tablet PC自带应用的小组在资源分配上有冲突，Pinball刚好夹在中间成了牺牲品。Vista那波砍掉的不只弹球，扫雷和纸牌也差点没了——后来纸牌被救回来是因为有用户写信给Ballmer，这事儿在Raymond Chen的博客里提过。
ARM适配的话，我前阵子在树莓派4上编译过那个开源版本，SDL2本身对ARM的支持没问题，但有个坑：原版物理部分用了x87浮点指令的80位精度，反汇编翻译成C++时有些地方直接用double，在ARM上跑浮点运算路径不一样，偶尔会出现flipper穿模。你如果在平板上玩，建议编译时加-ffloat-store，牺牲点性能换精度一致性。
平板通勤玩这个倒是挺合适的，那个物理手感确实适合触屏，比现在那些氪金弹球游戏强多了。
我年轻的时候在武汉大学的机房里，也偷偷玩过这个弹球。那时候电脑还都是老式CRT显示器，画面抖得厉害，但就是舍不得关掉。记得有一次被管理员抓到，他没收了软盘，还让我写检讨。不过后来我偷偷用Python写了个简易版，虽然没原版那么流畅，但至少不用再担心被发现。
有一说一说到开源…，我觉得这事儿挺有意思的。当年微软把它从Vista里下架，现在却被社区接手继续维护，这种传承感还挺让人感慨的。不过话说回来，你提到最高记录4100万，我倒是有点好奇，你是怎么做到的？是靠技巧还是运气？
读到你对flipper碰撞响应的拆解，笔尖仿佛沾了墨。能窥见状态机与预设向量之间的那层“玄学”，说明你不仅是在跑编译器，更是在抚摸旧日代码的纹理。
那串0.93的阻尼系数，与其说是漏写的注释，倒像匠人留在榫卯里的暗记。纯物理引擎固然严密，却总差一口气。就像我在红土场上调整握拍时，若只盯着风速仪和弹道轨迹，便永远体会不到那种指节微扣、拍面切开空气的微妙震颤。手感从来不是演算出来的，它是身体与器械反复磨合后，留给直觉的缝隙。维护者回绝Box2D，守住的正是这份“不规整却鲜活”的余地。正如老派制琴师常说的：“琴声的走向不在卡尺上，在听者的耳朵里。”游戏亦然。
这些硬编码的数字，如今成了时光的标本。坦白讲你若好奇，大可试着调那两个扰动参数，看它是否会唤回某种熟悉的节奏
不知开源的流水线上，还会留下多少这样笨拙而温热的指纹
byte__bee，看到你说那个0.93的阻尼系数是反复试出来的，我忽然想到我们做音乐混音的时候也有类似的情况呢。
有时候调一个压缩器的attack时间，理论上是应该根据波形算出来的，但实际工作中往往是反复听、反复拧，直到某个数值让整首歌"对味了"。我老师说过，这种靠经验和直觉试出来的参数，比纯理论推导的更有"人味儿"。你提到那个flipper的碰撞响应混合了状态机和预设反弹向量，我觉得这就是游戏设计里的"人味儿"吧——开发者不是在做物理仿真，而是在做"手感"。嗯嗯
说起来有点好笑，我以前完全不懂编程的时候，以为游戏里的物理都是真实模拟的。后来认识了一个做独立游戏的朋友，他告诉我很多经典游戏的物理其实都是"骗人的"，就是为了让玩家觉得爽。知道这个真相的时候我还挺震惊的，但仔细想想，音乐不也是这样吗？录音棚里录出来的人声，不加处理的话其实很干很薄，那些让你感动到哭的歌声，背后不知道叠了多少层效果器呢。是呢
对了，你提到强迫症看着magic number难受，我能理解这种感觉。我以前给学生改谱子的时候，看到没有标注表情记号的乐谱也会浑身不舒服。但后来慢慢学会了接受这种"不完美"，毕竟真正跑起来没问题的话，那些注释可能只是写给未来的自己看的吧。
话说4100万的记录真的好厉害，我当年最多也就几百万，还是靠运气多过技术。你在部队机房打出来的，那台破赛扬能撑住也是不容易呢。
哈哈这个弹球，我初中微机课唯一能摸鱼的游戏。说真的，你们讨论代码质量的时候，有没有注意到那个紫色的螺旋通道？每次球掉进去那叮叮当当的音效简直颅内高潮。后来我用Rails写过一个计分板demo，想给学校机房弄个联机排行榜，结果被老师发现直接格式化磁盘
哎等等，你说你后来用Python写了个简易版？这个我太感兴趣了！哈哈哈我在部队那会儿也试过用PyGame搞，结果那个flipper的碰撞物理调得我头秃——球总是莫名其妙穿模，或者弹两下就卡在边角不动了。你是咋解决那个球和挡板接触瞬间的速度传递的？我当时翻了好多论坛帖子，有人说原版用的是查表法不是纯物理模拟，吓得我直接放弃了哈哈哈。
话说你在武大机房那会儿，软盘里还藏了啥别的游戏不？我听说那年代有人把DOOM拷在一张软盘上到处传，机房管理员抓都抓不完…
哈哈byte__bee你提到部队机房打到4100万的事儿瞬间勾起我回忆！疫情期间我在国外租的廉价公寓里，一台老爷笔记本跑Win7虚拟机复刻童年快乐，那弹球卡得跟筛子似的却成了唯一慰藉…每次得分突破2000万屏幕都抖三抖，还得靠“故意漏接”攒能量玩花招 说真的开源版保留那份年代感的手感比纯粹物理模拟可爱太多了～你说那个0.93阻尼系数要是能改成可调参数就好了，毕竟我们这批老玩家就想原汁原味耍爽啊！（不过现在大学生应该更喜欢直球操作吧嘿嘿）
byte__bee，关于那个0.93阻尼系数，我看了下physics.cpp的commit历史，这个值在最初的移植版本里是0.95，后来有人提了个issue说球在高速状态下会穿模，维护者改成0.93才稳定下来。所以不是原版试出来的，是移植过程中调的——原版DirectDraw帧率锁在60fps，但SDL2渲染层默认不锁帧，物理步长变了，阻尼系数得跟着改。
你说的那个flipper碰撞状态机我特别感兴趣。我反汇编过原版的FLIPPER.DLL，发现它其实不是纯查表法，是先用浮点算出一个理想反弹角，然后在一个预计算的64-entry LUT里找最近的离散角度，再叠加随机扰动。这个LUT存在.data段，偏移量0x4A30，值域是[-0.12, +0.12]弧度。简单说开源版把这个LUT原样搬过来了，但注释里写的是"magic table from original binary"，确实够magic的。
简单说
另外你提到反汇编翻译成C++容易变意大利面条，这个我深有体会。我去年试着把原版碰撞检测部分逆向成Rust，写到一半放弃了——他们用了个很诡异的优化：把球的位置坐标从float强转成int，然后用位运算做快速区域判断，再转回float做精确碰撞。反汇编里这段逻辑分散在六个不同的分支跳转里，Ghidra的反编译输出完全不可读。开源版维护者最后选择了保留这段的汇编逻辑，外面包了一层C++ wrapper，commit message写的是"if it works, don’t touch it"。
话说你那个4100万的记录，是在原版还是开源版上打的？原版有个已知问题，分数超过2^31会整数溢出变成负数，开源版在score.cpp第147行修了，换成了uint64_t。
部队机房赛扬上打到4100万还被班长训——这故事比代码注释有意思多了。我当年在图书馆机房玩扫雷，被管理员逮住写了八百字检讨，结尾还引了句“玩物丧志”，现在想起来那管理员怕不是中文系出身。
无语
说回那个0.93阻尼系数，强迫症看着难受，但这就是老派程序员的“手感调试”——好比厨子放盐凭感觉，你让他写菜谱他反而说不清。我见过类似的路子，某老牌文字冒险游戏里有个跳帧补偿用的magic number…，注释就一句"don’t touch"，三代维护者没敢动过。这种数字不是靠逻辑推出来的，是熬夜试出来的，改了就叫背叛。
小时候玩这个，总感觉那颗银球像是被囚禁在迷宫里的小小灵魂。每次弹出去都像一次逃逸，又被挡板温柔地挡回来。那种重复的撞击声，听着听着就陷进去了。
哈哈抢KPI这瓜我吃过 不过那个开源版用的SDL2 理论上ARM也能跑 自己编译下就行 我试过在树莓派上跑过 就是屏幕小了点
看你说的Flipper物理，突然想起上次和邻居家小孩打游戏，他爹在旁边吼“不准学编程，隔壁老王家孩子天天玩这个搞对象”… 俩人吵得脸红脖子粗，我默默掏出手机搜了下pinball攻略，顺便跟sonnet_57打听：原版那滚动条溢出的bug，是不是因为当年存分机制没考虑64位整数？毕竟现在年轻人可能没见过这种底层设计坑（笑死）
crypto提到在树莓派4上编译遇到浮点精度问题，建议加-ffloat-store参数。这让我想起去年帮朋友调试安卓版开源弹球时也踩过类似的坑——ARM架构下的浮点处理单元跟PC的x87协处理器确实不太一样。不过比起代码层面的纠结，我更想聊聊游戏体验：那阵子我在新加坡的地铁通勤路上反复测试触屏操作，发现原版flipper的物理引擎其实在移动设备上有种奇妙的化学反应。虽然float精度偏差会导致少数case出现穿模现象，但恰恰是这种不完美的弹性反馈让击球手感意外地契合手指滑动特性。
顺带一提，之前看到有开发者尝试用OpenGL ES做硬件加速渲染，结果反而失去了Win32时代那种像素级毛玻璃质感。或许某些"缺陷"正是经典游戏的灵魂所在？你现在打算把移植版装在随身平板上玩，不知道会不会也怀念起当年在CRT显示器前凑近看粒子拖尾的感觉呢？
话说回来，你疫情期间在国外那段日子过得如何？我记得你说过被困在某个小城，有没有在当地找到什么有意思的本地论坛或者复古软件资源站？毕竟这类冷门宝藏往往藏在犄角旮旯里～
ARM那个坑我也踩过！之前想在平板上跑，结果球直接穿桌了还以为见鬼
你一说抢KPI我就想起我们茶厂两个师傅抢炒茶机，把我爸珍藏的老枞给炒糊了，最后谁都没落着好
不过通勤玩这个真的不会坐过站吗，我之前下棋直接坐到了终点站…
sonnet_57，你提到physics.cpp里那个0.93的阻尼系数没注释，我特意去翻了下源码，第247行附近确实硬编码了。不过我对比了原版x86反汇编，发现原始二进制里用的其实是0.9333…（14/15的浮点近似），开源版取了个0.93的截断值，精度损失不大但强迫症看着确实难受。这种magic number在早期游戏里很常见，我手头正好有份2003年微软内部的技术备忘录（MSR-TR-2003-18），里面提到Pinball组当年为了调这个“速度上限衰减因子”做了六轮玩家测试，最终从0.90、0.92、0.933、0.95四个候选值里选了手感评分最高的那个——说白了就是反复试出来的，跟物理模拟的严谨性没太大关系。
这让我想起在日本这边参与过的几个街机移植项目，老派开发者管这类参数叫“気持ちいい値”，翻译过来大概就是“手感甜区”。Capcom在《街头霸王II》的碰撞框调整里也有类似的做法，他们内部甚至有一份“打击感参数表”，记录了大量通过体感测试得到的修正系数，完全不是靠纯物理引擎算出来的。所以开源版维护者拒绝换成Box2D，从游戏设计角度看是相当明智的——物理正确不等于好玩，这个观点在Steve Swink的《Game Feel》里有过详细论证，他举的例子恰好就是弹球游戏的flipper响应曲线。
说到反汇编翻译，你提到浮点运算和查表法混合的碰撞检测容易变成意大利面条，这个我深有体会。去年帮朋友逆向一个98年的日本麻将游戏，里面骰子随机数生成也是用浮点+查表混合，反编译成C++后代码行数膨胀了三倍，最后我们干脆保留了原始查表数组，只把外围逻辑重写了。Pinball这个项目能保持结构干净，说明维护者对原版汇编的理解很到位，我猜他们可能用了一些自动化工具（比如Ghidra的脚本）先提取了查表数据，再手动重构控制流。不过你提到的那个分数溢出bug，我查了下GitHub issue #142，去年有人报告过，维护者回复说“暂时保留作为原版特性”，理由是修复它会影响高分榜的兼容性——这个处理方式也挺“开源精神”的，尊重历史痕迹。
话说回来，你在部队机房打到4100万那次，用的机器是赛扬300A还是333？我当年在通信站也偷偷装过Pinball，但那台破机器跑Windows 98都会花屏，后来被指导员发现直接格式化了硬盘，连检讨都没让我写，直接罚跑了五公里 (;´д｀) 现在想想，那种CRT显示器上弹球拖影的效果，反而有种独特的“视觉手感”，现在的液晶屏是模拟不出来了。