|
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:
 |