2009/05/27(水)StaticResourceLoader.cs
GSDK on C# で。
これで
namespace Tsukikage.GameSDK.Base { public interface IDXResourceLoader<ResourceType> { ResourceType LoadResource(ResourceType target); } }
こうして
namespace Tsukikage.GameSDK.Direct3D { public class D3DDevice : DXResource, IDXResourceLoader<D3DTexture>, IDXResourceLoader<D3DFont> { public D3DTexture LoadResource(D3DTexture target) { LoadTexture(target); return target; } } }
こうやって
using Ref = System.Reflection; namespace Tsukikage.GameSDK.Base { /// <summary> /// staticリソース読み込み支援クラス /// </summary> public class StaticResourceLoader { static Dictionary<Type, StaticResourceLoader> loaders = new Dictionary<Type, StaticResourceLoader>(); public static void Load<TypeToLoad>(Type target, IDXResourceLoader<TypeToLoad> loader) { lock (loaders) { if (loaders.ContainsKey(target) ) return; loaders[target] = new StaticResourceLoader(); foreach (Ref.FieldInfo fi in target.GetFields(Ref.BindingFlags.Public | Ref.BindingFlags.Static)) { if (fi.FieldType == typeof(TypeToLoad) && fi.GetValue(null) != null) loader.LoadResource((TypeToLoad)fi.GetValue(null)); } } } } }
で、こう。
namespace WindowsGame1.Scenes { public class Textures { public static D3DTexture Circle = new D3DTexture("circle.png"); } class Scene1 : Scene { public override void Initialize() { StaticResourceLoader.Load<D3DTexture>(typeof(Textures), GSDK.D3D); } } }
……。
まず口から出てくるのは「キメェ」の一言かもしれない。
ただ、大富豪的プログラミング時代においては、中規模程度のゲームまではこういうリソースの持ち方もありかなぁと思わないでもない。
(自分も含めて)ゲーム作り初心者が多いうちのサークルでは、この前もテクスチャリソースがリークして大変なことになってたけど。
ここを読んでくださっているみなさんはどう思われますか、なんつて。
ここを見てる人はきっとリソース管理なんて朝飯前で、こんなことしないのかもしれない……。
あー、ゲーム作りてぇなぁ……。
2009/05/07(木)ブロック崩し
そういえば5月に入ってから日記を書いていないじゃないか。
ブロック崩しを作っている。
作っているといっても、まだ、1文字もコードは書いてないので
作ろうかなぁと考えていると言った方が正しいか。
簡単だと思っていたけど1つわからないことがでてきてしまった。
ボールが長方形であるブロックにぶつかったときに、
X軸速度成分を反転するのか、Y軸速度成分を反転するのか。
これを判定するスマートなアルゴリズムとはなんだろか。
ブロックの縦横の辺の長さの比とatanを使う?
ボールの半径分太らせた長方形を用意して、ボ線分と円の交差ール中心が今どの矩形内に収まっているかを判定する?
ブロックの4辺に対して、線分と円の交差判定を適用する?
いずれの方法でもやればできそうなのだけど、なにぶん面倒くさがりなもので。
それに、ボールは離散時間上を動くわけでブロックや壁にめり込む。
単に衝突を矩形判定してると、2つのブロックに同時にぶつかりうる。
よくよく考えないと2回反射して貫通弾になってしまうだろう。
現フレームで移動するはずのブロックの軌道を線分で表して、
衝突面での反射をシミュレーションするとか。
ブロックを円にするという誰もが思いつきそうなアイディアを採用すると、
当たり判定は円判定になって、反射方向はベクトルを射影して計算するーとか。
でも、よりうまく反射させるには、同じように軌道を線分化、
ボール半径分太らせたブロック円との交差判定、
めり込むはずだった分の距離を、その交点で反射、か……。
とまぁ、改めていろいろ考えてみると、
アクションゲーム作りを学ぶにはブロック崩しはなかなかいい題材なのかも。
そのうちプロジェクト自体放り出しそうだなぁω