松江Ruby会議05に参加してきた(3)
昨日の最初に書いた「普段置かれている環境への疑問」てのは職場のことであって、Twitterとかで関わってる人たちのことではない。ここを誤解されると致命傷になりかねんので一応念のため。
さて、今回は松江Ruby会議05ちょー個人的感想の最終回で、DXRubyに関することあれこれをまとめて。
DXRubyとは
松江Ruby会議05はその後に懇親会もあって、たくさんの人と色々話してきた。そこで感じたのは、DXRubyを既に知っている人は講演で話したようなこととは少し違うことを知りたかったのかな、ということ。なので、ちょっと違った切り口で。
何度も繰り返すが、DXRubyは複雑なゲームを簡単に作れる、というタイプのライブラリではない。簡単なものを簡単に作れる。提供している機能は
・ゲームを作るのに最低限必須なもの
・表現力を拡張するもの
・こまごまとした面倒な処理をサポートするもの
という程度であって、ゲーム全体の構造の定義や制御に関することはほぼ無い。あるのはWindow.loopとSpriteだけである。
要は「表現する手段は提供するから手法は自分で考えろ」という話であって、それを考えるのがゲームプログラミングの楽しいところだ、と主張している。
ゲーム的な動きを自分の頭で考えて→作ってみて→動かして→喜ぶ、というサイクルを繰り返すのが俺の趣味であり、DXRubyはまさにこのためだけに生まれた。それに不要なものの一切をRubyレベルから隠し、または実装せず、俺にとって楽しいところを純粋に抽出したものが、DXRubyを使ったプログラミングなのである。書いて思ったけどすげー自己中だなこれｗ
ちなみに実行速度にやたらと力を入れているのは、その手の最適化もまた俺の趣味だからである。この2つの点が小さい頃から俺をプログラミングに引き付け続ける要素であり、例えばMatzが言語にのみ興味を持つような感じで、俺もその2点にのみ興味を持っている。なので、DXRubyを開発して自分で使うというのは、俺にとって理想的な趣味といえる。Matzの言う「魂の浮力」はここにある。
DXRubyに関する質問や要望について
x64サポート
いずれ世の中は64bitが主流になる。Windowsの場合、Microsoftが頑張るだろうから32bitのプログラムは長くサポートされるだろうが、Rubyの拡張ライブラリはことWindowsに限定するとバイナリ配布が多いので、32bitのみのままだと64bit用拡張ライブラリとの併用ができないという問題が発生する。ずっと先を考えると、どこかで64bit対応をする必要がある。
ところが、DirectX9は調べた限りでは64bitのバイナリが無い。すると、64bitに対応するためにはDirectX10以上を使うように書き直す必要が出てくる。
もともとやりたいことにImageとRenderTargetの融合というネタがあって、これができるのがDirectX12なのかもっと先なのかはわからないが、そのうち書き直すときが来るとは思っていた。とはいえ、世の中の流れに従っていないと取り残されることになるので、何かしらのタイミングでどうにかする必要はありそうだ。
まあ、Twitterのプロフィールにも書いてあるように「時代の最後端を追いかけるC言語プログラマ」というのが売り文句であり、世の中の初心者はいつでも最後端スレスレに存在していると思っているので、そこからはみ出さないように自然と追いかけていくことになるだろう。初心者と歩調をあわせるのは俺のスタイルである。ちなみに自分のプロフィールにこの文を掲げて17年になる。
Macサポート
やはりと言うかなんと言うか。この話題はネットでもちらほら見るし、dxruby_sdlやdxruby_rp5はその対策として生まれたものである。
現実的に、Macで動くようにするにはDirectX直叩きをやめる必要がある。手法としては(1)低レベルレイヤにマルチプラットフォームのライブラリ(SDLなど)を使うようにするか、(2)自力開発するなら低レベルAPIを切り離した形に設計して、差し替え可能にするか、そんなところだろう。OpenGLを使えば解決、というほどヌルい話ではない。
(1)の方法で、SDLを使えばWindowsでもMacでもそのまま動くかというと、たぶんそんな単純な話でもなくて、例えばStarRubyだってMacで色がおかしいとかの不具合報告がされたりしていたし、俺自身Macを持っていないので「SDLだからMacでも動きまーす」って公開するわけにもいかない。不具合報告されても直せないし動作確認もできない。個人で開発する以上、マルチプラットフォーム化には限界がある。
(2)は差し替えが可能な設計にしておくと言うだけで、動くように誰かがそのレイヤを書いてくれと言う話となる。これは恐らくほんとにそこを書くだけでバッチリとはならず、上のほうまで修正しないとダメね〜ってなることが容易に想像できるわけだが、少なくとも今のDXRubyを書き換えてMac対応するような泥沼の作業と比べて随分ラクにはなるはずだ。
よさげなのは(1)と(2)を合わせたような形で、低レベルAPIを切り離した設計にしたうえで、SDLを使うようなコードを誰かが書いてくれるという状態か。ただ、ImageとRenderTargetの融合などが実現された場合、SDL2.0でもそれは不可能なので、そういったものは作れなくなる。
俺としてはマルチプラットフォームを前提にしたせいでやりたいことが実現できないのはイヤなので、次世代DXRubyもやっぱり何も考えずにDirectXを使うようにしちゃうかもしれない。みなさん互換ライブラリ頑張ってください。
音関連
前にもTwitterでつぶやいたりしてたけども、AyameやLightNoteのバインダを作りながら思ったのは、外部のサウンドドライバを使う形ではRubyとの親和性という点で問題がある。まあ、主にGC周り。
例えばoggを再生しようとするとストリーミング再生することになって、別スレッドでデコード＆バッファへの書き込みを行うことになる。小さい効果音ならプリデコードしてバッファに突っ込む。そうした場合、どのデータをどこでキャッシュして、どのタイミングで解放するのか、Rubyのオブジェクトは何を保持するのか、別スレッドのアクセスとRubyからのアクセスをどのように協調させるのか、GCが動いたときにどうするべきなのか、などなど、考えるべき点がたくさんあり、ある程度がサウンドドライバ側で実装されていると、どうしてもRubyと拡張ライブラリと、サウンドドライバとの効率的な結合ができなくなる。もしくは実現できない機能が出てくる。
究極的にはRuby専用のサウンドドライバを設計するのが解決策になるわけだが、それをするのもまた手間と時間がかかる。そのへんは現在勉強中なのでそのうち始めるかもしれないが、誰か作ってくれたら嬉しいなーとかすごく思う。
少なくともこれだけは言える。現在の組み込みSoundクラスやDXRubyWikiに置いてあるものでは俺は満足していない。
Github
懇親会で中村さん(@nari3)と話した。
nari3「Githubにソース置かないんですか」
mirichi「Githubに置いたらなんかいいことあるんですか」
nari3「ソースが見やすくなります」
mirichi「へ？ソース見るんですか？」
nari3「見てますよ？」
mirichi「ﾌｧｯ?!」
まさかあの年単位で時間をかけてツギハギにしていった汚いコードを見ている人がいるとは。驚愕の事実である。誰も来ないからと部屋を散らかし放題にしていたところに突然お客さんが来ちゃったような気分である。とはいえSourceForgeで管理しているので言わばガラス張りの部屋を散らかしていたとも言えるわけで、それはそれでひどい。
Githubにコードを置くなら、SourceForgeのsvnと両方管理するのは面倒極まりないので、たぶんGithubメインになるだろう。ソースを管理せずリリースと公式サイトだけをSourceForgeにするというご都合主義的な選択はアリなのかと言うと、たぶんSourceForgeの理念的には問題無いと思う。
といってもすぐに引越しするかというとそうでもなくて、そのうち引越しするかも〜？程度に。リファレンスもGithubに置くかとかそういうのも考えたりしていて、それもあわせていずれ時期がくるだろう。
あと、Githubに置くなら今のように誰にもビルドできないような極悪な状態も問題で、x64サポートとともに開発環境をmingw系に移行しつつ、そこそこ簡単にビルドできるような状態を確保する必要がありそうである。
3D
これは昔からずーっと考えていることで、どのように効率的に処理するかが一番の問題点となっている。
スキンメッシュアニメーションをする場合、まず間違いなくRubyで処理することになるわけだが、そうするとそこに負荷が集中してしまうので、そのへんの対策が必須のポイントとなる。例えば今の開発版のVectorオブジェクトを配列に突っ込んで頂点バッファを生成するなどでは相当遅いことが予想できる。
俺としては最終的なターゲットをMMDのモデルの描画に置く感じでいて、最初からそれができるように作るのは大変だが、いずれ拡張していく形でそこにたどり着けるような設計にしておかなければならない。ベースとなる部分の柔軟性と速度を確保することが重要、ということだ。
これはまたチマチマ実験しつつ、ボツにしつつ、Rubyで実用的で簡単な3Dプログラミングとは何かを考えていくことになる。DXRubyの思想にあう3Dプログラミングとはどういうものか、と言ったほうがいいか。
バグとか互換性とか
Ruby合宿担当の野坂さん(@hnozaka)に聞いてみたのだが、バグを踏み抜いて大変なことになった経験は無いそうだ。また、バージョンアップで互換性が無くなって苦労したことも無いらしい。バグについてはそれなりにテスト＆実際に使ってからリリースしているが、環境によって出るものもありそうではあるのでラッキーという感じである。互換性はかなり気をつけているので基本的に過去のコードが動かないことはほぼ無いはず。はじめの頃はひどかったと思う。
それとは別に、Smalrubyのコードを見てたときにDXRubyのバグ回避的なコードとコメントを見た記憶があるので、あっちのほうではそういう点で苦労させてしまっていたかもしれない。高尾さんに同じことを聞かなかったのは俺のミスだが、とはいえイチイチ報告しろとも言えない。回避可能なバグであれば回避してもらって、コミットログなりコメントなりにちょろっと書いておいてもらって、俺が見に行くのがよいかなー。
ビルド環境
現在、Microsoft DirectX 9.0 SDK (October 2004)を使っている。恐ろしく古いSDKを使い続けているのはワケがあって、これがスタティックリンクできる最後のバージョンだからである。ダイナミックリンクするものはSDKのバージョン以上のランタイムが必要で、ランタイムが古いと変なエラーが出て質問が大量に来てしまうのでそれの対策という形。いまどきならすでにあまり問題にならないのかもしれない。どうでもいいがスタティックリンクしたほうがパフォーマンスは良くなる。
使っているコンパイラはVC2008。リンクするRubyの対象はRubyInstallerのmingw32版なので、元々はVC6.0でビルドされたRubyが無いと作れないのだが、かなり強引な方法を使うことでVC2008でビルドしている。ビルドしたいという人がいた場合にうまいこと説明できないのでどうしたものかと。
64bit版のRubyInstallerのバイナリにリンクする拡張ライブラリはどうやって作ればいいのかはまだ調べていないが、Devkitでビルドすれば動くだろうとは思う。問題はDirectXをそれで簡単にリンクできるのかというところで、mingw-w64ならDirectXも入ってるとかなんかそんな話を見た気もするが、そしたらmingw64のRubyとリンクできるのかどうかという話になって、結局よくわかっていない。いずれ試す必要があるだろう。
オープンソースソフトウェアについて
ふと思ったので書いておく。
勉強会的なものにDXRubyを使ってもらっているが、俺のほうはそれを狙って作っているわけではない。俺が作りたかったもの、自分で使いたかったものが、他と比べてフィットしたという話である。
当然、他にもっといいものが出てきたらそっちに乗り換えるだろうし、例えば俺が飽きてやめるとか、俺の好みを追求していったらフィットしなくなったとか、もっと予算がついて勉強会用にライブラリを開発することになるとか、そういったこともありえる。
つまりは、俺がやっていることと、島根・松江がやっていることが、今の時点で偶然クロスしたということであって、その「ゆるさ」や「一期一会感」こそがOSSのあるべき形なのかもしれない。もちろん、どっちかがどっちかに影響を受けて方針が変更されることもあるだろうし、フォークされることもあるだろう。その辺まで含めてOSSとはそういうものだ、と思う。
