今日回顧與計劃

在今天的直播中，我們將繼續進行游戲的開發工作，目標是完成資產文件（pack file）的測試版本。目前，游戲的資源（如位圖和聲音文件）是直接從磁盤加載的，而我們正在將其轉換為使用自己創建的資產文件格式。我們已經編寫了大部分的代碼，現在的任務是完成寫出資產文件的測試代碼，這樣我們就可以將其加載到游戲中。

在昨天的代碼中，我們通過測試資產構建器（test asset builder）已經實現了寫出大部分的資產文件頭部，唯一缺失的部分是資產數組。今天，我們的目標是繼續完成寫出資產數組的工作。除了資產數組，我們還需要將實際的資源內容（如位圖和聲音文件）也寫入文件中。這樣做是為了確保資產文件不僅記錄了資源的基本信息，還能正確包含資源的實際數據。

資產文件格式的設計如下：我們將每個資產（無論是位圖還是聲音）作為一個單獨的條目存儲，并通過一個數組記錄它們的位置信息、標簽以及數量。在資產的具體信息中，位圖將包括其尺寸和對齊方式，而聲音則會包含樣本數量及是否與其他聲音資源關聯等信息。

接下來，我們需要完成這些數據的寫入工作。我們之前已經完成了其他部分的編寫，只剩下將資產數組寫入文件了。對于其他數組的寫入，我們采用了將數據保存在內存中的方式，并且確保這些數據的存儲格式與文件中的格式一致。因此，現在我們只需要按照相同的方式將資產數組寫入文件，確保它們與其他數據項的格式保持一致。

整體來說，這部分工作非常直接，主要是確保數據的正確存儲與輸出。

文件是存儲在磁盤上的內存副本

文件和內存其實是非常相似的，文件只是內存的一種永久存儲版本。它們本質上都是一串字節，唯一不同的是，文件是被保存在硬盤或固態硬盤等設備上的，而內存則是暫時存儲在計算機的RAM中。當我們進行寫操作時，實際上就是將內存中的一塊數據寫入到硬盤上。之后，游戲中需要用到這些數據時，可以再從硬盤中讀取回來，恢復成原本的內容。

在寫入數據時，我們并沒有做特別復雜的操作，簡單地將內存中的一塊數據寫入到磁盤上。在資產文件的寫入過程中，我們的目標是將這些數據按順序存儲到文件中，這樣就能在以后根據需要將它們加載回內存。對于每個資源（如位圖），它們的存儲位置是相互依賴的，因為每個資產在文件中的位置是根據之前寫入的數據大小來確定的。如果第一個位圖占用了100個字節，那么第二個位圖的數據就會緊接著存儲在第一個位圖后面，而第三個位圖的位置又會依賴于前兩個位圖的大小。因此，在寫入資源之前，必須先計算出每個資源在文件中的具體位置，這樣才能確保它們按照正確的順序存儲。

目前，還沒有準備好資產數組，因為尚未處理所有資產的存儲位置。為了確定每個資產的存儲位置，需要遍歷所有資產并計算它們在文件中的偏移量。因此，處理這些文件寫入的方式有兩種選擇。最簡單的做法是按照順序寫入資源數據，然后在寫完所有資源之后，再更新文件中的資產數組，記錄每個資產的偏移量。這種方法比較直觀且易于實現。

存儲資產數組和資產的兩種方式：

有兩種方法可以處理這個問題。一種方法是先將所有資產寫入文件，但在文件中留出空間以便之后寫入資產數組。然后再回到這個位置，將資產數組作為一個整體寫入。我覺得這個方法比較麻煩，可能不會使用。我打算采用更簡單的方法，就是在寫入資源數據的同時，逐個寫入資產數組。

具體做法是，我們已經知道了資源從文件中的哪個位置開始，因此可以根據這個位置加上資產數組的大小，計算出下一個可用的文件字節位置。這樣，在寫入資產的同時，就可以同步寫入資產數組，因為我們已經明確了每個資產在文件中的存儲位置。

1) 在寫入每個資產后來回處理

打算采用手動遍歷資產集的方法，從資產索引0開始，逐一遍歷所有資產。每次遍歷時，使用seek操作來定位文件中的當前位置。雖然這種方式效率較低，但考慮到這是測試代碼，且只會在本地運行，我們并不關心它的效率。如果以后成為生產環境中的問題，再考慮優化也不遲。因此，這段代碼的效率并不重要。

在操作中，需要自己跟蹤文件流的位置。對于每個資產，先跳轉到文件中相應的部分，然后寫入該資產的實際數據。如果是位圖，就寫入像素數據；如果是音效，則寫入聲音樣本數據。完成后，再跳回資產數組部分，將相關信息寫入數組中。

2) 寫入所有資產，然后返回寫入整個資產數組

在討論如何處理資產數組時，最初的想法是先跳過資產數組的位置，通過一個 fseek 跳到文件的適當位置，然后再去寫入資產數組。然而，在重新考慮之后，發現其實這樣做并不比原來的方式更簡單。實際上，最合適的方式是通過一次 fseek 將文件指針移動到資產數組的位置，然后順序寫入所有資產數據，再返回到資產數組的位置并將它寫入。

這樣做的原因是，當通過 fseek 調整文件指針時，不必擔心給定確切的寫入位置，因為C語言的文件操作API（如 fwrite）會自動在當前文件指針的位置繼續寫入數據。這種方式簡化了寫入過程，并且避免了提前告知操作系統寫入位置的麻煩。

具體操作流程是，首先跳過資產數組的位置，然后依次寫入每個資產數據（如位圖或音頻等）。寫入完所有資產后，再返回到原來的位置，將資產數組寫入文件中。這樣做可以避免不必要的文件操作，同時效率更高。

總之，通過這種方法，首先寫入所有資產，之后返回到資產數組的位置進行寫入，而不必提前占用不必要的空間。這種處理方式簡化了文件操作，也符合我們對效率的要求。

C運行時庫函數：fseek

fseek 是一個用于移動文件指針的函數，它可以在不寫入任何數據的情況下調整文件的位置。通過 fseek，可以指定文件指針的移動方式，確保數據按正確的位置讀寫。具體來說，fseek 有三個參數，首先是文件句柄，指定當前操作的是哪個文件流；其次是希望移動的字節數；最后是移動方式的解釋參數，有三種方式：

