THE PSP攻略+α ~SONYへの挑戦状~

PSP関連ブログ?いいえ、ただのゆとりブログです

スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
[ --/--/-- --:-- ] スポンサー広告 | トラックバック(-) | コメント(-)

PSPで「ケロちゃん風雨に負けず」っぽい弾幕 

前回までの弾幕テストは、あくまで演算速度と描画速度のテストであって、実際に存在する弾幕ではなかったので、風神録のEXボスの弾幕を実装してみた。
龍神録プログラミングの館にあったものを参考にしたけど、この弾幕人気なの?

忙しい…でもプログラム組んじゃう!ケロンッケロンッ
バイナリは公開してねえぞ!

STGなんてHSPを始めた時に入門サイトにあったのを作ったぐらいで、三角関数使ったりする本格的なものなんて作ったこと無いです。
そもそもC言語でゲームすら作ったことないよ^^;
というわけで、東方風STGとして定評のある四聖龍神録を作成したDixq氏によるSTG作成講座の「龍神録プログラミングの館」を参考にさせていただきました。
高速化のためにラジアンを使わないように改良したのが悪かったのか、PSPサイズへの縮小の仕方が悪かったのか、なんか大きい青い弾の量が少なくなったような…
色々チューニングしたら今度は多くなったw
あと、実を言うと風神録は放置していてExtraやってない^^;
とりあえずExtra出すために誘導腋巫女でノーマルプレイして2回目でクリアできた。地霊殿は2日かかったというのに…
適当にExtraやってたら蛙みたいな形の弾配置する弾幕で死にまくり。
くぐれねーぞ!と思いながら攻略サイトみたらくぐるのであってたらしい。
何度かやって安定してたので、ようやく風雨に負けずを拝めたわけだが、米粒の動きが龍神録の奴と違うっぽいね。
本家だと落下の早い奴と遅い奴が混じっていて避けにくい。
まあ、この辺も含めて、演算を早くするために自分で作り直すべきなんだろうなぁ。

今回の動作環境
■本体
 ・PSP-1000 CFW4.01M33-2
■グラフィック
 ・テクスチャー、画面モードともに32bit
 ・弾画像はVRAMに配置、それ以外はswizzleしてRAMに配置
 ・フレーム、背景、ボス、ボス周りの魔法陣、スペル時のカエルを表示
 ・自機はノーマルショットを2本、ホーミングを4個同時に発射
 ・自機低速時に喰らい判定の目安とサークルを表示
■サウンド
 ・BGMはMP3をハードウェアデコード
 ・効果音はWAV(無圧縮PCM)を再生
 ・それぞれ、メモリに格納
■システム
 ・自機の喰らい判定あり、ボスへの体当たり判定は無し
 ・自機ショットとボスの当たり判定あり
 ・ホーミング弾は毎回ボスとの角度を計算
 ・基本は222MHz駆動。クロック数を変えるときはコメントを挿入してます。
■撮影環境
 ・録画用にUSBカメラを購入しますた^^
  VGAサイズで30fpsの撮影が可能なんだが、わけあり品の格安の奴だったので画質はお察しください。

前回と比べて、自機ショットとか追加されてるので、より本家に近づいたと思います。
魔法陣を回転させながら拡大&縮小させたり、スペル時のカエルも拡大&縮小させてます。
青い弾はちゃんとアニメーションをさせていて、すべての弾は進行方向に角度を変えてます。

