原生程式 / 互動案例 / 閱讀約 20 分鐘
DX-Ball：能聽出磚塊在哪一側嗎？
使用 REA 分析 DX-Ball 的立體聲聲像函式。追蹤指令與常數，體驗聲音示範，並測試還原的計算規則。
本頁內容
01. 拆解之前，先試一試
先按「左側」，再按「播放短音」；在右側重複一次。現在把縮放係數設為 −1：位置沒動，聲音卻換了方向。設為 0 時聲音居中。上方數值來自還原的演算法，下方聲音只是示範。
trunc((320 × 1.5625 − 500) × 1) = 0
戴上耳機更容易聽出位置。只有按下播放按鈕才會發聲。
數值規則依據報告。聲音是正規化的 Web Audio 示範，並非原版音訊引擎。
一個將位置換算為聲像的函式、一段可聽的示範，以及將重建結果與原機器碼比較的方案。
分析之前實驗建議使用耳機。若要進行二進位分析，需要你自己的英文 DX-Ball 1.07 可執行檔案和原生分析後端。報告提供了目標摘要和已紀錄證據。 設定 REA →
02. 從磚塊撞擊追蹤到聲音呼叫
從可見事件開始：螢幕一側的磚塊被擊碎。從聲音呼叫反向追蹤，確定呼叫方傳了什麼值。看似座標的數字，也可能是格子索引、偏移量或縮放後的位置。
複用上游報告中的地址前，先確認版本完全匹配。報告中的目標輔助函式從 0x406400 開始。如果可執行檔案不同，應定位對應行為，不要預設相同地址仍適用。
用 REA 分析與報告匹配的 DX-Ball 1.07 可執行檔案。從官方報告定位的聲像輔助函式開始，分析呼叫它的磚塊撞擊邏輯。說明呼叫方如何建構引數。引用呼叫點指令和輔助函式的輸入載入指令。不要預設反編譯函式簽名完整。03. 虛擬碼丟失引數時，檢視指令
即使機器指令完整，反編譯器仍可能生成很短且資訊不足的函式本體。結合檢視堆疊載入、浮點運算、引用資料和整數轉換。要求給出每個常數的原始位元組，以及型別和位元組序。
紀錄中的計算式為 trunc((x × 1.5625 − 500) × scale)。呼叫方提供橫向位置。注意最後的轉換：向零截斷會影響負數結果，與向下取整不同。
- 輸入從哪裡進入函式？
- 哪些被引用的位元組解碼後對應各個浮點常數？
- scale 是引數、已儲存的狀態，還是固定字面值？
- 在測試的輸入範圍內，轉換會截斷、捨入、飽和處理，還是溢位？
04. 謹慎地讓數字變成聲音
先實作數值函式，檢查左、中、右三個位置，再加入會產生小數的相鄰位置。當 x = 319、scale = 1 時，原始值是 −1.5625，整數結果為 −1。如果向下取整，就會錯誤地得到 −2。
聲音按鈕把 pan / 500 對映到 Web Audio 立體聲聲像器，並將試聽值限制在 −1…1。這能直觀呈現方向，但不會重現 DirectSound 的音量曲線或原遊戲音效。顯示的整數值不會被限幅。
獨立實作紀錄中的位置到聲像換算。分別測試 x = 0、1、319、320、321、640，以及 scale = 0、0.5、1、20、−1。保留向零轉換。製作由使用者觸發的短音試聽，單獨註明正規化處理，不能把試聽的限幅當成還原的數值行為。05. 理解透過 3,205 項驗證能證明什麼
專案報告將 641 個整數位置與五種縮放設定組合，與原 x86 函式進行了比較；還單獨報告了在指定歷史環境中得到 63 位元組編譯匹配。這是兩種不同的驗證：選定輸入的行為一致，以及生成的機器碼一致。
自己分析時，儲存每組輸入和兩邊輸出。遇到差異，把它縮小為最小失敗用例。只有明確編譯器版本、選項和重定位處理後，再嘗試位元組匹配。本站 JavaScript 測試覆蓋紀錄中的算術規則，並未重複原二進位比較。
06. 比較已知結果
將這些結果作為明確的檢查點。與它們一致，只能支持這一小段規則，不能證明與整個應用程式相容。
| 螢幕 X / 縮放係數 | 整數聲像值 | 意義 |
|---|---|---|
| 0 / 1 | −500 | 左邊緣 |
| 319 / 1 | −1 | 負數截斷 |
| 320 / 1 | 0 | 居中 |
| 321 / 1 | 1 | 正數截斷 |
| 640 / −1 | −500 | 反向縮放 |
| 640 / 20 | 10,000 | 數值結果超出音訊試聽範圍 |
將兩個檔案儲存在同一資料夾，用 Node.js 執行驗證指令碼，無需安裝套件。
node check-case-labs.mjs07. 到底驗證了什麼？
3,205 組原 x86 比較和 63 個匹配位元組，都是上游對一個函式的驗證結果。本站用有理數參考實作，在相同的位置/縮放組合上測試獨立算術實作。我們沒有執行 DXBALL.EXE、重建整款遊戲，也沒有重現音訊引擎。
來源： REA 的 DX-Ball 證據報告 · 固定版本的已維護聲像函式。教學、圖示和瀏覽器實驗均獨立編寫。