■ 開発日記 巻之七拾弐


OSTRA / Takeshi Yoneki


ブラッドボーン (PS4)

 緊急事態宣言のもと、自宅に引きこもってやることといえばやっぱりゲームという人が多いのか、先日近所のゲオを見たらスカイリムもフォールアウト4もダークソウル3もなかった。で、ゲームをプレイするとどうしてもコントローラーが壊れる。ゲオの店頭ではPS4向けは怪しい非ライセンス品と小さいホリコンしかなかった。ようはブラッドボーンで主人公が前に走らなくなったのでコントローラーとダークソウル3を物色に行ったら悲惨な状況が展開されていたというわけだ。ブラッドボーンとデス・ストランディングはちゃんと並んでた。沢山売れたから中古にも沢山流れてるのだろう。

 ヨドバシカメラの通販を見てもPS4純正コントローラーは全滅で入手不可。しかたないのでホリコンを注文。

 壊れたコントローラーはソニーに送付。Webでその辺の情報を得ようとするとあの手この手でサポートを断ろうと手ぐすね引いてる。PS4の設定の初期化とかいう操作までやらされちゃったよ。素直にジョイスティックが弱い部品だと認めろっての。任天堂はちゃんと改善したぞ。ソニーにできないはずはない。そのソニーさんに修理が集中してて、時間が掛かってるとWebに注意書きしてある。いやはや、弱い部品のまま改善しなかったツケですよこれ。

 以前に買ったPC/PS3向けのコントローラーはPS4でも動く。結構具合良い。でもタッチパッドがないので、一部の操作が行えない。

 緊急事態宣言解除で出勤が再開し、新宿のブックオフでダークソウル3を入手。Nintendo Switch向けに本当に移植してるんですかね。


2020.05.26


トルネコの大冒険2(PS)

 ブラッドボーンの最初の面の二人目のボスの神父が倒せなくてメゲたので暫く休止。デモンズソウルも結構休止した。PS VitaのAdrenalineでトルネコの大冒険2でも遊ぼうかとpops化したゲームデータをUSB接続でPCから転送したところ、転送に失敗する。半年ほど前にメモリーカードを初期化したのだがまた駄目になった。再度初期化。どうもフォーマットと表現されていても非常に速いので所謂クイックフォーマット。駄目な部分を隔離とかしてくれるわけじゃない。再度Henkakuを適用して再度Adrenalineなどをインストール。無事トルネコの大冒険2を遊べる環境を再構築。


2020.05.29


F1 2018 (PS4)

 一週間程でPS4コントローラーが返ってきたので、先日近所のゲオで買ってきたF1をプレイ。8bit機や16bit機の時代にはF1ゲームは全く興味がなかったが、DreamCastやN64向けのf1ゲームはプレイした。N64のF1ゲーム「F-1 WORLD GRAND PRIX」(VIDEO SYSTEM・任天堂)はやりたいことと処理能力のバランスが悪く、極めてカクカクで、あまりプレイしなかった。DreamCastのF1ゲーム「MONACO GRAND PRIX Racing Simulation 2」(UBI)は奇麗でスムーズに動き、結構プレイした。F1レースゲームはDreamCastの時代にはもうリアル指向となっており、プレイ感は極めて地味。基本的にはコーナーでクラッシュしないようにいかにブレーキを掛けるかという我慢のプレイ。リッジレーサーのようなファンタジー感はない。F1 2018は勿論リアル指向で、地味なプレイ感。


2020.06.01


エルミナージュIII (PSP)

 エルミナージュIIを3周して、とんでもなく強い敵は普通のプレイじゃ太刀打ちできないと理解し、IIIを始めたのが新型コロナ禍直前の2月初頭。オモテのボスは倒し、風の城を攻略中。風の城はセーブなし、マロール(ティオメンテ、ダンジョン内瞬間移動の呪文)なしという、いや、それはゲームデザイン的にアウトだろ、なダンジョン。片方ならまだしも両方は厳しい。なので、PS Vita + Adrenalineでのプレイは諦めてPCのPPSSPPでプレイ。ヘタレなのでオッケイ。ステートセーブいいですな。あぁそうだ、Adrenalineにもステートセーブはあるんだった、忘れてた。


2020.06.09


エルミナージュIII (PSP)

 Adrenalineのステートセーブを使ってみたが、非常に遅いのに加え、ロード後SE(BGMでない方のサウンド)が消えるという不具合あり。ということでGPD WIN2のPPSSPPでプレイ。無事風の城を終え、エルミナージュが出現したのでセーブデータをPS Vitaに戻す。もうマロールもセーブもある。


2020.06.10


 新型コロナ禍ということで「アンドロメダ…」「復活の日」「感染列島」を立て続けに観る。「アンドロメダ…」は昔のケーブルテレビの録画。原作はマイケル・クライトンの「アンドロメダ病原体」。「復活の日」はまぁ、例のアレだ。「人生はいいものだを日本語でなんていう」「人生はいいものだ」。原作は小松左京。「感染列島」は比較的新しい、21世紀の映画。「復活の日」と「感染列島」はアマゾンプライムビデオで観る。アマゾンプライムビデオは観始めの序盤、非常に映像が粗くなるが、もしかして数分一時停止などしてキャッシュを溜めると解消するのか?


