本篇說明目前在下發現，或已知的mkxp-z引擎問題
也歡迎在底下留言補充其他問題
mkxp-z建構時預設字型為英文字型（Liberation Sans）
也歡迎在底下留言補充其他問題
1.文字無法顯示、或顯示為方框
若沒有將cjk_fallback_font選項開啟，只要文字包含韓、日、中將無法正常顯示
mkxp-z建構時預設字型為英文字型（Liberation Sans）
需將建構選項cjk_fallback_font更改為true才可將預設字型替換為中文字型（文泉驛微米黑）
＊若遊戲中沒有指定使用字型，將會使用預設字型（Font.default_name）
＊若遊戲中沒有指定使用字型，將會使用預設字型（Font.default_name）
＊專案中可更改整體的Font.default_name，但字體系列名稱得正確（＊2020/12/6
＊單一部分的Font.default_name也是可被更改的 例：.contents內的字型調整
＊若上方的中、英字型不符合需求，是可以更改預設字型的
＊若要更改預設字型，需將欲更換的字型放置在/assets資料夾中（字型不可為otf檔，且檔案大小建議不超過5MB），並更改/src/font.cpp的腳本內容，找到"wqymicrohei.ttf.xxd"，並將之替換為欲更換的字型的名稱。
假如想放入的字體名稱為SourceHanSansTW，那麼就改為"SourceHanSansTW.xxd"
假如想放入的字體名稱為SourceHanSansTW，那麼就改為"SourceHanSansTW.xxd"
2.無法更換字型
可能找不到字型、也可能是字型名稱輸入錯誤
只要替換字型出錯，就會使用預設字型
只要替換字型出錯，就會使用預設字型
＊使用mkxp-z的專案若要更改字型，需將字型放入專案中的Fonts資料夾中（XP也可以）
並在腳本中輸入字型系列名稱（Font Family），而非字體檔案名稱。
這意味著在Windows系統下直接點開字型檔查看字型名稱是不一定準確的，建議可以使用其他作業系統來查看字型系列名稱，例如macOS、Linux。
這意味著在Windows系統下直接點開字型檔查看字型名稱是不一定準確的，建議可以使用其他作業系統來查看字型系列名稱，例如macOS、Linux。
3.播放音效後會當機、跳掉
mkxp-z不支援wav檔案，一旦使用到了就會這樣（微軟的陰謀
4.序列化與反序列化（Marshal）錯誤
由於mkxp-z將RM引擎全部用c++改寫了，包含序列化的部分也是，但主要錯誤原因在於重寫的RPG::架構上，不論是資料庫、地圖、事件…等等的，都與原引擎有差距，一旦添加或改變了RPG::架構部分都將有機率出錯。
比較常見的出錯 就是對資料庫或事件的說明、註釋部分用作腳本調用，用來顯示圖標、控制事件之類的，為了讀取控制文字（像是常見的\n、\color之類的），讀取並替換了資料庫文字內容就比較容易出錯。（建議少用特殊符號
5.更改了遊戲視窗大小，但遊戲畫面與地圖顯示沒有跟著變大
這點VX、VA比較不會出現，XP則是一定有
畢竟XP的畫布大小、視窗大小大部分都是定數（也就是寫死啦），所以才會出現這種問題發生
＊使用"defScreenW"與"defScreenH"又或者Graphics::resize_screen(n,n)可改變視窗大小
＊mkxp-z預設也可以用滑鼠拖曳拉伸畫面（可於mkxp.json中關閉）
＊若使用mkxp-z可以讓專案讀取到視窗大小，進而改變畫布大小
＊讀取視窗大小的程式為Graphics.width與Graphics.height，只有XP的原引擎沒有
若為XP用戶可以參考下圖，並將下圖的程式碼放置於腳本最上方
這樣三個全局（$origin、$Graphics_width、$Graphics_height）變數將會被定義
864與480分別為畫面的寬與高，可自訂
$origin變數為判斷是否為原引擎，若為true則使用原引擎，若為其他則使用mkxp-z（VX、VA可
$Graphics_width為畫面的寬，若為原引擎則為640（限XP
$Graphics_height為畫面的高，若為原引擎則為480（限XP
接下來凡是只要有用到畫面大小的地方就將$Graphics_width與$Graphics_height替換上
Spriteset_Map、 Spriteset_Battle、Game_Player、Window類、Scene類…等等的
例如：Spriteset_Map裡面的Viewport.new，將後面的640與480分別替換就可以了
＊畫面的移動也與畫面大小有關
雖然改好了畫面大小，但還沒結束，地圖的畫面需要tilemap拼接而成
這代表除非重寫tilemap類，否則沒辦法依畫面大小正常顯示地圖
而mkxp-z已經使用c++重寫好了該類，但要更改得自己建構mkxp-z
需更改位於src資料夾中的tilemap.cpp，67、68行分別為畫面上的地圖寬格與長格數
地圖格1格為32 pixel * 32 pixel，若為640*480則為寬20格長15格（畫面最大可顯示格數）
為了避免移動時地圖格顯示出現尚未渲染的黑格，所以需要＋1格
而tilemap.cpp內預設為21格、16格，這兩變數可自行更改大小
例：若專案畫面大小為960*640，那麼tilemap.cpp內的變數就分別設定為31、21
6.動態生成的圖像，遊戲讀取不到
例如：專案用到了截取畫面後存檔，並顯示截圖在頁面上，但截圖顯示不出來
很不幸的目前沒有解決方案，似乎mkxp-z若要讀取到這些檔案得再重新啟動一遍。
mkxp-z可以輸出bitmap為bmp檔，作為截圖用，且在下是用FileUtils控制資料的，不知道有沒有影響
7.使用外部dll檔無效
如果dll檔的內容不包含Windows的資料庫，那麼問題不大
但如果有用到的話，基本上就會無效，除非用到的資料庫可以直接包進引擎裡並建構出來
知名的mode 7、WhiteFlute腳本基本上都用不了
8.ruby的效率不比原引擎好
如果mkxp-z建構時ruby不是使用最新的版本，而是使用與原引擎同樣的ruby版本，那麼運算效能上會有一點差距，不過圖形處理的效能可是天差地別
9.跳出錯誤，找不到"Game.ini"
遊戲的名稱（也就是視窗上顯示的那個），請使用英文與數字，若使用了其他的文字將會讀取不到。
10.跳出錯誤，找不到BGM、地圖圖像、圖片…等等的
除非是忘記加上檔案，否則基本上是RTP沒有加入
若遊戲專案沒有脫離RTP，那麼就需要將RTP本身加入到遊戲專案中，讓引擎能夠讀取的到
可以將RTP直接移入專案、也可以將RTP壓縮成壓縮檔並於mkxp.json中265行加入壓縮檔名稱
可以將RTP直接移入專案、也可以將RTP壓縮成壓縮檔並於mkxp.json中265行加入壓縮檔名稱
＊如果可以的話還是建議脫離RTP
11.搖桿無法支援震動
主要是SDL2沒有識別到搖桿，像是現在的PS5、XSX搖桿都尚未支援
且mkxp-z是具有知道搖桿是哪家的能力的，這樣就可以專為不同加搖桿設計按鈕圖像跟操控了
＊如果電腦能成功支援搖桿的話，基本上搖桿操作都可以正常運作
12.使用到Win32API的腳本，會讓遊戲跳掉
雖然mkxp-z能夠支援dll檔，但並非是全部支援的，越是接近核心層面的kernel32就越容易讓遊戲無法正常進行，這部分只能斟酌取捨了。
13.遊戲時間無法正常顯示
在原引擎中有file.mtime的使用方法，可以查看檔案最後被更新的時間點，而mkxp-z的這個方法失效了。
這裡提供一個解決方法，就是將現在時間寫入存檔中：Marshal.dump(Time.now, file)
每要使用到存檔時間時，File.open後Marshal.load就可以了
每要使用到存檔時間時，File.open後Marshal.load就可以了
＊切記Marshal序列化是有順序的，若順序不對的話將會出錯
14.視窗或圖片的顯示出現問題
mkxp-z中的Window類，opacity與圖像順序比較嚴謹（Z軸概念）
如果位於Window類的話就擅用self.opacity、self.back_opacity、self.contents_opacity
分別控制：
主要透明度、視窗背景透明度、Bitmap透明度（文字、Icon之類的）
15.畫面漸變的效果與原先有差異
如果沒有特別改動這塊的話，應該是不會有問題的
若有的話，特效方面應該可以正常顯示，但是順序上會有點問題
例如特效還沒跑完，但玩家已經到達下一張地圖之類的
＊那麼請先將特效與動畫演完後，才顯示下一張地圖的"畫面"（Spriteset_Map）
16.zlib失效
目前只發生在高版本的ruby上（使用ruby 2.7的mkxp之類的），無一例外、所有版本RM的Zlib全部失效。
＊目前還沒有解決方法
＊目前還沒有解決方法
17.BGM與BGS的記憶與還原功能失效
目前可以知道的是，這是mkxp的bug
簡易的解決方法是 前往src/alstream.cpp，將if (needsRewind)的條件跟內容註釋或去掉
只是這樣就會導致另一個bug發生，就是即使沒有按還原BGM也會自己從記憶點播放
只是這樣就會導致另一個bug發生，就是即使沒有按還原BGM也會自己從記憶點播放
→ 解決參考
18.第17點的補救方案
RMVX、RMVA都支援ogg檔循環標籤功能，只有XP不能用
然而MKXP讓XP也可以使用這項功能了
然而MKXP讓XP也可以使用這項功能了
如果想要循環撥放一首BGM不想結束的話，用這種方式就可以不用記憶BGM了
19.快速輪流切換bgm時，音量會由小開始變大
原引擎在撥放bgm時，會直接卡住0.x秒，mkxp則不會
這項bug並不明顯，而且mkxp提供了優異的讀取效率，如果說 會卡vs不會卡且有淡入
我可能會選後者
我可能會選後者
20.同時播放ME與BGM時，有機率BGM會偷跑0.5秒才切回ME
＊在RM中，ME播放時BGM會先暫時停止，播完ME後才會將BGM回復
＊在RM中，ME播放時BGM會先暫時停止，播完ME後才會將BGM回復
＊最常見的就是上床睡覺時安排的睡覺音樂，播完睡覺音樂後切回原先的BGM
假如我在程式中安排了ME播放、BGM才播放（無間隔），那麼就會有機率出現這項bug
@像哈士奇的狼：可能是 mkxp 在偵測 me 有沒有播放時，是用 while loop 不斷去檢查
而這個檢查中間會 sleep 10ms
@像哈士奇的狼：在 RM 這裡也加個 sleep 11ms ，錯開他們 好像就修好了，不再會發生搶播的情況了
@像哈士奇的狼：在 RM 這裡也加個 sleep 11ms ，錯開他們 好像就修好了，不再會發生搶播的情況了
程式碼大概長這樣↓
sleep 0.011
持續更新…
