フリーフライトシミュレータ

ysflight.com

10周年記念からさらに10年が経過した。YSFLIGHTはもともと博士候補試験の勉強中の息抜きのために始めたプロジェクトだった。最近はスマホやゲーム機で優れたフライトゲームが多くあるから最盛期ほど盛り上がってないかもしれないけど、一応ゆっくりだけど今でも開発は続けている。

FM TOWNSを使ってた頃は３Dゲームをいくつも作って1000本とかいうオーダーのダウンロードがあった。当時フリーのゲームソフトで1000回ダウンロードされるというのはすごいことだった。だけどYS FLIGHT SIMULATORは世界中からダウンロードされて、ダウンロードカウントだけ見たら100万回のオーダーを超えている。ただ、同じ人が何度もダウンロードすることもあると思うんで、100万人かどうかはわからないんだけど。

アップロードしてみたらユーザが作る機体やマップのクオリティの高いことに衝撃を受け続けた20年でもあった。YSFLIGHTを盛り上げてくれているユーザの皆さんには非常に感謝しているので、ひきつづきYSFLIGHTをよろしくお願いします。心苦しいんだけど機体の作成とかマップのデータ構造に関する質問はほとんど答える時間が取れない。けど既にオンラインでものすごく詳細な解析情報があるから多分僕に効くよりそっちの方が速いと思う。

せっかくだから20周年記念で何か特別なことをしたいのだが、例えば手をつけたままできあがってない新機能をひとつでもふたつでも完成させるというのも手なんだけど、途中で止まってるのはやっぱり理由がある。大体メジャーな理由としては、やってみたら案外難しかった、後方互換性が維持できなくなる、難しくはないんだけど書かなきゃいけない分量が多すぎる、とかいうパターンが多い。少なくとも20周年記念機体データとか作ろうかな。

僕は、最近のソフトウェア開発のトレンドについて危機感を持っている。ソフトウェアが消耗品のように扱われてるのは正しくない。ソフトウェア・アズ・サービスって言いだした奴を絶対許さない。悪いけどソフトウェアはサービスではない。ソフトウェアは製品であると同時に芸術作品としての側面も持っている。傑作は将来まで保存されるべきであって、ティッシュペーパーのように使い捨てられるべきではない。安定したプログラムを書くためには、コードを再利用して、多くの入力を与えて頑強性を高めていくべきだ。そして、プログラムが安定してくると徐々に更新は不必要になってくる。更新が無いのはプログラムが捨てられたからではなくそのプログラムの目的を達成しつつあるからであるべきだ。コンピュータ界には数多くの素晴らしい成長があった。だけど同時に誤った考え方も広がっている。

YSFLIGHTは傑作というほどのものではないかもしれない。だけど僕はYSFLIGHTを誰でもいつでも戻ってこれるプログラムにしたい。誰かが今日YSFLIGHTをプレイするのをやめるかもしれない。だけど、何年かしてその人がまた久しぶりにYSFLIGHTで飛んでみようと思ったとき、YSFLIGHTをダウンロードして飛び上がって簡単にトラフィックパターンを回れるように維持しておきたい。しばらく離れていた人も、「ああ、このプログラムまだあるんだ」と思って久しぶりにダウンロードしてまたちょっと使ってもらえるようなソフトウェアを目指して引き続きメンテナンスしていこうと思ってる。

YSFLIGHTの最新版、バージョン20181124がVector.co.jpに登録されてダウンロードできるようになった。ダウンロードは下のリンクから。

- OpenGL 2.xでシャドウマップに対応。影が良くなった。
- 雲とスモーク両方をパーティクルレンダリングするようにした。
- OpenGL 1.1, Direct 3D9でもパーティクルレンダリングできるようにした。
- エアレースモード。まだかなり原始的な実装だけどとりあえずチェックポイントをすべて巡回する時間をカウントするようにした。
- アドオンを自動スクリプトでチェックするようにしたので、動かなくなってたアドオンとかもかなり動くようになったと思う。
- Windows版でインストーラを使うの、むなしくなったのでやめた。。
- ILS view (F6) and Tower View (F8)を分けた、というか前のバージョンに戻した。

リリース前テストしなくてちょと長いことテスト版のまま放置してしまって申し訳ない。シャドウマップ実装したのっていつだったかな？もう2年ぐらい前だったような。

YSFLIGHTユーザの皆さまには、実行時に署名されていないプログラム云々という警告メッセージが多分Windows 8になったあたりから、出ていたと思う。表向きの理由は、セキュリティを高めるためということになっている。誰が書いたプログラムなのか、その後誰かの手によって改変されていないか、それが確認できないプログラムは実行させないという趣旨だった。

情報セキュリティは非常に重要な問題で、実行ファイルの出どころをはっきりさせること自体は良いことだ。悪意のあるプログラムを実行したことによって被害を受ける事件は後を絶たない。そのような事件の責任は当然悪意のあるプログラムを書いた本人にあるべきで、僕はそんなやつは一生刑務所に入っていればいいと思う。

だがセキュリティ問題を利用して利己的な目的を達成しようとする者がいたとしたら、もっと軽蔑してもいい。残念ながらコード署名を発行する認証オーソリティは、誰の利益のためにそうしているのかなんとなくわかるけど、セキュリティ問題を利用して個人プログラマーを卑怯な手段で排除しようとしている。

コード署名はもともと年間500ドルとかいうレベルでとても手が出なかった。しかし、長いことYSFLIGHTを使ってくれているユーザから懸念のメールをいただいた。実際自分としてもできることならコード署名が欲しいと思っていたので、ときどき手の届く値段でコード署名を買うことができないか探していたのだが、今回COMODOという認証オーソリティが年間$179でコード署名を発行してくれることがわかった。そこで申し込んだのだが、返ってきた返事は、コード署名は個人開発者には発行しないということだった。

他の主要な認証オーソリティも調べたのだが、どうやら認証オーソリティは結託して個人開発者へのコード署名を発行しないことにしたらしい。だから、仮に僕が思い切って年間数百ドルを支払ってコード署名を買おうとしたしても、買うことができない。高くて買えないどころか、金を積んでも買えなくなった。何故こんなことが許されるのかわからないけど、認証オーソリティはすべて個人プログラマーを意図的に卑劣な手段で排除しようとしている。

そのようなわけなので、残念ながらYSFLIGHT.COMからダウンロードできるプログラムに署名することができない。そして、僕にはできることが何もない。残念だけど、奴らの思い通りに個人でフリーソフトを書いて発表するようなプログラマーは絶滅するだろう。できることと言ったら、ここに現状を書いて知ってもらうぐらいしかできない。

OpenGL ES 2.0用YSFLIGHTで、Shadow Mapによる影をつけてみた。一応、Direct3D9でも同様の影をつけることは可能らしいのだが、いまさらDirectX9用のコードに手をつける気にならないもんだから、当面、OpenGL ES 2.0用のみ対応の予定。一応、Vulkunが一般的に広く使われるようになるようなら、いずれYSFLIGHT on Vulkunも作るつもりだから、そのときが来たらVulkunによる影つけにも対応すると思う。けど、Vulkunって普及するのかね？ぱっと見た感想は、アセンブリコードか、と、思った。今、少し前のOpenGL 1.1に対応するようなAPIが無い。別に、誰でも映画みたいなグラフィックスを描きたいとは思ってないのだが。とくに、僕なんかだと仕事で開発したアルゴリズムとかが正しいかどうか確認したいだけだから、正直言うとOpenGL 1.1の範疇でほとんど用は済んだ。OpenGL ES 2.0に対応するために、ライブラリを書いていちいちローレベルまで降りなくてもなんとかなるようにして使ってるけど、Vulkunも同じような使い方になるのかな。でも、DirectX9い対応してみたら、DirectX10とDirectX9の互換性が無いから、DirectX9用に書いたライブラリはほとんど新しいDirectXで使えなくなったという苦い経験があるからなあ。今でもMicrosoftにはそのことを根に持っている。

このShadow Map、最近は影をつける標準の方法になっているようだ。が、最近のグラフィックス技術というのは、フライトシミュレータみたいに、前方40kmぐらい先まで見えるような景色を描くことをまったく考えていない。まず、光源からの距離のビットマップを作るわけだが、一応最近一般的なGPUで使える限界らしい2048x2048のビットマップにしたところで、40km四方をカバーしたら1ピクセルは大体20メートル。F-18の影が長方形になるレベルで役に立たない。

仕方ないから、Shadow Mapを複数枚使って対抗する。試しに今、一番効果的とされているらしい、Cascaded Shadow Mapというのを実装してみた。しかし、物の役に立たなかった。Shadow Mapの数を3枚に増やしてみたのだが、粗すぎて話にならない。ハイエンドのGPUで、Shadow Mapを8枚とかに増やしたりするといいのかもしれないが、3年前のハードウェアでも使えることを目標にしているYSFLIGHTでは、Shadow Mapを3枚というのが限界の線。さらに、Cascaded Shadow Mapの論文の方法にも問題がある。たとえば、光源がやや背後から照らしているとして、背後からデルタフォーメーションが前方に向かって通過するような場合だと、本来であれば、フォーメーションが視野に入る前に先に影が見えるはずだが、論文の方法だと、フォーメーションが視野に入るまで影が見えない。

