TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Serialization-Based Undo

76 点作者 prideout超过 3 年前

5 条评论

rocqua超过 3 年前
Essentially the idea here is not to muck about with diffs or event &#x2F; command based sourcing.<p>Just store each internal state you might want to recover, in full. Except use compression to store the states you want to recover. In this article, the compression is done based on the &#x27;initial state&#x27;. I imagine there is flexibility on maybe &#x27;checkpointing&#x27; some states once the difference becomes to big. Maybe do the compression not with a prefix of the &#x27;initial&#x27; state but with a prefix of the entire undo history.<p>All this requires is halfway efficient serialization &#x2F; deserialization implementation, and access to Zstandard (I guess other compression algorithms also work).<p>I think the key trick here is that, if you can serialize to bytes, you can just use compression methods as a replacement for storing diffs or other complicated methods for de-duplicating data. This could be a really powerful method to really easily keep a state history without high performance cost. From the developer p.o.v. its like you have each previous state at your fingertips. Whilst in reality the compression ensures it is stored efficiently.
评论 #28906060 未加载
steeleduncan超过 3 年前
It is interesting to compare this to Jonathan Blow&#x27;s talk on the rewind system in Braid [1].<p>This stores complete game states using a compression library to keep memory under control, whereas Braid stored a combination of keyframes, and diffs from those keyframes, to avoid using a compression library.<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=8dinUbg2h70" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=8dinUbg2h70</a>
Strilanc超过 3 年前
This is the design I also usually use for undo&#x2F;redo. Actually for small interactive editors I like to go further and make it so that anytime you do anything the program serializes its state and loads it back in. This is sometimes too costly but has unexpected reliability benefits. It makes sure your serialization code is well exercised, it ensures most of your program states are linkable&#x2F;nameable, and also it&#x27;s sort of like every time you do anything you&#x27;re restarting the program. There&#x27;s much less implicit state that can cause problems. And as a fallback if you do get the program into a bad state you can just hit undo and you&#x27;re back into a good state.
catern超过 3 年前
This is cool, but I don&#x27;t understand the justification for why a more traditional &quot;just store a sequence of events&quot; undo system wasn&#x27;t possible. As the author says in the post on the scripting system, the game scripts access virtual interfaces. Those could just record the methods called before forwarding them on - doesn&#x27;t matter that the scripts make arbitrary method calls. It seems to me that there&#x27;s nothing inherent to &quot;the level script is arbitrary code rather than a list of commands as data&quot; that makes that style of undo impossible.
评论 #28904670 未加载
评论 #28904657 未加载
评论 #28914877 未加载
hoseja超过 3 年前
&gt;but since I’m not a fan of C++ streams, it doesn’t use them internally<p>Nobody does, it&#x27;s one of the worst mistakes of C++.
评论 #28904896 未加载