1. SEEK_SET：表示從文件的開頭開始，移動到指定的絕對字節位置。例如，如果傳入值為5，則文件指針會移動到文件的第5個字節。
2. SEEK_CUR：表示從當前文件指針的位置開始，按給定字節數進行偏移。如果傳入的是正數，文件指針會向后移動；如果是負數，則會向前移動。
3. SEEK_END：表示從文件的末尾開始，向文件的起始方向進行偏移。這通常用于在文件末尾進行操作，或者回退文件中的數據。

在實際操作時，首先需要知道資產數組的大小，利用這個大小來計算跳過資產數組所需的字節數。然后，通過 fseek 從當前文件指針的位置開始，跳過指定的字節數，接著繼續寫入每個資產數據。完成所有資產的寫入后，再通過 fseek 將文件指針返回到資產數組的位置，繼續進行資產數組的寫入。

這樣，文件的寫入過程就能夠按預定順序進行，同時避免了不必要的重復計算和文件操作。文件指針的精確控制確保了數據的順利存儲。

CRT的fseek不支持64位偏移量

在處理文件寫入時，遇到一個問題，即文件的偏移量需要處理大文件。C語言的標準庫中并不直接支持64位的文件偏移量，導致無法處理非常大的文件。不過，由于當前的應用場景并不涉及大文件，因此可以使用標準的偏移量處理方式。

對于大文件，可能需要使用 lseek 等系統調用來處理64位的文件偏移量。盡管如此，由于這是測試代碼，實際在讀取時不會使用這種方式，而是通過Windows的I/O完成端口（IOCP）來進行數據讀取，根本不涉及這種偏移量問題。

在處理文件時，發現一個額外的問題：資產數組（AssetArray）與實際文件中存儲的數據不同。最初創建的資產集合僅僅是一個讀取文件的記錄，但并不是真正要存儲在文件中的數據。因此，需要將資產集合拆分為兩部分：資產來源（AssetSources）和資產數據（AssetData）。資產來源部分僅僅是用于文件的元數據，不需要實際保存到文件中。

通過這種拆分的方式，可以讓資產源（如文件名、類型等信息）存儲在一個數組中，而實際的資產數據（如位圖數據或聲音數據）存儲在另一個數組中。然后，文件的寫入流程就是先寫入資產數據，再將資產源的相關信息存儲到適當位置。

代碼中的具體實現細節包括：

1. 將資產集合拆分成兩個部分：資產源和資產數據。
2. 使用 fseek 定位到文件中的適當位置，跳過資產源部分的數據，直接寫入資產數據。
3. 通過 fseek 返回到資產數組的起始位置，填充資產源的相關數據。
4. 在寫入時，需要注意一些必要的檢查，確保沒有空的資產索引，并進行必要的斷言。

這種方法雖然簡單，但確保了文件結構的正確性，避免了寫入錯誤。最終目標是能夠正確生成包含所有資產的文件，文件大小也需要檢查，確保生成的數據符合預期。

如果一切都按預期執行，測試文件 test.HHA 可能會被正確生成，盡管文件的大小和內容還需要進一步驗證。

將BMP代碼移入測試資產構建器

接下來，進行資產處理的實現。首先，在 game_asset 文件中，現階段仍然保留一些已經不再使用的代碼，這些代碼最終會被刪除。比如之前處理位圖（BMP）文件的代碼，雖然現在它仍然存在，但在未來的版本中，這部分功能將不再需要，因此可以逐步刪除。

在實現過程中，首先把已有的代碼段復制進來，并在確認一切設置正確之后，從 game_asset 文件中移除這些已經不再使用的代碼。目前，項目中的位圖相關代碼仍然存在并未刪除，只是暫時保留，待確認之后再進行清理。

然后進行編譯，查看缺少的部分或者錯誤。檢查一些不再需要的部分，例如 AlignPercentage，這部分數據從未實際使用過，因此可以刪除。類似地，loaded_bitmap 也可以繼續使用，因為它在渲染器中依然有效，但不再需要與位圖文件的直接關聯。

接下來，開始處理文件讀取部分。需要實現 debug_latform_read_entire_file 函數，用來讀取整個文件。這部分將返回包含文件內容及文件大小的結構體，可以叫做 entire_file。ReadEntireFile 函數將接收文件名，并返回包含文件內容和文件大小的數據結構。

為了能夠正確讀取文件，還需要做一些處理。包括引入一些必要的內聯函數（如位圖掃描），可能還需要一些額外的庫（例如 V4 和 srgb 映射相關的函數）。這些部分在讀取文件時會用到，所以必須確保這些函數已經準備好。

綜上，主要步驟如下：

1. 移除不再需要的代碼，比如舊的位圖文件加載代碼。
2. 編譯和調試，檢查缺失的功能或者錯誤。
3. 實現新的文件讀取函數 ReadEntireFile，該函數返回文件的內容和大小。
4. 確保所有依賴的功能（如位圖掃描、顏色映射等）已經正確實現。

此過程有助于逐步清理和重構代碼，最終實現更簡潔、更高效的文件讀取和處理方式。

最終包含數學頭文件

在實現過程中，最初可能覺得不需要涉及數學計算，但實際上發現需要一些數學操作來處理顏色轉換。具體來說，需要實現兩個函數：Linear1ToSRGB255 和 SRGB255ToLinear1，這些函數用于顏色空間的轉換。

考慮到這些數學函數可能會在不同地方被使用，最好將這些函數提取出來并使其可以被整個項目共享。這樣可以避免重復代碼，也能提高代碼的可維護性。

一開始沒有包含這些數學計算函數，可能會讓人覺得有點后悔，但現在考慮到項目的需求，加入這些計算并不會太麻煩，反而可以讓代碼更加清晰和高效。因此，決定將這些數學操作函數集成到項目中，雖然最初沒有想到這一點，但現在看來這樣做會更加合理。

總結來說，主要內容包括：

1. 實現顏色空間轉換的數學函數，如 Linear1ToSRGB255 和 SRGB255ToLinear1。
2. 將這些數學函數提取并使其可以在項目中其他部分共享使用。
3. 重新審視最初的設計決策，意識到加入數學計算是必要的，并且可以提高代碼的整體結構。

將聲音代碼移入測試資產構建器

在實現音頻加載時，首先需要確保能夠加載聲音文件，并處理不同類型的資產。我們通過調用 read entire file 函數來讀取完整的音頻文件，然后判斷當前處理的是哪種類型的資產。如果是聲音文件，就會調用 load wave 函數來加載它。對于位圖文件，調用 load BMP 函數來加載。加載完成后，我們需要處理文件中的數據，并確保數據的格式與預期一致。