結論としては、視点のモードとか、視点付近の状況に応じてShadow Mapのカバー範囲を変えてやるしかないらしい。まだそこまではできてなくて、非常にいい加減な方法で計算した影なのだが、以下はスクリーンショット。

それから、大きなマップで、原点から視点の距離が遠くなるとぐらぐら揺れる問題は、今の手元のバージョンではかなり良くなった。これ、原因は、GPUが座標計算を32-bit浮動小数点で計算するからで、変換の行列をGPUに計算させずにCPUで64-bit浮動小数点で計算させるようにすると、まったく目立たなくなる。一時期、GPUを使った演算の高速化というのが話題になったけど、いつまで経っても内部の計算を32-bitでやるもんだから、真面目な計算に使おうと思うと精度が足りなくて、ものの役に立たない。

それでも、昔は、Z-Bufferが16ビットが標準だったんだけど、最近は悪くても24-bitが使えるようになったっぽいね。大体、手元にあるPCはどれも最低24-bit Z-Bufferが使えるような感じだから、YSFLIGHTのオプションのZ-Buffer Qualityを廃止してコードをすっきりさせようか、と、思っている。

そういえば、機械学習でYSFLIGHT内で飛行機を飛ばすという実験もやったんだけど、今のところ失敗。まずスピードの制御を機械学習でやらせてみよう（スピードも制御できないようだと複雑なことなんかできん)と、思って、いろいろな状況で勝手に飛行機を飛ばして、それを学習データとして、速度制御ができるようにしてみよう、と、してみた。が、ぜんぜん制御できんかった。まだ、勉強が必要らしい。

最近、ついに、YSFLIGHTで使っていたSRFとDNMのデータ構造を廃止して、Polygon Crest用のデータ構造と統一した。というか、SRF形式ファイルというのは、仕事でも使っていて、大体CADモデルを受け取ると、まずSRFに変換してから処理している。ただ、今までは、本業の方の処理に最適なデータ構造と、モデリングに最適なデータ構造と、表示するためだけの軽量なデータ構造はそれぞれ違う要件があるはず、と、思って、複数の独立したデータ構造にしていた。

それはその通りで、間違ってない。手間をかけて、それぞれのデータ構造をメンテナンスしていけば、それが最適なパフォーマンスになるのだ。だけど、何かひとつの機能を追加するたびに、三箇所の修正が必要になった。しかも、仕事用データ構造に派生方が発生したりして、収集がつかない状態になっていた。

それを、ひとつに統一しようという、(僕内では)一大プロジェクトを開始したのが、一昨年の後半ぐらいで、ついに、できた。これからは、このSRFとかDNMの仕様に何か追加したら、一箇所のコードを修正するだけで、仕事用コード、Polygon Crest、YSFLIGHTそれぞれで、その機能が使えるようになる。少なくとも、データファイルの読み込みに失敗することはない。

もうひとつ、やってるのが、グラフィックスのAPI依存部分を徹底的に縮小する作業で、結局、グラフィックスAPIの流れとしては、Vertex Attribute Arrayでなんでもやる方向になりつつあって、表示するものを配列にしてしまえば、単にその配列の中身をOpenGL 1.1のImmediate Modeに出すこともできるし、Vertex Buffer Objectを使って描画もできる。だから、今まで、HUDや計器パネルの描画なんかは、OpenGL 1.1用、Direct 3D9用、OpenGL 2.x (兼ES 2.0)用にそれぞれ別に書いていたものを、統一して、Vertex Attribute Arrayを生成するコード一本にまとめるという作業をやっている。

それと、コードの整理もやっていて、今までまさかYSFLIGHTがこんなに長続きすると思わなかったもんだから、大半のソースがひとつのディレクトリに入っていたんだけど、これだとメンテナンスしきれないから、小さなライブラリの集合に再編しようとしている。まあ、当分YSFLIGHTのソースコードを公開する気は無いんだけど、でも、何かの理由で僕が開発を続けられなくなったら、そのときは、ソースコードを公開するつもりでいる。そのとき、コードが何も整理されてなくて乱雑な状態だったら、誰も読んでもわからんもんね。なお、SRFとDNMのデータ構造を統一したおかげで、ずいぶんコードの整理が進んだ。

ひとつ失敗だったなと思ったのは、地上物のクラスと、その入れ物になってるクラスの間に相互依存関係を作ってしまったことで、ここのところをなんとかできんかと思って、何度かトライしたのだが、結局だめで、svn revert . --depth infinityの連発になっている。

ちなみに、コードを整理してるもうひとつの直近の目標は、YSFLIGHT for iOS。Polygon CrestはすでにiOSデバイス上で実験的に動作するようになった。ただし、iOSだからセーブしたデータをデバイス外に出せないけど。iCloud Driveでなんとかならんかと思ったけど、なんで、iCloud Driveってあんな仕様になっとんじゃ。だから、YSFLIGHT for iOSも十分可能という感触がある。

だけど、それには、まずコード整理して、iOSの枠組みに合うように修正しなきゃならない。しかし、こういうのって、ユーザから見たとき、いまいち変化が見えないんだよね。少しは、次のバージョンアップで、おもしろい機能も追加したいところなんだけど。(いや、コードの整理が進むと機能の追加も楽になるはず。)

Mac OSX 10.11 El CapitanでのOpenGL Viewの挙動の変化は、YSFLIGHTには影響ない、と、思ったんだけど、実はあったようで、動かないという報告が多数あったので、試してみたら確かに動かなかった。とりあえず、対応版を作ったので、以下のリンクからダウンロードできるようにした。近いうちにVectorとDownload.comにも上げる予定。

OpenGLの設定は、ウィンドウが開いた後も何度もモード切り替えるたびにしなおしてるから大丈夫と思ったら、ウィンドウ開いた直後にGLSLのプログラムを作るとこでしくじっていたとは。

実は既に数日前に公開されてたんだけど、忙しくて告知が遅くなってしまった。YS FLIGHT SIMULATOR 20150425バージョンが、Vectorに登録されて、ダウンロード可能になった。

テストバージョンにバグレポートやコメントを送ってくださったユーザーの方に感謝申し上げます。

- プロペラのシミュレーションを改善(対応機体のみ)
- F-22等で、失速後機動ができるようにした
- OpenGL 2.0用で、フォン・シェーディング対応
- スモークの色をジェネレータごとに設定できるようにした
- 管制官が指示を出しすぎる問題を修正
- 味方機への指示に「Land, Refuel, and Take Off」(補給して再度離陸せよ)を追加
- 編隊中の味方機に散開、密集の指示を出せるようにした
- 自分が操縦した後について飛行するモードが使えなくなっていた問題を修正

今年の初めにマイナーデバッグ版をリリースとか思ってたのに気がつけば8月末。夏休みが終わってしまって、怒涛の勢いで授業が始まってしまった。Polygon Crestの開発にも時間使ってるとはいえ、このままでは、YSFLIGHT 2014年版が出ない！！と、思って、焦って次のリリースに向けて準備中。

とりあえず、OpenGL ES2.0/2.0でVertex Buffer Objectなるものを積極的に使うようにして、Windows上だと、Direct 3D9バージョンと同じかそれより速いぐらいの描画スピードが出るようになった。YSFLIGHT for MacOSXも、同じ理由でフレームレートが結構良くなった。けど、MacOSXだと、なんか30fpsでリミッターがかかってるぽくて、なぜか60fps出ないんだけど。

なお、WindowsのCPU-Rendered版を廃止したときからやりたいと思ってた、地面にテクスチャ機能、やっと実現した。問題は、僕に絵心が無いから、貼り付ける絵が無いということだ。ネットからダウンロードできる地図にはみんな著作権があるから使うわけにいかんし。仕方ないから、六戸のあたりにハチドリの写真を貼ってみた。次のバージョンでは、いろんなところに地上絵が出現するかも。あと、滑走路なんか、センターラインをポリゴンで作らないで、多分テクスチャでやった方がいいよね。本物の滑走路は、接地点付近がタイヤクズで黒く汚れてるから、そんなのも再現できるようになるかもしれない。

もうちょっと手を入れれば、Elevation Gridにもテクスチャを貼れるようになるから、そこまでは次のバージョンに含めるつもりでいる。山の上の方に冠雪とかできるようになるはず。

それと、結構要望がおおかった多色スモークも実装してみた。

航空ショーで見るF-22のデモフライトは、圧巻で、ああいうのがYSFLIGHTでできるようになったらいいのにな、と、思って最近、YSFLIGHTで失速後機動をできるようにする実験をしている。ついでだから、F-18のハイ・アルファ・パスとか、Su-27系のコブラ機動みたいなのもできるようにしたいし、あと、欲を言うと、単発プロペラ機のアクロバットみたいな機動も実現してみたい。僕は航空ショーが好きだから、あれを再現してみたいんだよね。

それで、まだ通常機動から失速後機動への移行がいまいちスムーズじゃないという問題があるけど、とりあえず、F-22でこんな機動ができるようにしてみた。ジェット戦闘機の失速後機動というのは、低速時、動翼による姿勢制御の効果が弱くなってきたとき、ノズルの方向を変えて、姿勢を無理やり制御しようというものだから、データファイルには、ある程度よりスピードが下がってきたときで、かつエンジン出力が一定以上のとき、姿勢を直接制御できるモードに入るというような記述ができるように今のところしてある。