2020.06.10


 皆さん、Kindle Paperwhite 第10世代のバッテリーセーバー機能使っていますか? Web検索すると切り方の設定方法がトップに出てくる程度に嫌われている機能なんですが、私は普通に使っていました。なぜなら、Kindle Paperwhite 第10世代には電源オフ機能がないのです。端末を電源オフに近い状態にするにはバッテリーセーバー機能以外用意されていないわけです。バッテリーセーバー機能が名前からは想像できない重要な機能である理由が解ったでしょうか。

 昨年後半くらいから朝の画面復帰が速いと気付きました。バッテリーセーバー機能が効いてないと考え、アマゾンのサポートに修復を打診しました。何ヶ月も掛かって結局進展なし。アマゾンのサポートはバッテリーセーバー機能は動作していると判断しました。実機を見てもいないのに。

 皆さん、バッテリーセーバー機能は効いてますか。睡眠等まとまった時間放置した後、復帰にちゃんと時間が掛かりますか? まずは個体の問題なのかファームウェアのアップデートによるエンバグなのか切り分けないといけません。Kindleのファームウェアは勝手にアップデートされて、しかも一方通行なので以前はどうだったかの確認が一切ユーザには出来ません。

 アマゾンのサポートとやり取りして得たのが「;dm」を検索するとログを出力するという機能の情報です。このログを読むと24時間毎にWi-Fi接続を試みていると記録されています。ハイバーネーションどころかサスペンドすらしてるか怪しいのですが、アマゾンのサポートにその辺をツッコんでも非公開情報がどうしたとかみくるちゃんみたいなことを言いだす始末。

 よくよく調べるとそもそもバッテリーセーバー機能が何なのかはアマゾンは説明していない。ハイバーネーションだともサスペンドだとも説明していない。説明していないから何が起きても起きなくても正常、といった立場を貫いている風です。

 電源オフ機能がないので、例えば何らかの理由で数ヶ月放置すると電池が完全に放電されるでしょう。それは端末製品の仕様として間違ってます。ハイバーネーションだったと考えられるバッテリーセーバー機能を取り戻していただきたい。それが直せない(アマゾンの技術力ではバグを取れない)ならば、電源オフを実装してくださいな。