特別是在加載聲音文件時，需要處理樣本的數量、通道數量等信息。有時樣本數量可能未指定，這時會從文件中讀取實際的樣本數量；如果指定為零，則會使用文件中提供的數據。此外，需要關注音頻文件的通道數量，這在處理多通道音頻時非常重要。我們從文件中讀取通道數量，并將其存入相應的數據結構中。

在加載完成后，數據會被寫入一個數組中，這個數組會存儲音頻文件的所有相關信息。然后，音頻的實際樣本數據會被塊寫入到文件中。為了支持多通道音頻，數據寫入過程會使用循環處理每個通道的數據，每個通道的數據大小由樣本數量和單個樣本的大小決定。

最后，所有數據都會被寫入到指定的位置。需要確保在寫入時，所有的音頻數據和相關信息都能夠正確地被保存到文件中，以便后續使用。通過這種方式，確保了音頻文件的加載、處理和保存過程能夠按照預期進行，并且支持不同數量的通道。

CRT的ftell不支持64位偏移量

在文件寫入過程中，我們需要確保在寫入數據之前，記錄文件當前的偏移位置，以便在文件中正確存儲數據偏移地址。由于我們使用的是標準文件操作函數 fseek，但該函數在某些平臺上可能不支持64位偏移，因此需要注意如果未來文件大小超過4GB時，可能會存在兼容性問題。盡管如此，為了當前的測試，我們選擇使用32位偏移值，因為我們知道目前的數據量不會超過此限制。

首先，我們通過 fseek 獲取當前文件的偏移位置，用于記錄數據在文件中的起始地址。這對于位圖和音頻數據都是一樣的，因此我們可以將該操作共享處理，不需要在兩個分支中重復執行。獲取到偏移位置后，我們立即將其記錄到文件結構中，以便后續使用。

接下來，在處理位圖文件時，我們需要將文件中的位圖數據尺寸讀取出來，包括寬度和高度，然后存儲在文件結構中。文件中的 loaded_bitmap 結構僅包含寬度和高度，因此我們只需要直接讀取并存儲這兩個值即可。在讀取寬度和高度之后，我們需要確定數據的內存大小，以便進行寫入。由于我們采用的是32位像素格式（每個像素占4個字節），因此數據大小計算公式為：寬度 * 高度 * 4。

數據寫入時，我們再次使用 fseek 獲取當前位置，并將其作為數據在文件中的偏移地址，然后將整個位圖數據塊寫入文件中。我們通過直接寫入內存數據的方式來確保所有數據連續存儲，并保證文件的布局一致。

在處理音頻文件時，操作流程基本相同。首先獲取當前文件的偏移位置，記錄在結構中，然后將所有音頻數據寫入文件。音頻數據的大小由通道數量和樣本數量決定，因此我們需要讀取通道數量和樣本數量，然后將其作為數據寫入的依據。在多通道情況下，我們通過循環處理每個通道的數據，確保所有通道數據都能正確寫入。

需要注意的是，在寫入數據后，我們需要釋放之前分配的內存以避免內存泄漏。這對于音頻和位圖數據都需要進行相同的內存釋放處理，因此這部分操作也是通用的。

此外，我們還需要確保數據在文件中存儲的連續性，因此所有的數據寫入都會嚴格按照文件格式定義執行。音頻數據的偏移地址和位圖數據的偏移地址通過 fseek 獲取，并確保寫入的數據不會出現錯位或重疊的情況。同時，數據寫入時的大小也是嚴格根據數據結構計算得出的，避免寫入錯誤導致文件格式異常。

總之，我們確保了在文件中準確存儲了所有音頻和位圖數據，并記錄了數據在文件中的偏移地址。通過通用的 fseek 獲取偏移位置，并在兩個分支共享該操作，從而避免重復代碼。后續只需確保在加載數據時能夠按照文件結構正確解析這些數據，即可實現文件的加載和存儲功能。

ftell 函數是 C 語言標準庫 (stdio.h) 提供的一個函數，用于獲取文件流的當前位置（也就是文件指針的位置）。在文件讀寫過程中，我們可以通過 ftell 獲取當前文件指針在文件中的偏移量，從而用于記錄數據的起始位置或計算文件大小等用途。

---

? ftell函數的原型

long int ftell(FILE *stream);

? 參數

• FILE *stream：文件流指針，表示當前操作的文件。

? 返回值

• 成功時：返回文件流指針當前位置相對于文件開頭的偏移量（以字節為單位）。
• 失敗時：返回 -1L，表示出現錯誤，比如：
  • 文件流未打開。
  • 文件指針非法。
  • 文件出現 IO 錯誤。

? 說明

• ftell 返回的是 long 類型的值，因此在32位系統中最大只能表示 2GB 或 4GB 的偏移量（long 在32位系統中最大表示 2,147,483,647 或 4,294,967,295 字節）。
• 在64位系統上，ftell 可能仍然只能表示 4GB 范圍內的文件位置。因此如果要處理超過 4GB 的文件，需要使用 ftello 或 ftell64 等函數。

---

? 使用場景

📌 場景1：獲取當前文件偏移位置

如果我們想要記錄當前數據在文件中的起始地址，可以使用 ftell：

#include <stdio.h>int main() {FILE *file = fopen("example.txt", "r");if (file == NULL) {printf("文件打開失敗\n");return 1;}// 獲取文件起始位置，應該是0long pos = ftell(file);printf("文件指針初始位置: %ld\n", pos);// 讀取幾個字符char buffer[10];fread(buffer, 1, 5, file);// 獲取當前文件指針的位置pos = ftell(file);printf("文件指針當前位置: %ld\n", pos);fclose(file);return 0;
}

輸出示例：

文件指針初始位置: 0
文件指針當前位置: 5

解釋：

• 文件指針在讀取5個字節后，偏移量變為5。
• 可以通過 ftell 確定文件中的任何數據的起始位置。

---

? 場景2：計算文件大小

可以通過 ftell 配合 fseek 計算文件的大小：

#include <stdio.h>int main() {FILE *file = fopen("example.txt", "rb");if (file == NULL) {printf("文件打開失敗\n");return 1;}// 將文件指針移動到文件末尾fseek(file, 0, SEEK_END);// 獲取文件末尾的偏移量（文件大小）long size = ftell(file);printf("文件大小: %ld 字節\n", size);fclose(file);return 0;
}

解釋：