問題は、移行なんだよね。F-18のハイ・アルファ・パスの入り方なんか見てると非常にスムーズに入っていくんだけど、これは、多分F-18のストレーキの効果で、ストール後の揚力の減り方が多分スムーズなんだよね。YSFLIGHTの場合、現在ストールするといきなり揚力がゼロになるように書いてるから、多分、失速パターンをいくつか選べるようにしないとだめなんだろうな。

それから、もうひとつ、セスナ172を追加しようと思ってるんだけど、だったら、エンジンのリアクションを本物っぽくしようと思って、プロペラをもう少しまじめにシミュレートするようにしてみた。現在、Piper ArcherとP-51 Mustangにリアリスティックプロペラを搭載して実験中。次のバージョンでは、従来の簡易計算か、リアル計算か選べるようにする。

ただ、問題は、リアリスティックなプロペラシミュレーションにしたら、今まで使ってた自動操縦が時間遅れに対応できなくて悲惨なことになっている。こうなると、もう手動で適当な制御パラメータを決めるのが難しくなってきたから、今、機械学習の概念を取り入れて、制御を頭良くできないか実験中。

実は、今に実現したいと思ってる機能があって、プレイヤーが操縦することで、AIを学習させて、頭のいい空中戦AIを作って、そのデータを交換して対戦させる（自分が鍛えたAI対相手鍛えたAIの対戦）を実現したいと思ってる。どうやら、機械学習っていうのは、変数に何を選ぶかが結構ポイントのようで、果たしてそんなにうまいことできるのかもまだわからないんだけど。まあ、まだ細々と勉強中のことだから、これが実現するのがいつになるのやら。

今回、YSUpload.comのご厚意で、ファイルをホストしていただけることになった。Vectorの方のリンクは、登録され次第復活の予定。

- OpenGL 2.0/ES 2.0対応 (爆発や炎の表示をちょっと良くした)
- Computer機定期便を飛ばせるようにした。一部マップのみ。
- 機体・地上物乗換え機能
- 着陸評価ダイアログ
- ランダムに機体トラブルを起こすことができるようにした。（確立を指定可能）
- 機体ダメージ表示を追加
- CPU-Renderedバージョンを使ってた方には非常に申し訳ないんだけど、対応しきれないもんでCPU-Renderedバージョンは廃止。
- その他バグフィックスなど

やっと、乗り換え機能を実装した。ネットワークモードだと、クライアントがサーバーにお伺いを立てて乗り換えるようにしないと、飛行機/車両の取り合いになるんで、その部分はまだ作ってないけど。これで、マップ内の基地を次々に制圧していくようなキャンペーンモードを作りたいと思ってるんだけど、まだそこまでできてない。

それから、着陸分析モードも追加した。着陸の採点もつけたらいいんではないか、と、思ったんだけど、ショートアプローチなんかの練習だと滑走路に正対する直前まで滑走路の延長線上に乗らないし、向かい風だと多少急なアプローチになるのが正常だし、だいたい教官によってはビジュアルで降りるときは多少急角度で降りた方がいいと言う人もいるから、多分、僕が適当に採点基準を決めると、多分納得いかない人が大発生する。なので、一応、経路表示と、接地時の降下速度、それと地面に対する横滑り角を表示するようにした。

YSFLIGHTに着陸評価機能、というか、接地評価機能をつけようと思った。一回のフライトで、接地時の縦方向の速度、あと、着陸前一分ぐらいの縦の奇跡をプロットできるようにすると、うまいこと着陸したか、後からレビューできる。

この機能をつけようと思ったんだけど、そのためには、フライト終了後、ユーザーの操縦による着陸をフライトレコードの中から探してこなくてはならない。前のバージョンまでのYSFLIGHTだと、一回のフライトにつき、ユーザーが操縦するのは一機だけだったから、その一機の着陸だけ拾い上げればいい。

と、思ったんだけど、次のバージョンでは、機体の乗り換え機能をつけようと思っている。乗り換え機能をつけると、たとえば、ユーザーは、必ずトラックに乗って開始しなくちゃならなくて、そして、空港に置いてある機体のうちのひとつを選んで搭乗して離陸、みたいなことができるようになる。これができると、Scenery Editorがそのままミッションエディタみたいになる。

ところが、乗り換え機能を実現すると、一度のフライトで、ユーザーが複数の機体を操縦する可能性があるんで、着陸評価のためには、ユーザーが操縦した飛行機全部を拾い上げて、それぞれの着陸を探してこなくてはならない。もしも、今のまま着陸評価機能を書いてしまうと、後から、複数機に対応するために、新たな書き換えが必要になるんで、それなら、まず乗り換え機能を実現してから、着陸評価機能を実装しようと思った。

この乗り換え機能ができて、Scenery Editorがミッションエディタみたいになると、今度は、敵基地を奪取して、そこに置いてある機体に乗り換えて再出撃、なんていうことができるようになる。それで、大戦略的に、敵基地を奪取、みたいなミッションを考えると、やっぱり、近寄っていったら迎撃に上がってくる敵機も配置したくなる。

ただ、迎撃に上がった敵機が、燃料を使い果たしたらすぐ墜落してしまうのだと、ユーザーはただ空中戦を引き伸ばす、というような手で対抗してくることも考えられるんで、燃料が減ってきたら、勝手に基地に戻って補給してくるような機能がほしい。

それを実現するには、各空港に着陸してからランプに行くまでのタキシング経路と、ランプから滑走路までの離陸経路のデータを追加して、さらに、コンピュータ機を自動操縦で基地まで戻して、ランプに戻って、補給車を呼んで、補給して、再度離陸してくる、ようなことが必要になる。

で、それが実現すると、ユーザー機と関係なくマップ内を飛び回る定期便を飛ばすことができる。たとえば、ヒースローとガトウィック間にコンコルドを飛ばす、なんてこともできるようになる。

というわけで、現在その機能を大体実装したところ。えーと、元は着陸評価機能を追加したかったんだけど。

新年おめでとうございます。今年もYSFLIGHTをよろしくお願いいたします。

ところで、最近、猫も杓子もクラウド・コンピューティング。コンピュータ関係のニュースを見ると、毎日必ずクラウドが云々というキーワードを見るほどの流行になっている。

ただ、僕は、流行しているからというだけの理由で新しい何かに飛びつくような性格じゃない。自分の興味は、流行とは独立していて、大概、それは流行とはあまり関係ない。そんなもんだから、大してクラウド・コンピューティングには興味が無かった。そんなもんだから、すっかりクラウド・コンピューティングの流行から取り残されてしまった。

しかし、技術の研究を職業としてる者として、これは問題だと思って、この年末の休みの間にキャッチアップすることにした。下はその成果。

ん？何？なんかクラウド・コンピューティングについて勘違いしてるって？でも、クラウドじゃん。

陰影はついてないんだけど、旧バージョンに比べてずっと本物のクラウドっぽくなった。陰影をつける実験もしたんだけど、2008年後期のMacbook Proでやったらフレームレートががた落ちしたんで、とりあえず当面陰影はつけないことにした。他のゲームとか、どうやって高速表示してるんだろう？

ところで、YSFLIGHTだけど、YSFLIGHT for Windows, YSFLIGHT for MacOSX, YSFLIGHT for Linuxは良かったんだけど、YSFLIGHT for Windowsには、OpenGLバージョンとDirect3Dバージョンがあって、「バージョン」というと、何月何日バージョンと混乱があるんで、どのように呼ぼうか考えてたんだけど、今後は、YSFLIGHT for Windows on OpenGL 1.xとかYSFLIGHT for Windows on Direct3Dみたいに呼ぶことにした。

というわけで、次のバージョンのYSFLIGHT for Windows on OpenGL 2.0/ES2.0では、雲が前のバージョンよりもくもくして見えるようになる。あとはスモークだなあ。

とりあえず、グラフィックコードの半分以上をOpenGL 2.0 / ES 2.0に移植できた。理屈では、グラフィックのコードをOpenGL ES 2.0に移植して、あとインターフェースの部分をタッチインターフェース用に書けば、YSFLIGHTをiOS上で実行できることになる。ただ、インターフェースの書き換えというのも大きな山だから、YSFLIGHT for iOSまでには、あと山を1.5個超えなくてはならない。次のバージョンでは、

ちなみに、OpenGL ES 2.0の仕様は非常に悪くて、Shaderプログラムを書かなくてはならない。このShader Languageなんていうものは、いずれCPUとGPUの境界が無くなったら、ただのC++のコールバック関数になるものだから、多分向こう5年、長くて10年ぐらいで消滅することが決まっている言語だから、あまり勉強して気分がいいものではない。けど、せっかくだから、ただ時間を無駄にするだけじゃなく、視覚効果を追加してみた。

まず、YSFLIGHTの爆発があまりにもチープと言われ続けていたから、アルファマスクをかけて、もう少し爆煙っぽくしてみた。ちなみに、このアルファマスクは、過去の航空ショーで撮ってきた写真を加工して作ったから、本物の爆発からできている。ただ、ちょっと変なのは、輪郭はぼんやり消したつもりなんだけど、まだ8角形に見えるんだよな。なんで消えてくれないんだろう？それでも、前のバージョンの爆煙より良く見えると思うんだけど。