PSPで組む際に何が面倒だったかというと、画像の加工でしたね。
α値を保ったまま一個一個切り取って縮小してまた繋げる。そしてPSP用のフォーマットに変換…
弾がまとまってる画像を一気に縮小すればいいんだけど縮小率が56.25%なのでズレとか面倒なんだよなぁ…
PSPでの高速化には画像の配置も重要だし。
テクスチャーの幅は2の累乗にする必要があるし、BMPはボトムアップなうえにARGBな配置なので色の入れ替えがめんどくさい…
今後のことも考えて、PSP側のプログラムにBMPの読み込み関数を作ったという話。
PNGの読み込みに対応すれば楽なんだろうが、日本語のリファレンスがないとわかりません^^
ここはゆとり専用だから英語が読めても読んではいけません。(謎)
前回のTLG検証時はメモリ上のPNGを展開するソースを検索して貼り付けただけという手抜き仕様。
PNGとJPEGを自前関数で読み書きさせる方法が激しくめんどくさい。正直TLGのソースを移植する方が簡単だったw
あと、wikiにある画像展開ツールでPNG化したわけだが、16bit画像の32bit化がちょっとおかしい。
風神録あたりから32bit画像が増えてきているが、一部の弾は16bitで格納されている。
ツールでPNG化する際に32bitに変換してるのだが、単純に8bitずらしてるだけなので、色がズレてしまっている。
0xFFFF→0xF0F0F0F0という感じ。
16bitでの0xFは32bitだと0xFFにならないといけないので、色の誤差が生じてくる。
そのうえ、α値も誤差が出てるので2重に色がずれてくる。
#F0F0F0を透過率0xF0で#000000に合成する場合の色は
0xF0 = 240
240 * 240 / 255 ≒ 225.88
226 = 0xE2 (ここでは四捨五入したが、おそらく内部では241*241/256で演算してる?確認したら0xE2になっていた。)
本来なら#FFFFFFになるはずが#E2E2E2になってしまう。
どれだけ違う色なのかの比較はこちら。
#FFFFFFと#E2E2E2の比較
人間の目で見てもわかるぐらい違う色になっている。
今回の大きい青い弾が16bitで色が暗くなっていたので気づいた。
というわけで、16bit画像の修正も必要なわけで…
ソースが付いてるので自分で画像コンバータを作ったほうが良いのかもしれない。
画像の配置が元ファイルに格納されていて、各画像をIDで管理した方が楽なので、それ用に定義ファイルを吐き出したりすれば便利かもしれない。
多分本家もそれで対応してるのだろう。プログラムを書き換える手間が無いし。

前まではαブレンディングだけで済んだが、今回は加算合成とやらが必要になった。
というか、そこそこ加算合成が使われてるのでこれは実装しないと。
GUの使い方マジわかんね…
スレかどこかでGUはDirectXやってれば使い方がわかるっぽいことを書いていたが、DirectXなんてHSPでラッパーモジュールしか使ったことないです^^;
C言語初心者なめんなよゴルァ!
というわけでDirectXのブレンディングを説明してるサイトを検索しまくって多分実装できた。

そして今回も出現した、機能を追加したら他のところの負荷が増える謎仕様。
やっぱりCPUキャッシュが原因なのかなとか思ったけど、こんなに負荷が増えるもんなのか?
まだまだ無駄な部分が多いので、そこらへんを削っていけば少しは改善するかもしれない。
あと、今回調べて知ったのだが、2>>1と2/2は別ものらしい。
3*4みたいに2の累乗を掛ける場合は3<<2と同等なので(意味がわからない人はビットシフトを調べてね)コンパイル時の最適化で置き換えてくれるらしい。(基本的に乗算よりビットシフトの方が処理が早い)
逆に右にシフトすると1/2、1/4となるのでそこも置き換えてくれるのかと思っていたが、どうやら符号付の場合は意味が変わってくるらしい。
整数の除算は切捨てである。正数だと切り捨てられて値が小さくなるが、負数の場合は切り捨てると値が大きくなる。
-1.2という値を切り捨てると-1となり-1 > -1.2ということになる。
ビットシフトの場合は、どうやらそうなるとは限らないらしい。ここらへんは実際に負数を右へシフトすればわかると思います。
unsignedにコンパイルしてみたら最適化時に>>1とかになってました。なぜか負荷が上がったので符号付に戻したけど^^;

完成した後も動画の撮影が非常に面倒だった。
USBカメラのキャプチャーが出来るソフトをあまり知らないので、ふぬああを使ったが音ずれしまくり…
ほとんどのコーデックが上手いこと使えないのでhuffyuvを使うことに。
色々検索してなんとか音ずれを直す方法もわかって動画編集が終わったのが昨日の午前5時…
プログラムを組むのに時間がかかるのは構わんが、それを動画にするために時間がかかるとなんだか損した気分になりますw

ここまで読んだ方も、長文が面倒で飛んできた方も居ますが、そろそろ動画を貼り付けときますね。
640x480で上げて、高画質モードにしても480x360になるのでフレームレートとか弾数の文字が潰れて見にくいのは仕様。
高画質モードにすればなんとか見えますw
333MHzに上げたら負けかなと思ってる。
222MHzで動作し、そして…