• fseek(file, 0, SEEK_END)：將文件指針移動到文件末尾。
• ftell(file)：獲取文件末尾的偏移量，相當于文件大小。

---

? 場景3：獲取二進制數據的起始位置

假設我們在文件中寫入了音頻數據和圖像數據，我們想記錄：

• 音頻數據在文件中的起始位置。
• 圖像數據在文件中的起始位置。

我們可以這樣做：

#include <stdio.h>int main() {FILE *file = fopen("data.bin", "wb");if (file == NULL) return 1;// 寫入音頻數據long audioOffset = ftell(file);fwrite(audioData, 1, audioDataSize, file);// 寫入圖像數據long imageOffset = ftell(file);fwrite(imageData, 1, imageDataSize, file);printf("音頻數據起始位置: %ld\n", audioOffset);printf("圖像數據起始位置: %ld\n", imageOffset);fclose(file);return 0;
}

解釋：

• 在寫入音頻數據之前，通過 ftell 獲取音頻數據在文件中的偏移位置。
• 在寫入圖像數據之前，通過 ftell 獲取圖像數據在文件中的偏移位置。
• 后續在加載文件時，可以通過偏移地址直接跳轉到指定的數據。

---

? 場景4：搭配fseek回到特定偏移位置

如果我們已經知道了數據的偏移地址，可以通過 fseek 配合 ftell 定位文件中的數據：

#include <stdio.h>int main() {FILE *file = fopen("data.bin", "rb");if (file == NULL) return 1;// 跳轉到音頻數據的位置fseek(file, audioOffset, SEEK_SET);// 讀取音頻數據fread(audioBuffer, 1, audioDataSize, file);fclose(file);return 0;
}

• fseek(file, audioOffset, SEEK_SET)：將文件指針移動到 audioOffset 處。
• fread 就能直接讀取音頻數據。
• 同理，可以跳轉到 imageOffset 處讀取圖像數據。

---

? ftell的局限性

📌 1. 32位平臺最大只能讀取4GB文件

在32位系統中：

long int ftell(FILE *stream);

• long 類型最大表示 2,147,483,647（2GB）或 4,294,967,295（4GB）。
• 超過 4GB 的文件將導致 ftell 返回負數或異常值。

📌 2. 解決方法：使用64位ftell

如果處理大文件（超過4GB），需要使用：

平臺	替代函數	類型
Linux	ftello()	off_t (64位)
Windows	_ftelli64()	__int64 (64位)

示例：

#include <stdio.h>int main() {FILE *file = fopen("data.bin", "rb");if (file == NULL) return 1;// 獲取64位文件偏移long long pos = _ftelli64(file);printf("文件偏移: %lld\n", pos);fclose(file);return 0;
}

---

? 總結

功能	ftell	替代方案 (64位)
獲取文件偏移地址	long int ftell(FILE*)	_ftelli64()
最大支持文件大小	2GB 或 4GB	理論無限
通用性	適用于小文件	大文件推薦使用
常用場景	記錄數據偏移、計算文件大小	處理超大文件

---

? 建議

• 如果文件小于4GB：直接使用 ftell 即可。
• 如果文件超過4GB：請使用：
  • Windows：_ftelli64() 或 fseek64()。
  • Linux：ftello() 或 fseeko()。
• 在處理資源文件（如音頻、圖像）時，建議提前記錄數據的 偏移地址，以便快速定位和加載數據。

---

💡 適用場景

使用場景	推薦函數
記錄文件偏移	ftell
獲取文件大小	ftell + fseek
加載文件中特定資源	ftell + fseek
讀取超大文件（>4GB）	_ftelli64()

💡 如果需要，我還可以給你演示如何用ftell處理自定義文件格式（如游戲資源打包文件）！ 🚀😎

防止多個位圖的pitch問題

我們需要確保位圖（bitmap）的stride（步幅）和width（寬度）是相等的。具體來說，位圖的步幅應該等于寬度乘以4（因為每個像素占用4個字節），這樣數據才會是連續的、無填充的，方便加載和使用。

如果我們遇到不符合這種格式的位圖（即每行數據存在額外填充），那么我們就需要在這里編寫代碼來移除這些填充，以保證我們加載的數據格式始終一致。

我們不希望在游戲運行時加載數據時還需要處理各種不同的步幅，因為這會增加加載和處理的復雜性。因此，我們希望所有位圖的數據都是連續排列，即每一行數據長度 = 寬度 × 4，中間無填充。

如果未來我們需要將位圖填充到特定的邊界對齊（比如對齊到16字節或32字節），那么我們也應該在這里添加代碼來處理這種填充邏輯，而不是把這種復雜性推遲到加載時再處理。

將資產數據加載到可釋放內存中

我們現在的任務是確保加載的文件數據在使用完之后，可以通過釋放內存（free）的方式進行回收，避免內存泄漏。目前，我們的LoadWav和LoadBitmap函數在讀取文件數據時，還沒有正確地提供可釋放的內存塊，因此我們需要調整一下它們的實現方式。

首先，我們需要實現一個通用的讀取文件內容的函數，我們將其命名為ReadEntireFile，它的職責是讀取整個文件的內容并返回一塊內存，這塊內存是可以被釋放的，這樣在加載資源時，就不會出現內存泄漏的風險。

---

? 實現可釋放的內存塊

我們定義了一個函數ReadEntireFile，它接收一個文件路徑，然后讀取文件的全部內容，并將內容存儲在一塊內存中返回。同時，我們還需要確保這塊內存可以被釋放，因此我們會在文件讀取完成后，提供一個Free指針 ，用于釋放內存。

我們打算設計類似這樣的結構：

struct FileReadResult
{void* Contents;uint32 ContentsSize;
};

Contents是指向文件數據的指針，ContentsSize是文件數據的大小。

該函數的實現邏輯如下：

1. 打開文件，并確定文件大小。
2. 分配一塊內存，大小等同于文件大小，用于存放文件內容。
3. 讀取文件內容并存放到內存中。
4. 返回文件數據的指針，供調用者使用。
5. 提供一個Free指針，用于在使用完成后釋放內存。

如果文件打開失敗或者內存分配失敗，則返回一個空的FileReadResult，表示讀取失敗。

---

C運行時庫版ReadEntireFile

我們當前的任務是實現一個通用的文件讀取函數，其功能是讀取磁盤上的文件，將文件的全部內容加載到動態分配的內存中，并且保證內存是可釋放的，防止內存泄漏。這個文件讀取函數是核心基礎設施之一，因為我們后續加載的所有資源（比如音頻、圖片、數據文件等），都需要通過它來進行文件讀取。

