Ruffle 對 crossdomain.xml 的處理方式

ruffle 是一個 open source 的 Flash 模擬器,用 JavaScript (以及 WebAssembly) 讓使用者可以在瀏覽器裡面直接執行。

不過想到 Flash 的 crossdomain.xml 在技術上應該是沒辦法繞過瀏覽器對 CORS 的限制,所以找了一下目前的情況... 在「Ideas for getting arounds CORS restrictions #8972」這邊有提到兩個方法,另外 comment 提到了「Add setting to spoof URLs in network requests #1486」這個。

看起來這個問題還在「有點子,但沒解決」的情況。

不過找了一下當年有玩的小遊戲 Zookeeper,在「Zookeeper - Flash Games Archive | FlashArch」這邊可以玩,看起來功能都還算正常,讓人懷念啊...

世紀帝國系列裡的 AoE 與 AoK 使用組合語言加速的情況

Age of Empires (1997) 與 Age of Empires II: The Age of Kings (1999) 是當年兩個很紅的遊戲,有傳言裡面有很大一部分是用組合語言寫的。

剛剛在 Hacker News 上看到「Original Age of Empires 2 dev talks about its usage of assembly code (reddit.com)」這篇,看起來是原作者跳出來說明這段傳言 (講的更細),原文在 Reddit 的「AoE is written in Assembly - is this actually TRUE?! :O : aoe2」這邊。

32-bit 的 x86 組語部分有大約 13k 行,大多數 (11.5k 行) 是與繪圖有關的 (當年繪圖相關的功能都還是 CPU 在算):

There were about ~13,000 lines of x86 32-bit assembly code written in total.

The vast majority, about ~11,500 lines worth, was in the 'drawing core', which drew SLP sprites in a variety of ways (mirrored, stippled, clipped). The code for this was in a separate .asm file, which was "compiled" by Microsoft Macro Assembler 6.1 into a .obj file.

最主要的目的當然是效能,這邊提到隔壁棚的星海爭霸預設還是 640x480 的時候,AoE 這邊預設可以上 800x600:

The use of assembly in the drawing core resulting in a ~10x sprite drawing speed improvement over the C++ reference implementations, and AoE's drawing core was notably faster than competitors like StarCraft, which is why the default resolution 'out of the box' for AoE was 800 by 600, when nearly all our competition was 640 x 480 resolution - we could scroll the screen and fill it with sprites as fast or faster even though we had twice as many pixels-ish in the game world area.

後來到 64-bit 年代就變成用 C++,主要是因為 compiler optimization 的改進,以及多 CPU 與 multi-threading 的技術,讓計算力提升很多:

I re-wrote the assembly functions into C++ for both Definitive Editions, as they are 64-bit programs, and inline assembly was never supported by the 64-bit C++ compiler, and the vastly improved register sets and compiler optimizations made it un-necessary. Additionally, sprite drawing in the definitive editions is multi-threaded, and will use up to 4 cores for that task alone.

算是時代的演進,意外的留下一些記錄... 而更後面的時代則是把這些計算 offload 到顯卡上面了。

Twitch 宣佈退出韓國市場

Twitch 宣佈 2024/02/27 (星期二) 退出韓國市場:「An Update on Twitch in Korea」。日期不知道是怎麼選的,可能跟某些合約有關?

Twitch 目前的公告會有繁體中文,也可以看這份:「Twitch 韓國現況更新」。

另外今天早上找了一下,Hacker News 也有討論了:「An update on Twitch in Korea (twitch.tv)」。

目前官方給出來的理由是虧本,而且找不到方法克服虧本的問題:

Ultimately, the cost to operate Twitch in Korea is prohibitively expensive and we have spent significant effort working to reduce these costs so that we could find a way for the Twitch business to remain in Korea.

這邊提到的包括了 p2p model 以及降到 720p,但即使如此網路費用 (應該就是頻寬費用) 是其他區域的十倍以上:

First, we experimented with a peer-to-peer model for source quality. Then, we adjusted source quality to a maximum of 720p. While we have lowered costs from these efforts, our network fees in Korea are still 10 times more expensive than in most other countries. Twitch has been operating in Korea at a significant loss, and unfortunately there is no pathway forward for our business to run more sustainably in that country.

Cloudflare 這邊,2016 年還叫做 CloudFlare 的時候也有抱怨過:「CloudFlare 對 HiNet 成本的抱怨 (還有其他 ISP...)」。

當年是這樣寫 HiNetKT,成本大約是歐美區的 15 倍:

Two Asian locations stand out as being especially expensive: Seoul and Taipei. In these markets, with powerful incumbents (Korea Telecom and HiNet), transit costs 15x as much as in Europe or North America, or 150 units.

而尤其是韓國的部分,政府介入讓降價的速度比全世界慢,所以時間拉長後成本相較於其他地區就貴很多:

South Korea is perhaps the only country in the world where bandwidth costs are going up. This may be driven by new regulations from the Ministry of Science, ICT and Future Planning, which mandate the commercial terms of domestic interconnection, based on predetermined “Tiers” of participating networks. This is contrary to the model in most parts of the world, where networks self-regulate, and often peer without settlement. The government even prescribes the rate at which prices should decrease per year (-7.5%), which is significantly slower than the annual drop in unit bandwidth costs elsewhere in the world. We are only able to peer 2% of our traffic in South Korea.

不過不確定現在的情況,2016 年的 CloudFlare 跟 2023 年的 Cloudflare 已經差了七年了...

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」這篇完全是惡搞 PythonPoetry 套件 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