mieki256's diary

M病院附属S診療所に行って、脳に問題が無いか調べてきた。

• お医者さんの指示通りに手や指を動かして、小脳異常が無いことを確認。
• MRIを撮影して、脳梗塞、脳出血、くも膜下出血が無さそうなことを確認。白や黒になってる部分があると、そこで脳梗塞や脳出血、くも膜下出血があることが分かるらしいが、どこも異常無しとのこと。

少なくとも脳には異常が無さそうとの話だった。お医者さんの口ぶりからすると、こういった症状は耳から来てるパターンがほとんどらしい。

病院でも血圧を測ったけれど、111-74だった。まあ、フツーだよな…。低血圧でめまいが起きてる可能性をお医者さんに尋ねてみたけど、この数値でそれはちょっとありえない、みたいな反応だった。付き添いをしてくれたお袋さんが、目の酷使でこうなってる可能性を尋ねたけど、それは眼科に行って聞いてくださいと苦笑しながら言われてしまった。専門が違うから答えようがないよな…。

余談。初めてMRI撮影を体験したけど、こういう感じなのか…。大きい音がするからと耳栓を渡されて、どんだけスゴイ音がするのだろうと妙に期待してしまった。アレはモーター音なのかな…。考えてみたら、大きい音で苦しんでしまう状態になってる患者さんも居るだろうし、耳栓は保険みたいなものだろうか。

詳細はGRPでメモ。

「再起動しています」のまま5時間放置したけど、先に進まない。HDD(SSD)アクセスLEDはずっとチカチカ光っているから、何か処理をしているのかもしれんけど…。これは処理が無限ループしてそうな気配がする。仕方なく、リセットスイッチを押した。

その後1〜2回ほど再起動して Windows10 は立ち上がってくれたけど、Windows Update を確認したら、.NET関係のアップデートがまだ残っていた。しかし、アップデート3個分のうち、2個が、「ダウンロード中」→「アップデート中」になって処理が終わりに近づくあたりでブルースクリーン(BSOD)を引き起こした。

どうも自分の使っている Windows10 は、Windows Update がかかると高い確率でブルースクリーンになってしまう状態のようだなと…。

ただ、Windows Update だけがブルースクリーンを引き起こすわけでもなさそう。何かしらのアプリをインストールする際、管理者権限を要求してくるインストール処理をすると、たまにブルースクリーンになるので…。これがまた、常にブルースクリーンになるわけではないあたりもよく分からない。すんなりインストール処理が済んでしまう場合もあるし…。

一応念のため、管理者権限でコマンドプロンプトを開いて、以下を打ち込んでチェックディスクをかけておいた。

chkdsk /offlinescanandfix /f C:

「デバイスを使用中だから次回再起動時に処理をする」みたいなことを言われるので、OS再起動。Windows10のデスクトップが表示される前に、チェックディスクが走る。

Dドライブのチェックディスクは以下。

chkdsk /offlinescanandfix /f D:

一旦何か切り離された状態で処理されて、その後はDドライブにアクセスできなくなるっぽいので、チェックディスクが終わったらOS再起動。

GIMP Plugin Registry は、github にバックアップが残してあるらしい。

_GitHub - pixlsus/registry.gimp.org_static: A wget backup of http://registry.gimp.org
_registry.gimp.org_static/registry.gimp.org/files at master - pixlsus/registry.gimp.org_static - GitHub

欲しいスクリプトのファイル名さえ分かれば、まだ入手できる可能性はありそうだなと…。

Gimp Plug-in for Image Registration を使うと、そこそこ自動でレイヤーの位置合わせをしてくれる。このプラグインについては公式ページに辿り着けた。

_Gimp Plug-in for Image Registration: Welcome!
_Gimp Plug-in for Image Registration: Examples
_Gimp Plug-in for Image Registration download | SourceForge.net
_Gimp Plug-in for Image Registration - Browse /version-2.0.1 at SourceForge.net

SourceForge.net から 2.0.1 が入手できる模様。今回は gimp-image-reg-2.0.1-windows.zip を入手。解凍すると、gimp-image-reg.py と imregフォルダが入っているので、GIMPユーザーフォルダ/plug-ins/ にコピーすればインストールできる。

ちなみに、0.5.5 の頃は、gimp-image-reg.exe という実行バイナリの形で提供されていた。2.0.x から、Python-Fu (GIMP-Python) で書き直したようだなと…。