---

? 文件讀取的基本流程

我們的思路是這樣的：

1. 打開文件：使用fopen函數以二進制模式(rb)打開文件，如果文件不存在或者無法打開，直接報錯并返回空內容。
2. 獲取文件大小：使用fseek和ftell確定文件大小，然后將文件指針復位到起始位置。
3. 動態分配內存：根據文件大小，使用malloc函數分配一塊與文件大小完全匹配的內存。這塊內存將存儲文件的全部內容。
4. 讀取文件內容：使用fread函數將文件內容全部讀取到內存中。
5. 關閉文件：讀取完成后立即關閉文件，避免文件句柄泄漏。
6. 返回內存地址：將動態分配的內存地址和大小打包成一個FileReadResult結構體返回，供調用者使用。
7. 釋放內存：調用者使用完數據后，必須手動調用free函數釋放內存，否則將發生內存泄漏。

---

? 具體的函數設計

我們先定義一個結構體，用來表示文件的讀取結果：

struct FileReadResult
{void* Contents;      // 文件內容指針uint32 ContentsSize; // 文件大小
};

這個結構體會在讀取文件后返回，調用者可以通過Contents指針獲取文件內容，通過ContentsSize獲取文件大小。

---

? 打開文件的操作

我們使用fopen函數以二進制模式(rb)打開文件：

FILE* In = fopen(FileName, "rb");
if(!In)
{printf("Error: Cannot open file %s\n", filePath);return {};
}

如果文件無法打開，直接返回一個空的FileReadResult結構體，并在控制臺打印錯誤信息。

---

? 獲取文件大小

我們需要確定文件大小，以便分配合適的內存。這里我們使用fseek和ftell：

fseek(inputFile, 0, SEEK_END);
size_t fileSize = ftell(inputFile);
fseek(inputFile, 0, SEEK_SET);

• fseek(inputFile, 0, SEEK_END)：將文件指針移動到文件末尾。
• ftell(inputFile)：獲取當前文件指針的偏移量（即文件大小）。
• fseek(inputFile, 0, SEEK_SET)：將文件指針復位到文件起始位置，準備開始讀取內容。

通過這種方式，我們獲取到了文件的總大小。

---

? 分配內存

接下來，我們需要為文件內容動態分配內存，內存大小等于文件大小。

 Result.Contents = malloc(Result.ContentsSize);

---

? 讀取文件內容

我們使用fread函數將文件內容一次性讀入內存中：

fread(Result.Contents, Result.ContentsSize, 1, In);

• Result.Contents是內存地址；
• Result.ContentsSize是要讀取的數據大小；
• 1表示讀取1個完整的文件；

---

? 關閉文件

無論成功與否，我們都需要關閉文件句柄，避免文件句柄泄漏：

fclose(In);

確保文件句柄不被占用。

---

? 返回結果

  return Result;

這樣，調用者就可以獲取到文件內容以及文件大小。

---

意圖	正確的寫法
? 獲取文件大小	fseek(In, 0, SEEK_END);
? 獲取當前大小	size_t fileSize = ftell(In);
? 重置指針到開頭	fseek(In, 0, SEEK_SET);
? 保持指針不變（錯誤）	fseek(In, 0, SEEK_CUR); ?

記住：如果你想讀取文件，從頭開始讀取，就必須 fseek(In, 0, SEEK_SET);

跳過第一個故意留空的資產

在文件中，有些內容是故意留空的，因此不能假設文件名一定可以被加載。在最初的值中，文件名可能為null，因此不能直接使用第一個索引的文件名。為了避免這個問題，可以選擇從索引1開始處理文件，因為除了第一個索引外，其余的文件名應該都是非null的。這種方法應該是可行的。接下來可以進行測試，驗證這種方法是否有效。具體操作是進入系統或程序，嘗試加載文件，看是否會出現問題。

調試ReadEntireFile

接下來，通過讀取文件并執行比特掃描等操作，我們逐步分析文件的內容。此時，我們檢查了文件的偏移量、標簽和圖像尺寸等信息，結果顯示文件的數據偏移量、尺寸和其他數據與預期一致。這時，我們確認了文件的格式基本正確，并將其釋放掉。

接下來，我們編寫代碼，將這些處理過的數據寫入到新的文件中，這樣就生成了一個包含所有游戲資源的打包文件。雖然這個文件的大小約為17MB，看起來是合理的，但我們并沒有進行完全驗證，因此不敢完全確定文件的內容是否正確。

通過生成的這個打包文件，我們替換了之前的測試文件，并將所有數據合并為一個名為 test.HHA 的文件。該文件包含了游戲的所有數據。接下來需要驗證這個文件能否在實際的游戲中正常運行。

雖然我們還未進行完全的驗證，但到目前為止的進展顯示，整個過程是可行的，文件結構和數據格式應該是正確的。接下來的步驟將包括進一步的驗證和測試，以確保所有功能都能正常工作。

切換到從資產包文件加載所有資產

現在我們要做的第一件事是將游戲切換為使用打包文件。首先，我們需要明確哪些內容需要正確初始化，哪些內容則不重要。比如調試相關的代碼大多數可以去掉，只保留一些關鍵的部分。所有的調試代碼和不必要的部分會被移除掉，留下必要的初始化和處理邏輯。

在清理完這些不必要的代碼后，接下來的步驟是使用現有的調試文件加載例程，將整個打包文件加載到內存中，先通過這種方式進行測試。之后，計劃在Windows平臺層添加一個路徑，使用更高效的重疊I/O操作，以便更好地處理文件的加載。

為了實現這一過程，首先需要將不必要的代碼全部清空，剩下的核心部分就是文件加載相關的代碼。這一階段，我們將通過現有的加載方式來驗證文件是否能夠正確加載到內存中，并且確保加載的過程沒有出現問題。

接下來的步驟將會更復雜，需要實現一個支持高效I/O的加載機制，確保系統能夠在實際運行時更高效地處理文件數據。

處理大量代碼變更。一步一步來

在進行大規模的代碼更改時，最好將任務分解成小的步驟（或稱為“階段”），而不是一次性完成所有的更改。這種方法有助于我們在每次更改后驗證是否正確工作，這樣可以及時發現問題，避免一次性更改過多內容導致難以調試。每次只做一個小的修改，有助于更容易定位問題所在，而不是一開始就替換掉所有的內容，這樣調試起來會變得復雜且耗時。

