うへー、またやらかしたよ。土曜日に朝4時までバグを追っかけてたら当然の様に風邪引いた。
日曜はやけに眠いなーと寝てたから悪化はしてないようだが。
それはともかくMacBook。土曜日に銀座まで行ってきたけど、メモリ増やすのはできるけどUSキーボードは在庫が無いから入荷次第改めて交換にきてもらうことになるって。入荷予定は未定とのこと。
日本語キーボードでもって帰るのも良かったけど、べつに急ぎで欲しいわけでもなかったんでオンラインで注文して届くのを待つことにした。月末から11月頭くらいが予定になってるけどさていつくるかな。
数日前に同じような構成で注文した友人は同じような予定だったにもかかわらずもう発送になったらしい。意外に早いかも。
しかしAppleStoreめっちゃ混んでたな。新MacBookなんていつも人が群がってて近づけないほど。その割には買ってる人は多くなさげだったけどな。
iPod nanoのドック買おうかと思ったけど混んでたので止めた。
これがうまくいかずに朝4時までがんばったんだが。
結論からいくとSDLが悪いわけでもなく、というか何が悪いのかよくわからないが普通にDLLの読み込み順序をなんとかしたらなんとかなった。
まず最初は、exerbでかためたexeと同じ場所にMesaのopengl32.dllを置いてみた。普通はこれでいいはずなんだが何故かシステムのopengl32.dllが使われてしまった。
OpenGL Extension Viewerとかに同じ方法を試してみたらうまくいったんだけど…。
exerbは普通のDLLも埋め込めるのでやってみたらうまくいった。
ように見えたが、opengl32.dllはGDI経由？でも呼ばれるんでおかしなことになってしまった。ちょっと無理しすぎか。
最終的にはmanifestファイルを書いて無理矢理同じディレクトリのopengl32.dllを読ませるようにしたらなんとかなった。
普通dllを読み込むのは読み込み元の実行ファイルがあるディレクトリ、システムディレクトリ、カレントディレクトリみたいな順番らしいんだけど、なんでexeと同じディレクトリのopengl32.dllを読んでくれないんだ。
で、いま思い付いたんだけど。
っていろいろ書こうと思ったけど、ちょっぴりセキュリティ的によろしくない動作の解説になりそうなのでやめた。あとでExerbのMLにでも報告すればいいのかな？
分かるけどいまとなってはあんまりよろしくない動作してるな。どう回避したものか分からんけど。
で、これならちゃんと動くだろうと思ってsoをかためないようにしたけどopengl32.dllの置き換えは失敗。あれー？
あらら、ソース確認したらこの方法でもexeと同じディレクトリにdll置いての置き換えはできないわ。exerbの場合はmanifestで置き換えるしかないってわけね。
しかし覚悟はしてたがMesaのGDIドライバでは重すぎる。話にならん程では無く、いちおう重いけど動く程度だから今回はよしとしたけど、今後もOpenGLで2D物つくっても安心っていう程では無いなぁ。
今回ビルドしたのはVC++2008EEで普通にMesaのソリューション開いて速くなりそうに最適化オプションいじっただけなんで、アセンブリコードなんかは使われてない。
dllexport相当の物がアセンブラで指定できればMinGWでアセンブリ使用版もビルドできそうなんだけどなぁ。defファイルを作る方法もあるけどちょっとめんどいから保留。
3D物がビデオカード依存するのはしかたないけど、2Dはなるべく広い環境で動いてほしいな。
SDLをちゃんと調べてRikoの2Dでやってることぐらいができそうなら、サブセットをSDLベースで作ってみるかな。それともStarRuby使えるようになった方が早いかな。
まあRikoの2Dでできることなんて特別なことは全然ないから、ブレンドモード辺りが実現できそうならなんでもいいんだけど。