|
2018/12/31
投げ納め
なぜかYSFLIGHTの新バージョンがVectorに登録されないんだけど。年末は休みだったかな？
大みそかの朝はボウリングの投げ納めに行ってきた。というか普通の練習だけど。車で30分ほどの距離にあるBrunswick Playmor Zoneの試合に出るようになって、もう4シーズン目になるかな？ここは割とリーグ戦が無いときでもマメにレーンにオイルを敷いてメンテナンスが良い。しかし今日はまだオイル敷く前だったようでレーンはドライだった。最近試合ではレーン中央のオイルを利用することでほとんど10番ピンもはずさなくなったけど今日は10番ピン残したらほとんど取れなかった。
現在の自分の練習テーマはストライクのコースを早く見つけることと、見つけたらレーンの状態の変化についていくということだが、今日はストライクコースを見つけるのにほとんど1ゲーム目すべてを使ってしまった。見つけたあとは変化に着いていけたと思うけど、でもこれも試合だとこの倍以上の速さでレーンが変わるからなあ。引き続き練習しよう。
2018年中も大変お世話になりました。2019年もYSFLIGHT.COMをよろしくお願いします。
2018/12/29
ニューヨーク食い倒れ・本倒れツアー
我々が休みに旅行するとき、大体はミツワ(旧ヤオハン)と紀伊国屋または三省堂のあるところに行く。去年はサンフランシスコとサンノゼに行った。だが、飛行機で(乗客として)行ったから、生鮮食品は持って帰ってこれなかった。今年は、ニューヨーク、マンハッタンからハドソン川を挟んですぐ隣のニュージャージー、エッジウォーターに車で行ってきた。
ピッツバーグを出てからミツワまで、最後の最後以外まったく順調だった。が、最後にフリーウェイを降りるところが初見殺しだった。あれは一瞬冷やっとした。ドライバーを殺しにかかってる。フリーウェイI-95は、そのまままっすぐ突き進むと有料道路のトンネルを抜けてマンハッタンに突入してしまう。ミツワのあるエッジウォーターに行くにはその手前でフリーウェイを降りなくてはならない。フリーウェイから降りるために最も右の車線まで寄ったら、そこはHOV車線(High Occupancy Vehicle)で3名以上が乗った車しか通ってはいけない車線だった。仕方ないので車線を左に戻す。ところが、フリーウェイの出口はHOV車線から降りなくてはならないようにできていた。HOV車線を通っていいのか悪いのか？明らかな道路設計の欠陥だった。結果、僕は右に寄って、直後に左に寄って、また右に寄ってフリーウェイから降りることになった。
しかし、真の恐怖はこの後で、降りた直後何の前触れもなく右から別の道から車線が合流。これに気付いて冷やっとしてバックミラーを見るが何もいない。日本の自動車学校で叩き込まれた癖でブラインドスポットを目視。その瞬間、車が一台我が2008 Honda Fitの右をすり抜けていった。あと一秒早く僕がI-95を出ていたらぶつかっていた。標識はあったのかもしれない。だが、僕は車線を短い距離で三度も変えるために標識を見る余裕がなかったのかもしれない。左に車線を変更しようとしているときに右に標識があったら見えない。初見殺し。
そもそもフリーウェイから降りる車線をHOV車線にするべきではない。手前でHOV車線は終わるべきだ。いつからこの状態が放置されているのか知らないけれど、多分ここを初めて通るドライバーが何度も犠牲になったことだろう。そしてそのうち何名かは命を落としたことだろう。次回来るときはひとつ手前の出口から降りよう。10分かそこら余計に時間がかかるかもしれないが、死んでしまったら永遠に到着しない。飛行機だったらこういう欠陥アプローチがあったらすぐ是正されるんだけどね。車はいい加減なんだな。車の方が飛行機より危ない理由の一つは道路に欠陥があるということだろうな。
アメリカには欠陥道路は多い。ピッツバーグ、スクワレルヒルからI-376 Eastboundに乗る入り口は、一時停止の後短距離で二度車線を変更しなくてはならない。しかも、I-376から降りる車と経路が交差する。自分では多分100回のうち99回は何事もなく乗る自信があるけど100回乗ったら1回ぐらいは事故を起こす自信がある。1%の確立で死ぬような入り口は自分は絶対に使わない。オハイオ州デイトンからコロンバスに向かってI-70を走ってきて、I-270 Northboundに降りると間もなく右車線が無くなる。右車線が無くなるという標識はある。しかし、その直後左車線も無くなるが、標識は無い。しかも、徐々に無くなるのではなくナイフで切り落としたように車線が消える。最初にここを通った時、右車線が消えるというから左に寄っていたら死ぬかと思った。たまたま左右に車がいなかったから死ななかったけど。これも初見殺し。なぜこんな欠陥道路が放置されているのか。税金泥棒がいるんだろうな。
到着して、まずミツワで昼飯を食う。天ぷら定食は美味かった。北海道フェアをやっていて、ウニ・イクラ・エビ・カニ・ホタテ弁当が売っていた。思わず晩飯用に買ってしまった。痛風(英語でToo Foo。嘘だけど。)の原因物質は美味い。それから、隣の紀伊国屋書店でワンパンマン、銀河英雄伝説、ふらいんぐうぃっち、聖お兄さんの単行本を買う。我が妻と交代で3時間ずつの運転だったが、さすがに6時間も車に乗ってるのは疲れたのでその日は弁当とビールを買ってホテルに撤収。Homewood Suiteというホテルにした。ここは、前にも利用したことがあって非常に快適、のはずだったのだが、部屋に戻ってしばらくしたら、目が痒くなって涙が出てくる。鼻水が止まらない。風邪を引いたかと焦ったが、涙が止まらないのはどっちかというとアレルギー反応のようだった。一応、風邪だった場合に備えて体温を上げて免疫力を活性化するために熱めの風呂に入って寝たら鼻水は止まっていて、目のかゆみもやや引いていた。どうもベッドルームは大丈夫っぽいんだけどリビングにいるとアレルギーが出るようだ。
二日目。バス158番でニューヨーク・マンハッタンに行く。我が妻は本屋に放流すると何時間でも時間をつぶせるので、我が妻を紀伊国屋のマンハッタン店まで送って、僕はB&H Photo Videoの店舗に行く。実はつい最近B&Hからはオンラインで買ったものがあったけど、同じ値段で店舗でも買えるから、できればこのタイミングまで待ちたかったんだけど、そうもいかんかった。ただ、どうせUSB-C to USB 3.0 Type Aの変換ケーブルが多数必要になってたから3本ばかり買った。あと、最近まで使っていたIODATAのBlue Ray BurnerがWindows 10のアップデート後調子が悪くなったんでVerbatimのBlue Rayドライブを買った。光学メディアは長期保存に適さないってよく聞くけど冷暗所に乾燥剤を入れておいてあるCD-Rは20年ぐらい前に書いたやつがまだ読めるけど。少なくとも適切に保存すればSSDよりは持つんじゃないかな。
B&Hで買ったUSB-C to USB 3.0 Type-A
アダプタ。宣伝文句通りの性能を出している。
日本だったらカメラを買う前にヨドバシカメラとかビックカメラとかで手に取って感触を確かめることができるけど、アメリカではほとんど不可能。ベストバイには誰が買うのか理解不能なカメラしか置いてないし、ウォルマートだと安物しか置いてない。B&Hの店舗は多くの機種を手に取って使ってみることができる貴重な場所と言える。今回はSony RX 10 Mk IVをいろいろ試してきた。ソニーのスーパーズーム、RX 10 Mk IVは最長600mm望遠まで伸ばすことができて、恐ろしくオートフォーカスが速い。前回ヨドバシで少し試したときは時間が無くて何点か確認できなかった。とくに連射時の消像時間を確認したかったのでやってみた。結論：消像しないのね。記録中は直前のファインダーの内容を出しっぱなしにするようだ。これってハイスピードパスを撮るときめちゃくちゃ狙いやすいんじゃないだろうか。それにカメラ自体が軽いから振りやすい。あと昔のスーパーズームでよく見られた像の遅れも少ない気がする。スーパーズームが出始めたころ、試しにFuji HS20HXRを買ってみたんだけど、セスナ操縦しながら地上を撮影しようと思ったら像が遅れるもんだから頭痛がしてきたので以後空撮には使わないことにした。RX10だった大丈夫じゃないかな。
これ一台でほとんどの用途は済んでしまうんじゃないかと思ったが、野鳥までカバーしようと思ったら800mmは欲しい。画素数が多いからデジタルズームしてもいいんじゃないかという話もあるにはあるんだけど。12MPixelあったら相当細かいとこまで見えるもんね。広い範囲撮ったらって？オートフォーカスが変なところに合ってしまう問題というのがあって、できるだけ被写体周辺だけがファインダーに写るようにしたい。あ、そうか。フォーカス点の選択がどのぐらい柔軟にできるかも試してみるべきだった。ただ、ぼちぼちMk Vが出てもいいころなのではないかと思うんで、新しいモデルの最大ズームが伸びたら買いだと思ってる。貯金しておこう。
その後、紀伊国屋に戻って我が妻と合流。前日ミツワの隣の紀伊国屋ではワンパンマンの15巻と17巻が無かったのだが、マンハッタンの店にはあったので確保。銀河英雄伝説コミック版の方は、なぜかどちらも11巻しか置いていなくて、9巻と10巻が買えなかった。8巻まではすでにあるんだけど。次に日本に帰省したとき買ってくるしかないかな。紀伊国屋を出た時点で2時。その後4時過ぎぐらいまでBookoffにいて、日程終了。ちなみに我が妻はチャタム大学で日本語を教えているので教材をわんさか買い込んだようだ。バスターミナルに戻る途中いくつかの劇場の横を通過した。せっかくニューヨークまで来たからブロードウェイのミュージカルとか見るかという話もあったのだが、チケットがいずれも$100超えだったため、その金額で何か美味いものを食うことにした。それに結構歩き疲れて夜までマンハッタンに留まる体力無かったかも。
ホテルに戻る前にミツワの薬局で目薬を買う。それと、隣の雑貨屋でマスクを買う。実は最近特定の種類の猫で同様の症状が出ることがあったが、そういう状態でもマスクをしていると鼻水は防止できることがわかっているので、ホテルでマスクをしてみたらアレルギー症状は出なかった。前に泊まった人が猫飼ってたのかね？だとしても、ベッドルームで症状が出ないのはなぜなのか？ベッドルームは真剣に掃除しているとか？あるいはバスルームがベッドルーム直結だから湿気が高いのかな。湿度が高いとホコリとか湿って重くなって空気中に舞いにくいとか聞いた気がする。
三日目。朝、顔を洗った後うっかりマスクを忘れていたらさっそく涙目になってくる。マスクをして目薬をさす。朝、また185番のバスでマンハッタン入り。イントレピッド海・空・宇宙博物館に行く。ここには、コンコルド様が鎮座しておられる。うう、コンコルド様、おいたわしや。かような場所で博物になっておられるとは。(博物館にあるものだから「博物」じゃないの？)ここにはブリティッシュ・エアウェイの機体番号G-BOADが鎮座してあらせられる。けど、ひどいもんでハンガーも無く海風にさらされている。この機体は仮にもう一度飛ばしたいと思っても復元して飛ばすのは無理だろうな。ここには過去三度は来ているはず。ただ、数年前にスペースシャトル・エンタープライズが加わったということなんで見ようと思った。
185番バスを降りて徒歩10分程度で現地到着。着いたのはいいのだが、ありえない大行列。以前来た時はこれほど混んでなかった。このままでは並んで一日終わりそうな勢いだったので残念ながら断念。なお、ニューヨークのこういうアトラクションは前売り券は買わない方がいい。入れないことがあるから。仕方ないから外からG-BOADを見るだけにして、ロックフェラーセンターに向かう。ここもあり得ない人込み。なんかイベントでもあったんだろうか？ロックフェラーセンター前に大きなクリスマスツリーが毎年飾られてるんでそれを見ようとしたんだけど、人をかき分けて歩くのはかなり疲れた。博物館とか美術館とか大した距離を歩いていないのに足が次の一歩を踏み出すのもつらいような疲労に襲われる現象。英語だとMuseum Fatigueって言うらしいけど対応する日本語ってあるのかな？一応、ツリーを見ることはできた。ロックフェラーセンターのビルの上層階の展望デッキはおそるべき行列ができていたのでパス。その後、カフェ・ザイヤで遅い昼飯の後、我が妻は無印良品へ。僕は紀伊国屋で待つ。マンハッタンの紀伊国屋、Bookoff、無印良品、カフェ・ザイヤなどは大体徒歩圏内に集中している。
Intrepidに来てみたものの。。。。
ありえない大行列。
コンコルド様。
なお、ニューヨークのこのあたりのトイレ事情は厳しい。バスターミナルのトイレは待ち時間無しだった。ロックフェラーセンターのトイレは、トイレにたどり着くころには日が変わるのではないかと思うような行列。無印良品にはトイレ無しと判明。紀伊国屋にはひとつだけトイレがあるがいつも行列している。ひょっとすると紀伊国屋の正面の図書館内に公共トイレがある可能性はあるけど外の公園のトイレも多分一時間待ちぐらいの行列ができていたから同じぐらい待ち時間があったかもしれない。とくに、Museum Fatigueになるとそれまでぜんぜんトイレに行きたくないと思っていたのに一分後には緊急事態というようなこともなぜか起こるので、とにかく、使えるタイミングで体を軽くしておいた方がいい。緊急事態になってからでは多分間に合わない。たまたま紀伊国屋のトイレに既に並んでいたときにその現象に見舞われたからなんとか助かったけど。
というわけで、ほとんど買い物して食っただけのニューヨークの日程終了。晩飯はまたミツワで寿司買ってホテルで食べた。痛風の原因物質はうまい。
最終日はあいにくの雨だった。とりあえずホテルをチェックアウトしてミツワ。正月の買い出しを済ませて昼飯。山頭火の塩チャーシューメンにした。
ミツワのフードコートの山頭火のラーメン。
帰りのルートだが、前回来た時怖い目に遭っている。前回GarminのGPSが出したルートはフリーウェイの入り口が一時停止な上に合流が短い。しかも、停車位置から左後方がめちゃくちゃ見えにくいアングルになっていた。ピッツバーグのスクワレルヒルからI-376 Eastboundの入り口の交通量を3倍にしたような入り口。3%の確率で事故死する気がする。だから、今回は帰りはひとつ遠くの入り口から乗ることに決めていた。そこに向かう途中、ニュージャージーのユニクロと無印良品に寄る。我が妻はユニクロや無印に放流すると当分帰ってこない。なのでベンチに腰かけてこの文章をタイプしてる。
帰りはニュージャージーのユニクロを3時半ごろ出発した。最初の二時間ぐらいは雨の中の運転だった。しかも平日の夕方で車の量が多いし。その後しばらく順調。ハリスバーグを超えたあたりで濃い霧の中を走らなくてはならなかったけど、それを過ぎるとまた順調。帰り着いたのは10時半ごろだった。
2018/12/23
なお、YSFLIGHT最新版はアップロードしたので多分今日明日中にVectorに登録されると思う。
FM-7/77用RS232Cカード制作プロジェクト
今でもときどきヤフオクで中古の富士通FM-7シリーズ8ビットPCが出品される。割と動作品を入手するハードルは高くない。モニターが接続できてキーボードも使えるようにしたら、次の問題はどうやってWindowsなりMacなりからデータやプログラムを持ってくるか。FM77AV40以降の機種であれば、RS232Cポートが標準装備だから簡単なF-BASICのプログラムを書けばWindowsからデータを流し込むことができる。
しかし、FM77AV以前の機種だとRS232Cポートはついていない。そのままだとカセットインターフェースケーブルを入手あるいは自作して音で流し込むしかない。XM7が出た当時手元のディスクはすべてイメージ化してバックアップしたものの、既にディスクそのものは無く、これをなんとか再度実機で実行できないか、と思ったら一応カセットインターフェースケーブルを自作してDisk2Tapeを使ってディスクイメージを実機に転送することは可能。しかし、なぜかWAV化したディスクイメージを再生しても実機が認識するPCと認識しないPCがある。別のPCで録音してみたら波形はきれいだったから、多分、オーディオデバイスの最大ボリュームの問題だと思うんだけど。手元にあるPCでは以前はDell XPSデスクトップと2008 MacBook Proで再生したWAVは実機FM-7、FM77AV、FM77AV40がすべて認識できたが、他のPCでは失敗した。この方法は使うPCによって成功したり失敗したりする。
だからFM77AV40より前のFM-7系機種はせっかく動作する機体が手に入っても陸の孤島になってしまうかもしれない。
富士通純正RS232Cカードさえ手には入ればなんとかなるのだが、ヤフオクにも滅多に出てこない。出てきたとしても多分おそるべき金額に値段が吊り上がるから勝つのはかなり難しい。というような話をカーネギー・メロン大のコンピュータクラブでボソッと言ったら、回路図があったら作れるよ！と力強い言葉が返ってきたので、そこで、FM-7、FM77AVでもRS232Cが使えるように純正RS2323Cカード互換カード制作プロジェクトを開始してみた。(続きを読む)
2018/11/12
Demosplash 2018 祭りの後
Demosplash 2018が終わってしまって、なんか秋学期が終わったような気になってる暇もなくボウリングリーグは続き、学期末にかけて大学はクライマックスに向かっていく。(続きを読む)
COMODO CAは返金してくれるとのことで現在返金待ち中
$179払うまで個人開発者にはCertificateを発行しないという説明が一切ないような業者だからそのまま$179取られて返ってこないかと心配したけど。でも本当に返金が確認されるまで油断できない。
2018/11/04
Demosplash 2018レトロデモ部門2位獲得！
堂々の2位。首位に1点差で敗れた。投票の結果150対149だったか149対148で惜しくも2位。レトロ部門は5件しか応募がなかったけど。そのうち2件は僕の作品だったけど。
1位のApple II用デモはたしかによくできていた。来年こそは首位奪還を目指さねば。
なお、応募作品のバイナリ、ソース、ムービーなどは近日中に公開の予定
COMODO CAにだまされる
最近のmacOSやWindows 10ではサインしてないコードを実行しようとすると出どころ不明のプログラムをまず実行させてくれない。もちろん手動でセキュリティの設定を解除して例外を認めれば実行することができるが、まるでそのプログラムを実行すると世界が終わるような脅迫めいた警告メッセージに対してYesと答えなくてはならない。
だから本当はYSFLIGHTもコードにサインして送り出したいのだが、問題はサインするための証明書がひどく高い。フリーソフトを公開するために既にAppleに年間$99払っている。これに加えてWindowsでも使えるコードサイン証明書を買おうと思ったら大体年間$200かかる。とても手が出ない。
基本的にこれは業界全体でセキュリティの名を借りてフリーソフトを駆逐しようとする動きの一部と言える。YSFLIGHT.COMは一応広告収入とシェアウェアの売り上げで少しの収入があるものの経費を差し引くと赤字になってる。だけど確定申告で三年以上赤字にするとだめだと言われたから(なんで？)一部経費を申告しないという我慢で確定申告では黒字なことになってる。そんな状況で、認証のためだけにAppleに$99、Windows用に$200も毎年払い続けることはできない、と思ったらCOMODOだったら年間$179でAppleとWindowsどっちもカバーすると宣伝している。だったら今年はAppleに$99払うのやめてCOMODOから認証を買うか、と、思って早速$179払った。
ところが、払った後でわかったのだがCOMODOは個人事業主(事業してるつもりはあまりないんだけど)には証明書を発行しないそうだ。発行するには弁護士、公証人、または会計士から一筆書いてもらわなくてはならなくて、当然そんな一筆を頼む予算は僕には無い。$179払い終わるまでどういう書類を提出しなくてはならないのかの説明が一切なかった。やられた方から見たら詐欺だ。当然のごとく自分のアカウントからは認証の発注をキャンセルするようなボタンもリンクも無い。この$179取り返せるかどうか。$179もあったらセスナ借りて1.1時間飛べる。ヤフオクでFM-7用レトロゲームが3本は落とせる。ひどい話だ。COMODOがこのまま僕のアカウントを未認証のまま放置して結局$179も返金しないのではないかというのが心配。
仕事で研究プロジェクト用のコード書いて納品(とはやや違うけど)してるからセキュリティがどれほど重要かは理解できる。だけどフリーソフト作者として、プログラマーは自分のプログラムを自由に発表できるべきだと信じている。そして、バイナリを公開するかソースを公開するかはそのコードを書いた人または権利者が決めるべきだと思う。業界がこれほどフリーソフトに敵対的なのは非常に残念なことだ。
なお、コードサインが悪いと言ってるのではなくて、個人あるいは小さなグループの開発者でも買える証明書があるべきだと言ってる。
ちなみにAppleに$99払うのはやめることにした。
2018/11/01
明日と明後日、CMUでDemosplash 2018が開催される。今年はレトロ部門でFM-7用とFM TOWNS用のデモを一本ずつ書いた。それぞれのコードはイベント終了後に公開予定。新しいソフトウェアが開発されて公開されている以上、FM-7もFM TOWNSもプラットフォームとしてまだ生きていると言えるはず！
イベントの模様はネットで生中継される(その後は録画を視聴可能)らしいので、よかったら視聴してください。生中継の情報などは下のURLから↓
http://www.demosplash.org/broadcast
なお、イベントはアメリカ東部時間金曜日19:00-23:00、土曜日昼-22:30の予定。デモコンペティションは土曜日15:30からなので、日本時間だと午前2時半から。
2018/10/30
ピッツバーグは比較的治安の良い都市、というか全米でもかなり上位に入る治安の良い都市なのだが、近所のユダヤ教礼拝所で11名が犠牲になる銃撃事件が起きてしまった。事件現場は住んでる場所から車で10分かからない。頻繁に前を通るし、友達が通っていた礼拝所で彼の長女のネーミングセレモニーに参列したこともある。当日、カーネギー・メロン大学からテキストメッセージのアラートが届いた。我が妻にはカーネギー・メロン大とチャタム大(両方で仕事しているから)から同様のアラートが届いた。ウィルキンスアベニューとシェイディーアベニューの交差点で警察の作戦が進行中という以外その時点では何が起きているのかわからなかった。テレビをつけて5分か10分待って始めてローカル局が礼拝所で銃撃事件があったと報道した。
驚いたというよりは、ついに起こるべくして起こったか、と思った。今のアメリカを覆う恐怖と不安、それに怒りの感情がいつかこういう事件の引き金になるのではないか、とくに中間選挙前に何か起こるのではないかと心配だったのだが、その予想が的中してしまった。
不幸中の幸いにして直接の知人で怪我または亡くなった人はいなかったのだが、犠牲者のうち二人、Cecil RosenthalさんとDavid Rosenthalさんの兄弟は前のアパートに住んでいたとき近所でよく見かけた人だった。後で知ったのだが、同じアパートに住んでいたそうだ。よく近所で見かけるとは思っていたけど、同じアパートに住んでいたとは。大きなアパートだったから気がつかなかった。
日本ではよくこういうときに皮肉を言うと不謹慎だと言いがかりをつける人がいるが、それは違う。皮肉を言いたくなる心理というのは強烈な現実感だ。と、僕は思う。むしろ、そういうのをつかまえて不謹慎と言いがかりをつける人は、多分自分は安全なところにいて事件・事故・災害は自分の身に降りかからないと思ってる。今回はユダヤ教礼拝所が狙われた。だけどいつ大学が狙われるか。その銃弾は僕に向けられる可能性もあった。皮肉のひとつも言いたくなったが、やっぱり今はやめとく。
だからといって、僕が精神的にダメージを受けたかというとそうでもないと思うんだけど。何かしよう、と、思ってYSFLIGHTのアクロバットを追加して、ユダヤ教のシンボルであるダビデの星を描いてみた。なお、スモークを曳いてるのはイスラエルのクフィール戦闘機。フライトレコードファイルはここからダウンロードできる。なお次のバージョンだとメニューのオートデモから実行可能になる。
再分散化？
もう20年も前だったかBlogが流行ってBlog-Hostingサービスが出てきたころ、ローカルなバックアップが取れないのが嫌で使わなかった。ローカルなバックアップが取れるようなのもあったようだけど、じゃあ今度はそのホスティングサービスが終わったとき別のサービスに簡単にリストアできるのか？あんまり簡単じゃなさそうだったんで使わなかった。BlogなりWebサイトのコンテントの責任は作ってる本人にある。だから本人がバックアップを取れないサービスは使わない。いや、どんなシステムでもローカルなバックアップが取れないシステムは欠陥品と言っていい。だから僕はこうして旧態依然たるWebホスティングを使ってる。
FaceBookとかMySpaceとかMixiが出てきたときは、なんでWebサイトと同じことをわざわざ窮屈なサービスでやりなおさなきゃならないんだ？ローカルにバックアップが取れない点、それと他のサービスに移転しようとしてもできないこの2点の致命的な欠陥があるから僕はFaceBookはただの自動更新型アドレスブックとして使ってる。そもそも、自分のWebサイトのコンテンツは自分のものなのにそれを提供して他人に儲けさせるのは納得いかない。プログラミングを覚えるためにこれまで、金、時間、若さ、社会生活、それに頭髪を犠牲にしてきた。何をフリーにして何をフリーにしないかは自分で決める。
GitHubが台頭してきて、なんでもかんでもGitHubにホストされるようになって戦慄した。例えば僕が悪属性のハッカーだったとする。そうだったら僕は有名なプロジェクトのソースコードに悪コードを仕込む。次回そのプロジェクトが公開されたとき公式からダウンロードして実行した人全員が餌食になる。なんでもかんでもGitHubに集中してるんだからどこを狙えばいいのかは明白だ。だから僕は頑固と言われようがなんだろうがレポジトリはローカルに運用してる。
上すべてに共通するの問題は囲い込みだ。ユーザを自分とこのサービスに囲い込んで他に移行できなくする。なんでも中央集権化しようとする。自分のコンテンツや個人情報がコントロールできなくなる。今のコンピューティングは悪い方向に向かっている。なんていうことを危惧してるのは僕だけかと思っていた。ソーシャルメディアの問題を提起する人はいるけれど彼らが心配してるのはどうやったら情報が安全に管理されるかということで中央集権化自体はあんまり心配してないような感じがしていた。
と、思ったらかなりの有名人が同じ危惧を共有してたらしい。Solidプロジェクトに一筋の希望を見た気がする。 https://solid.mit.edu/ (うーん、理念には共感するけどソースはGitHubにあるんだね。)実は今自分のオープンソースプロジェクトをどうやって公開しようか困っていて、Polygon Crestなんか頻繁に更新しているのだがタイムリーに公開できない。なんでかというとリリースパッケージを作ってテストするよりもプライオリティが高い仕事が多すぎる。できればオープンソースのレポジトリを外部からもread-access可能にしたい。GitHubを使えばできるんだろうけど中央集権化に加担するのは嫌だ。 Polygon CrestとかSolidのプラットフォームで公開できるのかな？現在検討中。
とりあえずPODなるものを作ってみたのだがいまのところ何も有用なことはできていない。Firefoxと相性が悪いのかな？
よく航空機事故の後で、たまたま墜落機を乗り逃して生き残ったみたいな話を聞く。そういう話は大体、用ができたとか渋滞があったとか、不運にして飛行機に乗れなかったと思ったらおかげで生き残って実は超幸運だったという展開が多い。奇跡的とか思えるような話だけど、最近の航空機が数百人も乗せられることを考えるとおそらくどのフライトも2〜3人は乗り遅れが発生していると考えられる。だとすると墜落事故一回につき2〜3人は奇跡的に生き残っている可能性が高い。だから、僕も同じだけの確率で奇跡的に事件・事故を回避する機会がある。この世はおしなべて確率的にできている。航空事故ほどドラマチックではなかったけど昨日そういうことがあった。
毎週木曜はボウリングの試合があるからボウリング場まで行く途中だったのだが、数台のパトカーが自分が向かっているのと同じ方向に走っていった。多分事故でもあったのだろうと思った。ところが、大雨の影響で道路が冠水して通行止めになったらしい。パトカーは車をブロックするために走っていったものだった。数台の車がその方向からけん引されて出てきたので、多分エンジンまで水につかって走れなくなったのだろう。死者が出たとはニュースになっていなかったから多分乗ってた人は予期せず水泳する羽目になっただけで済んだ。多分。
もしも僕があと5分ぐらい早くうちを出ていたら冠水に突っ込んでいた可能性が高い。冠水していた場所は谷底みたいになっているから上の方からどんどん水が流れ込んできていた。ひょっとすると走ってるうちに一気に水位が上がって出られなくなる、なんていう目にあったかもしれない。ところが、今日は雨が激しかったから我が妻(同じくCMUに勤務)に電話してうちに車で送ってから出ることにした。それを見越して早めにうちを出たものの、普通5分もしないで着く距離が10分以上かかってしまって、結果的にボウリングの試合に向かうのは当初の予定よりも10分ばかり遅くなってしまった。この10分の遅れがなければ多分我が車は冠水地帯からけん引されて出ることになったと思う。
実際水が溜まってるところは自分の位置からは見えなかったが水は1時間ぐらいで引いたらしい。水が溜まったというよりは谷底に上流から水が流れ込んで川のようになってすぐ横のモノンガヘラ川に流れ込んでいる間だけ道路が通れなくなっていたらしい。その影響で練習投球には間に合わなくて、5フレーム目までに到着すればそのゲームに登板できるルールで、4フレーム目ぐらいに現地についてウォーミングアップもしないまま4フレームを投げたんでそのうち2フレームを落としてしまって、169。ただ、1ゲーム目後半でレーンを読めたから2ゲーム目は211。3ゲーム目は、いいところに命中してピンがはじけ飛ぶんだけどなぜか1ピンだけ残るというかなり忍耐力を要求されるゲームになって188だった。ただ、宿敵の10番ピンはスペアショットですべて取ったし、一度は6-7-10スプリットをスペアにした(大体1年に1回ぐらいは出る)。車が水没してけん引されて出る羽目になっていた可能性を考えると幸運な日だったと思う。
2018/09/30
ログブック一冊目終了!
ここ数日、アップルの奴め余計な作業を増やしやがって！新バージョンのOSなぞ迷惑なんじゃ！と、macOS 10.14を呪いながら予想外に書き換えの必要な箇所が多くくなってしまったYSFLIGHTのコードの書き換えをやってたけど、気を取り直してBeaverから飛んできた。今日のフライトで、一冊目のログブックの全ページが埋まった。(続きを読む)
2018/09/29 macOS 10.14の迷惑
なんかもうひとつ地雷踏んでたらしく、キャッシュしてあるNSMutableDictionaryがなんかの拍子に消えるようだ。もうちょっと調べればどのタイミングでそれが起きてるか究明できると思ったが、これ以上時間を無駄にしたくなかったからキャッシュしないで使うたびにallocしてreleaseするように書き換えたら動くようになったけど。
でも、このエラー、ユニットテスト仕掛けて無かったら気が付かないままYSFLIGHTリリースするとこだったな。時間かかったけどユニットテスト仕掛けておいてよかった。
それにしてもmacOS 10.14の変更点に全部対応したかどうかってどうやって調べればわかるんだ!?ユニットテスト走らせたと言ったって絶対これで全部カバーしてるとは思えん。
ついでに我がiPhone 5Sが、iOS 12に上げてからPCのUSBポートからだと出力が足りないのか充電できなくなった。2.4Aとかの大出力のやつだとチャージできるけど。どうもAppleのOSアップデートと僕は相性が悪いらしい。
YSFLIGHT
macOS 10.14対応のための変更は予想外に影響が大きかった。Windows用とLinux用コードに影響が出てまともに一時的にまともに動かなくなったのだが、大体直したと思う。あと数か所このままだと動かないのが確定な箇所があるので、それを直してから、もう一度テスト版を出してからリリース前点検を最初からやり直す予定。新しいバージョンのmacOSは本当に迷惑だ。
2018/09/28 Vulkanの迷走
macOS 10.14のOpenGLの仕様変更のおかげで余計な仕事が増えてしまった。授業用の例題修正しなきゃ。個々の修正は小さいのだが、本数が多くて。あとPower Point上の説明も更新しなきゃ。
この仕様変更についてどこにも説明がない。行儀よくprepareOpenGLとdrawRectの中以外からOpenGL関数を使ってないプログラムなら大丈夫だと思うけど、そうでないプログラムはmacOS 10.14では正常に動かないだろう。テクスチャとか適当な場所で登録しちゃってるプログラムは他にもありそうな。YSFLIGHTも現行バージョンはmacOS 10.14では動かない。新しい正式版がもうすぐ出せると思うんで、そっちでは10.14にも対応する予定。手元では動いてる。夏休み中に正式版化しようと思ってたけど結局学期に突入してしまってリリース前点検が滞ってたけどかえって良かったか。
ただ、macOSでOpenGLが使えなくなるというのがかなり現実味を帯びてきたからVulkanへの移行に備えて7月ごろ集中的に書いてたコードを見直してみた。そうだった。7月中にShadow Mapまでできるようになったんだった。まあ、なんとか使えそう。いや、使おうと思えば僕はVulkan使えるよ。
僕は使える自信あるけど、Vulkanを使えるのは極めてごく少数のデベロッパーに限られそうだ。VulkanはOpenGLに比べて使うのが桁違いに難しい。桁違い、というのは表現が甘い。OpenGL ES 2.0でさえGLSLが必須になってしまって苦労したものがVulkanはそれに加えてありえないほどのローレベルなプログラミングが要求される。Vulkanを使いこなせる人はOpenGL ES 2.0が使える人の1%もいないと思う。
Vulkanが出てからというもの、ちょっと検索してみるとOpenGLがこの先も使えるのか心配する声がごっそり出てくる。そもそもVulkanはNext-Generation OpenGLという名目で始まったものだからそういう心配が発生するのはある意味当然だ。いくらKhronosがOpenGLも引き続きメンテナンスすると言ったところで手遅れだ。VulkanはKhronosの失敗だと思う。
僕は大学4年のとき、当時の指導教授の命によりSilicon Graphics社のIRIS Performerというライブラリを使ったことがある。1994年だったかな？果たしてこのAPIが使いものになるのかどうかを調べるというのが目的だった。このIRIS Performerが出てきたのは、ちょうどScenegraphという概念が広まっていたタイミングで、あらかじめレンダリングするシーンの構造を(なんの構造も無いばらばらの三角形や線分でなく)ライブラリに登録しておけば描画が最適化できていい、という発想だった。だけど、IRIS Performerではこの登録がえらく難しい。たしかにそこまでやったらIRIS Performer内で最適化できるかもしれないけどプログラミングが大変すぎて使い物にならない。という結論だった。間もなく誰もIRIS Performerの話はしなくなった。ちなみにSilicon Graphics社はAPI作りに迷走していて他にもCosmo 3Dというのを作ってみたけどこれも自然消滅。このあたりからSilicon Graphics社は開発者の信用を無くし、グラフィックス業界で地位を失っていった。Indyのあたりからなんか変だったけどね。
今のVulkanの状況はIRIS Performerの状況に酷似してる。そこまでやったら、そりゃパフォーマンスは上がるかもね。だけど使える人がほとんどいないんじゃないの？IRIS Performerも最初のうちは注目された。そりゃ、業界最大手だったSilicon Graphicsがいい加減なものを作るわけがない、と、皆思った。だけど、あまりにも難しくて誰も使わなかった。僕の極めて非科学的な調査では、Vulkanは難しすぎて使えんという人の方がありがたがってる人より多いように見える。使われなければ、そのうち誰も話題にもしなくなって自然消滅する。Silicon Graphicsが信用無くしたように誰もKhronosを信用しなくなる。KhronosはIRIS Performerの失敗から学ばなかったのか。 。。。。多分今の若い人はIRIS Performerなんて聞いたこともないか。大失敗だったもんな。
Vulkanの迷走を表すかのようにVulkan Portability Initiativeというのをやってるらしいけど、去年から更新が止まっている上に、なぜかRustとかいう聞いたことしかないプログラミング言語でやってるらしい。今困ってる人たちって、僕も含めてOpenGLのコードベースをVulkanに移行しようと思ってもほとんど不可能なことに困ってる。Rustって多分最近流行のC++の劣化コピーだと思うけど、そんなので何か出されても何の役にも立たない。無責任に次々にプログラミング言語が出ては消える状況は今のプログラミングの大問題だと思う。状況をよく理解してないらしい。
そんな状況だからいまいちコードベースをVulkanに移行するの躊躇するんだよね。以前にDirect X9に対応したらDirect X10で後方互換性斬られて根本的に時間が無駄になった嫌な経験があるから、散々苦労して死ぬほど使いにくいVulkanに対応してみたらやっぱりVulkan消滅なんてことになったら嫌すぎるし。いや、もう一つの理由はクロスプラットフォームなことになってるVulkanがうちのThinkPad X250, X230Tのどっちでも動かないからだけど。Fake newsだ。
ひとつだけKhronosがこの迷走から抜け出す方法があるとしたらVulkan上にOpenGLのレイアを実装することだけだと思う。リファレンスコードとしてKhronosが責任持って維持する。それは多分結構可能。 当然一層噛むからパフォーマンスはVulkanほどにはならんだろうけど、我々がOpenGLに求めてるものってパフォーマンス全振りじゃなくてメンテナンス性とか書きやすさだから。というか、そもそもOpenGLはVulkanほどの過激なローレベルAPIではなくて、もう少し上のレベルなんだから、ある意味それが正しいアプローチだと思うんだよね。 OpenGLも維持する、と、いくら言っても行動が伴わないと誰も信用しないよ。
2018/09/25
macOS Mojave nuisance
いきなり学生さんからmacOSをバージョンアップしたらOpenGLがガビガビになったというメールが来た。Appleは10.14ではDeprecatedと言うだけでまだOpenGLコードの実行は可能って言ってたのに、またAppleが嘘ついたか？恐れていた事態が起きたか？と、思ってうちのmac miniも10.14にアップデートしたら、たしかにガビガビになった。
これなんとかしないと残りの授業今からmacOS非対応にするのは学生さんがかわいそうすぎると思って調べること数時間。どうやら10.14ではNSOpenWindowのdrawRectの外でレンダリングしようとするとOpenGL関数が無視されることが判明。(これまで調べたところ、prepareOpenGLとdrawRectの外では一切のOpenGL関数が無視されるっぽい。)
例えばゲームみたいの作ってて、どうせ全力で書き換えるんだからということで一ステップキャラクターを動かす関数の最後で画面もついでに書き換えるみたいなことしてるとダメっぽい。あと、prepareOpenGL以外のタイミングでOpenGLステートの初期化とかしててもダメっぽい。前までだとSub ViewがひっついているViewの場合はdrawRect範囲外でレンダリングすると何か変なことが起こるという制限があったけどこのバージョンからはSub Viewが無くてもダメにしたらしい。あれって確かSub Viewが上書きされて見えなくなるんじゃなかったかな？だからOpenGLの描画自体はできていたような。いや、でもSub Viewアリのときの制限調べておいてよかったよ。あの件覚えて無かったら多分途方に暮れてた。
初級プログラミングだからまだコールバック関数とか使いたくなかったんだけど仕方ない。明日の授業で対応しよう。
しかしmacOSでいつまでOpenGL使えるかな。Metalで初級グラフィックプログラミングをどうやって教えるよ。Vulkanは掛け声倒れで、ぜんぜんクロスプラットフォームじゃないしな。5年物のThinkPad X230Tに対応できないのはまだ理解できるが、3年物のThinkPad X250で使えないくせにクロスプラットフォームと呼ぶなんてのはfake newsだ。このまま3年前のIntelのGPU対応しないつもりだろか。Khronosの中の人だとこれはIntelの問題であってVulkanの問題ではないかもしれない。が、ユーザーにしてみると使えないことには変わりない。いまいちVulkanやってる人たちにやる気があるのか疑問だ。Vulkanはかなりの確率で失敗する。というか、既にOpenGLを置き換えることに失敗しているし。VulkanはAppleにOpenGLを落とす言い訳を与えてしまったから、他のOSも追従するかもしれない。そしてVulkan自体も自然消滅するかもしれない。そうなるとクロスプラットフォームなグラフィックスAPIが存在しない世界が結構な可能性で発生しそうな気がする。
ところで新しい元号の予想が流行ってるっぽいけど、「宇宙歴」で決まりだろ。
2018/09/16
FM TOWNS実機再稼働&延命支援プロジェクト: 非常用Towns OS GUI起動フロッピーディスクの作成 (あと英語化も可能)
ディスクイメージから1.23MBフォーマットフロッピーディスクにイメージを書き込む目処が立ったので、FM TOWNS実機をしぶとく稼働状態に維持し続けている人、稼働状態に復旧させようとしている人のためにエミュレータを使ってTowns OS GUIを起動可能な非常用起動フロッピーディスクを作るバッチファイルを作った。
ついでにある程度の英語版化もできるようにした。需要が限りなくゼロだけど。
今時よくできたエミュレータもあって当時のプログラムを走らせてみたくなったらWindows環境内でほとんどなんでもできるのに、あえて実機を稼働状態に維持しようとするその技術の無駄遣いさがいい。
2018/09/15
FM TOWNS再稼働支援プロジェクト: Windows 10で1.23MBディスクイメージから実フロッピーディスクへの書き戻し方法
中古であったり約30年ぐらい押し入れに眠ってたFM TOWNSを再稼働するためにはもしもCDドライブが死んでいたらフロッピーから起動してなんとかするしかない。起動可能なディスクイメージはエミュレータを使うことで作ることができる。だけどそのイメージを実フロッピーディスクに書き込む方法が無かった。
無かったのでいろいろ参考にしながら作ってみた。
PC-9801もFM TOWNSフォーマット(誰だPC98フォーマットなんて言ってるのは)の1.23MBフロッピーディスクを使ってるからPC98を再稼働させようとか思ってる人も使えると思う。
今の若い人FM TOWNSなんて知らない鴨しれないね。今から30年ぐらい前にそういう傑作機があったんよ。まだ2台飼ってる。
2018/09/10
FM TOWNS用外付けSCSI CD driver「CDSD.SYS」のビルド方法
どうやらFM-TOWNSの内蔵CDドライブは壊れやすいらしい。もう30年も前に生産されたコンピュータだもんな。この間、間違ってヤフオクで落としてしまったFM-TOWNSも、CDドライブ動作確認と言ってたのに、届いてみたら動かなかった、というかかろうじてTownsOSが起動するものの、エラー出まくる、CD−DA再生できず、で現実的に使えない。
しかし、ほとんど奇跡的なことに外付けCDドライブを内蔵ドライブ代わりに使うドライバCDSD.SYSとCDISC2.SYSが存在する。しかし、CDSD.SYSはバイナリは製品とあるにもかかわらずもう売ってない。公開されているのはソースだけ。しかもバグっててTownsOSではそのままでは使えない(READMEにはFM TOWNS対応って書いてあるのに!)。
仕方がないのでバグ取った。あとFM用ビルド方法も確立したので公開した。なお、実機FM TOWNS 2MXで動作確認した。
FM TOWNSを宇宙の終焉のときまで生かすのだ。
2018/08/08
ドラゴンスレイヤー
ヤフオクでFM-7用カセットテープ版「ドラゴンスレイヤー」を落とした。昔FM77AVを使っていたころ、テープ版ドラゴンスレイヤーをなんとかディスク起動にしようと試みて、結局ローダーを解析して書き換えたんだったか、なんらかの手でいったんFM77AVの拡張メモリにデータを読み込んで、それをメインメモリに展開して実行するようなコードを書いて、なぜかFM7７AV専用版ドラゴンスレイヤーを作った記憶がある。
当時ドラゴンスレイヤーは難しすぎてクリアできなかった。どうやって開始直後に画面右に見えている剣にたどり着けるのかまったくわからなかった。マップが左右でループしていることさえ知っていれば。だが、今は知っている。ザナドゥと同じ構造で左にずっと歩いていくとそのうち元の位置の一段上に戻る。開始直後右に見える剣にたどり着くにはどんどん左に歩いて行くのが正解だった。
FM-7用テープ版ドラゴンスレイヤーはプレイしたいというよりはテープをWAV化して実行可能な状態に持っていけるかの方に興味があったのだが、それはあっさり成功した。成功すると今度はせっかくだからクリア確認したくなった。ただ、ドラゴンスレイヤーはテープ版だとマップがひとつしか無い。ディスク版には複数入っている。そういえばいつぞや買ったドラゴンスレイヤー・クロニクルにはPC88ディスク版が入っていたっけ、あれまだやってなかったな。
ということで、もはや当初の目的とはまったく関係なくドラゴンスレイヤー・クロニクル収録のPC88版ドラゴンスレイヤーを始めてしまった。今の俺には2次元レトロマップツールがある。しかもどこでもセーブ機能もある。マップさえ作ってしまえばいくら当時でも難易度が高かったドラゴンスレイヤーと言ってもクリアできるだろう。
始めた時点ではステージ(ドラゴンスレイヤー用語ではフェーズ)が何面あるのか知らなくて、せいぜい10面じゃない？と、思って始めたのだがやってもやっても新しいフェーズが出てくる。しかも、やっぱり当時のゲームだけに難しい。途中、たまらず攻略サイトを見てしまって全20面あることを知って気が遠くなった。
しかし、ついに今日最終フェーズ(フェーズ K)のクリアに成功。ゲーム自体はフェーズ1のマップに戻って永遠にループするらしいけど、とりあえず全マップを見たってことで。
パズル要素もあり、結構戦略的な要素もあり、当時大ヒットした理由がわかった気がする。ドラゴンスレイヤーは一応その続編のザナドゥのクオリティがあまりにも高くて、当時リアルタイムだった人は割とザナドゥから入った人は多かったんじゃないかと思う。僕もドラゴンスレイヤーをプレイするより先にザナドゥやったし。ただ、ドラゴンスレイヤーをまだクリアしたことが無かったのがややひっかかっていたので、またひとつ心残りだったものが取れた気がした。
2018/07/14
Vulkan
ここ数週間Vulkan APIを勉強していた。とりあえず必要であればYSFLIGHTをVulkanベースに移植できそうな自信はついた。パーティクルレンダリングとかシャドーマップとかWindowsとMacでできるようになったし。いつの日かOpenGL滅亡の日が来たらVulkanに乗り換えて引き続きクロスプラットフォームで開発続行できそうな気がする。
だけどそれはVulkanが成功したらの話だ。Vulkanが本当に広く使われるようになるのか、かなり疑問を持っている。なんでかというとVulkanがOpenGLを更新するものではなく、もっと低レベルAPIのDirect 3DとかMetalを置き換えようとしているから、MicrosoftもAppleも自分とこのAPIを否定されてるんだからいい気はしないだろうし。ついでにOpenCLも置き換えようというんだからnVidiaにしてみればこの機にVulkanとOpenCLを両方叩きつぶしてしまえばCUDAの天下になると考えているんじゃないかな？ある意味GoogleとIntel以外Vulkanを推す理由が見当たらない。このへんの大きな企業はAppleを除いてVulkanをサポートすると表明しているが、面従背反の可能性が結構高いかもしれない。
実際Vulkanは既に折れかかっている。AppleがVulkanを公然と無視したもんだから、話をつけてMoltenVKをオープンソースにしたものの、MoltenVKはVulkanのサブセットでしかない。全機能を持ってない。とくに致命的なのがValidation Layerが使えない点だ。Vulkanは設定項目が多すぎて、Validation Layer無しでは正しいパラメータを与えているかまったくわからない。だから、うちのMac miniで動くVulkanコードを書いてもそれをWindowsに持って行って動くかまったくわからない。
だから、ここ数週間どうやっていたかというとうち帰ってきてMac miniでVulkanコードを書き動作を確認したら、次の日大学では自分の机のWindows 10で実行してみて、そうするとValidation Layerが山のようにエラーを吐くからそれを直す。ちなみにIntelもVulkanサポートに関してやる気の無さ満々でうちにある二台のThinkPadのどちらでもVulkanを実行できない。まだ3年しか経ってないThinkPad X250ではVulkanが実行できない。世の中の大半のIntegrated GPUではVulkanが走らない有様だから現状ではとてもクロスプラットフォームでは無い。IntelはGPUプログラミングでnVidiaの寡占を崩したいところだろうからVulkanは推しても良さそうな気がするのだが、3年前のIntegrated GPUでVulkan対応しないんじゃねえ。
あとひっかかったのはMetalではVertex shaderの出力 (OpenGLで言うところのvarying)が配列か行列であってはならないらしい。他プラットフォームのVulkanにはそんな制限はないのだがMoltenVKはMetalのダメさ加減に引きずられてVertex shaderの出力に配列とか行列を使うとエラー出して落ちる。だからWindows上でVulkanコードを書いて完璧に動作してValidation Layerが一切エラーを出さなくてもmacOSとかiOSに持って行ったら動かない可能性がある。
この有様なもんだからKhronosはVulkanの公認サブセットなんてことを言いだした。あー、もう、いい加減にしてほしい。標準化の意味って何だと思ってるんだ？
あと、もういとつ言わせてもらうとLunarGのVulkanについてくるGLSL to SPIR-Vコンパイラってバグってない？シェーダーのUniformを、
layout(std140,set=0,binding=0) uniform State
{
mat4 projection;
// 16-byte alignment
vec4 lightEnabled;
このように書くと完璧に動作するのだが、
layout(std140,set=0,binding=0) uniform State
{
mat4 projection;
// 16-byte alignment
float lightEnabled[4];
こう書くとlightEnabled[0]にセットした値はshaderに見えるんだけどlightEnabled[1]以降にセットした値が見えない。これが誰も理解できない意味不明仕様ではなくて単純なバグであって次のバージョンでは修復されることを望む。16バイトにアラインしてるはずなのに動かないんだもんな。しばらく悩んだ後で試しにvec4にしたらすべてが完璧に動いたよ。
Uniformといえば、VulkanでUniformに値をセットしようと思ったら、まずUniform bufferを作って値をセットする。この段階で既にGPUメモリに値は入っているはずだ。そして、次にUniform bufferの値をVkDescriptorSetに'write'する。そして最後にVkDescriptorSetをVkDescriptorSetLayoutにバインドする。
素朴な疑問なんだけど、VkDescriptorSetっていらなくない？
既にUniform bufferがGPUメモリ上にあるならShaderは直接Uniform bufferの値を参照できるはずだ。それをあえてVkDescriptorSetに'write'する意味がわからない、というか意味がない。VkDescriptorSetはどうやらUniform bufferとかSamplerを指すただのポインタらしい。("write"って言ってるのに書き込んでないじゃん!)そうであれば、わざわざアロケートしなくてもコマンドバッファに乗せてもオーバーヘッドは無視できる程度のはずだ。
今のままだとUniformに値をセットするにはUniform bufferとVkDescriptorSetのふたつのリソースが必要になる。(Uniform buffer memoryを別にカウントすると3個)。一応、今のところ自分のコードではUniform bufferをアロケートするときペアでVkDescriptorSetもアロケートしているけど、VkDescriptorSetのアロケーションがどう考えても無駄だ。次のバージョンのVulkanではUniform bufferを直接VkDescriptorSetLayoutのバインドポイントにバインドするvkCmd関数が追加されてほしい。まあUniform bufferとVkDescriptorSetを常にペアで管理すればいいだけなんだけど。
とりあえず、(1) Vulkanが宣伝通りにクロスプラットフォームAPIとして広まるか、(2) 誰かがOpenGLをMetal上に実装して引き続きAppleの環境でもOpenGLを使うことができる、のどちらか(両方ならなお良い)が起きてほしい。Vulkanが広く使われるようになるなら、Vulkan使えばいいだけだ。上に書いたような問題があるけど、確かにOpenGLの問題点を結構解決している。何よりType safeなのはありがたい。あるいは、引き続きAppleのプラットフォームでOpenGLが使えるならOpenGLは残っていくと思う。OpenGLを必要とする最大のメリットで、かつ唯一の存在意義ってクロスプラットフォームであるという一点だった。Appleで使えないとなるとその存在意義が無くなるとまで言わんけど大きく損なわれるわけで自然消滅する危険は大きい。
一番嫌なのはVulkanがOpenGLを巻き込んで自然消滅して、クロスプラットフォームなグラフィックスAPIがこの世から消滅するという状況だ。そしたらUnityとかUnrealを使うことを検討してもいいんだけど、どっちも基本的に商業用開発を前提としてる。Unityが後方互換性をかなりの努力で維持しているのは僕は素晴らしいことだと思うものの、プログラムを商用化したときに売り上げの一部を支払わなければならないライセンス条項は困る。一般ユーザ向けにはあんまり商用コード書いてないから困らないけど、大学で企業と共同研究した成果物としてコードを納品する場合はある。そういう成果物にUnityなりUnrealを使ったとき、売り上げとみなされないのか。これ結構グレーだと思う。大学はもちろん学術研究という名目で企業と共同研究するわけだけど企業からすると研究資金を払ってコードを買っているとも言えるわけで。そういう研究にUnityなりUnrealなり使おうと思ったら知的所有権専門の弁護士を頼んで問題ないことを確認してからじゃないと怖くて使えないわけだが、そんな予算は無い。
多分KhronosがVulkanについて来月のSIGGRAPH 2018で何か言うだろう。今度は何が出てくるかね。
2018/06/20
FM-7再稼働支援ユーティリティがデバッグモードでコンパイルしていたのでリリースモードでコンパイルなおしてアップロードした.
アメリカの大学は夏休みに突入して、日本に帰省してきて、ナイアガラ・フォールズ航空ショーを見て帰ってきた。この週末はデイトン航空ショーなんだけど天気がいまいちのようだ。
帰省している間ついにYSFLIGHTカーネルをAndroidで動作させることに成功。さすがにプレイできるレベルでは無いけど、デモ版かPCで飛んだフライトレコードを再生できるYSFLIGHT Player(仮称)みたいなのを考えている。次の春の授業ではもう少しMobile / Tabletプログラミングについてカバーしたい。そして、この夏の目標、
と、思っていたのだが、、、、、
https://www.macrumors.com/2018/06/05/apple-deprecates-opengl-opencl-gaming/
macOSとiOSはいずれOpenGL非対応になるそうだ。Metalを発表した時点でいずれこうなるのではないかと良そうしていたが、ある程度ハイレベルなグラフィックスAPIも維持してくれるのではないかという極めて薄い期待も同時に持っていた。あっさり裏切られてしまった。
MicrosoftはWindows VistaでOpenGLを切ろうとした。あの時は世界中から非難を浴びて撤回した。今でもOpenGLは公式にはVersion 1.1までだがWin32 APIの一部だし、Universal Windows Platform API用にはDirect X上に実装したOpenGL ESを使うことができる。だけどAppleは言い出したら聞かないだろう。
とりあえず今すぐOpenGLが使えなくなるということは無いらしいが、場合によると最低でも少しの間YSFLIGHTのMac対応とiOS用の開発は停止するかもしれない。
一応、Vulkan API対応は検討してるんだけどね。最近のプログラミング環境の問題のひとつにグラフィックスAPIがプログラムとかデータ構造にあまりにも強い影響を持つってことがある。Vulkanの説明を見ると「最高のパフォーマンスを引き出すために」という記述が頻繁に出てくるわけだが、最高のパフォーマンスよりちょっと落ちてもいいから書きやすくてコードのメンテナンスがしやすい書き方を教えてよ、と言いたい。別に映画を作ろうってわけじゃないんだから。正しい書き方であるということとメンテナンスしやすいという二点はパフォーマンスよりも優先だと思う。
2018/04/14
RAM操縦輪マウントを試してみた。(続きを読む)
2018/04/07
YSFLIGHT開発状況
いつになったら次の正式版を出すんじゃ！という声が聞こえてきて久しいんだけど、ごめん。最近レトロゲームで遊びすぎた影響でリリース前テストする時間が無いもんで。理由のひとつはYSFLIGHTのオプションとか機能とかが増えすぎて、テストしきれなくなってきている。それでテストを自動化しようとしてあの手この手を試してみて最近やっとそれなりにうまいこと動くものができてきた。例えば、Simulationメニューの全メニューを選んでみるとか、デフォルトの機体を一通り選んでみるとか、そういう機械的な作業はスクリプトで自動的にできるようにした。既にこれまで手動で一時間ぐらいかかってたテスト項目をスクリプトが5分ぐらいで実行してくれるようになった。
設定をいろいろ変えて飛んでみるのもスクリプトで実行できるようにしつつあって、これができるとリリース前テストが一気に楽になるはず。クラッシュされるとわかんないからある程度眺めてないといけないという問題がまだ残ってるけど。
振り返ると今の正式版に比べて結構機能が増えたからぼちぼちリリース前テストして正式版にしてもいいんだよね。がんばろう。
あと、ときどき思い立ってiOSとAndroidでとりあえずオートデモが動くとこまで作ろうとしてみるのだがこっちも難航している。どっちもCMakeだけではビルド環境を作れないのが痛い。 なんとかならないもんかね。
なんか忘れたと思ったら
なんか忘れたような気がする。と、思ったら一個ミーティング出るの忘れてた。
論文書いたりコード書いたりしてると簡単に時間が経つのを忘れてしまったりどのミーティングが発生してどのミーティングがキャンセルになったんだっけ？と把握しきれなくなり、ましてiPhoneをMuteにしているともはや収集がつかない。そうそう。昨日は3時から学生さんとミーティングが入ってその準備ができたと思って油断してコーディング始めたら2時のやつを忘れたんだよ。
論文も書いてコードも書いて授業も教えて山のようなミーティングに出てる人ってどうやってマネージしてるのかな。
2018/04/04
おお、Blue Impulseが弘前城の上空を飛ぶのか！見に行きたかったな。
https://hirosaki.keizai.biz/headline/972/
今年の桜まつりは航空ファンで大入り満員だろうな。
2018/03/30
Forward Lanes閉店
ピッツバーグに越してから長いこと通ったボウリング場「Forward Lanes」が先週末で店を閉めた。なんでも1924年からあったらしいからかなり歴史の長いボウリング場だった。学生の頃はたまに行って投げる程度だったけど、博士号を取って研究員として働き始めた年にForward Lanesから歩いて一分のアパートに引っ越したから、その後はより頻繁に通うようになった。
僕は人より上手なスポーツというのがボウリングしか無い。せめてひとつぐらいは上手なスポーツを維持しようという興味だったからよく一人で行ってひたすら練習で8ゲーム連投とかいうことをやっていたら、ある日ボウリング場の当時のオウナーのケビンにリーグに参戦してみないか勧められて毎週土曜日のリーグに出るようになった。たしかそれが2004年の秋リーグか2005年の春リーグだったからこのリーグには14年ぐらい通ったことになる。
Forward Lanesのリーグは素人リーグとは言え何度かアベレージでトップの成績だったシーズンもあった。しかし最近はオイルをケチっているのかリーグ戦でもほとんどレーンにオイルを敷いてなくてスピードの無い僕だとボールが曲がりすぎていいスコアが出なくなっていた。また最近Playmorの公認リーグに参加するようになったからそっちがメインになっていた。だからForward Lanesがクローズしてもボウリングする場所はあるんだけど。とはいえ長いこと通ったボウリング場が閉店するのは少し寂しかった。
それまで車を停めることができたボウリング場の裏の道路が冬場に表面が傷んでしまってそのまま修復されずに通行止めになってしまったのが痛かったかもしらんね。あの道に車を停められなくなってForward Lanesにかなり行きにくくなったもんね。というか通い始めた当時から午後の早い時間だとがらーんとしていて誰もいなくて一人で集中して練習できるのはいいけど経営は大丈夫なんだろうか？と、思っていたからよく持った方なのかもしれない。
ちなみに下は僕のForward Lanes最終戦成績。
2018/03/21
FM77AV 「九玉伝」 (Techno Soft 1986) 攻略
長いことひっかかっていたことがある。FM77AV用「九玉伝」(テクノソフト)を買ったまま30年以上クリアできないままになっていた。基本的に買ったゲームは自力クリアができなかったら攻略本を見てでもなんでもとりあえずクリアする方針でやってきた。シューティングゲームとか反射神経が要求されるようなゲームだと断念せざるを得ないことがあったけど、ロールプレイングに関しては基本的にこの方針を貫いてきた。
「九玉伝」は、珍しく当初FM77AV専用で、のちに他機種にも移植されるまでの間はFM77AVが独占していたタイトルだった。とにかくPC88に比べてソフトが少ないFM77AVにあって、このタイトルの期待は大きかった。またFM77AVの多色表示を活かして、多分64色二画面を使ってると思うけど、当時としてはグラフィックスが綺麗な方だった。発売と同時に買ったと思う。そしてかなり時間をかけたはずなのだが、結局クリアできなかった。
しかし、当時のフロッピーディスクの大半が行方不明になってしまった今でも、なぜか九玉伝フロッピーディスクは残っていた。いつかこのタイトルをクリアしてやりたいという僕の執念によるものだと思う。そして、去年Xanadu Revival IIをクリアするために、二次元レトロマップツールを開発したので、XM7のスクリーンショットをつなぎ合わせてで原寸大マップを作れる環境はできていた。マップさえ作りながら進めれば、今ならクリアできるのではないか。時は来た。春休みを利用して九玉伝のクリアに挑んでみた。
（続きを読む)
2018/01/24
FM77AV再稼働支援 : 赤外線ワイヤレスキーボードエミュレータ公開！
FM77AVまたはFM77AV40実機はあるけどキーボードが無い、という場合、PCにIRToyという赤外線トランシーバーを接続して、Windows上でタイプしたキーをFM77AVに送るプログラムを作った。
2018/01/14
もしも、まだ稼働状態のFM-7/77シリーズの本体＋モニタがあって、ディスクドライブが生きているものの、持ってたフロッピーディスクは既にだめになってしまって、残っているのは.D77ディスクイメージのバックアップだけという場合、このプログラムを使ってデータレコーダインターフェース経由でディスクイメージを書き戻すことができる。
2018/01/5
ちょっと遅れましたが、新年おめでとうございます。今年もよろしくお願いします。
年末は、サンフランシスコに行っていた。そして、夜行便で帰ってきたら風邪を引いた。
サンフランシスコでは、毎日海産物を食っていた、というか、ピッツバーグに住んでるもんだから、サンフランシスコとか行くと、観光名所を見てまわるんじゃなくて、魚を食う、とか、正月の買い出しに行くとか、そういう行動に出る。また、サンフランシスコ旅行が国内旅行であるという非現実感がいい。
現地には四日滞在して、四日目にはNice Airというフライトスクールからセスナを借りて、ベイツアーと呼ばれるコースを飛んできた。現地の空域にぜんぜん詳しくない上に、ピッツバーグのように単純な空域と違って、クラスBとCとDが入り組んでいる現地では、いきなりソロで飛ぶ自信はぜんぜんなかったので、教官にも乗ってもらった。
Comments are welcome.
Send E-Mail to:
 |