インストールすると、GIMPのメニューバーの「ツール」に「Image Registration...」という項目が増える。

使い方は以下。例えば、以下のような状態の2枚のレイヤーがあるとして、上のレイヤーを移動して位置合わせしたい。上のレイヤーを選択してアクティブにしておく。



ツール → Image Registration を選択。



設定ダイアログが開くので、Reference Image として、参照するレイヤー(下のレイヤー)を選んで、OKをクリック。



アクティブだったレイヤーが移動して、位置合わせができた。



ただ、どちらのレイヤーもそれなりに近い位置にないと正しく処理されないようにも見えた。縦方向は位置合わせしてくれたけど、横方向はずれたままになる場面もあって…。あらかじめ、ざっくりでいいから、目視で大まかにレイヤー位置を合わせておく必要がありそう。

前述の設定ダイアログを眺めると、移動＋回転ではなくアフィン変換を使ったり、画素の補間アルゴリズムも色々選べるようだなと…。

自動で位置合わせするわけではないけれど、GIMPのパスツールを利用して、移動先と移動元の位置を指定してやることで、比較的簡単にレイヤーの位置合わせをしてくれる、exact-aligner.scm という Script-Fu もある。github の GIMP Plugin Registry のバックアップから入手することができる。

_exact-aligner.scm at master - pixlsus/registry.gimp.org_static - GitHub
_Exact Align via 4-Point Path - GIMP Chat

ただ、このスクリプトは古いので、もしかするとGIMPのメニューに出てこないかもしれない…。メニュー位置だけを、Script-Fu → Tries-Tools → Exact Aligner に変えた版も一応置いておく。

_exact-aligner.scm

変更点は以下。