根據這個方法，首先會處理調試加載的部分，比如加載位圖（BMP）和音頻文件（WAV）。我們會將這部分代碼暫時替換為斷言操作，確保它們不會繼續執行，直到我們明確這些操作應該如何進行。具體來說，會用 assert 來替代實際的加載操作，并立即返回一個結果，這樣代碼執行時就不會繼續進行錯誤的加載操作。

當這些更改完成并編譯時，系統會提示缺少資源，因為沒有加載資產。這時的行為是非常有趣的，系統并不會崩潰，而是嘗試去加載圖像和資源，發現沒有相關資源后，它會繼續執行，不會停止，這種行為也說明了系統的設計是健壯的，可以在缺少資源的情況下繼續運行。

接下來，計劃恢復這些資源。首先，我們將使用調試版的 DEBUGReadEntireFile 函數讀取之前寫入的 test.HHA 文件。通過讀取這個文件，獲取其中的所有資產，然后將它們加載到內存中，系統將通過這些資源來繼續工作。具體步驟包括讀取文件內容，并通過遍歷所有資產，將其引用填充到內存中的相關位置。

引用加載到內存中的資產文件

我們已經將整個文件加載到內存中，接下來計劃直接用指針覆蓋內存中的其他內容。具體來說，我們將覆蓋資產計數、資產本身以及相關的數據。這些內容將從文件中加載的數據進行替換。為了正確更新這些內容，我們需要對一些數據結構進行處理，特別是資產數量和標簽數量等。

首先，我們會根據從 HHA 頭部中獲取的資產數量來設置新的資產計數，然后將這些資產數量推送到數組中。類似地，標簽的數量也會根據 HHA 文件中的信息來更新。之后，我們將通過遍歷標簽數組、資產類型數組以及資產數組，依次將數據填充到新的位置。

對于標簽數組，目前我們還沒有明確的加載方式，可能會考慮將標簽數據平鋪加載，即將其直接指向內存中的相應位置。我們可能會在下一步中決定哪些數據需要平鋪加載，哪些則不需要，而這部分內容會在之后的迭代中進一步優化。

在當前的實現中，我們將數據的源（即從文件中加載的標簽）和目標（即我們最終使用的資產標簽數組）進行匹配和復制。具體來說，我們會將標簽的ID和對應的值從源復制到目標。這里的關鍵操作是確保從文件加載的數據能正確地映射到我們的數據結構中。

最后，我們已經知道從文件加載的數據結構是什么樣的，下一步將是根據這些數據來正確地填充我們的內部結構，并確保數據能夠順利流動和使用。

直接將頭文件強制轉換為hha頭文件結構，并檢查魔法值和版本

首先，HHA頭部是我們文件格式的第一個部分，因此我們可以通過將文件數據直接轉換為對應的結構體來訪問它。我們將文件中的數據直接轉型為HHA頭部結構，并驗證它是否包含我們預期的魔法值。這樣做可以確保我們讀取到的文件是我們寫入的文件，避免出現讀取錯誤。

在調試過程中，我們還可以檢查HHA文件版本，以確保文件格式是正確的。然后，我們可以通過讀取資產數量和標簽數量等信息，來確定文件中的數據布局。接下來，我們需要找到HHA標簽的位置，來正確地讀取標簽數據。

標簽數據的位置可以通過查看HHA頭部中的位置指示來確定。通過將文件指針移動到標簽數據的起始位置，我們就能訪問這些標簽數據。因此，我們需要在文件中找到標簽部分的位置，并基于這個位置來讀取數據。

在這一過程中，我們還注意到文件格式沒有被包括在現有的代碼中。為了修復這個問題，我們將需要將文件格式包含到代碼中。這意味著要將必要的頭文件和格式定義加入到項目中，這樣我們就能正確地處理文件的加載和解析。

此外，關于數據類型的命名，也進行了些微的調整。在命名時，我們考慮了是否使用帶有前導零的數字（如08）或標準的數字（如8）。雖然一些人在線表示應該避免使用帶有前導零的命名方式，但有時為了對齊，我們還是會使用它，這樣看起來更加整齊。

在所有這些調整完成后，我們會繼續進行測試和驗證，確保文件的正確加載和數據解析。雖然過程有些超時，但這也是正常的，特別是在調試和調整細節時。

什么是“平面加載”？

“Flat Loaded”通常有兩種意思，具體含義取決于上下文。第一種解釋是指直接將數據文件作為一個整體加載到內存中，然后程序直接從內存中讀取數據并運行，而不對數據進行進一步的修改或分配內存空間。也就是說，這種方式加載的內存是一個連續的塊，游戲或程序可以直接從這個塊中讀取并執行數據，而不需要重新調整數據的位置或者分配新的內存區域。

這種加載方式被稱為“Flat Loaded”，因為數據是直接一次性加載進內存中，沒有經過額外的處理和修改。相比之下，另一種常見的數據加載方式則可能需要額外的步驟，比如先將整個文件加載到內存中，然后根據需要解析出數據結構并為每個數據部分分配內存，進行更為細致的操作。這種方式通常較為繁瑣且低效，因為需要在加載過程中做很多額外的工作，因此盡量避免使用。

盡管“Flat Loaded”方式通常用于更高效的游戲或程序中，但它并不是唯一的方式。在實際應用中，加載數據時還可能會涉及解壓縮步驟。即首先將數據作為一個塊加載到內存中，然后進行解壓，再將解壓后的數據用于程序。這種方式與“Flat Loaded”類似，但因為多了一步解壓處理，因此并不完全相同。通過這種方式，程序仍然可以利用內存中的數據塊，但會先對數據進行必要的解壓操作，以便更高效地使用。

總的來說，Flat Loaded方式能夠有效減少不必要的內存分配和數據重排，因此被認為是一種性能較好的數據加載方式。

為什么將所有資產放在一個文件中比將不同類型的資產分開到不同文件中更有好處？

有人提到了將所有資源放在一個文件中而不是為每種資源類型創建不同文件的好處。這個問題需要澄清一下，因為它可以有兩種不同的理解。

第一種理解是，為什么要將所有資源放在一個大的文件中，而不是為每個資源（例如每個位圖）創建單獨的文件？這種問題的重點在于資源如何存儲在文件中，是否通過將不同的資源類型（如位圖、音效等）分別存儲在不同的文件中，或者將所有資源集中在一個大的文件中。