多分、スモークトレールとか雲ももう少し良くできると思うんだけど、それは現在勉強中。スモークも雲も、色は今のままでいいんだよね。輪郭線が雲っぽく見えるようにできればいいんだけど。論文とかに出てる方法だと、ちょっと60フレーム毎秒でたくさん雲を描画するのは無理っぽそうだったり、雲がひとつやふたつならいいけど、多数あったら、メモリが足りないって、というような方法ばっかりのようだから、そこまでリアルじゃなくていいから、簡単にできそうな方法を模索中。現バージョンだと、雲は最初に開始地点上空に発生させて、それっきりだけど、新しいバージョンでは、雲が増えるようにしたいと思ってるから、メモリ食う方法はだめだね。

感謝祭の休日の成果。やっとOpenGL ES 2.0 + iOS SDKでF-22の表示に成功。あと、一応タッチで回転できるようになってる、と、言ってもまだSimulator上でしか試してないけど。あと、YSFLIGHT本体の方も、iOS上でも実行できるように、構造を大改造中。大改造中と言っても、ユーザから見ると何も変わらないけど。もう少し開発が進んだら、iPhone Developer Programに入ってデバイス上でのテストを始めようかな。

次のバージョンで少なくとも決まってることは、CPU Rendered版は正式に廃止して、代わりにOpenGL 2.0に対応する予定。細かいことだけど、OpenGL 2.0だと視覚効果とか、ちょっとだけ良くなる予定。

Microsoft Surfaceに対応することも考えたけど、ありゃあ、ひどいもんだね。OpenGL非対応、Direct Xは、Direct X11のみ対応、Direct X9で書いたプログラムは実行できないって、グラフィックスの部分をほとんど全面的に書き換えろって言ってるわけだけど。OpenGLを切った時点で、かなりの多くのプログラマーを切り捨ててるけど、その上Direct X9でやってたプログラマーも切り捨てて、それでソフトウェアが順調に出てくると思ってるんだろうか。少なくともOpenGL ESにぐらいは対応してくれなきゃ。Microsoftが独占状態だったときは、傲慢でも良かったろうけどね。Microsoftが今でも、世界中のプログラマーがWindowsでしか動作しないプログラムを書いてくれると思ってるんだったら、Microsoftの将来は暗い。

VectorとDownload.comから連絡無いなあ、と思ってたら、実はもう登録されてた。なんで連絡が無いんだ。。。。Spamメールと思ってサーバーに消されたかな？

とりあえず、プレイに障害になるようなバグは取れていると思います。操縦に支障の無いバグは、まだ直ってないのもありますが、そろそろいったん安定した版を出さないと、無限ループにはまりそうだったので、いったん正式版ということで出させていただきました。今回も、バグレポートにご協力ありがとうございました。レポートいただいたバグで直っていないものは引き続き直していきますんで、気長にYSFLIGHTとお付き合いください。また、Scenery Editorの方が引き続きテスト中ですんで、気づいた点などありましたら、ご報告ください。

1月中にテスト始めるという目標には間に合わなかったけど、あと少しでリリース前テストを始められる、と、思う。次のバージョンでは、一応、視界が悪い状態で、管制官にアプローチを要請して、ヘディングとか高度とかの指示を受けながら、ファイナルアプローチコースに乗る、というような飛び方ができるようにする。まだトラフィックのスペーシングはしてくれないんだけど。とりあえず、実験で飛んだ限りでは、正しいヘディングを指示してくれるようなので、IFRの雰囲気だけでも再現できたのではないか、と、思う。本当は、音声で指示を読み上げてくれるといいんだけど。まだ、そこまでは実現してない。語彙が一定だから、ある程度の単語を録音したらそれをつなげてできそうな気もするんだけど。

とりあえず、着陸訓練モードで、管制官がターンのタイミングを言ってくれるようになるから、多分、どこで曲がっていいかわからなくてローカライザーをオーバーシュートすることはなくなるはず。

しかし、音声が無いと、ウィンドウの左上にメッセージが出ても計器に集中してて気がつかないことが多発することが判明。とりあえず「ポーン」という鳴らして知らせることにしてみた。

ちなみに、下は、次のバージョンで追加する地対空迎撃ミッションのスクリーンショット。15分間の時間つぶしには結構おもしろい、と、思う。これこそiOSとかAndroidに移植できればいいんだよな。

次のバージョンの予告編。空母甲板に傾斜をつけることができるようにした。これは結構僕の中では優先順位が高かった変更で、これによって、空母インビンシブルみたいなのができるようになった。あと、同じ仕組みで地上物が橋の上を通行できるようにした。現状では、ひとつの地上物で複数階は構造上できないけど、上下に地上物を重ねて配置することで、立体駐車みたいなのも一応実現可能なはず。飛行機が地下から出てきて、斜面を登って滑走路に出てて離陸、なんてことも可能になった。

これを実現するには、結構中身をいじったんで、やっぱり、結構バグも潜んでるんだろうな。。。。YSFLIGHTを最初に作ったとき、地上物はおまけみたいな感じで作ってたんで、まったく航空機とは無関係のデータ構造になっていて、このへんまじめに考えて作ればよかったと結構長いこと後悔していた。今回、思い切って、地上物と航空機のデータ構造の共通部分を抜き出して、コードを共通化した。

C++プログラミングの話をすると、今まで、class FsAirplanePropertyとclass FsGroundPropertyというまったく無関係のふたつのクラスに分かれてたものを、class FsVehiclePropertyというクラスを作って、そこに共通なデータ構造を持たせて、FsAirplaneProperty、FsGroundPropertyはFsVehiclePropertyから派生するように書き換えた。まだいくつも共通な部分があるから、引き続き構造の見直しは進めていくけど、とりあえず、今までやった分だけで、上のような機能の追加ができるようになった。というか、旧データ構造でも実現は可能だったけど、同じものを二箇所ずつ書かなきゃならなくなるからかなり面倒なことになるところだったのが、データ構造を前よりクリーンにしたことで、少ない単純なコーディングで実現できるようになった。

まだいくつか追加したい新機能があるんで、それが出来たらテスト版を公開の予定。それは、多分1月下旬か2月上旬ぐらいにはできると思うけど、まだはっきり確定できるレベルになってない。

空母インビンシブルのフライトデッキから離陸するハリアー。AV-8Bだから、イギリス空軍のハリアーと微妙に違うけど。

橋の斜面を登るジープ。地上物の動きは、ぜんぜん物理計算とかしてないんでいい加減。

一応、（半分意地で）操作可能な地上物を一応作ってみた。まだ、ジープと燃料トラックに乗れるようになっただけだけど、とりあえず、一歩前進。扉の開閉ができるようにしたんで、そのうち扉を開けて、他の航空機または地上物に乗り換えることができるようにする予定。かなりいい加減だけどドリフトもするから、レースコースなんか作るとレースができるかも。

しかし、今の状態だと、ジープか燃料トラックで出ても何もすることが無いんで、次のステップとして、対空砲を操作できるようにして、対空砲で拠点防空ミッションを作れるようにしようと思ってる。

現状では、ユーザが操作する地上物と他の地上物との衝突判定が無いんで、その衝突判定を作ろうと思ったら、今まで手抜きしていた衝突判定高速化のためのデータ構造をまじめに書き直す必要が出て、それをまじめに書き直すと、飛行機同士の衝突判定とかも微妙に書き直さなくちゃならなくなって、一応、そこまでやったとこ。

あと、地上物でドアが開くようにしたから、飛行機でもキャノピーとか開けられるようにしようかとちょっと考えているところ。あと、飛行機でも地上でタイヤが回転するようにしてみようかとも考えてるけど、実現するかどうかは未定。

扉も開く。今のところデフォルトでセミコロンキーで開閉。

YSFLIGHTは、相変わらず、マイペースでゆっくりな開発が続いているけど、ちょっと最近の開発状況報告をしようと思った。20110207バージョンから、手元の開発中バージョンでは、次のような点が変わった。

多言語対応は、簡単にできなさそうだから、次のバージョンでは無理だろう、と、思ってたんだけど、一念発起したらできてしまった。

今の正式版だと、日本語を表示するために、メッセージをすべてPNG形式ビットマップで持たせている。PNG形式は圧縮率も良くて、ハードディスク全体から見ると大した浪費ではないけれど、プログラマーとして、いまいちすっきりしないやり方だった。ついでに、フォントサイズを変えたとき、ビットマップの拡大・縮小で対応するもんだから、字が崩れて読みにくいという問題もあった。

次のバージョンでは、もっとすっきりした形で多言語に対応する。僕が対応できるのは、日本語と英語だけだけど、定義ファイルを記述することで、他の言語にも対応できるようにする。定義ファイルは次のような書式で、UTF8（Shift-JISとかEUCはダメ)で保存すれば、日本語に限らず、他の言語にも対応できるようにした。ただし、右から左に書く言語は対応できんけど。

日本語圏の人と英語圏の人にはあまり関係ない変化かもしれないけど、これまでにYSFLIGHTの感想を30カ国以上から受け取っていて、なんとか多言語にも対応したいとは思っていた。日本語と英語以外の定義ファイルに関しては、ここは、図々しいけど、各国のユーザコミュニティに甘えてしまおうと思う。