--- exact-aligner.orig.scm      Thu Jul 13 06:08:24 2023
+++ exact-aligner.scm   Sat Jul  5 15:36:07 2014
@@ -146,7 +146,8 @@

 ;Now we want to register this stuff...
 (script-fu-register "script-fu-exact-overlay"
-       _"<Image>/Tries-Tools/Exact Aligner"
+       ;; _"<Image>/Tries-Tools/Exact Aligner"
+       _"<Image>/Script-Fu/Tries-Tools/Exact Aligner"
        "Exact projection of 2 images in 2 layers"
        "Dr. Volker Tries"
        "(c) 2009, Dr. Volker Tries - Volker.Tries@kfopraxis-oberursel.de"

インストールの仕方は、該当ファイルを、GIMPユーザフォルダ/scripts/ 以下にコピーすればいい。

使い方は以下。GIMPのパスツールを選んで…。



マウスで左クリックして、4つの点を指定。1番目の点の位置に3番目の点が、2番目の点の位置に4番目の点が移動する感じで…。最初に移動先の2点を打つ、みたいな。



Script-Fu → Tries-Tools → Exact Aligner、を選択。



アクティブレイヤーの位置が変更されて、位置合わせができた。



おそらくだけど、このスクリプトは、移動、回転、拡大縮小をして、位置合わせをしているような気がする…。例えば以下のように、移動＋回転＋拡大縮小をしたレイヤーに対して処理しても、それらしく位置合わせしてくれるので…。



逆に言うと、単に移動だけしたい場合でも、回転や拡大縮小がかかってしまって、レイヤー内の画像が荒れてしまう可能性もありそうだなと…。

前述の exact-aligner.scm を Python-Fu で書き直した、ofn-layer-aligner.py という版もあるらしい。exact-aligner.scm が持っていた不具合をいくつか修正済みとのこと。

_ofn-layer-aligner - GIMP Chat
_Ofnuts' Gimp Tools - Browse /scripts at SourceForge.net

ofn-layer-aligner.zip を入手して解凍すると、ofn-layer-aligner.py というファイルがあるので、GIMPユーザフォルダ/plug-ins/ にコピーしてやればインストールできる。ちなみに、件の zip には使い方の説明書(ofn-layer-aligner.howto.html) も入ってる。

メニュー項目は、レイヤー → Realign。

使い方は、exact-aligner.scm と同じ。GIMPのパスツールを選んで…。



4点を打って…。



レイヤー → Realign、を選択。



アクティブレイヤーの位置が変更されて、位置合わせができた。

前述の exact-aligner.scm と似た感じで、パスツールを利用して点の位置を指定することでアレコレできる、SS-path-referenced-scale-move-rotate_v1-0.scm という Script-Fu もある。移動、回転、拡大縮小が別々の項目になっているので、利用したい処理だけを選ぶことができる。

_SS-path-referenced-scale-move-rotate_v1-0.scm at master - pixlsus/registry.gimp.org_static - GitHub
_GIMP script scale-move-rotate tutorial.pdf at master - pixlsus/registry.gimp.org_static - GitHub

"GIMP script scale-move-rotate tutorial.pdf" という説明pdfもあるのだけど、github上に置いてあるpdfは、そのままWebブラウザで閲覧できないようで…。一旦ローカルにダウンロードしてから開かないと中身を確認できなかった。一応ここにも置いておくけど、これで見れるのかどうか…。

_gimp_script_scale-move-rotate_tutorial.pdf

さておき。SS-path-referenced-scale-move-rotate_v1-0.scm を入手して、GIMPユーザフォルダ/scripts/ にコピーしてやればインストールできる。

メニュー項目は、レイヤー → 変形 → With Path... → (Move|Ortho|Rotate|Scale) by Path。4項目ほど追加される。

まずは Move by Path の使い方をメモ。パスツールで、移動元の点の位置、移動先の点の位置を指定する。



レイヤー → 変形 → With Path... → Move by Path、を選択。



アクティブレイヤーの位置が移動した。この処理は移動のみで、回転や拡大縮小はしない。


移動直後に赤い色のパスが新規に作られるけれど、これはこの後、回転処理もしたい時に利用する。移動処理のみで済むなら、無視するなり、パスを削除してしまっていい。


回転処理についてもメモ。例えば以下のように、位置がずれていて、かつ、角度が違っているレイヤーがあるとして…。



まずは位置だけ調整する。パスツールで、移動元、移動先の順で、点の位置を指定。



レイヤー → 変形 → With Path... → Move by Path、を選択。



位置のみを変更できた。新規に作成された赤いパスをパスツールでクリックして、角度を指定していく。



水平になっていたパスの点の位置を、移動元に合わせる。垂直になっていたパスの点の位置を、移動先に合わせる。



レイヤー → 変形 → With Path... → Rotate by Path、を選択。



アクティブレイヤーが回転して位置合わせができた。



Ortho by Path を使うと、水平、もしくは垂直に、レイヤーを回転させることもできる。例えば以下のような状態のレイヤーがあるとして、水平にしたい部分をパスツールで指定する。



レイヤー → 変形 → With Path... → Ortho by Path、を選択。



レイヤーが水平に見えるように回転してくれた。


ちなみに、垂直になるように回転させたい場合は、縦方向に長いパスを指定してやればいい。おそらく45度を境目にして判別してるのではないかな…。たぶん。


Scale by Path を使うと、拡大縮小をさせることもできる。例えば以下のような状態のレイヤーがあるとして、移動先、移動元の順に、パスツールで点を指定する。注意したいのは、2本の線があるような感じで指定すること。2本目の線の最初の点は、Shift + 左クリックをする。これで、線が分離してるようなパスを作れる。



レイヤー → 変形 → With Path... → Scale by Path、を選択。



アクティブレイヤーが拡大縮小されて位置合わせができた。

手動で位置合わせをしたい時は、上のレイヤーの合成モードを「差の絶対値」にしておくと楽かもしれない。




一応メモしておくけれど、GIMPの移動ツールでレイヤーの位置を調整する際、カーソルキーを使えば1ドット単位で調整できる。

更に余談。GIMPの統合変形ツールを使えば前述のスクリプト群と似たようなことができるよ、という話も見かけた。ピボット(回転軸)を、固定したい点の位置までずらして、Ctrlキーを押しながらピボットを中心にして拡大縮小するのがコツらしい。

_ofn-layer-aligner

perspective_transform_0_7.zip を入手して解凍すると、中に perspective_transform.py というPython-Fuスクリプトが入ってる。これを、GIMPユーザフォルダ/plug-ins/ にコピーしてやればインストールできる。

メニュー項目として、フィルター → 変形 → Perspective transform が増える。この中に、以下の5つの項目が追加される。

• Perspective transform - 1+2+3 points to circle (center and 2+3 points)
• Perspective transform - 2+2+2 points to circle (3 diameters)
• Perspective transform - 4 points to 4 points
• Perspective transform - 4 points to circle (clock face)
• Perspective transform - 4 points to rectangle corners

このプラグインは、元画像の状態や、パスツールでの点の指定方法によっては、変形処理ができない場合もある。GIMPの「遠近法ツール」自体が「その変形は無理。無限大の数値になる」とエラーを出す時があるので…。そんな時は、変形したい部分だけが残るようにトリミングしてから処理をすると変形できたりするかもしれない。

「4 points to 4 points」は、元の4点と、変換先の4点を指定して処理をする。

まずはパスツールを選んで…。



変形元になる4点を指定する。下の画像では、赤い線がパス。パスは閉じないので、「コ」の字のような見た目になるはず。



別のパスで、変換先の4点を指定する。下の画像では、赤い線が変形先のパス。青い線が変形元のパス。



フィルター → 変形 → Perspective transform → Perspective transform - 4 points to 4 points、を選択。



設定ダイアログが開くので、source path に元になるパスの名前を、target path に変換先パスの名前を指定。ちなみに、「Keep the original layer?」を「する」にすれば、元レイヤーを残した状態で処理してくれる。



画像が変形された。



ちなみに、レイヤー全体は以下のように変形されてる。

斜めから見て歪んだ形に見えている円を正面から見た状態に変換したい場合は、4 points to circle (clock face) を使ったほうが簡単。4点を指定すれば、円の形に変形してくれる。

パスツールを使って、以下のような4点を指定して…。



フィルター → 変形 → Perspective transform → Perspective transform - 4 points to circle (clock face)、を選択。



設定ダイアログが表示されるので、source path に、4点のパスの名前を指定する。



画像が変形された。ちゃんと正円っぽくなっている。



レイヤー全体は以下のような形に変形されている。

4点を指定して矩形に変換するなら、4 points to rectangle corners が使える。

パスツールを使って、「コ」の字になるように4点を指定して…。



フィルター → 変形 → Perspective transform → Perspective transform - 4 points to rectangle corners、を選択。



設定ダイアログが開くので、source path に4点のパスの名前を指定。



矩形になるように変換された。



レイヤー全体は以下のような形に変形されている。

斜めから見た歪んだ円を正円に変換する際には、1+2+3 points to circle (center and 2+3 points) を使うこともできる。

パスツールで、以下の点を指定する。

• 円の中心位置を1点。
• 上下の方向を2点。
• 円の一部分を3点。

全部1つのパスの中に含めるので、2点目、4点目をShift+左クリックで指定して、パスが分割されてる状態にしておく。



フィルター → 変形 → Perspective transform → Perspective transform - 1+2+3 points to circle (center and 2+3 points) を選択。



設定ダイアログが開くので、source path にパスの名前を指定。



画像が変形された。

斜めから見た歪んだ円を正円にする際には、2+2+2 points to circle (3 diameters) を使うこともできる。

パスツールを使って、円の直径部分を3本分指定する。1本ずつ、別のパスとして作成。そのうち一本は、上から下に引くように指定する。



フィルター → 変形 → Perspective transform → Perspective transform - 2+2+2 points to circle (3 diameters) を選択。



設定ダイアログが開くので、直径3本分のパスの名前をそれぞれ指定。かつ、上から下に引いているパスの名前を指定する。



画像が変形された。

error: Nothing matches org.gimp.GIMP in remote flathub

しかし、困った…。例えば、昔のネットブック機に載っている初期の Intel Atom CPU は 64bitに非対応なので、Debian Linux 32bit ぐらいしかインストールできない…。Ubuntu Linux等、他のLinuxディストリビューションは 32bit を切り捨ててしまったので…。

更に、昨今の Debian Linux の公式リポジトリからインストールされる GIMP は Python-Fu (GIMP-Python) に対応してないから、できれば Python-Fu が使える flatpak版のGIMPを使いたい。しかし 32bit版 Linux では flatpak が使い物にならないとなると…。困った。

Linuxの各ディストリが Python 2.x を殺して Python 3.x のみサポートするようになったせいで、GIMP の Python-Fu が使えなくなって、Linux + GIMP では、これまで Python で書かれてきた多くのプラグインがごっそり動かなくなっているわけで…。この状況はなんだかな…。

もっとも、ずっと Python 3.x に対応してこなかったGIMPがそもそもアレな気もするし。それに、64bitに対応していないぐらい古いCPUを今時使い続けるのってどうなのよという気もする。昔のネットブック機よりスマホを持ち歩いたほうがまだ便利だろうし。フツーに使いたいならせめて64bit対応のCPUが載ってるPCを入手しましょう、という流れも妥当と言うか…。

まあ、自分の場合、普段は Windows機で作業してるし、部屋の中には Ubuntu Linux (64bit OS) をインストールしてあるPCが何台もあるから、作業できなくて困るということはないのだけど。でも、ハードウェア的に壊れてなくてまだ動作する昔のPCが、OSの関係で色々使えなくなっていくのは、なんだかもったいない気もする。とは言え、古いCPUまでサポートしていくのは大変だろうし…。

ついでに、マウスパッド ELECOM MP-113BU (W150 x D180mm, 色はブルー) も一緒に注文した。

_スタンダードマウスパッド - MP-113BU

今まで使っていたマウスパッド、サンワサプライ MPD-NS1GY (W150 x D180mm, 色はグレー)と交換してみたけれど、マウスがスイスイと動く。今まで使っていたマウスパッドは随分と削れてしまっていたのだな…。

この世代の Canon製コンパクトデジカメは、CHDKという、ユーザが開発したファームウェアが利用できる。CHDKを使うと、RAW画像で撮影できたり、ブラケット撮影(露出を自動で変更しながら連続で数枚撮影する機能)が使えるようになる。

_CHDK Wiki | Fandom
_CHDK Download - build 1.6.1, revision #6239

今まで CHDK 1.3.0 をインストールしてあったけど、1.6.1 が安定版として公開されていたようなので更新してみた。手持ちの PowerShot 3300 IS のファームウェアは 100c なので、ファイル名に 100c と書かれてるものを選ぶ。a3300-100c-1.6.1-6239-full.zip を入手。

解凍すると以下のファイルとフォルダが入っていた。

CHDK/
camnotes.txt
changelog.txt
DISKBOOT.BIN
PS.FI2
readme.txt
vers.req

これを、デジカメで使うSDカード(FAT16でフォーマットされてる)のルートに全部コピー。

使い方は、A3300 IS の場合、以下になる。

1. 電源OFFの状態で再生ボタンを押す。電源が入る。
2. MENUボタン → Firm Update → 「1.0.0.0 → 1.1.0.0」と表示されるのでOK。
3. CHDKが起動している旨を伝える画面が出てくる。
4. シャッターボタンを押すと撮影モードになる。(レンズが出てくる)
5. 撮影モードの状態で再生ボタンを押すとALTモード(CHDK有効モード)になる。
6. MENUボタンを押すとCHDKの設定その他ができる。

例えばブラケット撮影をしたい時は…。

1. MENUボタンを押して出てきたCHDKメニューの中から、Enhanced Photo Operations → Bracketing in Continuous Mode → TV Bracketing で 1 Ev や 2 Ev を選ぶ。
2. MENUボタンや再生ボタンを押してメニューを消したら、タイマー撮影でカスタムを選択。左上のほうに赤い文字で「BRACKET:-/+ TV:2Ev」等が表示されたらブラケット撮影モードが有効になってる。
3. 1秒ごとに3枚撮影する設定にしてから撮影すれば、0Ev, -2Ev, +2Ev の3枚が撮影される。

ブラケット撮影が使えれば、PCにそれら画像を取り込んだ後、HDRI画像を作成することも可能になる。

まあ、今時のスマホにはHDR撮影モードがついてたりするのでアレなんだけど…。でも、勝手に合成されて結果だけ残されるのがちょっと…。スマホにもブラケット撮影モードがついていればいいのに…。

ふと思ったけど、これはネタバレ予防に使えるかもしれないなと…。

「この作品、舞台はホアーッ！ホアアアホーッ！ホアホホーッ！ホアーッ！。主人公はホホアホホーッ！ホホホーッ！ホアアホーッ！ホホホアーッ！アホアホーッ！アアホホアーッ！ホアホホーッ！アアアーッ！ホアホアアーッ！ホアホアアーッ！ホアホアホーッ！ホアアアホーッ！ホアーッ！してしまう。」

みたいな。

どうしても感想を書きたいが、ネタバレはしたくない。そんな時に便利かも…。そこに何が書かれているかどうしても知りたい人は解読すればいいし。

件の新作の感想がどれもこれも「カヘッ」で書かれてたら面白い…かもしれない…。眺めていてヘカヘカカッカヘカカッカカッカカカヘッヘカヘヘカッカヘッヘヘヘカッカカヘッになるかもしれんけど…。

ネタバレ防止と言えば、この日記ページでも機能追加してある _「もんたメソッド」 も便利な気がする。こんな感じで 文章の一部分を黒塗りできる機能なんだけど。この黒塗り部分、マウスクリックすれば外せます。

Twitterあたりでも実装されてたら、利用する人が結構出てくるんじゃないか…。まあ、今の Twitter はそんな実装してる余裕は無さそうだけど…。

考えてみたら、クリップ式老眼鏡を買う人って、「老眼鏡ってどんな感じなんだろう」とお試し感覚で買う人が多そうな気がする。というか自分がそうなんだけど。老眼になり始めたことを意識したぐらいの状態、軽い老眼になり始めてる状態だから、度数+1.0の需要が突出するのではないかなあ。

ただ、メーカ側、お店側は、「ずっと眼鏡を使ってきた人達はそのうち遠近両用メガネ等に切り替えていく場合がほとんどだから老眼鏡なんて欲しがらない」と思い込んでそうな気もする…。老眼鏡を買う層は今まで裸眼で生活してきた人達だろう、眼鏡をかけている人はターゲットにならないから無視するのが妥当、と考えて、フレームがちゃんとついてる、いかにもな老眼鏡ばかりが店頭でズラリと並んでいるのではないか。でも、その認識は間違ってる気がする。いかにもな老眼鏡が店頭で売れ残っていて、クリップ式老眼鏡ばかりが在庫切れになってるのは何故なのかを考えたら…。

もちろん、数万円を払ってそのうちちゃんとした遠近両用メガネに切り替えていく人は多いのだろうけど。まずは老眼鏡ってどういうものなのか体験してみたい人も居るだろうし、経済的に眼鏡を買い換えるのが難しい人だって居るはずで…。

フツーの眼鏡店で、いきなり数万円払って、しかし単にお試しというのは、さすがにちょっと怖いというか。そのあたりの需要を埋めてくれる商品のような気もするのだけどなあ。

自分はアニメ業界人さん達が時々書き込むツイートを眺めるのが好きだったけど、ああいう種類の情報なら掲示板の類で代替できそうな気もするなと。インターネット創世記は、アニメ監督さんが作った個人サイトに付属していた掲示板で情報交換してたような気もするわけで。今なら掲示板にお絵描き機能をつけたりして、その場で解説図をさらさらと描いてアップロードしたりできそうだし。

掲示板で代替できない部分があるとしたら、それは何だろうな…。

昔、Godot Engine 3.x.x で作成していた頃のプロジェクトを読み込もうとしたのだけど、「これは 3.x のプロジェクトだから 4.x 用に変換するか？」みたいなことを尋ねてきた。

The selected project "Helloworld_001" was generated by Godot 3.x, and needs to be converted for Godot 4.x. Project path: D:/home/USER/godot/_prototype/HelloWorld_001_v411 You have three options: - Convert only the configuration file ("project.godot”). Use this to open the project without attempting to convert its scenes, resources and scripts. - Convert the entire project including its scenes, resources and scripts (recommended if you are upgrading). - Do nothing and go back. Warning: If you select a conversion option, you won't be able to open the project with previous versions of the engine anymore.

試しに変換。

変換できずに、Godot Engine 4.1.1 x64 が落ちる…。何故。

落ちるプロジェクトを、Godot Engine 3.5.2 x64 LTS で開いてみた。これなら落ちないな…。

Godot Engine v4.1.1 x86 ならどうだろうと、そちらもインストールして試してみたけど、そもそも起動すらしなかった。うーん。

公式サイトを眺めてみたら以下の記述があった。

Note: The 32-bit .NET binaries do not run on 64-bit Windows systems at the time being. Make sure to export 64-bit .NET binaries for your 64-bit target platforms.

「32bit .NET版のバイナリは、64bit版 Windows上で動かないよ」と書いてあるのかな。手元では .NET版じゃなくて Standard (x86) 版を試しているのだけど、そちらも同様ということかもしれない。

ググってみたら、4.x は、3.x からかなり変更点があるようで…。

_Godot 4.0で変わったところ
_【Godot】Godot3.5から4.0への移行メモ | 2dgames.jp

フォント関係がごっそり変わってるので、そのせいで今回落ちたのかもしれない…？ 分らんけど。

sudo apt update
sudo apr upgrade -y -d
sudo apt upgrade -y
sudo apt --purge autoremove
sudo apt install update-manager
sudo apt dist-upgrade

sudo do-release-upgrade

_WSL2のUbuntu18.04LTSを、20.04LTSにアップグレード - SE_BOKUのまとめノート的ブログ
_Ubuntu 18.04(LTS)→20.04(LTS)アップグレード方法 - Qiita
_Ubuntu 22.04 LTS にアップグレードする方法 - 技術的な何か。
_力技で Ubuntu 20.04 LTS にアップグレードする方法 | 雑廉堂の雑記帳
_Ubuntu 20.04 LTS をインストールした後やること12選 - Qiita

sudo apt install love

$ love
love: error while loading shared libraries: libsndio.so.6.1: cannot open shared object file: No such file or directory

sudo ln -T /usr/lib/x86_64-linux-gnu/libsndio.so.7.0 /usr/lib/x86_64-linux-gnu/libsndio.so.6.1

sudo add-apt-repository ppa:bartbes/love-stable
sudo apt update
sudo apt install love

$ love
love: error while loading shared libraries: libsndio.so.6.1: cannot open shared object file: No such file or directory

flatpak (flathub) でも、love2d の最新版(11.4)が公開されているらしい。

_LoVE | Flathub
_Ubuntu Flathub Setup | Flathub

そちらをインストールできないか試してみた。しかしそもそも、flatpak のセットアップ時、以下でエラーが出てしまう。

sudo apt install flatpak
sudo apt install gnome-software-plugin-flatpak

$ flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

** (flatpak remote-add:12667): WARNING **: 11:08:06.475: Error unregistering authentication agent: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name :1.84 was not provided by any .service files
error: Authorization error: Message recipient disconnected from message bus without replying

sudo をつけたらエラーが出なかった。そんなことしちゃっていいのか分らんけど…。リポジトリ？を追加できたらOSを再起動。

sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo reboot

love2d をインストール。

sudo flatpak install flathub org.love2d.love2d

実行は以下。

flatpak run org.love2d.love2d

一応動いたけれど、起動時にエラーが出る…。アンインストールしておいた。

sudo flatpak uninstall flathub org.love2d.love2d

AppImage でも、love2d 11.4 が提供されている模様。

_LinuxでAppImage形式のアプリを使う方法と注意点のまとめ | virtualiment
_Release LoVE 11.4 [Mysterious Mysteries] - love2d/love - GitHub

mkdir ~/bin
cd ~/bin

wget https://github.com/love2d/love/releases/download/11.4/love-11.4-x86_64.AppImage
chmod a+x love-11.4-x86_64.AppImage

./love-11.4-x86_64.AppImage

こちらならエラーを出さずに実行することができた。

alias で定義しておけば呼び出しも楽になるかもしれない。以下は bash利用、かつ、~/.bash_aliases で alias を定義してる場合の事例。

vi ~/.bash_aliases

alias love='/home/USERNAME/bin/love-11.4-x86_64.AppImage'

別の Ubuntu Linux 20.04 LTS上で試してみたら、libsndio.so.6.1 が無くても ppa版 love2d 11.4 が動いてしまった。原因も分かったので、2023/07/29の日記にメモしておいた。

せっかくだから、.exe と html5 をエクスポートしてみようとしたのだけど…。

_mieki256's diary - Godot Engineでプロジェクトをエクスポート

.exe は問題無くエクスポートできたし、実行することもできたけど、html5 のエクスポートで問題発生。

Python 3.10.10 を使って、python -m http.server と打ってローカルWebサーバを起動して、http://localhost:8000/ に Firefox 115.0.2 でアクセスして .html ファイルを開いてみたのだけど、エラーが表示されて実行できない。

ググってみたら以下の記事に遭遇。

_[Godot] Godot4.0のWebエクスポートしたゲームがエラーで動かない！（Cross Origin Isolation、SharedArrayBuffer） | WorkToolSmith

Godot 4.x から、エクスポートした html5 の実行時に、Cross Origin Isolation、SharedArrayBuffer なるものが必要になったらしい…。python -m http.server で立ち上がるローカルWebサーバはあくまで簡易サーバなので、そこまではサポートしていない、ということなのだろう。

これがもし、Webサーバが Apache等であれば、.htaccess に以下を追記することで解決するらしいのだけど。残念ながら、自分の手元のWindows環境では Apache を動かしていない…。

Header set Cross-Origin-Embedder-Policy "require-corp"
Header set Cross-Origin-Opener-Policy "same-origin"

それぞれ、略称として COEP、COOP と呼ばれてるようだなと…。

さておき。Godot でエクスポートした html5 の動作確認のために Apache を新規導入するというのもちょっとヘビーな作業のような気もする。Pythonだけでどうにかならんかとググっていたら、以下のスクリプト、server-cross-origin.py に遭遇。

_Local HTTP server with COEP+COOP enabled for SharedArrayBuffer - GitHub

これは使えそうな気がする…。.pck もファイルの種類を指定しないといけないので、extensions_map = { } に、.pck の記述も追加した。

    extensions_map = {
        '': 'application/octet-stream',
        '.css':	'text/css',
        '.html': 'text/html',
        '.jpg': 'image/jpg',
        '.js':	'application/x-javascript',
        '.json': 'application/json',
        '.manifest': 'text/cache-manifest',
        '.png': 'image/png',
        '.wasm':	'application/wasm',
        '.xml': 'application/xml',
        '.pck': 'application/octet-stream',
    }

python server-cross-origin.py で動かしてみたところ、ローカルWebサーバが起動した。http://localhost:8000/ にアクセスして .html を開いたところ、Godot 4.1.1 でエクスポートした html5 を実行することができた。助かった。ありがたや。

ちなみに、Webサーバが Apache で、Godot からエクスポートした html5 を置きたい場合、.htaccess に以下も書いておいたほうがいいのかもしれない。

AddType application/octet-stream pck
AddType application/wasm wasm

Header set Cross-Origin-Embedder-Policy "require-corp"
Header set Cross-Origin-Opener-Policy "same-origin"

以下のページで配布されてる。

_love-stable : Bart van Strien

以下を打てばインストールできる。

sudo add-apt-repository ppa:bartbes/love-stable
sudo apt update
sudo apt upgrade
sudo apt install love

love2d 11.4 PPA版が動いてる環境と動いてない環境に対して、まずは /usr/bin/love のバイナリに違いがあるのか調べてみた。

md5sum という、MD5アルゴリズムによるハッシュ値を取得するツールを使って、/usr/bin/love に違いがあるのか確認。

$ md5sum /usr/bin/love
3c9d0f4a64e21be46ebf56cd253668fc  /usr/bin/love

どちらも同じ値になった。つまり、異なるバイナリを動かしているわけではない、と分かった。

次に、ldd というツールを使って、それぞれが要求する共有ライブラリの一覧を取得した。

ldd /usr/bin/love

_edit_love_dep_so_i52500.txt (動かない環境)
_edit_love_dep_so_onvm.txt (動く環境)

Windows10 x64 22H2 + WinMerge 2.16.20.4 を使って違いを眺めたところ…。

• 依存している *.so の数が全然違う。
• 動かない環境の love だけが libsndio.so.6.1 に依存している。
• 動く環境では、love は libsndio.so.6.1 に依存していない。
• 呼び出される libSDL2-2.0.so.0 の場所が違う。動く環境は、/usr/lib/x86_64-linux-gnu/。動かない環境は、/usr/local/lib/。

ls /usr/local/lib で、/usr/local/lib/ 内のファイル一覧を眺めてみたら…。

_usr_local_lib.txt

love2d が動かない環境では、/usr/local/lib/ 内に、SDL2関連ファイルがごっそり入っていた。これらのファイルが呼ばれてしまうことで、動作が違ってしまっていたようだなと…。

どうしてこんな状態になっていたのか、日記を検索して調べてみたら、2017/10/28頃に go-sdl2 というライブラリの動作確認をするために、SDL2関連のビルドとインストールをしていた。このせいでおかしなことになっていたのだな…。

_mieki256's diary - Ubuntu 16.04にgolangとgo-sdl2をインストール

そんなわけで、libsndio.so.6.1 が無い、といったエラーが出てアプリが動かない場合は、共有ライブラリがおかしなことになってないか確認する、というのはアリなのかもしれない。

以下を打てば共有ライブラリの一覧が見れるし、libSDL2* がどの場所にあるか確認もできる。

ldconfig -p

$ ldconfig -p | grep SDL2
        libSDL2_ttf-2.0.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so.0
        libSDL2_ttf-2.0.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so
        libSDL2_mixer-2.0.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0
        libSDL2_mixer-2.0.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so
        libSDL2_image-2.0.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2_image-2.0.so.0
        libSDL2_image-2.0.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2_image-2.0.so
        libSDL2-2.0.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
        libSDL2-2.0.so.0 (libc6) => /usr/lib/i386-linux-gnu/libSDL2-2.0.so.0
        libSDL2-2.0.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so