Tag: game

macOS 要提供 DirectX 介面了

Hacker News 上看到 macOS 要提供 DirectX 介面了：「DirectX 12 Support on macOS (twitter.com/andytizer)」，原推是：

算是降低遊戲引擎維護的成本？讓開發商更有意願實作？不確定會有什麼效果...

KataGo 1.12.0 與 UEC 杯用的 model：b18c384nbt-uec.bin.gz

剛剛看到 KataGo 出了 1.12.0，同時也放出了在 2022 年十一月 UEC 比賽時用的 model：「New Neural Net Architecture!」。

1.12.0 比較特別的新的類神經網路架構：

This version of KataGo adds support for a new and improved neural net architecture!

這個新的架構以及其他的改善讓訓練的速度改善：

The new neural nets use a new nested residual bottleneck structure, along with other major improvements in training. They train faster than KataGo's old nets and learn more effectively.

另外一個是他把 UEC 比賽時用的 model 放出來了，很特別的是採用 b18c384，而 KataGo Distributed Training 這邊目前主要是 b40c256 與 b60c320，看起來是為了比賽而一次性訓練出來的。

依照他的說法這個 b18c384 版本跟目前訓練網站上的 b60c320 有差不多強度，但計算速度會比 b60c320 快不少，甚至在一些機器上會跟 b40c256 差不多快：

Attached to this release is a one-off net b18c384nbt-uec.bin.gz that was trained for a tournament in 2022, which should be of similar strength to the 60-block nets on http://katagotraining.org/, but on many machines will run much faster, on some machines between 40-block and 60-block speed, but on some machines even as fast as or faster than 40-block.

另外一個大改變是他把訓練工具從 TensowFlow 跳槽到 PyTorch：

The training code has been all rewritten to use pytorch instead of tensorflow.

在 release note 裡沒有提到原因，但這個頗讓人好奇的...

用 Poetry 的相依性演算法解數獨 (Sudoku)

在 Daily Lobsters 上看到「Solving Sudoku with Poetry's dependency resolver」這篇完全是惡搞 Python 下 Poetry 套件 XDDD

作者搞出來的方法是這樣，指定 81 個版號來表示題目，然後跑 Poetry 找可以的版本組合：

[tool.poetry.dependencies]
python = "^3.6"
sudoku-cell11 = "*"
sudoku-cell12 = "2.0.0"
sudoku-cell13 = "*"
sudoku-cell14 = "8.0.0"
sudoku-cell15 = "*"
sudoku-cell16 = "9.0.0"
sudoku-cell17 = "*"
sudoku-cell18 = "*"
sudoku-cell19 = "*"
sudoku-cell21 = "3.0.0"
sudoku-cell22 = "7.0.0"
sudoku-cell23 = "*"
sudoku-cell24 = "6.0.0"
...

另外作者有提到，本來是打算用 Yarn 來解，但看起來各種嘗試都會搞爆 Yarn，才換到 Python 上面玩 XD

QTE 小遊戲 Looptap

在 Hacker News 首頁上看到這個小遊戲：「Show HN: Looptap – A minimal game to waste your time (vasanthv.com)」，如同他的標題寫的，浪費時間的小遊戲 XDDD

標題講的 QTE 是「快速反應事件」這個東西，在現在的遊戲裡面算是蠻常見的機制，是一種需要在事件有效區間反應的設計 (太早反應或是太晚反應都不行)。

在 Minecraft 裡面幹出一台完整的電腦

在 Lobsters Daily 上看到有強者在 Minecraft 實做邏輯電路，幹出一台完整的電腦出來 (CPU 的部份應該是 turing-complete 了)：

PCWorld 有報導：「This 8-bit processor built in Minecraft can run its own games」。

把影片裡的描述截圖出來：

連分支預測器都出現了：

記憶體就 Minecraft 來說也是超大的 256 bytes：

然後還做了 cache 層，這邊提到的是 data cache：

然後這邊是 instruction cache：

也因為已經相當的 powerful，很多經典遊戲都可以玩，像是俄羅斯方塊：

貪食蛇：

打磚塊：

Connect Four：

QOI 圖片無損壓縮演算法

在 Hacker News Daily 上看到「Lossless Image Compression in O(n) Time」這篇，作者丟出了一個圖片的無損壓縮演算法，壓縮與解壓縮的速度超快，但壓縮率又不輸 PNG 太多，在 Hacker News 上的討論也可以看一下：「QOI: Lossless Image Compression in O(n) Time (phoboslab.org)」。

裡面有提到在遊戲產業常用到的 stb_image.h：

Yes, stb_image saved us all from the pains of dealing with libpng and is therefore used in countless games and apps. A while ago I aimed to do the same for video with pl_mpeg, with some success.

作者的簡介也可以看到他的主業也在遊戲這塊：

My name is Dominic Szablewski. I build games, experiment with JavaScript and occasionally tinker with low-level C.

圖片的無損壓縮與解壓縮算是遊戲創作者蠻常用到的功能，所以他想要看看這塊有沒有機會有更好的工具，於是他就用了四個很簡單的演算法幹完了 QOI (然後發現效果很讚)：

  • A run of the previous pixel
  • An index into a previously seen pixel
  • The difference to the previous pixel
  • Full rgba values

其實從 Hacker News 的討論也可以看到這組演算法也常被拿出來在現代的壓縮演算法使用，所以雖然作者自稱不是 compression guy，但他用的演算法其實蠻專業的...

然後挑 single thread 主要是可以避免 threading 的複雜度以及 overhead，在「QOI Benchmark Results」這頁可以看到，無論是什麼類型的檔案，壓縮與解壓縮的速度都相當漂亮，而且壓縮率又沒有差 libpng 太多。