今のYSFLIGHTだと、フィールドのY=0が標高0ということになってるけど、地元ピッツバーグのマップとか作ろうと思うと、このへんの標高は約1200ft (366m) なもんだから、全体をElevation Gridでカバーするなどということをしないといけなくなってしまう。なので、これはScenery Editorと合わせてのバージョンアップになるけど、フィールドにベースとなる標高を指定できるようにする。

それから、一口に方位と言っても、実は磁方位と真方位というのがある。例えば、北と言っても、本当にそっちに真っ直ぐ向かっていくと北極点に到達する方位と、磁石のN極が指す方位にはちょっとズレがある。なので、本物の東西南北のことを真方位と、磁石を元に出した方位を磁方位と言う。それで、飛行機が飛ぶときは、コンパスが磁石でできてるもんだから、磁方位を基準にする。実際、ピッツバーグ周辺だと、真方位に対して磁方位が+8度もずれている。ところが、YSFLIGHTでは、この差（Magnetic Variation : マグねティっク・バリエーションと言う) は無視していた。けど、新しいバージョンでは、フィールドごとにMagnetic Variationを指定できるようにする。まあ、セスナでも1時間半も西か東飛べば、Magnetic Variationも1度ぐらい変化するんだけど、そこはまだ無視することにした。

そのほかは、報告のあったバグをちょっとずつ直しているところ。操縦できる地上物とか、バーチャル管制官とか、ダイナミックにコンピュータ機を生成して飛ばす、飛行機/地上物の乗り換え、とか、その他にも多数TODOリストの上位に上ってる項目はあるんだけど、それはできるところからちょっとずつ追加していくので、気長にお待ちください。

YSFLIGHT Version. 20110207用ネットワークサーバーを起動してみた。アドレスは↓。

6時間ごとにリセットで、バッチファイルでリセットするたびにフィールドを切り替えるようにしてある。でも、CMUの僕の机に置いてあるんで、日本からのアクセスだとラグが結構あるかもしれない。

これは、我が妻が以前使ってたラップトップ、Dynabook T4-495CMEという年代モノのラップトップで、コンソールサーバーだったらこのぐらいでもなんとかなった。ただ、既に光学ドライブはまともに動作せず、いつ壊れるかわからないんで、とりあえず壊れるまで起動しとく予定。

のんびり飛ぶなり、地上に強力な敵陣地があるマップだったら連携プレーで攻撃に行ったり、ご自由にご利用ください。

VectorソフトライブラリにYSFLIGHTの新バージョン20110207が登録されてダウンロードできるようになった。主な変更点は次の通り。

それから、Windows 98でYSFLIGHTを使うには、今メインで使ってるVisual Studio 2008でコンパイルしたバイナリだと使えないもんで、別に古いバージョンのコンパイラでコンパイルした実行ファイルをここからダウンロードできるようにしてみた。もうWindows 98実行してるPCが無いもんだから、確認できなかったんだけど、多分、これでWindows 98でも実行できると思うんだけど。

それから、サウンド用のDLLのソースファイルも公開した。DLLで機能を拡張できるようにする、という予定だけ立てたのがもう2年も前で、やっとサウンドだけかい、という声も聞こえて来そうな感じがするけどごめんなさい。気長にお待ちください。

今回も、テストバージョンで、多くのフィードバックをいただいて、大変お世話になりました。おかげさまで、（前から放置されたまま僕が気づいてなかったバグまで取れて）かなり安定した良いバージョンにできたと思います。ありがとうございました。

DirectSoundに対応したけど、マイクロソフトのプログラマーの資質に疑問が増える。

数日前、YSFLIGHTユーザの方からメールがあって、サウンド関係でトラブル発生とのことだった。ちなみに、メールの返事は現在3ヶ月遅れまで回復してきたので、まだ返事が来てない方は、もう少しお待ちください。返事が遅くてすみません。

Windows用YSFLIGHTの効果音は、いずれDirectSoundにしないとなあ、と、思いつつ放置していたので、ここで一念発起してDirectSound化してしまうことにした。DirectX系APIって根本的にソフトウェア設計とかわかってない人が作ってるんじゃないかと思うことが多い。最近、そう思ってるのは僕だけじゃないことが判明したので、割と自信を持って言える。DirectXの設計は基本ができてない。けど、DirectSoundは、サウンド鳴らすだけならそうひどいことも無いでしょ、と、思ってとりあえずコマンドから音を鳴らす例題を作ってみた。ちなみに、そうひどいことも無いでしょ、という期待は過去何度と無くマイクロソフトによって裏切られてきた。

というわけで、例題を作ったが、音が鳴らない。エラーコードをチェックすると、DSERR_PRIOLEVELNEEDED。IDirectSoundBuffer8のPlayメソッドの説明で、CooperativeLevelというのをセットしないと音が出ない、というのと関係があるのかもしれない、と、思ってIDirectSound8のSetCooperativeLevelという関数を見てみる。

ん？第一引数がウィンドウハンドル？なんで音を出すのにウィンドウが関係するの？常識的に考えて、ウィンドウが無ければ音が出ないなどという、本質的にバカな仕様なはずがない、と、思ってこれはきっとNULLでも大丈夫に違いない、と、思って試しにNULLポインタを渡してみた。本質的にバカな仕様なはずがない、という期待は、過去幾度にもわたってマイクロソフトによって裏切られてきた。NULLポインタを渡してSetCooperativeLevelを呼んでみたけど、結果は一緒。音が出ない。まさかと思いつつダミーのウィンドウを作ってやってみたら、鳴った。いや、それならそれでもいいから、ダミーのウィンドウを作って、それを非表示にしたらどうか、と、思ったら鳴らない。そんなバカな、と、思ってGoogleで調べてみたけど、どうやら根本的なDirectSoundの問題のようで、どうやら、見えるウィンドウが無いと音が鳴らないらしい。

インターフェースを設計するときは余計な依存関係を作らないようにって学校で習わなかったか？＞ DirectSound作った人

YSFLIGHTは、Windows用、Mac用、Linux用があるんで、サウンド関係はサウンド関係だけで独立したモジュールにして、それぞれ共通のインターフェースで音が鳴るようにしたい。ところが、Windows用だけサウンドがウィンドウに依存するのだと、サウンドの初期化は必ずメインウィンドウを開いた後にする必要がある。また、なんらかの理由で、メインウィンドウを閉じて（最小化じゃなく閉じて）開きなおすような必要があると、Windows用だけ改めてウィンドウハンドルをサウンドモジュールに通知しなおすという余計な処理が必要になる。今のところ、メインウィンドウは起動時に開いて開きっぱなしだからいいけれど、そのうちそういう必要性が出たら困る。また、音が変になったとき、ウィンドウが悪いのか、DirectSoundが悪いのか、判定が難しい。独立したテストプログラムを書いて何が悪いのか究明できない。まあ、できないとは言わないけど不必要に難しい。というのは単なる一例で、とにかく、DirectSoundがウィンドウに依存するというのが良くない。DirectSoundを作った人は、そういう基本中の基本がわかってないってことだ。ウィンドウマネジャに依存するってそれだけの理由で、成績Fと言っていい。思わずダメな設計の例として授業で見せてやろうかと思った。

そんな基本ができてないプログラマーでもマイクロソフトで給料もらってるのね。マイクロソフトの天下も長くは続かないかもしれない。あれだけ大規模な会社になれば、必ずしも優秀ではないプログラマーも間違って雇ってしまうことはある。が、技術が未熟なプログラマーが、DirectSoundのインターフェースの設計に従事しているってとこが問題。

とりあえず、YSFLIGHTはなんとかなったからいいけど。というわけで、次のバージョンだとWindows用でもエンジン音が途切れないで機関砲の音とか鳴ります。乞御期待！

ちなみに、これがそのとき作ったテストプログラム。ウィンドウが無いとダメらしい。

今のところ、それほどユーザーインターフェースに関する要望はそれほど多くないけれど、インターフェースの改良にも取り組んでいる。それで、タブダイアログを使えるようにした、というか、とりあえず実装したので、テスト中。今のところ正常に動作している模様。航空機選択ダイアログで、搭載するものの種類が増えてきてしまったので、ダイアログが混み混みになってしまいそうだったけど、これでなんとか整理できると思う。

下は現在開発中バージョンのスクリーンショット。結構要望が多かった、高抵抗爆弾を追加した。これを使うと、レーダーを避けて超低空を侵攻して、攻撃して帰ってくるようなミッションが作れると思う。最近の世代の戦闘機だと本物は地形追従システムがあるから、自動操縦でできるんだろうけど、それだとゲームとしておもしろくないから、YSFLIGHT内ではやっぱり自力で操縦ってことで。

それから、チャフ・フレアポッド（ゲーム中ではフレアしか無いけど）を搭載することもできるようにした。ミサイル使用のEndurance Modeでフレアを使い切ってしまって15分持たなかったような人は、これを搭載して出ると勝てるかも。

それから、これも結構要望が多く来ていた外部燃料タンクも追加してみた。ただ、これは追加するかどうか結構迷っていた装備だった。というのも、追加燃料タンクを搭載して燃料を増やしても、そんなに長い時間飛び続けたらユーザーが疲れてしまうんじゃないか、というのが気になっていた。YSFLIGHTの最初のバージョンを作った当時、これからどんな感じに拡張していこうか、と、考えていたころ、ふと、サウジアラビアから飛び立ってイラクを攻撃してくるようなミッションを作れたら時事ネタでおもしろいかもしれない、と、思った次の瞬間、「....何時間もひたすら巡航して楽しいか？」という疑問に直面して、やっぱりマップは最大速度で飛んでも30分とか一時間圏内にしよう、と、思った。