第二種理解是，為什么要選擇將資源都放在一個文件里，而不是選擇多個文件，例如一個文件專門存儲音效，另一個文件專門存儲位圖？這涉及到將不同資源按類別分開存儲和管理，還是將所有資源都統一放在一個文件中。

這兩個問題雖然看起來相似，但實際上是不同的，因此需要確保理解清楚提問者的真正意思，以便做出合適的回答。

如果查詢沒有匹配的資產，是否應該有錯誤斷言？

如果查詢沒有找到匹配的資源，是否應該使用斷言（assert）來進行處理呢？對此不確定，可能并不需要使用斷言。更可能的做法是設置一種方式來記錄這種情況，例如通過日志記錄。建議采取一種等待和觀察的方式，看看是否會遇到這種情況，如果確實出現了問題，再做進一步的處理。

我們的單一文件HHA文件格式

目前的文件結構大致是這樣的，它由幾個部分組成。首先是文件的頭部，頭部里面包含了一個前導部分，這部分其實沒有什么具體內容。接下來有一個魔法值（Magic Value），表示一些特殊的標識，還有一些計數和地址信息。然后是一些數組，比如標簽、資源類型和具體的資源。這些數組之間是相互關聯的，數組指向特定的數據，指示各個資源的具體位置。

當前的文件中，資源按定義的順序排列，通常是位圖（Bitmap）資源先列出，接著是聲音（Sound）資源。但這些資源的順序并不是固定的，我們可以在定義時調整順序，比如可以將位圖和聲音資源交替排列，這樣仍然是有效的。所以，資源的順序只是當前定義方式的結果，并不意味著文件格式本身要求按照這個順序排列。

為什么要拆分我們的HHA文件？

為什么不將資源分成兩個文件，一個存儲位圖（比如BMP文件），另一個存儲聲音（比如WAV文件），然后每個文件的開頭都加上一個頭部信息，這樣就有兩個文件，一個專門存位圖，一個專門存聲音。

針對這個問題，首先想到的理由是，為什么要這么做呢？增加文件數量有什么好處？如果我只使用一個文件，這個文件包含了所有數據，當我打開這個文件時，只需要檢查是否能成功打開這個文件，就知道可以獲取到所有的資源了。如果文件打不開，唯一需要擔心的就是文件損壞或丟失的情況。

但是如果使用兩個文件，就需要處理更多的工作。在啟動時，除了要處理位圖文件，還需要處理聲音文件，這樣就多了一個解析路徑，意味著更多的工作、更多的潛在錯誤和更多的代碼。所以，最主
要的原因就是沒有必要這樣做，為什么不將文件簡化，合并成一個文件呢？沒有找到將它們分開存儲的明顯好處，因此更傾向于將所有資源都存儲在一個文件中。

游戲是多人還是單人？會不會像這個名字所暗示的那樣讓玩家自己編程角色？

游戲將是單人游戲，而不是多人游戲。雖然游戲的最終版本將是單人游戲，但為了展示如何編程，我們在代碼中支持了多人游戲的功能。例如，在引擎測試代碼中，如果插入一個Xbox手柄并按下按鈕，就會添加第二個角色，這表明代碼是支持多人游戲的。

然而，游戲的設計并不適合多人游戲，所以雖然代碼本身可以支持多人同時游玩，但游戲的玩法和體驗并不是為了多人互動而設計的，也不會以多人游戲的形式發布。我們確保代碼可以支持多人功能，但最終發布的游戲將專注于單人游戲，因為多人模式在這種設計下不會帶來有趣的游戲體驗。

為什么你的個人資料網頁在沒有JavaScript的情況下無法查看？

我的網頁之所以需要JavaScript才能查看，是因為我對傳統的網頁技術（HTML、CSS和JavaScript）并不喜歡，覺得它們都很糟糕。出于這個原因，我做了一些實驗，其中之一就是制作一個不依賴這些技術的網站。

我的網頁實際上是一個C程序，它負責布局，并將JavaScript作為后端輸出，就像一個編譯器一樣，生成我在C程序中設計的布局。這是我在業余時間做的一個項目，雖然它并不完美，但我從中學到了一些東西。

在實現這個過程中，我還與Firefox的開發者討論，如何使這個過程更加高效。因為JavaScript和HTML非常慢，甚至做一些基本的布局都幾乎不可能，除非掌握一些特定的技巧。所以，我的網頁設計方法實際上是繞過了這些常見的網頁技術，嘗試用一種不同的方式實現網頁的布局和展示。

什么是位圖？

位圖（Bitmap）這個詞其實是一個誤用，雖然它在早期的定義中更為準確。在最初的計算機圖形中，位圖確實是指“比特的圖”，也就是說，它是由0和1構成的圖像，每一個0或1代表圖像中的一個位置的狀態。如果在早期的顯示器上使用這種方式，比如黑白顯示，0表示不繪制，1表示繪制，這樣就能夠構成圖像。

比如，假設要繪制字母“H”，可以通過在一個矩陣中使用1來表示字母的部分，0表示背景部分。這個過程實際上就是將一個字符的圖像存儲為“比特圖”（bitmap）的形式。在那時，位圖的定義是相對準確的，因為顯示器通常是單色的，一個比特可以表示一個像素的開關狀態。

然而，隨著顯示技術的發展，尤其是彩色顯示的出現，僅僅用0和1來表示一個像素顯然不夠用了。現在，位圖更多的是指一種每個像素存儲多個值的數據結構。現代的位圖文件通常會在每個像素位置存儲完整的RGBA（紅色、綠色、藍色、透明度）顏色值，每個顏色通道占8位，從0到255之間的值，用來表示顏色的強度。

因此，位圖這個詞的定義已經發生了變化，雖然它仍然是由比特組成的，但現在的位圖實際上可以表示更多的信息，比如彩色和透明度。盡管如此，位圖這個術語依然存在，它的起源實際上是指每個像素只有一個比特，用于黑白顯示，隨著技術進步，才逐漸擴展為現在的彩色位圖。

什么是重疊I/O？

重疊I/O（Overlapped I/O）是Windows操作系統中的一種機制，允許對硬盤進行異步讀取操作。通過這種方式，可以在等待數據從硬盤讀取的同時，繼續執行其他任務，而不需要阻塞程序的運行。這個機制允許更高效地管理I/O操作，因為它使得程序可以在執行其他工作時，仍然能夠并行進行數據讀取。

