兩套互補、不能混為一談的機制
Dynamic Drop-frame 是逐 LCD frame 的 deadline scheduler。若估算新場景無法在安全期限前完成，就保留上一張已完整提交的 OAM、VRAM 與背景狀態，避免把半套畫面交給顯示硬體。
Adaptive presentation dispatch 是建立在 Drop-frame 上的壓力狀態機。它觀察連續 deadline 壓力與真正的 missed VBlank；確認不是一次冷快取尖峰後，才把完整場景建構鎖到較低且規律的 cadence，避免不穩定地連續超時。
哪些工作永遠不能被省略
Adaptive 只捨棄已被較新狀態取代、尚未送出的中間畫面。下列 authoritative state 仍按原順序執行：
- 玩家輸入、移動、武器 cooldown 與能量；
- 敵人事件、Boss 流程、碰撞、傷害與掉落；
- 關卡位置、script 分支與 RNG 呼叫順序；
- 每個實體 VBlank 的 Maxmod 音樂與音效服務。
因此畫面在壓力下可能維持上一個完整 frame，但下一張出現時會直接反映正確時間點，不會因少畫一張而讓關卡慢動作或改變戰鬥結果。
三段壓力狀態與 17.4 FPS 下限
Tyrian 的 Normal speed 約為 34.8 logic tick/s。正式設定將一張刻意輸出的場景限制為最多代表兩個 source ticks，因此 Medium／Severe 的目標下限約為 17.4 FPS。早期 Severe 曾允許三 tick、約 11.6 FPS；實機觀感過於不連續，現行程式已從型別與編譯檢查上禁止回到該設定。
只對持續壓力反應，不因單一尖峰抖動
一般 gameplay 必須累積至少 4 點 deadline 壓力及 2 次 missed VBlank 才進入 Adaptive；壓力達 8 或 missed VBlank 達 4 時標記為 Severe。lava／water 場景因波紋還占用顯示時序，在確認 2 點壓力及 1 次 missed VBlank 後可提早進入 Severe，但仍受相同 17.4 FPS 下限約束。
- 連續 16 張完整 render 都低於 150,000 cycles 才退出，避免 cadence 來回跳動；
- 最多保留兩個 pending logic ticks，超過就強制產生新場景；
- 背景 ring row、關卡狀態轉換及 freshness 條件永遠可以強制 render；
- 一般 Boss、爆炸與複雜武器使用同一套全域量測，不靠 per-level 特例。
歷史 A/B：一般非 wave 關卡也能受益
Episode 2 Section 1 的 600-VBlank 壓力測試，在遊戲邏輯更新、RNG、玩家子彈數與音訊結果完全相同時，加入 Adaptive 後 missed VBlank 由 165 降至 93，減少 43.64%；平均 loop work 由 224,781.42 降至 186,695.33 cycles，減少 16.94%，兩版 audio frame loss 都是 0。
安全網不是免除最佳化的魔法
GBA 每個 LCD frame 約有 280,896 CPU cycles。若單一不可切割的 render、解碼或 cache miss 本身已超過這個預算，Drop-frame 與 Adaptive 只能避免它再和其他昂貴 phase 疊在一起，不能縮短該工作本身。這類瓶頸仍要以 build-time 預處理、DMA、cache、IWRAM／ARM leaf kernel 或演算法改善解決。
正式版因此同時開啟 Dynamic Drop-frame、全域 Adaptive presentation dispatch 與 wave 快速進入策略。關閉 Adaptive 只用於受控 A/B；它不是一般 Release 選項，也不套用到靜態前端選單。
最終原則
過載時可以少交付一張已過時的畫面，但不能少算一次會改變遊戲結果的工作。把 authoritative simulation 與可被取代的 presentation 分開，才讓 GBA 在極端火力下維持音樂與正確流程，同時把視覺退化限制為穩定、可量測且有最低下限的呈現頻率。