Spriteの衝突判定では、まず全オブジェクトのAABBボリュームを計算して保存し、それを判定する。AABBの算出はそれなりに負荷がかかるから、これを保存するのは効率的に必要な処理だ。Spriteは複数の衝突判定範囲を持つことができるから、SpriteのAABBを算出…

DXRuby1.4で導入されたSpriteクラスはほぼデータ保持用という作りになっている。かろうじて描画機能があるが、結局のところ通常の描画機能と比べて描画用のパラメータを引数で渡すか、オブジェクトが保持している値を使うかの違いでしかない。この部分に関し…

Win32でフォントを扱う場合、APIのCreateFontIndirectにフォント情報構造体を渡してフォントハンドルを受け取り、それをつかってGDIで描画する。このフォント情報構造体というのが微妙にあいまいで、指定のフォントが無い場合に最も近いフォントをOSが選択し…

DXRubyでわりと最近追加したメソッドがRenderTarget/Imageのdraw_font_exだ。これはImage#draw_fontのようにGetGlyphOutlineWで受け取ったビットマップ情報を使って、影や縁取りを行う機能が追加されている。Imageのほうは地味だが厄介な編集処理が入ってい…

フォントと文字描画の扱いで問題になるのはエンコードとレンダリング処理である。Ruby1.8用の場合はエンコードは決め打ち、1.9ならRubyの機能で変換すればいい感じにはなる。残る問題はレンダリングだ。 WindowsのAPIとかDirectXのD3DXFontとかを使うと文字…

CPUとGPUは半導体なので、すごい勢いで技術が進歩している。主に製造プロセスの進歩と、それに伴い増えたトランジスタをどう使うかという部分での性能強化だ。ただし、CPUに対してGPUのほうが性能の伸びがずいぶん大きい。この違いは載せている回路の使い方…

DXRubyの描画予約順ソートはマージソートを採用している。初期の頃はシンプルなバブルソートだったのだが、さすがにアレなのでマージソートに変更したのだ。なぜマージソートを選択したのかというと、描画優先順が同一だった場合、メソッドを発行した順に描…

RenderTargetがCPUから編集できないタイプのデータであることは何度か書いたのだが、その原因のあたりの話を少々。 DirectX9時代のGPUはCPUとのアドレス共有機能が無くて(いまでも無いけど)、ビデオメモリにしかアクセスができない。GPUからテクスチャを書き…

DXRubyはいろいろな機能を詰め込んではあるが、基本は描画まわりである。音に関しては別のライブラリを使うという選択肢があるし、入力はWin32APIを使ってどーにかすればなんとかなるんじゃないの、と言ったところで、でもDirectXによる描画だけはどうにもな…

DXRubyは1.2からRenderTargetを導入したおかげで、内部的にはWindowモジュールが一つのRenderTargetオブジェクトを持つようにして、そいつをスクリーンバッファに関連付けて使うように変更した。こうすることでWindowモジュールのdraw系メソッドは内部Render…

RubyのGCはマーク&スウィープで、Ruby1.8時代からするとずいぶん改善されていてはいるが、それでもやっぱりGCが動くとプログラムは停止するし、逆にGCが動くまではオブジェクトは回収されない。 DXRubyを使うほうとしては初期のころはGCでずいぶん苦労したも…

最近のGPUはビデオメモリが数GBとかになっていて、普通にテクスチャを置く程度ならいくらでも置けるようになってきている。とはいえ安いものでは少ないのもあるし、APUとかチップセット内蔵とかになるとメインメモリ共有になってたりもするし、ビデオメモリ…

何かしらアウトプットしていかねば、ということで、連載記事「DXRubyの創り方」である。まあ、連載といっても順番に読めば理解が進むというわけでもなく、ターゲットを絞っているわけでもなく、思いついたときに思いついたことを書くからどうせ毎回レベルは…