実際の軍のパイロットの資質のひとつとして、忍耐力ってのがかなり重要になってくるんだと思う。目標上空にいる時間というのはほんのわずかで、現実は、基地なり空母なりを飛び立ってから、いつ迎撃を受けるかわからない緊張感の中、目標まで数時間、ひたすら飛ばなくてはならない。これは、相当辛抱強くないとやってられない職業だと思う。

というわけなので、YSFLIGHTで外部燃料タンクを使えるようにはしてみたけど、それが活用できるようなミッションとか作れるのか、現在考え中。燃料切れで廃空港に不時着した友軍機に燃料持ってくミッションとかありかな？

それから、短距離AAMが二種類になって、A-AAMというのは形状のモデルはAIM-9Xだけど、何が違うかというと、ミサイルが目標をいったん見失っても発射母機の方で同一目標を補足していけば、再度目標に向かっていくようにしてみた。継続して補足できるような位置から発射すると命中率が圧倒的に高くなるし、敵機に撃たれたら、ただミサイルを振り切るだけでなく、敵機の補足圏外に出ないとミサイルの射程が切れるまでどんどん追ってくるようになった。あと中距離AAMにも同様の機能を追加したので、現バージョンほど中距離AAMが役に立たないということは無ったと思う。(なお、簡単に調べたところ、最近の空対空ミサイルは本当に発射母機との間にデータリンクがあるそうで、アクティブ誘導とパッシブ誘導の両方のいいとこを取ってるらしい。）

Add-On作者の皆様へ。これまでのバージョンでは、飛行機の.DATファイルで、武装搭載箇所だけ指定した後で、MAXNMAAMなどのコマンドで搭載箇所の個数を超える武装の搭載が可能でしたが、次のバージョンでは、MAXNMGUN以外の指定は(エラーは出しませんが)無効になり、搭載個数はHRDPOINTのみで決まるようになります。また、ひとつの搭載箇所に複数の弾薬を搭載するような場合は、

のように記述することでできます。HRDPOINTに個数指定が無い場合、ロケット弾は19発、それ以外は一発の搭載になります。

補足: MAXNMAAMなどの記述は、あってもエラーにはならないので、旧DATファイルもそのままでも使うことはできます。

YSFLIGHT本体と平行して、Scenery Editorも開発を進めている。もうすぐ、Windowsだけでなく、MacOSXとLinuxでもネイティブで使えるようにする予定。一応、全機能をYSFLIGHT用GUIライブラリに移行させることができて、今日、MacOSXとLinuxでコンパイルして実行することができた。まだいろいろ変なとこがあったんで、これから直していくところ。

今、目標としては、地元のアレゲニー・カウンティ空港、ピッツバーグ国際空港、それと、最近飛行機借りてるビーバー・カウンティ空港を作りたいと思っている。それで、YSFLIGHTで管制官からの誘導でIFRのアプローチの練習ができるようにしてやろうと思ってるんだけど、そのためには、マップ上にアプローチプロシージャーを編集できるようにするとか、管制空域を設定できるようにするとかの機能が必要で、まだ先は長い。

そういえば、YSFLIGHT開発中バージョンのスクリーンショットで、新しいHUDを公開したら、小さいモニター画面だと読み取れなくなるのではないか、という質問のメールを結構いただいた。けど、それはまったくもっともなご意見なので、旧デザインのHUDも設定で選ぶことができるようになっていので、その点は大丈夫。

結構要望が多かった、マルチスモーク、フレア射出位置と射出方向の設定ができるようにした。フレアの表示もParticleにすればもっと綺麗になると思うんで、それも検討中。それから、計器パネルとHUDの同時表示もできるようにしてみた。

開発中バージョンのヘッドアップディスプレイと計器パネル

YSFLIGHTの計器パネルとヘッドアップディスプレイは、従来のバージョンだと、いまいち見栄えが悪かった。見栄えが悪いだけならまだしも、コクピット内視点で、表示方向を変えると見えなくなってしまうという問題があった。そこで、次のバージョンでは、コクピット内視点なら、見る方向を変えたりズームを変えても計器パネルまたはヘッドアップディスプレイを表示するようにしてみた。（ただし、CPU-Rendered版は非対応。）

関連サイトのコーナーに、YsFlightInformationGehaを追加。（しかし、関連サイトっていうのもなんかネーミングが変な気がするから、「ファンサイト」とか「ユーザーサイト」とかに変えようかな）。

お待たせしました。YSFLIGHT Version 20100331公開です! 今回も、テスト期間中に多くのユーザにご協力いただきました。本当にありがとうございました。

Mac OS Xへの移植に時間がかかったもんで、ちょっと機能面で新しい追加は少なかったかもしれない。けど、とりあえず、Mac版はこれで一段落したんで、これから、またいろいろ期待に応えられるように、機能を追加していこうと思う。なので、気長にお付き合いください。要望とは関係ないんだけど、これの次のバージョンで、ひとつこれは絶対やりたいと思ってるのが、Head Up Displayをもう少し本物っぽくしたいと思っている。あと、モニタをふたつつなげて、片方に計器、片方に景色を表示できるようにしたい。それで、管制官の誘導で計器アプローチができるようにしたい。やりたいことはいっぱいあるんだけど、まあ、時間ができたらちょっとずつ書いていく。

それから、前のポストの「ジェットエンジン出力の謎」にたくさんメールで有益なコメントをいただきました。今後のYSFLIGHT開発で取り入れていこうと思います。ありがとうございました。

YSFLIGHTを作ってて、ひとつだけなんとかしたいと思っていて、どうすりゃいいのかわからないことがある。いや、ひとつだけってことは無いな。いくつかある。いや、結構たくさんあるかも。

ただ、その中の筆頭が、エンジン出力の計算式。プロペラ機の場合、大雑把に計算すると、エンジンの馬力×プロペラ効率÷スピードで出力が計算できる。けど、これはかなり大雑把な上に、プロペラ効率は飛行機のスピードにも影響を受ける。しかも、スピードで割っちゃうんだから、速度がゼロのとき無限大の出力が出ることになる。けど、速度が低いときは、プロペラ効率も悪いんで、無限大の出力にはならない。実際、速度が低い状態だと、プロペラのブレードの迎え角が大きいので、プロペラブレードの揚力効力比はかなり悪くて、スロットルを押し込んでも、そんなに回転数が上がらない。そういう状態までもっともらしい推力の値を得るには、簡単な式は無くて、真面目にプロペラブレードごとの揚力を計算してやらないと正しい出力はわからないんだと思う。というか、大雑把にプロペラブレードごとの揚力を計算するようにすれば、この問題は結構解決するはずだ。（問題は、いつ僕がやる気を出すかということ）

もっとわからないのがジェットエンジン。ジェットエンジンは、エンジンに流入する空気を内部で加速するので、その反作用が推力になる。なので、流入する気体の速度と出て行く気体の速度差に単位時間にジェットエンジンを通過する気体の質量が推力になる。ジェットエンジンの説明を読むと、エンジン出力の式 T=m(v2-v1) とかいうのを見ると思うんだけど、この式がそれ。ということは、エンジンは、静止時に最大の出力が出て、速度が上がるにつれて、推力が下がっていく、ということになる。

けど、それだと、F-15とかF-22とか推力重量比が軽く1を超えてるような飛行機は、公開されてる性能緒言を元に飛行機のデータを作ると、離陸時にありえない勢いで加速してしまう。速度が低いうちは、タイヤの抵抗も、空気抵抗も小さいから、自由落下よりも大きな加速が出ることになる。航空ショーとかで飛んでるのを見ても、あの勢いでは絶対加速してない。

この問題について、中学時代の友達の目撃証言として、どこか（たしか千歳基地と言ってたと思う）の航空祭でF-15が目測で100mも滑走しないうちに脚が地面から離れ、ちょっと水平に加速してから垂直上昇をやった、と言っていた。けど、彼の目測はかなりあてにならないんではないかと思っている。そもそも、彼は、離陸滑走中のF-15よりもかなり遠くにいたはずなので、遠くのF-15が少ししか動いていないように見えても、実際は結構な距離を移動していた可能性がある。

ただ、ジェフ・エセル(Jeff Ethell)著、浜田一穂訳「F-15イーグル」(原書房)の中には、F-15はアフターバーナー全開で離陸するとき（多分クリーン形態だと思うけど）は、60度の上昇角にしないと、離陸上昇中に音速を超えてしまう、という記述があるので、案外最近の戦闘機のアフターバーナー全開というのは本当に半端無いのかもしれない。そうだとすると、普段航空ショーで見るアフターバーナーを利用しての離陸というのは、実は本来出せる出力の6～7割の力しか出してないのかもしれない。でも、本当にそうなのかね？

それで、僕が思うに、ジェットエンジンって、静止時じゃなくて、ある程度速度が出てるときに出力が最大になるんだと思うんだよね。だから、多分、ジェットエンジンが最大推力を出せる最適な速度があるんだと思う。大体どういう傾向でエンジン出力がピークになるのかがわかると、それを力学計算で加味するんだけど、残念ながらこの情報がわからない。こればっかりは、僕がやる気出そうったって、どう力学計算を修正していいのかわからないもんだから、どうにもならんのだよね。多分、これがわかると、戦闘機によってエンジンが最適に出力を出す速度が違うから、いかにその速度を保って空中戦を戦うか、とか考えて飛ばなきゃ勝てなくなって、おもしろくなると思うんだけど。それに、軍用機については、こういう情報は機密なんだと思う。だって、僕が空中戦をやってる相手が苦手な速度を知っていたら、自分はその速度を維持するように飛ぶだけで相手より随分大きなアドバンテージが持てるから。というわけで、この情報は、YSFLIGHTの中には取り入れられないままになっている。

YSFLIGHTは、とりあえず、YSFLIGHT for Mac OS Xを出して、それから、Windows用、Linux用を順次更新しようと思っていたけど、やっぱり、まとめて更新することにした。Windows用、Linux用は、インターフェース周りの改善とかがメインで、かなりマイナーなアップグレードになってしまうけど、それでも、いくつかMac用で追加した機能とか視覚効果が使えるようになった方がいいかと思った。ついでに、F-22のモデルを更新した。結構気合入れて作ったんで、細かいとこまでよくできてると思うんだけど。（コクピットはただの囲いだけど。）とりあえず、まだどれもテスト版なので、近いうちにリリース前テストを通してから、正式にVectorにアップロードの予定。

ところで、Macbook Proを買おうと思った。僕がMacを買おうと思うというだけで、ちょっと前ならありえないことだった。僕は機械工学科にいる。工学ってのは、まず機能的に使い物になるのが最優先で、見てくれを良くするために機能を削減するようなものは、好きになれない。逆に、ある目的を達成するために作り上げたものが結果的に美しくなったようなものは、最高の芸術だと思う。そういう理由で僕はコンコルドが好きなんだけど。そして、僕のMacに対する印象は、見てくれがいいだけで、使い物にならないもの、という印象だった。第一印象というのは恐ろしいもので、そう思ってしまったら、Mac OSのバージョンが上がっても、どうせ一緒だろうと思ってあらためてどういうものか見てみる気も起こらなかった。

その大きな転換点は、Windows Vistaだった。、Windows Vistaこそ見てくれだけで使い物にならないOSの親玉だった。ありゃあ使い物にならんかった。遅いってのもそうだけど、いろんなインターフェースが変わっちゃってた、というかキーボードだけでできないことが多くなった（と、思う）のが困った。僕はプログラミングが仕事だから、ほとんどの作業をショートカットキーでできるように指が覚えている。また、OSなんて使ってるうちに重くなって再インストールが必要になるんだから、ほとんどカスタマイズしない。素のWindows XPを速く使えるようにキーを覚えてきた。それを、ごっそり変えちゃうってのは、それまでWindows XPを使いこなしてきたユーザに対する裏切りと言っていい。同じ理由で、Windows 7にも大して良い印象が無い。何が悲しくて新しいインターフェースを覚えなおさなきゃならんのか。新しい使い方を覚えなおすために費やす時間ってのは、完全な無駄だ。世界中のユーザがインターフェースを覚えなおすために、仕事がストップまたはスローダウンしている時間を計算すると、恐るべき経済損失になってるはずだ。

Windows Vista/7の登場によって、別にMacがWindowsよりいいと思ったってわけじゃないんだけど、Windowsにこだわる理由が無くなっちゃった。というタイミングで、CMUでプログラミングの授業を教えることになる。それで、授業を履修している学生さんのうち、少なくとも3人は、Macで宿題がしたいという人がいた。教える方としても、宿題とか、夜中までCMUのPC部屋に篭って宿題をさせるのは心苦しい。なるべく学生さんの手持ちのPCでできるようにしてあげたい。そのためには、OpenGLが使えるウィンドウを開いて、キー、マウスの入力を取ってくる簡単なフレームワークを作る必要があった。これはちょうどいい機会だし、ということで、CMUのMac部屋に行ってMacのプログラミングを勉強してみることにした。

それで、やってみたら、Mac OS Xって結構いい。Objective-Cを使わなくても良けりゃなお良いけど。ベースがFree BSDなので、安心感がある。ただ、使っててマウスとキーボードの反応が一切無くなる現象も何度かあったので、Windowsよりも必ずしも安定しているとは思えない。だとしても、ひょっとするとWindows 7よりこっちの方がいいかもしれないなあ、と、思った。

結局、秀丸エディタが使えないのでWindowsから離れられない現実はあるということに気づいたけど、それでも、現在、うちで使っている6年目のPCをMacbook Proで置き換えて、ハードディスクの半分にWindows XPを入れて、バーチャルマシンにLinuxを入れればYSFLIGHT開発にも仕事にも使える完璧な環境になるんじゃないだろうか、という結論に達した。やっぱり、遠出の時にもって歩ける方がいいから、13インチか15インチがいい。それじゃあってことで、近所のApple Storeに行って使ってみた。感触も良くて、思わずそのまま発注しちゃうところだった。

.... eSATAで外付けハードディスクをつなぐことができないってことに気づくまでは。

仕事にも使うためには、eSATAで外付けハードディスクがつながらないのでは話にならない。USB 2.0が速かった時代は、既に一昨年には終わっていて、Firewire 800で十分だった時代は、去年か一昨年あたりで終わっている。既にハードディスクの連続転送速度は800Mbpsを超えている。扱うデータの中には大きいのもあるので、ハードディスクは全力で動いて欲しい。今のラインナップで、eSATAポートを使うことができるのは、Express Cardスロットがある17インチモデルだけで、15インチ、13インチモデルは、外付けハードディスクはFirewire 800が最速らしい。しかも、2008年後半モデルだと15インチMacbook ProにもExpress Cardスロットがあったらしい。それを、わざわざSDカードスロットに置き換えて、2009年モデルにしたんだとか。CPUのスピードは上がったかもしらんけど、外部記憶装置とのデータ転送速度はダウングレードになった。SDカードなんて、ちっこいReaderを持って歩けば読み書きできる。けど、USBでExpress Cardを置き換えることはできない。Express CardスロットをSDカードスロットに変更した設計上の判断は、明らかな誤りだった。少なくとも、ここに、それだけの理由でMacbookを買うのを控えてる僕がいる。そんなの、ちょっと考えればわかりそうなもんだけどなあ。

こういうところはいかにもApple。やっぱりAppleはもう一歩のところで使い物にならないものしか作らんのだろうか。Mac OS Xが結構気に入っていただけに、がっかりした。

別に、Web見て、メール見て、動画見るだけなら、eSATA接続なんて無くてもいいと思うけど。n十万行のプログラム（YSFLIGHTじゃないよ）をコンパイルして、100MB以上のテストファイルを何本も読み書きするような用途には使い物になんない。ラップトップなんだから、デスクトップ並みの計算力はなくてもいいんだけど、ハードディスクの読み書きスピードとか、遅くならなくてもいいところで遅くなられるのは困る。

できれば、YSFLIGHTの開発用に一台Macが欲しいところなんだけど、$2000投資して仕事には使えないPC買うわけにいかんし。というわけで、もうすぐ出ると噂されている新しいラインナップを待っている。2009年モデルユーザがAppleにたくさん文句言ってればいいけどなあ。新しい15インチモデルにeSATAポートかExpress Cardスロット(USB 3.0でも可)がついてりゃすぐにも発注するんだけど。

サイドウィンドウの表示ができるようになった。あと、一応効果音も追加したけど、何故かちょっと違和感がある。それから、ネットワークモードも動作を確認。12月中には、テスト版を出す予定。

さらにYSFLIGHT for Mac OS Xのスクリーンショット
とりあえず、マウスを操縦桿にして操縦できるようにした。とりあえず、三沢基地のRW28から飛び立って、Left Traffic Patternで着陸できることを確認してみた。あと、地面のテクスチャを追加。まだ、サブウィンドウ開いたり、効果音つけたり、ユーザディレクトリに設定を保存するようにするとか、やることたくさんあるけど、とりあえず、移植作業進行中。

YSFLIGHT for Mac OS Xのスクリーンショット
YSFLIGHTのMac OS Xへの移植に向けて、大きく前進。とりあえず、オートデモが動いて、メニューや各ダイアログが使えるようになった。まだ、操縦するには、少しのプログラミングが必要だけど、既にジョイスティックの読み取りは、別のプログラムでテスト済みなので、あとは、時間の問題で操縦もできるようになると思う。

ちなみに、自分用のMac持ってないもんだから、どうやってプログラミングしてるかというと、まずWindows上で、「これで動くはず」というプログラムを書いておいて、それを大学のファイルシステムに転送して、それで、Wean HallのMac部屋に歩いていってコンパイルしてテストするという、非常に効率の悪い開発の仕方をしている。なので、あんまり速くは進まないんだけど。それでも、ちょっとずつは進行しているので。

Windows 7での動作確認
研究室に何台かWindows 7が入ったので、試しにYSFLIGHTが実行できるかやってみた。結果は成功。すべての機能をテストしたわけじゃないけど、動作に支障は無いようだった。

ただ、OpenGLの動作が極端に遅かった。これが、うちの研究室のPC固有の問題なのか、Microsoftが意図的にOpenGLの動作を遅くしているのかは不明。多分、後者だと思う。Direct 3Dをプロモートするために、意図的にOpenGLの動作を遅くするぐらいのことは、Microsoftならやるだろう。

とりあえず、Direct 3Dだと普通に高速に動作したので、Windows 7の人は、当面Direct 3Dを使っていただきたいと思う。

百里基地航空祭、エアロックブースのフライトシミュレータ体験会
百里基地航空祭、エアロックブースのフライトシミュレータ体験会でYSFLIGHTを使用していただけるとのことです！詳しい情報は次の通りです。

百里基地航空祭にお越しの際は、是非お立ち寄りください！

YSFLIGHT Ubuntu Linux版バイナリ
YSFLIGHTの新バージョンを公開してから、Linux版がSegmentation Faultで落ちるというレポートを結構多くいただいた。これまでは、Linux版は、Cent OS 5でコンパイルしてテストしていたんだけど、どうも、そのバイナリがUbuntuと互換性が無かったらしい。うちのPCにもUbuntu 8.04をインストールして、その上でコンパイルして動作を確認した実行ファイルをアップロードしたので、Ubuntuを使っていてYSFLIGHTが実行できなかった人は、そちらをダウンロードしていただくと、多分正常に実行できると思う。

YSFLIGHT、PCFreunde.deからEditors' Choice Awardを受賞!
YSFLIGHTが、http://www.pcfreunde.de/ (ドイツのダウンロードサイト)のEditors' Choice Awardに選ばれたとのこと。ドイツでもダウンロードランキングに入るほどダウンロードされているとはとても光栄なことだと思った。下は、トロフィー。受賞した人だけ貼ってもいいとのことだったので、早速いただいてきた。

ところで、YSFLIGHT for Linuxの最新版が、Ubuntuの最近のバージョンでSegmentation Faultが出て実行できないという報告が結構出ている。なので、うちのPCのLinuxもついにUbuntu 8.04に入れ替えた。どうも、nVidiaのドライバをインストールした後で実行できなくなるらしい。それで、まったく同じソースコードをコンパイルしなおしたら普通に実行できるようになったので、数日テストの後、差分の実行ファイルだけここにアップロードしようと思う。

大変お待たせしました。YSFLIGHT 20090611バージョン公開です！今回も、テスト版でデバッグに協力いただいた方には大変感謝しております。今後ともYSFLIGHTをよろしくお願いします。

なお、今回からユーザーインターフェースを一新して、というか、全部自分で書いて、それで日本語化もできるようにした。中身を見ればどれほど強引な方法でやってるかわかってしまうけど、多分、自分で好きなフォントパックとか、津軽弁化パックとか、作ろうと思えば可能だと思う。そういう○○化パックとか作ったら、是非どこかで公開されては良いのではないかと思う。また、これによって、WindowsのGUI機能からほとんど解放されたので、Linux版も、ほとんど同じ感じで使えるようにした。まだファイルダイアログとかで使い勝手の改善の余地はあるんだけど、前みたいに、Windows版の一部機能しか使えない状態よりはずっと良くなったと思う。

なお、Vectorのソフトウェアライブラリでは、もうすぐ、ファイルへの直接リンクができなくなるということなので、このページからはVectorのソフトウェア紹介ページへのリンクを載せておくことにした。英語版をどうしようかと困ってるんだけど。

YSFLIGHTはこの2009年5月で公開10周年を迎えた。なので、現在のテスト版が正式版になるときは、10周年記念バージョンということになる。ついでに、このページもイメージを変えてみた。昔のYSFLIGHT.COMは青空をイメージして青いバックグランドにしていたけど、いろいろ検討した結果、やっぱり白地に黒が一番見やすいようなので、白地に黒を基調にするようにした。YSFLIGHT自体そうだけど、シンプルが一番いいかもしれない。

もともとYSFLIGHTは、博士候補試験の勉強からの現実逃避で作っていたプログラムだった。僕は、それまで、大して勉強もしないのに、それなりの成績を出すタイプの学生だった。（大して勉強しないのに、というよりは、帰ってから勉強したくないので、意地でも授業中に内容を理解しようとしていた。）それが、なんとなく大学にも合格し、（全日空のパイロット自社養成課程には不合格になり）、なんとなく大学院に入った。その間、持ち前のプログラミングの腕を生かして、プログラムさえ書ければ取れるような単位を集中攻撃して割と楽に切り抜けてしまった。その後、教授に言われるがままにアメリカに留学してしまったようなもので、本気で困難に正面から取り組んで突破した経験は無かった。しかし、いざ留学してみて、相手にした博士候補試験は過去に相手にした困難とはレベルが違った。とにかく、1998年の9月から、1999年の5月まで、おそらく、自分の人生で初めて限界の力を出して勝負に挑んだと思う。1999年の5月、合格を告げられたとき、生まれて初めて、嬉し涙は実在することを知った。それまで、うれしくて涙が出るなんて本当にあるとは知らなかった。今だからこそ、あれはいい経験だったと言える。もしも、博士候補試験に不合格だったらそのまま燃え尽きていたかもしれない。その一年間、ほとんど毎日実質10時間は勉強していたけれど、勉強だけ毎日10時間やって一年間はとても神経が持たない。何か息抜きを作ろう、と、思って作り始めたのがYSFLIGHTだった。なので、YSFLIGHTは、僕の精神安定に大きく貢献していたと言える。

1999年の5月、晴れて博士候補試験に合格したので、それを機に最初のバージョンを公開したんだった。ただ、5月何日に公開したのかまでは記憶していない。中のファイルの日付を見ると、5月15日（博士候補試験が5月14日）なので、アメリカ東部時間の5月15日公開だったかもしれない。

公開した当時は、まさかこれほど多くの国から多くの人に使ってもらえるソフトに成長するとはとても想像していなかった。これまで、少なくとも31カ国から感想のメールをいただいた。なお、感想やコメントのメールには、どんなに遅くても返事を書くことにしているので、まだ返事が来て無くても気長に待ってほしい。なお、半年待っても返事が無かったら、届いていないとか、あるいはエンコーディングが変で僕が読めなかったか、迷惑メール扱いになっている可能性があるので、自分のメールの設定とか、あと、よく迷惑メールの元になっている無料メールアカウント以外からメールを再度出してみてほしい。

今は、本職のプログラミングと別の趣味プロジェクトとしてYSFLIGHTを続けているおかげで、いまだにプログラミングが楽しい。学生時代プログラミングが趣味だったのに、仕事でプログラマーになった途端にプログラミングが嫌いになった、というような話をよく聞くけれど、やっぱり本来プログラミングってのは楽しいものだと思う。

YSFLIGHTではまだまだ他にもやってみたいことはたくさんあるので、これからも開発を続けていこうと思っている。今後ともYSFLIGHTをよろしくお願いします。

ちなみに、記念すべき初バージョンもダウンロードできるようにしてみた。当時は、OpenGLを高速に描画できるディスプレイアダプタの方が少なくて、また、Direct 3Dなんていうものは存在しなかった。なので、現在"CPU Rendered"とされているバージョンしか無かった。

なお、混乱を避けるために、最新バージョンのダウンロードはこちら。

YSFLIGHT2000を利用するために必要なシステムは次の通りです。

なお、OpenGL版はよりグラフィックスカードに依存し、CPU Rendered版はCPUに依存します。なので、OpenGL版だと、多少遅いCPUでも高速なグラフィックスカードがあればかなりなパフォーマンスを出します。逆に、遅いグラフィックスカードを搭載したPCだと、速いCPUを搭載していれば、CPU Rendered版で画質は悪いですがそれなりに使うことができます。

Windows XP Service Pack 2でネット対戦を利用する場合は、こちらをご参照ください。

(*)関連サイト集ですが、それぞれのページの改造方法などについてまで僕は詳しくは見てません。というわけですので、各サイトの改造情報を利用した結果YSFLIGHTが正常に動かなくなったような場合でも、僕にメールで問い合わせるのはご遠慮ください。

なお、リンク切れになっていると思われるページを以下に移動しましたが、移転先をお知らせいただければ再度リンクさせていただきたいと思いますので、お知らせください。

また、閉鎖されたサイトの管理者の方には、大変お世話になりました。また機会があったらYSFLIGHTを使ってみてください。

なお、関連サイトに登録をご希望の方は僕までメールください。

それから、改造機のデータを個人のページで公開することはいっこうに構いませんが、僕はサポートしきれないもので、それに関する質問が僕に来ないように配慮してください。本当はデータフォーマットとかも仕様をきちんと公開すればいいのでしょうが、まず、まだいろいろ変える可能性があるところが多いのと、データフォーマットの説明を書いている時間がないので、公開できません。それに、事実上いろんなサイトで調べ尽くされているようなので、あらためて僕がデータフォーマットを公開する意味があんまり無さそうですし(^_^;)

また、スクリーンショットの個人のページでの公開などは自由にしていただいて結構です。

以前は、各サイトの簡単な紹介を書いていましたが、今回のリニューアルでリンクだけの紹介にしてみました。というわけで、ぜひそれぞれのサイトをまわってみてください。

このセクションではYSFLIGHTのスクリーンショットを掲載しています。