上の動画だと糞画質だが、実際はこんな感じです。
ケロちゃん風雨に負けずっぽい弾幕1
背景、魔法陣、カエルが描画され、その上にケロちゃんの足が見えてますw

ケロちゃん風雨に負けずっぽい弾幕2
ショットを撃ったりしても、CPUにはまだ余裕があります。

ケロちゃん風雨に負けずっぽい弾幕3
ノーマルショットは前方に、ホーミング弾はボスの方へ。

ケロちゃん風雨に負けずっぽい弾幕4
大雨でも、まだCPUに余裕があります。

111MHzで動作させるために色々書き換えました。
C++よりCの方が早いと昔聞いたことがあったので、Cに書き直してみてもぜんぜん変わらなかったり、inline使ったら逆に遅くなったり…
角度が360を超えた場合の補整にn%360を使っていたのをwhile(360<=n)n-=360にしたりすると微妙に負荷が下がりました。
あとはこれの積み重ねでなんとか111MHzを達成!
まだまだ無駄を省いたり、あらゆる高速化方法を試して111MHzで大雨降らせても60fps保てたら良いなぁ…
俺の知識だとこの程度だけど、C言語を使いこなしてる人なら大分高速化できるでしょう。
あと、トリプルバッファ的なことも試してみるか。別の目的で使うので多分速度落ちるだろうけど…

バイナリは配布しません。というかバイナリ配布しても画像の加工ができないと動かせないw
画像コンバータでも作るかなぁ…
俺的にはバイナリを配布すれば他の移植しようとしてる人の燃料になりそうな気がするんだが。

なんかこの記事もあらゆる組織に監視されてる気がするので、東方関係はしばらく置いとくかなぁ。
なんという自意識過剰な被害妄想…


今回は土日丸ごと使って時間使いすぎたから今月は変なことして記事書くのは厳しいかもね。
今使ってるノートPCの分解方法が分かったので掃除するかもしれん。
その後、彼の行方を知る者は誰も居なかった…

明日は朝早いのにいつまで起きてるんだ、早く寝ろ俺。
[ 2009/06/22 02:56 ] 未分類 | TB(1) | CM(28)
No.686
毎度ながらお疲れ様ですー

