MOV is where the two engines diverge most, and the page should lead with that - #282
Merged
Merged
Conversation
…ith that Asked whether v1 and v4 MOV differ more than the docs let on. Checked, and the answer is in two parts. **The page itself was right.** `mov.md`'s DreamFactory 1 section is the most thorough v1 account in the whole doc set — seven differences, each with the `DF.EXE` read behind it — which is why the alignment pass never touched it. Every claim in it checks out against `mov-v1.ts`, including the two gaps it admits to (`+0x06` is not wait flags and the loop never reads it; `+0x00` is the hotspot count and the reader walks past it instead). The census figures are better than accurate — `dust/tests/movies.ts` pins 152 frames of 6717, 69 segments of 185, 50 films of 160 against the disc, so that paragraph cannot drift without going red. **The framing was wrong, and it was mine.** "The same machine ... with everything v4 factors into per-frame logic containers kept inline" reads as a packaging difference, and so did the one-line summaries I wrote for it in `architecture.md` and Dust's index. It is not a packaging difference. The MODEL survives — a chain of segments, a frame state machine, hotspots, chains — and almost every mechanic under it differs, more of it behaviour than layout: advance is an authored goto where v4's is implicit, a frame can block until the sound it started has finished, hotspots are typed variable-stride records rather than a region table, and two palette indices are keyed out of the blit. Of the formats the two engines share, this is the one that diverges most, and all three places now say so first. Dust's "what is different, in one paragraph" left films out entirely, which was the same mistake in the place a reader meets it earliest. One rule was genuinely missing from the list: the segment teardown follows the next-segment pointer only when playback stopped ON the last frame (0x404b9c), so a mid-film exit drops the rest of the chain. v4 reaches the same place by the narrower route of ESC clearing the pointer. Behaviour, not layout, and the kind a port gets wrong by inventing a return. No code changed. VitePress build clean, every anchor and link resolving. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You asked whether v1 and v4 MOV differ more than the docs let on. Checked it, and the answer is in two parts.
The page itself was right
mov.md's DreamFactory 1 section is the most thorough v1 account in the doc set — seven differences, each with theDF.EXEread behind it. That is why the alignment pass in #279 never touched it, unlike SET and audio, which needed their v1 sections written from scratch.I verified it rather than assuming. Every claim checks out against
mov-v1.ts, including the two gaps it honestly admits to:+0x06is not wait flags and the movie loop never reads it, and+0x00is the hotspot count while the reader walks past it instead (disagreeing on 422 of 525 frames, always by finding more).The census figures are better than accurate — they are guarded.
dust/tests/movies.tspins 152 frames of 6717, 69 segments of 185, 50 films of 160 against the disc, so that paragraph cannot drift without a red test.The framing was wrong, and it was mine
That reads as a packaging difference, and the one-line summaries I wrote in
architecture.mdand Dust's index repeated it. It is not a packaging difference.The model survives — chain of segments, frame state machine, hotspots, chained films. Almost every mechanic under it differs, and more of it is behaviour than layout:
action 2, targetgoto; a loop is a backward targetmax(hold, what's left)Of the formats the two engines share, this is the one that diverges most — and all three places now say that first. Dust's "what is different, in one paragraph" left films out entirely, which was the same mistake where a reader meets it earliest.
One rule was genuinely missing
The segment teardown follows the next-segment pointer only when playback stopped on the last frame (
0x404b9c), so a mid-film exit drops the rest of the chain — v4 reaches the same place by the narrower route of ESC clearing the pointer. Behaviour rather than layout, and exactly the kind a port gets wrong by inventing a return, whichmov-v1.tsrecords having done once already (the wardrobe closing between the diary and the page-reading flat).Scope
Docs only, no code. VitePress build clean, every anchor and link resolving.
🤖 Generated with Claude Code