而且作者自己有提到，還沒用到 SIMD 指令集加速，這樣猜測應該還有不少空間...

獨立遊戲創作者推出 Linux 版的好處

標題不知道怎麼下，大概就是這樣...

從 Hacker News 首頁上翻到的，以這個 upvote 數量來看，應該會收到今天的 Hacker News Daily 上：「Despite having just 5.8% sales, over 38% of bug reports come from Linux (reddit.com)」。

作者是一位獨立遊戲開發者，在兩年前推出了「ΔV: Rings of Saturn」這款遊戲，並且也發佈了 Linux 版。

作者先就數字來比較，他賣出了 12000 套，其中 700 套是 Linux 玩家；另外他收到了 1040 個 bug report，其中大約 400 個是從 Linux 玩家回報的：

As of today, I sold a little over 12,000 units of ΔV in total. 700 of these units were bought by Linux players. That’s 5.8%. I got 1040 bug reports in total, out of which roughly 400 are made by Linux players.

That’s one report per 11.5 users on average, and one report per 1.75 Linux players. That’s right, an average Linux player will get you 650% more bug reports.

看文章時可能會覺得「Linux 玩家真難伺候」，但實際上作者講到，這 400 個 bug 裡面只有 3 個 bug 是平台相關的 (只會發生在 Linux 上)，其他的 bug 其實是所有平台都會發生：

A lot of extra work for just 5.8% of extra units, right?

Wrong. Bugs exist whenever you know about them, or not.

Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone[.]

原因是 Linux 社群在參與各種 open source project 養成的習慣，會盡可能把各種資訊講清楚，並且找出可以重製問題的方式：

The thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!

But that’s not all. The report quality is stellar.

與一般玩家的回報方式完全不同，Linux 玩家很習慣就會附上基本的環境資訊，系統紀錄，甚至有時候還會包括 core dump 與 reproducible steps：

I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed.

And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.

不知道有沒有遇到回報 GDB 資訊的...

很特別的分享 XDDD

AMD 推出 FidelityFX Super Resolution

AMD 推出了功能上類似於 Nvidia 的 DLSS 的技術，叫做 FidelityFX Super Resolution (FSR)，並且 open source 出來：「AMD FidelityFX Super Resolution is Here」，另外可以看一下 GPUOpen 官方網站裡面的內容。

DLSS 的機制上可以這樣解釋，遊戲輸出 1080p，透過 machine learning 運算的方式將畫質提升到 2K 或是 4K，這樣比起遊戲直接要計算 2K 或是 4K 的輸出內容，運算量可能會比較少。

不過 DLSS 只能跑在 RTX 20xx 與 30xx 系列的顯卡上，以前的舊顯卡不支援。而先前 AMD 公佈 FSR 的時候，除了是宣示 AMD 也推出類似的技術外，另外一個賣點是 FSR 可以跑在 Nvidia 的顯卡上。

而這次的消息則是又多說明了 open source 的釋出部份，將在七月中放出來：「AMD FidelityFX Super Resolution is Here」。

The source code for FidelityFX Super Resolution 1.0 will be coming to GPUOpen in mid July!

目前有七個遊戲支援，後續會有更多遊戲加入...

Windows 上現成的 KataGo + Lizzie 安裝程式

本來花了一些功夫整理了一下 KataGo + Lizzie 純 CPU 版本在 Windows 上的安裝方式 (在「KataGo/Windows」這邊)，後來找了一下發現早就有人做的更簡單了：「BadukMegapack」。

底層的部份除了可以選擇裝 KataGo 外，也可以選擇目前已經停止維護的 Leela Zero，或是 SAI、AQ 與 Ray。

而界面的部份除了可以用 Lizzie 外 (而且還是改過的加強版 XD)，還可以選其他的界面... 除此之外還連 JVM (Java 8) 都一起拉進來幫你裝。

看起來算是包的好好的... 看起來最困難的應該是弄一張高階顯卡了？

GTA Online 釋出官方修正，大幅改善啟動效能

看到「GTA Online load time fix released, shaves off actual minutes of waiting for some」這邊的消息，先前在「GTA 的啟動讀取效能問題」這邊提到 GTA Online 啟動速度很慢的問題，官方正式推出修正版本了：「GTAV Title Update 1.53 Notes (PS4 / Xbox One / PC)」。

抓了一些在 Reddit 的討論「Loading Times Have FINALLY been patched - Discussion Thread」。

這則降的比率與當時 workaround 的修正差不多：

Insane. GTA menu -> GTA: Online.

Dropped from 7 minutes to 1:57

i7-2600k,GTX1070,16GB RAM and the game is on HDD.

這個就有點誇張了，這是 90% 吧？

Dropped from 5-8 minutes to 35 seconds

這個差不多 70%～80%：

Loading time 2m 20s for online directly from steam. Before it was like 8-10 minutes for me. Damn

Edit: 50s for story mode. 35s from story mode to online. So it seems it's still faster to load into online from story mode.

這個也差不多 70%：

From 4-5 minutes to 1 a minute and 22 seconds. Y e s p l e a s e

然後 PS4 的版本原來也受到一樣的影響？

Currently tested on PS4 , from main menu to online : 3min 45 sec From story mode to online: 1min 20sec (😩 i can't tell for sure )

整體看起來是正面的，畢竟大家等這個問題等超久了... 另外也可以看出來當初的 workaround patch 其實相當精準的把問題都解掉了，官方的修正並沒有快更多。

來繼續關注 libc 那邊的問題...