東方は友人に熱狂的ファンがいるぐらいで自分は大して知らなかったり(汗
ただPSPでこういう感じのゲームがあると楽しいかもしれませんねw

正直プログラムの話の部分の大半は理解できないのですが…
本当にプログラミング勉強しないとやばいような気がするこの頃・・・
と言ってみるもののなにから手をつけていいのか分からないのが現状です(マテ

自分もPC掃除しなきゃなぁ
埃が怖いぐらいにたまって(ry

自分も同じく朝早いのにこんな時間ww
少し文章がおかしくなってるかもしれませんがご了承をw
[ 2009/06/22(月) 03:19 ] [ 編集 ]
No.687
はっきり言おう。
このアメニハマケマス
[ 2009/06/24(水) 20:06 ] [ 編集 ]
No.690
>>tales fanさん
東方はBGMが良いですからねぇ。
自分が作った曲を聴いてもらいたいからSTGを作ったとかなんとか。
自分はキャラに関してはあまりよく知らないので、ニコ動で量産されたキャラ厨にはウンザリ気味だったり…
今回やってわかったことは、携帯ゲーム機で弾幕STGは死ねる。
PCでやるときにフルスクリーンにしないと駄目って人が多いですからね…
ガチ避け以外は見て避けるのではなくて、こうすれば理論的に当たらないって感じなのでパターン化の練習には使えそうです。

プログラミングの話は随時調べて覚えたことを適当に書いてるだけですから、まだ自分もわからないことがいっぱいあります^^;
>なにから手をつけていいのか分からないのが現状です(マテ
自分も最初はそんな感じでずっとC言語をHello Worldレベルで放置してきましたが、HSPを弄ったり、他人のソースを見てるうちに基本的なことは出来るようになりました。
たまに初心者向けサイトで構文とか調べ直したりしてますw
自分はウィンドウを表示するレベルまで行ってませんので、まだまだ勉強が必要です。

ノートPCの分解掃除はハイリスクハイリターンです…
デスクトップ型は簡単に開けられるのになぁ。

自分も夜中に何か書くと話が飛躍したり、日本語がおかしくなったりしますw


>>pさん
>あなたが神か?
いいえ、ケフィアです。
か、勝ったケロ(某テニスの王子)
[ 2009/06/25(木) 06:06 ] [ 編集 ]
No.867
あれだけの事をしてまだCPUに余裕があるなんて凄いですね・・・
もしかしたら本当に移植できるかもしれない・・・
自分はプログラムには疎くて何もできませんが頑張ってください
[ 2009/09/04(金) 17:55 ] [ 編集 ]
No.868
失礼ですが東方移植計画さんのサイトでバイナリを公開したと言う情報があったのですが、upろだにはありませんでした、今は公開されてないのでしょうか?9月にもなって質問ですがすいません・・・
[ 2009/09/04(金) 18:18 ] [ 編集 ]
No.869
>>応援者さん
PSPのスペックはハンディ型ゲーム機の中では高い方だと思うので、これぐらいなら余裕だったりします。
CPUやGPUの性能は良いのにメモリの読み書きが遅くて足を引っ張ってますが…
333MHzにクロックアップすれば余裕なのは分かりきってることなので、PSPの標準である222MHzでLunaレベルの量を処理落ちなく処理するのが理想だったりします。
あと、多くの弾を処理落ち無く表示させるプログラムが組めても、まだ準備が終わってスタートラインに立ったのと同じ状況です。
本家の弾幕をどう移植するかがメインで一番面倒な作業ですね。
プログラムに関しても、サンプルソースやゲーム開発系のサイトを参考にしながら組んでるので、大したことはしてません。

>東方移植計画さんのサイトでバイナリを公開したと言う情報があったのですが
一体どこからそんなデマが…
基本的にバイナリは公開所に置いてブログに告知するか、テストレベルのものを他所様のロダに上げてブログに告知するか、ローカルな物を駐在スレに上げるかぐらいです。
今回のバイナリは記事や動画のコメントに書いてある通り、夏休み限定なのでもうロダから消えてます。
色々とあって新しい奴を作って上げるのは、当分先になりそうなのでご了承ください。
[ 2009/09/04(金) 21:25 ] [ 編集 ]
No.870
このコメントは管理人のみ閲覧できます
[ 2009/09/08(火) 16:35 ] [ 編集 ]
No.871
このコメントは管理人のみ閲覧できます
[ 2009/09/10(木) 00:26 ] [ 編集 ]
No.872
>>871
開発環境を書いてもらわないとよくわからないです。
libpngで読み込んでいるのか、DXLPなどのライブラリ経由で読み込んでいるのか。
画像はwindows上で閲覧してちゃんと透過されているか、パレット画像なのか。
元画像に付いてるαチャンネルをそのまま使えば問題は無いと思いますが。
自分はpngじゃなくてbmpとか生データをそのまま使ってるので詳しく分かりません。
libpngを使ってるなら、なんか色々オプションがあって色々弄れたと思います。
展開後のデータを数値レベルで確認して問題が無いようなら、PSP側の描画でα値を無視してる可能性があります。
sceGuEnable(GU_BLEND);
sceGuBlendFunc(GU_ADD, GU_SRC_ALPHA, GU_ONE_MINUS_SRC_ALPHA, 0, 0);
とかをGUの初期化時に指定すれば透過するかもしれません。
sceGuTexFuncの第2引数も関係あるのかな?
とりあえずそれっぽいGU_TCC_RGBAを設定してます。
ぶっちゃけDirectXの解説サイトとか見て色々やったので、よくわかりません^^;
AlphaだとかBlendだとか色々あるみたいですが、DirectXに似てるらしいので、そっち方面で調べると分かるかもしれません。
DXLPなら透過オプションの指定に関しての質問がちらほらあるようです。
[ 2009/09/10(木) 01:11 ] [ 編集 ]
No.892
このコメントは管理人のみ閲覧できます
[ 2009/09/16(水) 23:52 ] [ 編集 ]
No.893
下の話はlibpngを使って画像を展開し、自分でGUを使って描画したときの話なので、DXLPを使った時には関係がありません。
当方ではDXLPを使ったことが無いですが、本家のDXライブラリと同じように動作するように作られてるはずなので、描画命令のTransFlagをTRUEにするだけで透過されるはずです。
もしDXライブラリでも正常に透過されないなら元のファイルに問題があるということになります。
[ 2009/09/17(木) 01:20 ] [ 編集 ]
No.894
DxLibなら透過できたんですけどね。
PSP上だと透過できないorz...
普通にTRUEにはしていますがDXLPを作ってる人が、PNGの透過はTRUEじゃなくてアルファ透過じゃなきゃいけないとか言うようなことを言っていました。
>>DXLPなら透過オプションの指定に関しての質問がちらほらあるようです。
よかったらその質問のあるサイトを教えてくださるとうれしいかもです。
[ 2009/09/18(金) 00:45 ] [ 編集 ]
No.895
ヘッダファイルには特に何も書いてないのでわかりませんね…
DxLibと互換性のある作りになっていますし(画像のロード部分は本家のソースを改変して使ってるとか)、透過画像を使ってるのは見たことがあるので原因はわかりません。
使用してるのは32bitのPNGですか?
パレットや色を指定した透過だと上手くいかない可能性もあります。

透過に関する質問はDXLP公式の掲示板でいくつかあります。
掲示板にも、本家にあわせてるのでNOBLENDでもα値が考慮されてると書いてあるようですが…
[ 2009/09/18(金) 02:51 ] [ 編集 ]
No.902
行動範囲外、ボードの部分もTRUEにした結果透過できたというおちでございます。いままで回答していただいてありがとうございますです。これからもお互いがんばっていきましょうね
[ 2009/09/25(金) 21:49 ] [ 編集 ]
No.903
行動範囲外、ボードの部分もTRUEにした結果透過できたというおちでございます。いままで回答していただいてありがとうございますです。これからもお互いがんばっていきましょうね
[ 2009/09/25(金) 21:50 ] [ 編集 ]
No.904
なるほど
大事な事だったんだな
[ 2009/09/26(土) 12:48 ] [ 編集 ]
No.905
大事なことなので2日開けて書き込みますた

>>ちぇんさん
一応解決したみたいなのでよかったです。
最近はモチベが異常に低いのでやるとしてもいつになるのやら…
[ 2009/09/27(日) 21:36 ] [ 編集 ]
No.914
私も東方移植化計画さんの情報からホイホイ・・・

バイナリを1時間くらい探しましたが、もう消えちゃってるわけですね・・・orz

クレクレ厨ですみません^^;

まわりがずいぶんうるさいみたいですが、C言語見習いのワタシは応援してます(・∀・)

[ 2009/10/18(日) 21:00 ] [ 編集 ]
No.915
テスト段階というのもありますが、他所からぞろぞろと流れてくるのも困るので、期間限定にしました。
本当はひっそりやりたかったのですが、なぜか公開する前にスレに晒されてたので^^;

C言語やPSP向けのプログラミングにもそこそこ慣れてきたので、まともなものを作ってみたいのですが、モチベーションが低いのとリアルが忙しいのが相まって作業ができない状態です。
あと、本家のをそのまま移植するだけじゃ何か芸が無い気がしてきた。

うちのブログはなぜかROMばかりなので、コメントがあるとうれしいですね。
忙しくて書くのが溜まってる分の記事を消化したあとに、まったりと手を付けたいと思います。
[ 2009/10/18(日) 22:18 ] [ 編集 ]
No.958
このコメントは管理人のみ閲覧できます
[ 2009/12/14(月) 00:15 ] [ 編集 ]
No.959
>>> ・弾画像はVRAMに配置  とこのサイトにありますがVRAMに配置する方法がよく分かりません。

PSPのVRAMは2MBあります。
画面のバッファサイズは512x272で、フルカラーだと32bppなので512x272x4 = 557056byte
ダブルバッファだとこれの2倍なので
557056x2 = 1114112byte
3Dで使うらしい深度バッファとかいうのは、各ピクセルに2byte使うので512x272x2 = 278528byte
1114112+278528 = 1392640byte
2MB = 2097152byte
2097152-1392640 = 704512byte
704512byte = 688KB
つまり、画面用のバッファをフルに使ってもVRAMに688KBの空きがあります。
この領域を画像用のバッファに使うというわけです。
VRAMの先頭アドレスは0x04000000なので、それに704512足したところに画像を読み込んでやるだけです。

と、まあ、1から自分で描画する場合の方法を書きましたが、DXLPを使ってるなら最初の方に読み込んだ画像は勝手にVRAMに配置されます。
画像をVRAMに配置したり、RAMに戻したりする命令も追加してるみたいです。
というか、この質問もDXLPの掲示板に全く同じようなものがあります。
私はDXLPを使ってない(正確には無い頃に作った)ので、DXLP関係は向こうの掲示板に書いてあることが詳しいです。

あと、そちらのブログのコメントに書いたほうが分かりやすいと思うので、投稿時にブログのURLを入れてもらえると助かります。
[ 2009/12/15(火) 23:18 ] [ 編集 ]
No.960
このコメントは管理人のみ閲覧できます
[ 2009/12/18(金) 19:34 ] [ 編集 ]
No.965
かなり返事に間が開いてしまいましたが…

前にコメントを貰ったときに、ブログのURLが書いてあったのですが、あれば別の方だったのでしょうか?
名前も、ブログの内容も同じだったのですが…
[ 2009/12/30(水) 02:00 ] [ 編集 ]
No.977
このコメントは管理人のみ閲覧できます
[ 2010/01/11(月) 06:22 ] [ 編集 ]
No.978
まあ、自分でプログラムを組んで楽しむだけならブログなどのサイトは必要ないですが、今後、自作ソフトを公開することを考えているのならば、あった方が便利です。
個人的には、何かに行き詰ったときなどに記事にして、他の技術者に聞くという使い方もありだと思います。
ぶっちゃけ、コメント欄でのやり取りは閲覧者が見づらくなりますし、掲示板と違ってブログはログが流れにくく、検索エンジンにも引っかかりやすいので、同じ症状で困ってる人などの参考にもなったりするかと思ってます。
大してブログを利用した更新する必要性が無いのならば、無料鯖と掲示板を借りる方が良いかもしれません。
[ 2010/01/11(月) 23:41 ] [ 編集 ]
No.1003
本文を読まない人は嫌いです。
返事はメールでクレという自分勝手な要望も面倒なので却下します。
本来なら黒歴史として残しますが、非公開米なので削除対象と判断されました。
[ 2010/03/30(火) 19:14 ] [ 編集 ]
No.1032
お疲れ様です~。
東方関連ってことでまとめに入れさせていただきました。
今後も暖かく見守っておりますねw
[ 2010/05/23(日) 21:17 ] [ 編集 ]
No.1056
このコメントは管理者の承認待ちです
[ 2013/02/24(日) 00:25 ] [ 編集 ]
コメントの投稿













管理者にだけ表示を許可する
この記事のトラックバックURL
http://nanajigen.blog74.fc2.com/tb.php/80-2485ad3c

かなり具体的な状況になってきたので、追記。 追記: 10/05/23 『東方DX』追加。 09/06/07 『東方持遊創』、『PSPで「ケロちゃん風雨に負けず」...
[2010/05/23 21:20] PSP-君でもできること
プロフィール

七次元

Author:七次元
永遠の18才
夢を追い求める学生
プログラミング初心者(笑)
愛用言語はHSP(スイーツ)
プログラマーを目指すものの「C言語?読むだけ^^」「C++?知らんがな。クラスって何?おいしいの?」
というゆとりっぷり。
Delphi入れたりVC++2008入れたり迷走中。
夢はコミケで何かやりたい。一般参加すらしたこと無いけど。
PSP-1000(CFW)持ち。PSP-4000マダー?
よく難波周辺のゲーセンに出没するらしい。
STGも格げーも初心者。
ろ、ロリコンちゃうわ!!!

連絡先:homepage_touroku[a]yahoo.co.jp
(メールはほとんど確認してません。掲示板に書き込むのが確実です)

関連リンク
そふとうぇあこうかいじょ
公開したファイルが置いてあります。

掲示板
連絡やら雑談やら適当にどうぞ。
カウンター



現在の閲覧者数:
ブロとも申請フォーム


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。