ガンハウンドUnrealEngine4研究所UnrealEngine4の研究/開発をしてます。ガルルソフトウェア研究所です。ガンハウンド2016年06月07日13:15カテゴリガンハウンドMac版ガンハウンドおおお、動いた。苦労したが動いたぞー!ファイル名の大文字、小文字が異なるところや、ファイルパスの区切り「/」「¥」「\」の違いなんかをうまく吸収するのに手間取ったけど綺麗に動いてる。同じCocos上で動いているのにもかかわらず、えらく動作速度が異なる。2200MHzで40FPS不思議だなぁ、Windows版のCocosが最適化されてなさすぎるのだろうか。(Sint32)&Data;みたいなやや強引な渡し方でアドレスを渡しているところで辻褄が合わなくなってる。アドレスが64bitなので引数の32bit幅ではキャストできない。なんとなく覚えてるけど、1つの関数でなんでも受け取れる仕組みにしたところがこういうところで問題を起こす。昔からこういう書き方はよくない、って言われてたところだな。ARGB(0xff,0xff,0xff,0xff);こんな感じのマクロで値を生成する場合、渡されてくる値がそもそも64bit長のものである可能性があるので、それを32bit長の変数に入れられなくなってる。0;まず、上記の場合はKeyCodeをTest配列の添字にすることができなかった。enumにすることで、添字化することができた。Cocos23::KeyCode::Key_Right;}これはWindowsではうまく行った。Macでコンパイルするとうまくいかなかった。そもそも、enumに自動でキャストしてくれないのである。(Sint32)Cocos23::KeyCode::Key_Right;}だから、こんな感じで明示的にキャストしてやる必要があった。)2016年06月06日22:33カテゴリガンハウンドそして画面がステージ1が動いたおおお、Cocos2dxでデバッグ版が動いた・・・・・!し、しかし遅いなああ。移植度はさすがに自分で作ったライブラリだけあって、つじつまあわせは完璧。するほどにガンハウンドであるが、Cocosの特性を無視した移植になっただけあってむちゃくちゃ遅い。この後、デバッグ用の描画とかを外して少し処理速度を稼いで20FPSくらいにはなったが、それでもPSPの30FPSに及ばない。PCでcore-i7の3500MHzとPSPの266MHzで30FPSっていうかなりのパワー差があるにもかかわらず。次は念願のMac版ガンハウンドの生成にチャレンジしてみようと思う。スマホ版はどうなるかな。メモリに乗り切るか心配ではあるが、最近のスマホはVita以上の性能があるので普通に動くかもしれない。できるところまでやってみよう。ライブラリがまとまり次第、ガンハウンドのソースと私製ライブラリ、Cocos用のラッパーをオープンしてみようと思う。ガンハウンド素材を作ったガンハウンドみたいな横スクロールアクションを作るパワーが再び貯まるまで、誰かの創作に期待したい。)2016年06月06日12:35カテゴリガンハウンドタイトルが出た!タイトルが出た!Cocosをスプライトリクエスト方式で描画するラッパーがうまく動作した感じ!画面サイズはPSPサイズの480x272をCocosの640x480に合わせてるのではみ出しちゃってるが、さてさて、この先どうなるのか?こっから先に動かないーーーーーー!あ、スマホ対応ばっかり意識してたので、ライブラリのキーボードとかコントローラーの入力の部分を作ってなかった。)2016年06月06日12:27カテゴリガンハウンドCocos2DxでガンハウンドもともとWin32環境で動いていたガンハウンドをCocos2Dxで動かしてみよう。買ったMacでゲームをつくれる環境がほしいもんね。PSPで動かしていた実績もあるので機種依存しないコードでできている自信はあるんだけど、DirectX用につくったゲームエンジン部分をCocosエンジンに載せ替える必要があるのが結構大掛かりではある。ゲームエンジンと言っても、最終的にはOpenGLに集約されるので、入り口と出口の部分は割りと問題なさそうではあるが、そこに至るまでのポリゴンの形成とか、入力や出力の集約の仕方がCocosとはまったく考え方が違うので苦労しそう。おおざっぱにわけてしまうとスプライトの表示方法には2通りあって、1つのスプライトと1つのテクスチャを1対1で使う方法と、1つのテクスチャから複数のスプライトを生成する方法の2通りある。前者はキャラクタの絵を書いたテクスチャを読み込んでインスタンス化し、それをコントロールする。UnityとかCocosは基本的にこの方法であって、便宜上名前をつけると「スプライト・インスタンス方式」とでも言っておこう。プログラムで描くとイメージはこんな感じ。スプライトの大きさ=テクスチャの大きさになる。Sprite("texture.png")->Draw();で、僕の得意とする方法は、テクスチャは個別に読み込んで、スプライト側が参照するテクスチャを決めて表示する。イメージで言うとこんな感じ。)->Draw():Draw()となっているが、実際には「こんなスプライト表示をしたい」というリクエストを送るだけで、リクエストを貯めこんだあと、描画のフェーズでまとめてOpenGLなりDirectXの求めるポリゴン形状に丸めて描画する。これを便宜上「スプライト・リクエスト方式(※)」と言っちゃう。スプライト・インスタンス方式の場合は、画面に出てくるキャラクタがしっかりと決まっていてあまり不定な要素がない場合にとても便利。アングリーバードみたいにキャラと敵の数がステージごとに決まっていて最初に生成してしまった後は、それを操作しまくってゲームに仕立てあげる。スプライト・リクエスト方式は、無数の敵キャラが時間に応じてどんどん出てくるようなシューティングの場合、あとから中ボスを足そう、敵キャラを間引こうっていう不定なキャラとか、仕様がかっちりしていない場合に柔軟に対応できる。※Cocosも最終的にはノードに割り付けられたスプライトを順番に描いていくので、その場で描いているわけではない。