第一百四十八章 如何看懂調(diào)試界面 ①
?。ㄗ⒁?,本章的側(cè)重點在于Java 1.8及之后的版本,1.8之前的版本本章并沒有對其仔細研究,到時候會專門出一章來研究研究)
前面的一百多章節(jié),講了許多東西,但似乎漏了一個挺重要的東西。
想來想去,原來是調(diào)試界面還沒講。
既然第十四卷已經(jīng)有19章了,那就新開一卷,放松一下,雖然還有許多東西沒講(比如自定義交易之類的,放第十六卷吧,村莊與掠奪更改的內(nèi)容還得好好研究研究)。
在寫本章時,作者為了檢測各個Minecraft版本調(diào)試界面的區(qū)別,分別使用了四個啟動器加一個第三方客戶端開了五個不同版本的Minecraft Java版,它們分別是:Java1.7.10,Java1.8,Java1.12.2,Java1.13.2和Java1.16.5。因為Minecraft Wiki對于調(diào)試界面的歷史變更記載起碼有一半漏掉了,所以本章但凡有提到版本變更的,大部分都是作者自己測出來的一個比較模糊的范圍。
進入正題。首先,什么是“調(diào)試界面”?
眾所周知,在Minecraft Java版中,按下F3(Mac電腦和一些筆記本電腦是Fn+F3),屏幕上就會出現(xiàn)一大堆東西。這一大堆東西讓許多Minecraft玩家直呼:“我看不懂,但我大受震撼”。
現(xiàn)在,請停止你的震撼,然后跟著我來從左上角開始一行一行看。
左上角第一行,顯示的是游戲的基本信息,即:這個Minecraft Java的版本號是多少,啟動器是什么,啟動器版本號又是什么等。如果你是通過我的世界官方啟動器啟動的純凈Minecraft版本(即無插件),那么這一行將會顯示:
Minecraft 版本號(版本號/vanilla)
這里的“vanilla”的意思是“純凈的”,即這個Minecraft是純凈版本,沒有裝任何其他插件(這里的插件并不包含資源包、附加包,而是指Forge之類的東西)。
如果你裝了個Forge,那么這里將會變成:
Minecraft 版本號(版本號/fml,forge/Forge)
?。ㄉ厦孢@一行是在1.12.2版本下測試的結(jié)果)
但是,有些插件并不會顯示,比如OptiFine。
如果你像作者一樣,使用的是HMCL(HelloMinecraftLauncher)啟動器,那么這兒將會顯示:
Minecraft 版本號(HMCL 啟動器版本號/vanilla/HMCL 啟動器版本號)
如果你使用HMCL啟動器并裝了Forge插件,那么將會顯示成:
Minecraft 版本號(HMCL 啟動器版本號/fml,forge/Forge)
其他的一些Minecraft啟動器作者也進行了測試,結(jié)果如下:
PCL2(Plain Craft Launcher 2):和Minecraft官方啟動器一樣
BakaXL:Minecraft 版本號(版本號/vanilla/BakaXL)
這是第一行,接下來請看第二行。
第二行的最前面你絕對看得懂,即fps(每秒傳輸幀數(shù)),大家口中的“幀率”。如果你連fps是啥都不懂......簡單來說,fps數(shù)值越高,游戲越流暢,反之越卡。
后面就有些亂了。首先是個:
(數(shù)值 chunk updates)
實際上這很簡單,你把這串放進生草機里攪拌一下,就會得到:
?。〝?shù)值個區(qū)塊更新)
這本書看到這兒,只要你沒有跳著看,區(qū)塊是個什么你應該知道吧。
那“區(qū)塊更新”又是什么東西?
答:當一個區(qū)塊內(nèi)有任何一個方塊其NBT標簽發(fā)生任何的改變,或者方塊被破壞、放置、移動,這個區(qū)塊就被視為發(fā)生了更新。
這個(數(shù)值 chunk updates)就是向我們顯示目前游戲內(nèi)有多少個區(qū)塊發(fā)生了更新。
但可惜的是,1.15版本Mojang將chunk updates移除了。
(數(shù)值 chunk updates)后面是一個“T:xx”。這個T的值對應了視頻設置內(nèi)的“最大幀率”值。如果游戲設置內(nèi)的最大幀率值是120,那么這里將會顯示成“T:120”。如果游戲設置內(nèi)的最大幀率被拉到了最大,也就是“無限制”,那么這里將會顯示為“T:inf”。(這里的inf是infinity無限的縮寫)
“T:xx”后面是一些單詞,這些單詞加上“T:xx”本身都是顯示一些關于游戲畫面的配置。
如果你在Minecraft的“游戲菜單/選項/視頻設置”里打開了“使用垂直同步”選項,那么這兒將會在T:xx后面多出一個單詞:
1.8/1.12.2/1.13.2——vsync
1.16.5——vsyncfancy
(vsync是Vertical synchronization[垂直同步]的縮寫)
同樣的,對于“云”的設置也會顯示在上面。在Java 1.8.1以前,云的流暢和高品質(zhì)是由“圖像品質(zhì)”選項控制的,1.8.1及之后云的流暢和高品質(zhì)被獨立到了“云”選項里。因為云有兩種品質(zhì),所以當你打開云層時,顯示的單詞會有所不同。對了,對于“云”的設置其單詞一定是顯示在垂直同步后面的。
流暢:
1.8——fast clouds(這里的fast和clouds沒有連起來是因為這兒的fast實際上并不只指云層是流暢品質(zhì),而是對應了“圖像品質(zhì)”選項里的流暢。當你把云關掉,你會發(fā)現(xiàn)fast還在這里,只是clouds消失了)
1.12.2/1.13.2/1.16.5——fast-clouds
高品質(zhì):
1.8——clouds
1.12.2/1.13.2/1.16.5——fancy-clouds
1.14的18w44a快照將“啟用頂點緩沖器”選項移除了,并讓頂點緩沖器在之后的版本中一直是保持開啟狀態(tài)。在移除這東西之前,只要你打開它,你就會在“云”的單詞后面發(fā)現(xiàn)一個單詞:vbo。
vbo是Vertex Buffer Object(頂點緩沖對象)的縮寫。在移除過后,調(diào)試界面中就再也見不到它了。
在作者打開的1.16.5版本中,在“云”的單詞后面還有一個:
“B:x”
這東西不知道是什么時候更新的,反正1.13.2版本沒有見到。這個東西是關系到視頻設置中的“生物群系過度距離”選項。這個選項可以選擇0、3x3、5x5、7x7.....15x15一共8個級別的過度距離,分別對應“B:x”顯示的0到7級。比如,如果你顯示的是“B:2”,那么你的生物群系過度距離就是5x5(普通)。
第二行的內(nèi)容還真多。接下來請看第三行。
1.13版本更新時,Mojang在原本的第二行到第三行間插入了一行,將原本C開頭的第三行擠到了第四行也就是這串:
Integrated server @ xx ms ticks,xx tx,xx rx
嗯......不對,我是單人游戲,哪來的延遲?
實際上這兒并不是告訴你單人游戲的延遲,而是告訴你:
游戲中的一游戲刻需要電腦耗費多長時間運算出來。(ticks是游戲刻的意思)
眾所周知,1000ms=1s,20游戲刻=1s,一般情況下電腦是可以保證一秒滿20游戲刻,即一游戲刻需要運算的時間≤50ms。作者之前測試了一下,作死重復執(zhí)行/execute at @e[type=item] as @e[type=item] run fill ~1 ~1 ~1 ~-1 ~-1 ~-1 air destroy,這行的ms ticks值立馬飆到了1000ms多,也就是一游戲刻需要耗費1秒多的時間來計算。所以,這個ms ticks的數(shù)值在檢測游戲有多卡時還是挺有用的。
后面的xx tx,xx rx顯示的是客戶端每秒發(fā)送(transport)和接收(receive)的包數(shù)。單人游戲還在發(fā)送接收包就挺離譜,而且就算關了匿名反饋也照樣發(fā)送接收。發(fā)送給誰?接收的是哪個服務器的包?這些問題還有待研究。
在服務器中,這一行有些變化。作者進入了Hypixel服務器,發(fā)現(xiàn)其變成了:
“vanilla“ server,xx tx,xx rx
前面說過,vanilla代表著這個Minecraft是沒有加任何插件的。所以這兒的“vanilla”server的意思就是:該服務器并沒有加任何插件。
第四行,也就是1.13版本之前的第三行,又是讓人大受震撼的一行。
但只要你仔細一看,會發(fā)現(xiàn)這一行是由一堆“縮寫:值”拼湊起來的,拆分開來就簡單許多了:
C:xxx/xxxx (s)——視野內(nèi)渲染的區(qū)段數(shù)/已經(jīng)加載的區(qū)塊(不管強還是弱加載)所包含的區(qū)段總數(shù)量。注意,是區(qū)段數(shù)不是區(qū)塊數(shù)?。ǎ繀^(qū)段是什么個東西)(區(qū)段本身是16x16x16的立方體,一個區(qū)塊在1.18更新之前一共有16個區(qū)段。區(qū)段可以通過F3+G顯示區(qū)塊邊界查看區(qū)塊上的藍色線條來判斷。)
D:xx——對應游戲視頻設置里的“渲染距離”。如渲染距離是12區(qū)塊,那么將會顯示成“D:12”。
L:xx——作者也不清楚,存在于1.8版本之后1.16.5版本之前,中文Wiki上沒有相關的描述,英文Wiki倒是有:Client-side blocks count that have light update to apply,但不解其意。
pC:xxx——等待成批處理(卸載)的區(qū)塊數(shù)量(第一百二十章講的區(qū)塊卸載機制跟這東西有關系,建議回去復習,還是挺有趣的)
pU:x——等待提交給顯卡的更新數(shù)量。說白點就是:在一游戲刻內(nèi)你視野內(nèi)凡是有東西,不管是實體還是方塊,發(fā)生了變化(更新)之后,都要呈現(xiàn)到你的面前,這時候就要將這個變化(更新)提交給顯卡來處理成圖像。這個pU就是記載本游戲刻將要給顯卡更新圖像的東西的數(shù)量。
aB:x——成批處理(卸載)區(qū)塊時可以用的緩沖區(qū)數(shù)量
額,看起來拆分開來并沒有簡單許多。(估計很多人一遍過后看不懂,這一行確實挺難的,建議多看幾遍消化消化)
但接下來的第五行,也就是1.13版本前的第四行,聽我的,特別簡單。
這一行主要是關于實體:
E:xx/xx——在視野中的實體數(shù)/已經(jīng)加載的區(qū)塊所包含的總實體數(shù)
B:0——啥用也沒有,估計是Mojang哪位員工做這個的時候摸魚了
在1.8版本左右還有一個:
I:xx——不在視野中但處于已經(jīng)加載的區(qū)塊的實體數(shù)量。因為這個東西太雞肋了,所以在1.8版本之后1.12.2版本之前不知道哪個快照更新時砍掉了。
下一行P開頭也很簡單:
P:xx——渲染的粒子數(shù)量
T:xx——已經(jīng)加載的區(qū)塊所包含的總實體數(shù),在1.16.5版本之前是“T:All:xx”,不得不說這和那個被砍掉的“I:xx”一樣雞肋。
第七行(1.13前第六行)只有一個東西,但看起來很高級:
MultiplayerChunkCache:xxxx,xxxx(作者發(fā)現(xiàn)在1.16.5版本已經(jīng)改為了Client Chunk Cache)
Wiki上描述是“所能載入的最大區(qū)塊數(shù)?!?,但作者實測發(fā)現(xiàn)這還有個東西。
可以發(fā)現(xiàn)這兒有兩個數(shù)值,但按照這個功能來說只需要一個數(shù)值就好,所以作者對此進行了深入研究,得出來一個嚴謹?shù)慕Y(jié)果:
這兩個值中,前面那個值即是“所能載入的最大區(qū)塊數(shù)”,受渲染距離影響,必定比渲染距離所加載的區(qū)塊數(shù)量還要多,只要不改變渲染距離就不會變化,但目前尚不知到計算方式。后面的那個值,是“已加載的區(qū)塊數(shù)量”,包含強加載和弱加載區(qū)塊。
看來Wiki也不過如此.jpg
在1.13.1版本之前,到這兒左邊的第一大段已經(jīng)完了。但1.13.1版本更新了個第八行:
minecraft:xxxxxxxxx FC:xx
前面的這個帶有“minecraft:”命名空間的單詞,就是你所處的維度id。比如你身處主世界,那么這兒將會顯示:
minecraft:overworld
這個“FC:xx”,顯示的是你所處維度有多少個被強制加載的區(qū)塊(即使用特殊手段加載的區(qū)塊,比如使用/forceload加載的區(qū)塊)。
?。~,/forceload在1.13.1被加入,這一行也是在1.13.1被加入....../forceload真有牌面)
(唉,為什么我的FC值是n/a)
在1.15版本之前,到第八行左邊第一大段已經(jīng)完了,但Mojang在1.14到1.15版本之間的某個快照更新中將一個新的東西插入到原本第七行和第八行的中間,這東西就是:
ServerChunkCache
Minecraft Wiki上不確定這東西有啥用,但根據(jù)Client Chunk Cache,我們可以大膽猜測這東西就是:服務器最大加載區(qū)塊
但在服務器中這一行根本就沒有顯示,這個說法也就不攻自破。
那么本章就到這里了。