2020.06.11


 Kindle Paperwhiteには双方向リンクを脚注としてポップアップする機能があります。まぁ、問題はそれが不適切な実装だということに尽きるんですが、詳しくはこちら「Kindle PaperWhite2013のリンクが脚注として表示される現象について」(http://densyodamasii.com/?p=2479)。最大の問題は脚注と判断するロジックが全く公開されていないということです。概ね双方向リンクを張ると脚注扱いされますが、双方向リンクは脚注のための機能でなく、電書魂さんのページにもあるように、目次で普通に使われる手法です。私はCalibreにRSSを食わせるという方法でニュースのEPUBを生成してMOBIに変換、Kindleで読んでるのですが、同じ問題に遭遇しています。目次で記事へのリンクをタッチすると脚注のポップアップが表示されるのです。かなり迷惑な機能です。これはKindle Paperwhiteが勝手に行っている機能なので、この動作をしないように設定できるべきなのですが、そんな設定は見つかりません。漫画向けの「見開きページのプレビュー」もKindle Paperwhiteが勝手に行っている機能なのですが、これはちゃんとオフにする設定があります。

 偶然ですが、脚注と判断させない方法が見つかりました。リンクの飛び先の方の戻るためのリンクの前に画像があると脚注と判断されません。アマゾンはこの不具合には長らく対処していないので、背に腹は代えられません。どう考えてもダーティーハックですが、EPUBの戻るリンクの前に1ピクセルの画像を入れるようにプログラムを書きました。


2020.06.14


ウィザードリィ エンパイアIII 覇王の系譜 (PS2)

 PSPのエルミナージュIIIも倒せないやつらのところまで来て、二周目をプレイする気はないので終了。プレイしてないWizardryモドキとして長らく家で積まれていたエンパイアIIIをプレイしてみようと思い立った。PS2のゲームはテレビを占拠することになるのでどうしても敬遠されがちになるし、そもそもPS2のゲームコントローラーが既に壊れかけ、実機では難しい。GPD WIN2 + PCSX2でエンパイアIII程度なら、あまり問題なくプレイ可能と判明。

 エンパイアシリーズは大昔ゲームボーイカラーの2作をプレイ。その後のPS1の「エンパイア 古の女王」「エンパイアII 女王の遺産」は入手もしてないはず。どこか中古屋に行けば買えるんだろうか。PS1のエンパイアは致命的なバグがあるそうなんで手を出すつもりはないけど。

 呪文を使わないとマップが見えないとか、ソフトリセットが割と時間を食うとか、半角カナは格好悪いでしょとか、文句もあるが、暫くプレイするとそれなりに面白くなってきた。マップの問題はステートセーブでやり過ごす。


2020.06.22


Windows 10にて以下のようにHTMLを書き、UTF-8で保存します。


<html>
<body>
<p>山田花子</p>
</body>
</html>

FireFoxで表示してMicrosoft Print to PDFでPDFで保存します。

Adobe ReaderでPDFを表示して「山田花子」をコピーして、文字コードを読めるテキストエディタ(例えばSakuraエディタなど)にペーストします。「山」と「田」と「子」が康煕部首(Kangxi Radicals)に化けます。

これ、FireFoxとMicrosoft Print to PDFとAdobe Readerの誰が犯人なのかわからなかったのですが、このなかに犯人はいなかったのです。犯人はメイリオや游明朝や游ゴシックでした。FireFoxでの表示にMSゴシックなどのフォントを使っていると化けません。


「見た目の変わらない文字化け―康煕部首とメイリオ」(https://scrapbox.io/jair/%E8%A6%8B%E3%81%9F%E7%9B%AE%E3%81%AE%E5%A4%89%E3%82%8F%E3%82%89%E3%81%AA%E3%81%84%E6%96%87%E5%AD%97%E5%8C%96%E3%81%91%E2%80%95%E5%BA%B7%E7%85%95%E9%83%A8%E9%A6%96%E3%81%A8%E3%83%A1%E3%82%A4%E3%83%AA%E3%82%AA)

「メイリオの罠」(http://espresso3389.hatenablog.com/entry/20090526/1243327471)

「How To Translate Unicode Character Codes to TrueType Glyph Indices in Windows 95」(https://github.com/LayoutFarm/Typography/wiki/How-To-Translate-Unicode-Character-Codes-to-TrueType-Glyph-Indices-in-Windows-95)

「PDFへの出力で文字コードのバグ?」(https://forums.ubuntulinux.jp/viewtopic.php?id=5102)

「改訂常用漢字表試案のPDFの「𠮟」とか」(https://moji-memo.hatenablog.jp/entry/20091222/1261461092)

「文字化けで一部の文字だけ何故かハテナに化ける」(http://workmemo.techblog.jp/archives/2020-06-29.html)

「CMap・cmap(Character Map)」(https://www.morisawa.co.jp/culture/dictionary/1921)

「GID/CID (Glyph ID/Character ID)」(https://www.morisawa.co.jp/culture/dictionary/1919)


結局のところ、Windowsのメイリオや游などのCJK対応したフォントではUnicode→GIDは一意だがGID→Unicodeは一意ではないという問題だったようです。印刷時プリンタドライバが貰える値はGIDで、それをPDFに出力するため、元のUnicodeの情報は残されていないわけです。PDFの規格ではGIDでなくUnicodeで作ることも可能なので、プリンタドライバ経由であることが最大のネックであるといえます。

で、納得できたら良かったのですが、どうもそんな単純な話ではないようです。

上記山田花子HTMLをInternetExplorer 11で表示させ、デフォルトではシフトJISを要求するのでUnicodeを指定してちゃんと表示させ、Microsoft Print to PDFで保存すると、康煕部首になりません。もちろんインターネット オプションでフォントをメイリオに指定した上でです。念のため印刷プレビューのフォントの変更でもメイリオを指定しましたが化けません。いったいInternetExplorerはどうやってるんでしょう。何か日本語環境向けに特殊なことをして上記問題を回避してるのでしょうか。各サイトの情報からすると原理的に回避不可能な話なんだと思うのですが、何か重大な見落としがあるのでしょうか。

FireFoxで保存したPDFとInternetExplorerで保存したPDFのどちらも/CIDInitが2つあります。ひとつ目がUnicodeを持っています。FireFoxの方には「山」のU+2F2Dが、InternetExplorerの方には「山」のU+5C71が記録されてます。つまり、どちらのPDFもToUnicode実現のための情報としてテーブルが用意され、InternetExplorerの方には適切な値が、FireFoxの方には不適切な値が入っています。この違いが何に由来するのかが問題点です。

次に、最初から康煕部首で山田花子HTMLを作りPDFを出力します。InternetExplorerのPDFは二つあった/CIDInitのひとつ目の方が出力されていません。FireFoxの方は二つ/CIDInitが出力され、ひとつ目の内容は不適切な値だったPDFと同じになっています。

はてさて、こうなるとFireFoxが犯人でないというのはちょっと違うのではないかと思えてきます。InternetExplorerはUnicodeとGIDの間に一意の関係がなかった場合、ToUnicode向けのデータをちゃんと出力しているけれど、FireFoxはそんなこと考慮していないとも言えるからです。ただし、Microsoftがプリンタドライバ向けの文書化されていないAPIを使ってる可能性も否定できません。

ただ、FireFoxには不利な情報もあります。MicrosoftはテキストのレンダリングにUniscribe APIを使っていると考えられますが、「remove the Windows platform font shaping backends (GDI/Uniscribe/DWrite) now that we use harfbuzz for all scripts」(https://bugzilla.mozilla.org/show_bug.cgi?id=985220)によると、FireFoxはUniscribeなどを使うのをやめてHarfBuzzに移行したそうです。このあたりが影響しているのではないかと思わないでもありませんが、よくわかりません。

Ubuntu 18.04のFireFoxでNoto Sans CJK JPを指定してPDFを出力した場合も化ます。

犯人はCJK対応フォントだが、FireFoxはその問題には対処してないってあたりなのかな、と。

新しいEdge(Chromium版)で作られたPDFをAdobe Readerで開いてみると、文字を選択できません。どうやらベクターグラフィックとしてのみ出力しているようです。これはこれで上記問題の解決方法ではあるんですが、なんというか問題から逃げた感が強く残念です。確か古いEdgeもInternetExplorerと同じように化けないPDFだった記憶がありますが、ちゃんとメイリオを指定していたかはっきりしません。

当面の回避方法は、FireFoxでPDFを作るならば、メイリオや游などのCJK対応したフォントを使わない、あるいはInternetExplorer 11で作る、という極めて消極的な対応しか残されていません。


2020.07.12


ウィザードリィ エンパイアIII 覇王の系譜 (PS2)

 GPD WIN2 + PCSX2。PCSX2のバージョンアップがあり、1.6.0。普段は普通のグラフィックを使うが、出勤時の電車の中など明るくて液晶画面が見づらいときは線画モードにする。ただし、Direct3Dのハードウェアモードだと線画がちゃんと表示されないので、ソフトウェアモードにしている。普通のグラフィックのときもソフトウェアモードの方が負荷が安定している。まぁ、アクションゲームではないから可能な設定だ。

 表のボスは倒したが、まだ続きがある。三人転職させた。ホビット忍者のHPがさっぱり上がらない。体力の最大値が16だからだろうが、割と困ってる。


2020.07.21


 .NET Coreを試してみようともはやオンボロマシンとなりつつある主力Windowsマシンのmonado君に.NET Core 3.1 SDKをインストール。どうもVisual Studio 2015 Communityではあまり上手く扱えないのでVisual Studio 2019 Communityを入れてみたわけですよ。これはもうメモリ的に32bitではギリギリ限界。アンインストール。

 Visual Studio Codeでデバッグなんかも可能なんだそうで、次はこいつを入れてみた。ところがだ、どうやら.NET Core 3.1 SDKでは32bitのデバッグがサポートされてない。あぁ、オンボロマシンはついに開発機として機能しなくなってきたわけだ。まぁ、既にAndroid Studioは32bit向けにはリリースされてないはずだし、何年か前に32bit版を動かしたら限界を超えてて、スラッシングが発生してた(勤務先の開発機)。

 64bit Windowsの載ってるVAIO君を引っ張り出してきてSDKとVSCodeをインストール。普通に扱える。ちゃんとデバッグも可能。

 VAIO君にはUbuntu 18.04も入れてあるのでそっちにもSDKとVSCodeを入れる。普通に扱える。しかしエディタ部分以外のフォントが小さすぎで厳しい。禁断のフォント倍率を弄ろうか。

 OCamlで書いたプログラムのF#への移植を始める。


2020.08.04


 今年に入ってからだと思うがFirefoxがやたらとクラッシュする。ページを開いたまま用事で他の事をして戻ってくるとクラッシュレポートのダイアログが出ているということが多い。クラッシュするのはYahooのページが多いのだが、何かFirefoxの秘孔を突くJavaScriptコードでもあるんだろうか。32bitのWindows版でしか起きないとかあるかもしれない。


2020.08.05


 VSCodeのエディタ部分以外のサイズ変更はコマンドパレットで「view zoom」と探すと出てくる。ちゃんとスイッチがあった。実のところ、UbuntuのTweaksでフォント倍率を1.75にしてしばらく使っていたのだが、PySVN-Workbenchでフォントが小さいままだったため、再度解決方法を探していた。PySVN-WorkbenchはTweaksのフォント指定には従うが一部倍率に従わないウィジェット(コントロール)がある。WxWidgetsのバグなんだろう。VSCode側で解決できるのなら倍率は使わない方向でオッケイ。

 文字実体参照とHtmlパーサをOCamlからF#に移植。割と機械的な書き換えで動く。


2020.08.08


 ITmediaの「六本木に本格フライトシミュレーターサロン登場」の記事を読んで、「そうだ、MSFS5を動かしてみよう」と思い立った。Microsoft Flight Simulator 5.1のCD-ROMを引っ張り出してきて、GPD WIN2のDOSBoxにインストール。3FPS程度で動く。こんなんだっけとDOSBoxのパラメータを弄ってみる。cyclesを20000に変更すると割とちゃんと動く(初期値のautoでは3000)。

 Microsoft Combat Flight SimulatorのCD-ROMを引っ張り出してきてインストール。割とちゃんと動くが、ジョイスティックがちゃんと認識されない。まぁ、ジョイスティック(フライトスティック)なしでドッグファイトとか不可能なので、実質的に遊ぶのは無理。MSFS5はDOSBox経由で、そもそもDOSBoxがイマドキの環境でDOSゲームをプレイできるようにというコンセプトのプログラムなので、ジョイスティックも使える。古いWindowsゲームでイマドキのジョイスティックを認識させる方法はないんですかね。そもそもDirectInputなのかも不明。

 A-10 CUBA!はインストーラーが16bitなので、まずはオンボロmonado君にインストール。足りないと言われるDLLを適当に探して入れてみたところ、monado君ではデモやプレイ画面までは動いた。飛行機の飛ばし方がわからなかったのでプレイできるかまでは試せてない。で、インストールされたディレクトリをGPD WIN2にコピー。メニュー画面までは動いたが、プレイ画面に行けない。「問題が発生したため、プログラムが正しく動作しなくなりました」。何が起きてるんだろう。動かなくても不思議ではないが。

 久しぶりにNintendo 3DSでパイロットウイングス リゾートを遊ぶ。Nintendo Switchには開発してないんですかね。


2020.08.17


 Ubuntu 18.04の公式音楽プレーヤーPhythmboxのプレイリストの坂本龍一を見て、ファーストアルバムの1曲目(千のナイフ)が一覧にないと気付く。プレイリストの元はWALKMANで使っている.m3u8ファイルで、単にファイルパスが一覧されているテキストファイル。色々やってみると素人臭い動きが見える。改行コードはCRLFでないと読まない。1行目はスキップされる。ちょっと出来の悪い部分もあるかなぁ。サウンド再生の部分はきっと頑張ってるんだろうけど、こういったUI周りの、さらに周辺部分はやる気ないよなぁ。


2020.08.31


 今年に入って位から、32bit Windows 10のFirefoxの調子が悪い。突然クラッシュするのはまだしも、描画のフリーズのような変な現象まで発生した。クラッシュがよく起きるのはYahoo!のサイト。Yahoo!のページを開いたまま暫く放置して帰ってくるとクラッシュしているといった感じ。64bit Windows 10や64bit Ubuntuではクラッシュの経験はない。32bit Windows 10だけやたらと落ちる。32bitと64bitの差と考えているが、一応もう一台ある32bit機を使ってみるか。再現したところで自力で何かできるものでもないけれど。


2020.08.31


 以前ならPythonで書いてきたようなちょっとした処理のプログラムを、ここ暫くはOCamlで書いたりしていたが、ロイターのサイトを読むプログラムで詰まってしまった。OCamlのSSLライブラリで落ちる件が解決できなかった。

 Visual Studio Codeと.NET Core 3.1を調べると、LinuxとWindowsでどちらでも動くちょっとしたプログラムを書ける環境として使えるのではないかと思えてきた。で、OCamlで書いたロイターのサイトを読むプログラムの移植を筆頭に、OCamlで書いたプログラムの大部分(実用してるもの全部かも)をF#に移植した。OCamlで書いた自作HTMLパーサがキモだったのだが、その移植が割とすんなり通ったのは流石F#はOCamlの方言だと言われるだけある。

 で、まだPythonで動かしてたrsyncモドキプログラムもF#に移植。結構最近Python3に移植してたのだが、Python3を本格的に使うくらいならF#を使った方が色々と良い。当面のテーマはPythonからの脱却であることは変わらない。


2020.08.31


 スラドで紹介されてた本、日本評論社の『「地球温暖化」の不都合な真実』。電子化されていない。もうこの時点で読むのは諦める。何度目かの電子書籍元年から10年経っても、いまだこの体たらく。


2020.09.04


地球温暖化懐疑論批判(PDF、東京大学、TIGS叢書)

 http://www.cneas.tohoku.ac.jp/labs/china/asuka/database.html(http://www.cneas.tohoku.ac.jp/labs/china/asuka/_src/sc362/all.pdf)

 これが紙でどんな判なのか知らないが、PDFのプロパティでは210x297mmなのでA4。23インチのフルHDモニタ(96ppi)で100パーセント表示でも字が小さい。ワードパッドでの游明朝9ポイントが同じようなサイズ。9ポイントかぁ、A4で9ポイントのPDFって電子媒体で読むことを全く意識してないよね。Kindle Paperwhite(6インチ、300ppi)で読むのはかなり厳しい。300ppiあるので、そのままでも一応文字の判別は付くが、A4をB7相当で読むってなると横表示にして拡大してようやくなんとか。サイズの大きい電子ペーパー端末をWebで調べると、Kobo Forma(8インチ、300ppi)なんかだとB6相当なので、かなり楽なのかもしれない。ともかくA4で9ポイントってのがそもそも厳しい。注釈とかさらにポイントが小さい。Asus TransBook T90Chi(8.9インチ、160ppi)では普通に表示したのでは解像度が低いこともあり読めたもんじゃない。あぁ、でもKobo Forma気になるなぁ、漫画が読みやすそうだ。楽天でなけりゃなぁ。


2020.09.08


 I/Oなどの、失敗することがある一連の処理を記述する場合、C系列の手続き型言語では以下のように書くことが多い。


bool func0(...) {
  if (!func1(...)) {
    return false;
  }
  if (!func2(...)) {
    return false;
  }
  if (!func3(...)) {
    return false;
  }
  肝心な処理;
  return true;
}

 どうやら、これには「途中リターン」などと名前が付いているようで、コーディング規約で禁止されていたりなど一部の界隈では禁じ手となってたりするようだ。まぁ、GOTOの一種なのだが、「途中リターン」を禁じるなら本質的に同じである「途中ブレーク」も「途中コンティニュー」も禁ずるべきで、そんな手枷足枷でプログラムを書くのは苦行である。

 ML系列の関数型言語、OCamlやF#やHaskelは普通に書くと「途中リターン」も「途中ブレーク」も「途中コンティニュー」もない。C系列の関数型言語のScalaやKotlinにはある。

 「途中リターン」なしをC系列で表現すると、以下のような書き方になる。


bool func0(...) {
  bool ok;
  if (func1(...)) {
    if (func2(...)) {
      if (func3(...)) {
        肝心な処理;
        ok = true;
      }
      else {
        ok = false;
      }
    }
    else {
      ok = false;
    }
  }
  else {
    ok = false;
  }
  return ok;
}

 「途中リターン」を使う最大の理由は、「肝心な処理」がネストの奥深くになることを避けることであり、読みやすさ向上のためのささやかな手法に過ぎない。

 F#で普通に表現すると以下のようになる。


let func0 (...) =
  if func1 (...) then
    if func2 (...) then
      if func3 (...) then
        肝心な処理 ;
        true
      else
        false
     else
       false
   else
     false

 オライリーの「プログラミングF#」でのコンピュテーション式の例がこの「途中リターン」の実現となっている。


type OptionResultBuilder() =
  member this.Bind (x, rest) =
    match x with
    | Some (r) -> rest r
    | None -> None  // 一度NGになったら後続の処理は行わない。
  member this.Return (x) = 
    x

let boolOption (b: bool) =
  if b then
    Some (b)
  else
    None  // falseをNGとする

let optionResult = OptionResultBuilder()

let func0 (...) =
  optionResult {
    let! _ = boolOption(func1 (...)) in
    let! _ = boolOption(func2 (...)) in
    let! _ = boolOption(func3 (...)) in
    肝心な処理 ;
    return boolOption(true)
  }

 とまぁ、こんな風に書けるわけで、確かに「肝心な処理」がネストの奥深くになることは避けられたが、読みやすさは向上しているだろうか。OptionResultBuilder型のBind関数とlet!の関係を知らなければ読みようがないコードになっており、「途中リターン」実現で得られるささやかな利益よりはコンピュテーション式導入での絶大なる不利益の方が上回っていると言えそうだ。


2020.09.09


 audio-technica ATH-M50のヘッドバンドの革(?)が劣化してボロボロ崩れ、中のスポンジが丸見えとなってしまった。もう何年も経っているのでしかたがないが、イヤパッドの交換品はあってもヘッドバンドはない。ということで、ヨドバシカメラで後継品ATH-M50xを買ってきた。新型コロナ禍が始まってからヨドバシカメラに行ったのは初めて。前回のリプレース前のATH-M50を買った翌日にATH-M50xがプレスリリースされたんだったか。モノは一緒なんだがケーブルが取り換えられるという仕組みが違い。M50xには3本ケーブルが付いてきた。


2020.09.14


 VSCodeにて、F5キーでデバッグを開始すると、既に開いているソースファイルを別のタブでもう一つ開いて動いていた。割と煩わしい動きだったのだが、バージョン1.49で解消されたようだ。でもリリースノートにはそれっぽい記載はない。

 リリースノートを読んでて気付いたんだが、スクロールバーのサム(ハンドル)のないところをクリックするとページ単位で移動した。Electronでも可能なんじゃないか。なんでエディタではページ移動でなくジャンプなんだよ。設定変更はないのかよ。

 「feature-request: click below/above scrollbar handle moves one screen height #43564」(https://github.com/microsoft/vscode/issues/43564)で、まさしくリリースノート読んでて動きが違うと気付いたネタがあがってた。Smalltalk-80の昔から30年以上にわたって使われてきたスクロールバーの機能を云々と書いてる人もいる。ホイールのないマウスでの操作の面倒さを書いてる人もいる。


2020.09.25


オブリビオン (PC)

 以前にオブリビオン日本語版はゲーム機向けにしかないと諦めていたが、再度PC版オブリビオンの状況について調べると、ファンによる勝手日本語ModがWindows 10でも動くということだそうだ。しかも以前はパッケージ版が必要だったそうだが、Steam版が特定のバージョンのd3d9.dllを加えることで動くと発見されていた。英語版のままならWindows 10で動くそうなんだが、日本語Modでは動かないそうだ。

 「Win10上で『Oblivion(オブリビオン)』を日本語化する方法 」(https://kakihey.com/pc-gaming-mod/oblivion-japanese/)を見ながら必要なファイルを探し、全部揃ってからSteamのアカウントを作成。オブリビオン デラックスを購入。

 GPD WIN2にて手順通りに作業を進め、日本語でオブリビオンが起動する。PC版のプレイは初めてなのだが、そもそもキーボードとマウスを前提としたゲームだった。GPD WIN2はジョイスティックとマウスが排他なので、ちょっと悩む。antimicro(ジョイスティックをキーやマウスのイベントに変換するソフト)にて仮に右スティックをマウスの移動、Rを左クリック、Lを右クリックにした。オブリビオン自体もジョイスティックを拾うので、Oblivion.iniでは bUse Joystick=0 に変更。

 チュートリアルを終了すると英語でクエストが発生した。DLC分の日本語を入れてないからだ。「OblivionJPModWiki (避難所) 派生版Mod」(https://jpmod.oblivion.z49.org/?%E6%B4%BE%E7%94%9F%E7%89%88Mod#gjnfre11)を見てachiさんのModを反映させる。起動してジャーナルを見るとちゃんと日本語になっていた。

 オブリビオンがGPD WIN2で遊べるのは嬉しいのだが、スリープさせると落ちるのは戴けない。日本語Modなしだと落ちないのでOBJAかOBSEの問題なんだろう。Steam版はOBSEなしでのOBJA直接インストールは対応していないため、原因がどっちなのかは調べられない。Alt+Tabで落ちるのは元々。

 さすがにこんなに文章の多いゲームを英語版のまま遊ぶという選択肢はないです。スリープさせられないのは厳しい。起動にそれなりに時間が掛かるので通勤電車で遊ぶかというと微妙かもしれない。

 試行錯誤してて気付いたのだが、実行モジュールに互換性設定すると起動すらしないのはSteamの制限なのか元々のプロテクトなのかはわからないが、ともかく動かない。

 フルスクリーンでなくウィンドウモードで動かし、他のウィンドウを前面にしてスリープさせると復帰後も落ちない。ただし、文字が表示されるべき部分が消えてしまう。安定してるとはいいがたく、落ちることもある。OBJPのソースを読んでみたい。


2010.09.28


 VSCodeでC++を使ってみる。GPD WIN2にも入れるということで、VCでなくMinGWで試す。VSCodeがGDBでのデバッグのフロントエンドになるってのは驚いた。で、fullscreenizerのソースを参考に、オブリビオンのウィンドウを疑似フルスクリーンにするプログラムを書く。オブリビオンをウィンドウモードで起動して後、外部からMoveWindowするだけ。こうすることで、Alt+Tabで落ちなくなる。デメリットはおそらく本物のフルスクリーンモードに比べて負荷があるだろうこと。

 外部から最小化もしてみる。最小化した状態でスリープして復帰した後は文字表示が消えるのは変わらない。


2020.09.29


オブリビオン (PC)

 GPD WIN2にてウィンドウモードでオブリビオンをプレイするとかなりファンがうるさい。フルスクリーンモードだとさほどうるさくない。それくらい負荷に差がある。GPD WIN2では現実的にはフルスクリーンモードしか選べない。

 ジョイパッドをマウスにアサインできるantimicroを使っているのだが、普通にWindowsで使っているとき、タスクマネージャーが前面にあるとマウスカーソルが消えてしまい、クリック(相当のアサイン)も効かなくなる。タスクマネージャーって予想外に怪しいツールなのかもしれない。GPD WIN2はスイッチ切り替えでドライバレベルのマウスモードが使えるから脱出はできるのだが、タスクマネージャー大好きな私にとって意外に難儀な話。


2020.09.30


マインクラフト (PC)

 いつのまにやらオンラインで普通にJava版のマインクラフトを買えるようになっていた。クレジットカード等を持ってなくてもプリペイドカードっぽいものも売ってるようだし、買いやすくなっている。マイクロソフトに買収されて販売方法関連が良くなるだろうとは思っていたが、結構時間が掛かった印象(気付かなかっただけ?)。その昔、マインクラフトを遊びたくてPS Vita版を本体ごと買った私である。

 GPD WIN2にJDK8をセットアップしてから購入、インストール。勝手にJRE8が入った模様、Java8のインストールいらないんじゃん。

 「保存せずに終了」がない。あぁ、もうSwitchなどのBedrock版と一緒で、ゲームをプレイしたら、なかったことにはできない仕様に統一されちゃったのか。ちと残念。元々Java版に「保存せずに終了」があったのかは知らないが、検索すると元々なさげ。むしろゲーム機版がBedrock版になるときにJava版の動きに統一されたと見るべきか。Switch版やPS4版も以前はオートセーブなしにできたようだし。


2020.10.06


Microsoft Combat Flight Simulator (PC)

 GPD WIN2でゲームの設定をする際、マウスとジョイスティックが排他という仕様(ジョイスティックをマウス代わりに利用するモードにするスイッチがある)は結構厳しいものがあるので、ビックカメラ新宿ハルク店でタッチパッド付BluetoothのASCIIキーボードを買ってきた。3E-BKY5という製品。使い始めてキー配列が絶妙に駄目な製品と気付いたが、まぁ、ここまでコンパクトだと、店頭には似た製品もなく、選択肢はない。

 「Microsoft Combat Flight Simulator」についてWebで検索すると、「Microsoft Combat Flight Simulator 1 joystick problem fixed(Win10)」という動画が見つかる。MSCFS1でジョイスティックが使えないという問題は皆に共有され、おそらく解決方法が存在するということだ。探すとちゃんと見つかった。古いWindowsで有効だったレジストリと現在有効なレジストリのパスが違うとのことで、実行モジュールのバイナリを直接修正するという力業だった。

 おかげで「Microsoft Combat Flight Simulator」をジョイスティックで遊べる。


2020.10.09


Tomb Raiders (PS, PC)

 先日書いたウィンドウを疑似的にフルスクリーンにするC++プログラムにTomb Raider IIを追加。Vaioをテレビに接続してフルHDでPC版Tomb Raider II(以降TR2)をプレイ。奇麗。PS版のTR2をPS3で見てみたが、ママはこれは酔うと言い出す。PSはテクスチャがらみで動きが怪しくて、ウネウネ動く。どのゲームでもそうなので、しかたがないのだろう。で、OpenLaraを思い出した。

 monadoにRetroArchの最新版を入れ、OpenLaraエンジンをダウンロード。PSのPSXファイルを指定してみたがいきなり落ちる。最新ではないRetroArchでやってみると動く。またかよ、RetroArchはレベルダウンが激しく発生する。Stableがちっとも安定してない。

 本家OpenLaraからダウンロード。readme.txtにはPCに適当にディレクトリを作り、そこにPSのCDの中身を全部コピーして、そのディレクトリにOpenLara.exeを入れろとある。Virtual CloneDriveの問題なのか、FMVファイルがコピーできない。起動、PS版Tomb Riders(以降TR1)が動く。ただし、一回終了させるともう起動しない。なんじゃこりゃ。Users\<ユーザー名>\AppData\Roaming\OpenLara に大量に出来てる.xshファイルを削除したら起動できるようになった。64bit Windows 10では起動できなくなることはない(.xshファイルも出来てる)。OpenLara開発陣は32bit Windowsでの動作確認は一切してないということだ。しかし、どうやったらこんなバグ仕込めるんだか。

 TR1はそもそもBGMはオーディオCDとしてトラックに入っているので、OpenLaraで再生させるには工夫が必要。試行錯誤の結果audioディレクトリを作ってそこにtrack_02.wavで始まるトラック番号付きのファイルを入れると判明。readme.txtには「track_*.ogg, track_*.mp3」と書いてあるが.oggは再生されるのものの.mp3はノイズが出力される。.wavが再生されるとの情報はないが再生される。トラック番号が2桁の数値で、トラック番号02から始まるなんて情報も見つからない。iTunesでのリッピング結果をこのルールでリネームするプログラムを書き、BGMは用意できた。

 TR1のCDからだと普通にFMVはコピーできた。しかしFMVを入れるとOpenLaraが起動しない。ムービーは再生できない。PSのFMVは特殊な形式らしく、jPSXdecというツールを使って展開しないと読めるFMVにならないそうで、これで用意したFMVでムービーもバッチリ。

 Vaioをテレビに接続してフルHDでPS版TR1をOpenLaraでプレイ。奇麗。TR2は17インチブラウン管モニタ時代から奇麗さは堪能していたが、TR1はPS版しか持ってないので(PC版はWindowsでなくDOS)こんなにはっきりくっきりなのは今回初めて見た。

 OpenLaraは操作性に関して、方向ジャンプの判定がシビア。割とその場でジャンプになっちゃう。

 OpenLaraでTR2をプレイした場合、ララの家にてタイムアタック表示がない。途中の網付きで登れる壁にてアクションが効かない(登れない)のはかなり致命的。ゲームステージで発生したら詰まる場合もあろう。PC版とPS版どちらのデータでも一緒。

 質問してる人がいた(https://github.com/XProger/OpenLara/issues/229)。「TR2 features are not implemented yet」だそうで、TR1は遊べるんだと思うがTR2はまだなんだと。そういうことはreadme.txtに書いとくべきだろう。イマドキのPCでどうにも動かなかったのはTR1だけなので、他の優先度が低いのはしかたあるまい。


2020.10.12


 VSCodeでC++を試してみようとWeb検索するとMinGWを使った方法が沢山出てくる。素直にMinGWを入れてみる。しばらくして.wavファイルを扱うコードを書こうと思い、こういうWin32 APIべったりな処理はC++だということでMinGWを「実際の開発」に使ってみようとした。きわめて残念な状況が判明し、MinGWを使うのは断念した。WindowsでC++を使うなら本物のVSのCommunity版を使えってことだ。昔と違って無料で配布してる。

 残念な状況

1. 最近のC++(例えばC++17など)を使うと、__ANSI_STRICT__が有効になり、ワイド文字関連の標準ライブラリ関数が壊滅状態になる。_wfopenとか_wstatなど、Unicodeを使うものがなくなるので、Win32 APIで自力で用意するなど、意味不明な労力を要求される。

2. 起動時のパラメタをUnicodeで受け取る方法が用意されてない。これもWin32 APIで自力で用意するなど、意味不明な労力を要求される。

3. FourCCがWarningになる。まぁ、gccってのはそうなんだろう。ウィキペディアによると「FourCC (フォーシーシー) とは、データフォーマットを一意に識別するための4バイトの並びである」と説明され、「Mac OS の OSType が起源であり」とある。32bitの整数の一種なのだが、Cのソースコードで'WAVE'というようにシングルクオートで囲まれた4文字のASCIIキャラクタで表現できる。.wavファイルのチャンクの識別に使われている。まぁ、FourCCなんてものと縁のあるプログラマは少数派だから、見たくなけりゃオプションを付けろという意味か。でもinteliSenseの動きの制御に四苦八苦ってのは本末転倒。

 そんなわけで、WindowsでのC++開発は本物のVSのCommunity版に戻る。


2020.10.16


Tomb Raider II (PC)

 TR2をイマドキのPC環境で動かすべく、NT系OSで動かすためのパッチを充て、その結果「ダメだ」は「No」に、時々ある寸劇やララの家のチュートリアルも英語になっている。「ダメだ」はダメだとしても寸劇はBGMと同じ扱いで、audio/cdaudio.mp3に入っているのでなんとかなりそうだと思ってからかなり年月が経った。OpenLaraでTR1が遊べるようになった記念にこれをどうにかしようと着手。

 Tomb Raiderファンのフォーラムでの書き込みで、audio/cdaudio.datの仕様がわかる(https://www.tombraiderforums.com/archive/index.php/t-139425.html)。

 試行錯誤の結果、

1. audio/cdaudio.datの記述の開始ミリ秒と終了ミリ秒はaudio/cdaudio.mp3に合わせる。

2. audio/cdaudio.datの各行のコメントらしきテキストも必要。

3. audio/cdaudio.mp3はCBRであればビットレートは問わない。

と判明。

 まず、元ネタのオーディオデータをPC版TR2のCDからリッピング。で、リッピングされた.wavファイルのミリ秒の長さを調べるプログラムをVSCode + MinGW(C++)で書こうとしたわけだ。不条理な制限に遭遇し断念してVS2015(C++)で書いた。AudioFixLiteの.wavファイルを扱う部分を持ってきてちょろっと書くだけ。各.wavファイルのミリ秒データと元のaudio/cdaudio.datを合わせて新しいcdaudio.datを生成するプログラムはVSCode + F#で書いた。

 ダミーの無音はSound Forge(の廉価版)で生成し、リッピングされた.wavファイルを連結するのはAudioFixLiteの得意技。LAMEは俺のプログラムでの指定がVBRでダメだったので、ACMコーデックでCBRの.mp3にエンコード。無事寸劇やチュートリアルが日本語化された。

 ララの家に行ってからトップに戻るとBGMが鳴らない。32bit Windows 10では鳴らないが64bit Windows 10では鳴る。元々のaudio/cdaudio.mp3等でも現象は一緒。64bit Windows 10という本来想定外の環境の方が真っ当に動くってのはなんだろう。


2020.10.19


オブリビオン (PC)

 Vaioにゲームパッドを接続し、テレビでプレイ。PC版オブリビオンはゲームパッドでプレイする前提で作られてないので、圧倒的にキーが足りてない。GPD WIN2でのプレイではキーボードと一体なので問題ないがテレビと接続するVaioでは問題。なるべくキーボードを使わないようにしたい。AntiMicroには特定のキーを押すと配置をシフトするという機能がちゃんとある。で、Opt(+) + PS(Home)キーに数字8を割り振った。ゲーム画面が消えて別のウィンドウが前面になってしまった。ええと、何が起きたんだ。調べるとオブリビオンの起動時に常駐するSteamが存在する場合に発生すると判明。Steamがゲームパッドのキーコンビネーションを奪って勝手な機能を割り振ってるということだ。

 Steamの作りが悪くてなかなか発見できない部分でAlt + Tabを発生させる設定があり、それを削除。ええと、Windowsのゲームで、全画面で動いてるとき、Alt + Tabでクラッシュする作品が多いのは常識なんじゃないでしょうか。Valveさん、余計なことしないでください。

 GPD WIN2でも削除しようとしたが、ロード中っぽい画面のまま辿り着けてない。こんなプログラムに付き合いたくない。出来が悪い。


2020.10.19


 GAFAとはなるべく距離は取りたい。色々と限界があり、電子書籍は電子ペーパーの専用端末においてはDRM問題からあちこち色々というわけにもいかず、Amazonに依存している。そんなことでの愚痴を書きたいわけじゃない。電子書籍はどうあるべきなのかという青臭いことを書きたい。

 本の販売業者が購入者の個人情報を把握するのは極めて危険なことだ。どの本を買ったのかという情報には思想信条が明白に現れる。現在Amazonは通販業者であるがゆえに本の購入者の名前と住所を購入した本のリストと簡単に結び付けられる。それが電子書籍にも適用される。

 Amazonに限らず電子書籍にDRMがあるのが当たり前になっている。サービス提供側が倒産などで継続できなくなったら本が消失してしまう危険と隣り合わせという話だ。我々は何を買ったのだろう、何の権利を得たのだろう。これは不誠実な商売ではなかろうか。確かソニーがPSP向けに漫画配信をしていたはずだが、そのユーザーの権利は適切に扱われているのか? 何か別のデバイス向けに引き継がれたのだろうか。

 結局のところ、個人情報を渡すことなく、DRMなしで、電子書籍を売買するという商売が成り立つのかという問題。最初からあきらめるのでなく、進むべき方向が見えればと思う。

 当面DRMはあってもしかたがないが、どこの扱ってる電子書籍も俺のKindlePWで読めるようにしてくれってのが最初の現実的な方向なのではなかろうか。サービス提供側の都合で読めなくなるという事態をなくすにはそもそも囲い込みをさせてはいけないということだ。Kindleで買ったらKoboでも読める。ebookjapanで買ったらKindleでも読める。これ、技術的弊害は存在しない。単に、サービス提供側の間でユーザーの購入情報を共有することが求められているだけ。放っておいてもプラットフォーマーがこの方向には動くとは全く考えられないので、何らかの圧力が必要なんだろうと思う。さて、我々に何ができるか。

 個人情報を渡さない方向へは、各国政府が動き始めている。度を越えた動きは違法とするのもアリではあろう。個人情報は利便性との兼ね合いらしいのだが、その利便性とやらを選ばない方法を用意してもらえないものだろうか。おかげでAndroidもiPhoneも持ってない。色々なことにスマートフォンが要求される時代になってきているのでどこかで年貢は納めないといけないとは思っているが、持ち歩く機器はEeePC以来長らくPC。Windows 10ではMicrosoftも色々情報を集めてるのが気に食わないのであるが。あぁ、そういえば一時期Nexus 7 (2013)を使ってた。スマートフォンではなくAndroidタブレット。

 当面はGAFAにブー垂れる必要がありそうだ。「アマゾンで購入した中国製バッテリーが原因で火災。アマゾンが審査を怠ったためとして提訴へ」(https://srad.jp/story/20/10/26/1958234/)とかね。お前らのやってる商売は限度を超えて不誠実だぞ、と。


2020.10.27


「英政府、SIMロック端末の販売禁止へ 2021年12月から」(https://www.itmedia.co.jp/news/articles/2010/28/news075.html)

 電子書籍のDRMもSIMロック端末と同じように国レベルで規制しないと変わらないってことだろうな。問題意識を共有しないとなぁ。民主主義的手続きは時間が掛かるし、なんとかなるとは限らないが、諦めないことが肝要かと。


2020.10.28


 Windowsのお邪魔機能SuperfetchがいつのまにかSysMainという別の名前になってた。さっそく止めなくちゃ。


2020.10.28


 池袋のビックカメラでKobo Forma 32GBを購入。普通に電源が切れる。


2020.11.01


 Kobo Formaに技術評論社で買った「[改訂第3版]C++ポケットリファレンス」のPDFを転送する。読もうとすると「この文書を開く権限がありません」となる。技術評論社としては閲覧を制限するようなDRMを掛けてるつもりは無いようだが、Adobe DRMの仕組みを使ってユーザーIDを埋め込むことはしているようで、Koboが間違ってかわざとなのかは知らないが表示できなくしている。これは、泣き寝入り案件か? EPUBがあるから致命的ではないものの、Kobo側としては自分のところで売ったわけでもないPDFなんて知ったこっちゃないんだろうけど、不誠実な扱いだなぁ。

 同じく技術評論社で買った「プログラミング in OCaml ~関数型プログラミングの基礎からGUI構築まで~」のPDFは開ける。ページ送りに変に時間を食うので実用的でないが、開けることは開ける。何が起きてるんだろう。


2020.11.02


 プラットフォーマーは作家がDRMを求めていると主張するんだろうけど、DRMはベンダロックの道具として機能する。これはしかたがないことなのか? 作家はベンダロックを求めているのか? 違うだろ。違う問題を混ぜないで欲しい。


2020.11.04


「ホーム」へ戻る


OSTRACISM CO.

OSTRA / Takeshi Yoneki