编程与软件工程blog.moertel.com
一个绝妙的老式游戏编程技巧
A Great Old-Timey Game-Programming Hack
2013 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Tom Moertel 回顾了一个老式游戏编程技巧：在内存极其有限的年代，他的朋友通过只重绘屏幕上发生变化的区域（而非整屏刷新），让游戏在慢速机器上流畅运行。文章讲述了当年在性能受限的机器上想尽办法压榨性能的故事。
为什么经久不衰：它记录了资源受限时代程序员的巧思与乐趣，在抽象层堆叠的今天读来别有启发，也解释了 Carmack 等经典游戏技术的由来。
HN 评论精选
独立重新发明了自适应局部刷新技术，与 Carmack 的做法不谋而合
这让我想起高中时用 Pascal 写贪吃蛇的经历：整屏重绘导致闪烁严重，后来我改为只重绘每帧变化的部分，游戏就不闪了。多年后才发现，这基本就是 Carmack 在老游戏里用的 Adaptive Tile Refresh 技术。
Morgawr查看英文原文
This reminded me of a game programming hack I did back in highschool. I had just started a school course on Pascal and decided to code a small game of snake, just for fun. I knew very little about actual programming, I was a real novice. The game was very simple, it was running in a windows console (cmd) without any graphics, the actual assets were ASCII art. The grid of the game was represented with asterisks and the snake was dots with a smiley face (one of those weird ASCII symbols nobody knows why it's there). Every game update I would redraw the whole grid, snake and the comma that was used to output the food. The problem was that this was terribly slow, it flickered like crazy and it was unplayable. I was very sad because my game was working but unplayable for anybody so I tried to engineer a way to make it stop flickering. The solution came when I found out about a couple of functions in pascal that let you clear a specific character in the console at a specific X,Y coordinate and write another character that that coordinate. What I ended up doing was keep track of all the changes in the game for each frame (snake movements, food position) and just re-draw only the portions of screen that had changed. This was great, no more flickering and the game was playable. (Nobody really played it because nobody cared but I was really proud of it). Found out years later that this approach is pretty much what Carmack did in his old games: Adaptive Tile Refresh[1] [1]https://en.wikipedia.org/wiki/Adaptive_tile_refresh
现代抽象让代码行为难以完整理解，与过去的简单机器形成对比
我喜欢这句话：当年的挑战不是复杂度，而是把想法塞进慢得装不下大多数想法的机器里。如今抽象层层叠加，虽然更方便了，但很难再对代码的实际行为有完整的心理模型。
tbirdz查看英文原文
>The challenge wasn't overwhelming complexity, as it is today. The challenge was cramming your ideas into machines so slow, so limited that most ideas didn't fit. I like this line right here. It does seem like we've piled on abstraction after abstraction in these days. Sure this does make things easier, but I think things have gotten so complex that it's much harder to have a complete mental model of what your code is actually doing than in the simpler machines of the past.
嵌入式开发中资源受限下的优化乐趣依然存在
我也经历过这些！在电子工程专业里，我们曾彻夜把 Viterbi 编解码器塞进小小的 FPGA，在 8051 上挤下复杂的温控程序，在老 ARM 上用汇编写 128kHz 录音器。嵌入式领域里这种疯狂优化的乐趣依然活着。
caster_cp查看英文原文
Loved the story! Mostly because I lived this stuff, and I'm 25 years old :p. In my Electronic Engineering graduation we had three professors crazy about assembly and slow PCs (in fact, FPGAs and microcontrollers). I remember the nights I spent awake trying to make a Viterbi Encoder/Decoder fit into a tiny FPGA, cramming a complex temperature controller (while reading sensors, commanding motors, and handling the input/output) in an 8051, or programming a 128khz sound recorder in assembly on an (old as hell) ARM, while communicating to a PC, showing info on a LCD and doing all the filtering digitally (the only analog stuff we were allowed to use were an anti-aliasing filter and the input/output conforming circuits). Ah, the crazy filters we devised to use all the old ARM's juice. I lost myself there, but my main point is: in electronics (embedded systems, mainly) all this beautiful joy of crazy optimizations is still alive :D
文中提速百分比的计算方法有误，实际提升被夸大了
作者犯了常见的百分比计算错误：提速百分比应该用 (t1-t0)/t0 计算，而不是除以新时间。比如 157 降到 98 周期是提速 38%，不是 60%；总共省下 1200 周期实际是提速 42%，不是 70%。
couchand查看英文原文
This is a really neat article. One thing: the author falls victim to a common, unfortunate mistake in calculating the percentage gains: ...120 cycles. That’s a 30-percent speed-up. and then ...98 cycles. Compared to the original code, that’s 60 percent faster. The right way to calculate this figure is (t1 - t0)/t0, rather than the author's formula which seems to be (t1 - t0)/t1. For instance: (157 - 98)/98 = 60%, but the actual amount is (157 - 98)/157 = a 38% speed up. A heuristic: 60% of 157 will be much more than 60 (since 60% of 100 = 60), which means a 60% speed up would reduce the speed to below 97 cycles. It gets even more misleading the more efficient it gets: Adding up the cycles, the total was just 1689. I had shaved almost 1200 cycles off of my friend’s code. That’s a 70 percent speed-up! The author has 1200/1689 = 71%, but the correct numbers yield 1200/(1689+1200) = 42%. Not that I don't think these are significant gains, but it's just misleading to label them like this. If you've removed less than half the cycles, there's no way you've seen a 70% speed up.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选