在接下來的幾天里，將詳細介紹如何使用重疊I/O來進行資源加載的過程。

在這種情況下，為什么其他開發者將資產拆分到不同的文件中？

有些開發者會將資源分成多個文件，比如把聲音文件和位圖文件分別存儲在不同的文件中。對于這個問題，我不太清楚為什么會這么做，因為我個人沒有遇到過這樣的做法，也不認識有開發者這樣做。這并不代表沒有這樣的做法，只是我沒有親自見過。因此，我不能解釋為什么他們會這樣做。

如果問題是問為什么很多開發者把每個資源單獨存儲為一個文件，可能是因為他們沒有使用打包文件（pack files），或者因為不想處理打包文件的復雜性。打包文件可以將多個資源合并成一個文件，但可能會讓一些開發者覺得麻煩，所以他們選擇保持每個資源單獨存儲為一個文件。

擁有單獨的文件是否有助于游戲的修改或補丁？

將資源分成不同的文件并不一定有助于修改或打補丁。因為我們設定的資源文件格式允許添加盡可能多的文件，所以始終可以根據需要增加新的資源。因此，從資源的管理角度來看，是否將資源分開并不會帶來太大差異。

至于打補丁，如果我們需要更新或替換現有的資源，可能需要考慮補丁的方式。但實際上，如果打補丁的機制設計得當，可能能夠自動處理這些更新，所以不一定需要額外的工作。總的來說，這個過程可能會比較簡單，打補丁的需求并不會因為資源是否分開存儲而產生太大不同。

面向數據設計和壓縮導向編程有什么不同嗎？

壓縮導向編程和數據導向設計是不同的概念，盡管它們有些地方可能會重疊。數據導向設計關注的是如何在編寫代碼時，首先聚焦于數據的處理方式。它強調編寫代碼的首要目標是根據需要改變數據的結構，無論是將數據移動到另一個位置，還是直接在原地進行修改。簡單來說，數據導向設計的核心是圍繞數據的操作和變化來組織代碼，這是計算機在處理數據時的基本任務。

而壓縮導向編程則是處理更高層次的結構，它關注如何通過抽象和重用代碼來提高效率。壓縮導向編程并不是改變數據的操作方式，而是通過提取出類似的部分，將其構建成可重用的模塊，并確保這些模塊仍然遵循數據導向設計的原則，避免改變其基本功能。其目標是保持數據處理的一致性和正確性，同時通過合理的結構化，能夠在多個場景中復用相同的代碼。

總之，數據導向設計關注的是如何高效地操作和處理數據，而壓縮導向編程則是如何優化和重用代碼，保證設計在數據處理的基礎上更加靈活和高效。

拆分文件的一個原因是為了繞過FAT32的4GB限制。另一個原因是，如果你的工作流程允許音頻開發人員更新他們的包文件，而不需要更改其他游戲部分（如模型、紋理），這也是一個好處

將文件拆分的一個原因是為了繞過FAT32的4GB限制。另一個原因可能是在開發過程中，如果音頻開發人員能夠上傳和更新他們的包文件，而不需要修改游戲的其他部分，這樣可以避免影響游戲的其他資源。然而，這屬于開發階段的事情，與最終游戲的發布方式是不同的。

關于FAT32的限制，現在可能已經不太常見了。即使在傳輸數據時使用U盤，可能還會遇到FAT32的4GB文件大小限制，但這通常不再是常見的問題。

至于在哪里可以閱讀到相關的實際內容，這里并沒有明確的資料來源，但可以通過查找有關FAT32文件系統的文檔或關于開發過程中的資源管理資料來了解更多。

游戲是否需要等到所有資產都解壓完成后才能啟動？

游戲并不需要等到所有資產都解壓縮完畢才能啟動。處理方式是將每個資源單獨壓縮，而不是將所有資源作為一個整體塊壓縮。這樣，當需要加載某個特定的資源時，游戲只需要解壓該資源，而不是解壓所有資源。因此，解壓的過程是有選擇性的，只針對需要的資源進行解壓，以支持隨機訪問。

為什么你使用Windows而不是Linux？

選擇使用Windows而不是Linux作為主要開發平臺的原因，主要是因為Windows在PC游戲市場中占據了絕大多數份額。根據Steam硬件調查，約96%的玩家使用Windows系統，而使用MacOS和Linux的玩家分別只有不到4%。因此，作為游戲開發者，選擇Windows作為主要開發平臺是為了能夠覆蓋大多數潛在玩家，確保游戲能夠順利銷售和獲得成功。如果沒有支持Windows，游戲可能會面臨無法順利發布、玩家反饋大量問題的風險。

盡管如此，開發者仍然會考慮將游戲移植到Linux和MacOS等其他平臺。首先，編寫跨平臺代碼是一個有價值的技能，能幫助開發者準備應對未來可能的需求，比如移植到主機平臺（例如PS4）。此外，微軟對游戲開發者的態度并不友好，他們不斷推行有利于自己利益的政策，比如限制舊版Windows對Direct3D的支持，強制要求開發者使用最新版本的操作系統。這種行為令開發者在Windows平臺上的工作變得更加困難。

因此，盡管Windows仍然是主流平臺，開發者將游戲移植到Linux也有其戰略意義。隨著Linux平臺在Steam上的逐步崛起，開發者通過支持Linux可以增加市場競爭力，為玩家提供更多選擇，甚至在未來能夠減少對微軟平臺的依賴，避免成為單一平臺的“俘虜”。通過這一舉措，也有可能推動Steam Linux等替代平臺的成功，從而增加整個游戲行業的多樣性。

你能在直播中說點什么讓reddit生氣嗎？他們已經在抱怨你關于OOP的言論了

對于Reddit的反應，似乎不需要刻意去做什么讓他們生氣，因為Reddit上的用戶總是容易抱怨和發火，所以不管做什么，他們似乎都會有意見。

但是你可以在Linux上為Windows編程，對吧？

在Linux上為Windows進行開發并不算非常容易。雖然可以通過Wine來模擬運行并進行開發，但這種方法并不可靠，因為Wine與真實的Windows環境有很大的不同。所以不建議通過模擬器來測試主要平臺，最好在真實的Windows平臺上進行測試。雖然在Linux上開發是可行的，但由于Linux的調試工具相較于Visual Studio較為差勁，因此也不推薦將Linux作為主要的開發平臺。盡管Visual Studio也有其缺點，但與Linux的調試工具相比，它依然更為有效。因此，目前不建議將Linux作為主力開發平臺。