戯言徒然日記開発日記東方DTMC/C++DoJaLuaCG備忘録
気が向いたら創作活動とかしてる人のチラシの裏。
--.--.-- --
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
2007.12.31 Mon
☆Imageから取得した描画コンテキストを使ってGraphics3Dのレンダリングできない。

→オプションのGraphics2#getImage、基本APIのImage#createImage->Image#getGraphics、どちらにしてもGraphics3D#flushBufferを呼んだ時点でinternal error occurred while drawingとなり強制終了する。確認されているものはDとF?

[追記]
Javadocにて以下のように記述があります。DとFはこれでアウトなもよう。
[DoJa-4.0 (901i) 以降]
戻り値として得られるグラフィックスオブジェクトが Graphics3D インタフェースを実装しているかどうかは機種依存です。

☆Graphics#copyArea と Graphics#getPixels -> Graphics#setPixels

→D902iSにおいてしかテストしていないが、Graphics#copyArea の方が比較にならないくらい速かった。原因はよくわからないが、どこかでD端末は液晶の色深度が32bitなのでGraphics#getPixelsに時間がかかる、ってことが書いてあったような気がするのでそれかもしれない?ただ、D902iSにおいては Graphics#copyArea も相当遅い。

→Graphics#copyArea を使わずに済むためにも Transform#lookat を理解したい。わけわからんorz


☆Transformクラス、FastMathクラスの誤差

→某スレにてすごく叩かれていたのを見て鵜呑みにしているが、よろしくないもよう。float演算をあまり行わないように作成しているので処理高速化には最終段階で取り組むところかな?DirectXのlookAtを参考に自作したlookAtが微妙に正負が異なっていて困っている・・・。数学の基礎知識を習得する必要ありorz


☆モデルデータの軽量化

→単純に描画対象のモデルデータをローポリ化するだけでも処理速度は上がる。当たり前?


☆大きなモデルデータを1回レンダリングするのと、その1/3サイズのものを3つ描画する

→うまく表現できなかったが、同じモデルが延々と続いていく場合などで、モデルデータ上でその延々と続くものを作って、プログラム上では1回の描画で済ますのが前者。続く箇所のみのモデルデータを作成しそれをプログラム上で数回に分けてレンダリングするのが後者。この場合、プログラム上で描画される(画面外を含めて)頂点の総計がキーになってるみたい。変わらないなら少しでもモデルデータのサイズを減らすことができる後者が有利。

→Fogを扱う場合、上記の前者の場合だと、うまく続いていく感じが表現しにくかった。後者でも同じかもしれない。・・・・後日検証してみます。

→つなぎ目をわかりにくくするのは後者の方が楽かもしれない。前者で作ってみたものの、モデルデータの調整に時間がかかった。


☆加算、減算合成

→3DCGからは少し離れるが、Graphics3DのレンダリングよりもGraphics2の加算・減算合成の方が処理が重いみたい。合成する矩形サイズにも依るがD902iSにおいては非常に時間がかかっていた。
スポンサーサイト
2007.12.31 Mon
 つんさんのブログで「今晩更新する」と宣言したので約束通り更新します~。結構中途半端になってます(^_^;)ご了承下さい。

20071230.jpg

 ほんとは黒色のフォグで暗闇の中を進んでいくイメージだったんですが、風神録のあそこと似てるのでそれっぽくしてしまいました(笑)未プレイの方、すいませんm(_ _)m

 自作ライブラリではライトに関するものがまだ整理しきれてない状態です。ってかライトの設定は3DCGソフトで全部やるべきでしょうね。うまいこと使えば面白いエフェクトになりますし。あとはマルチパステクスチャってやっぱ無理なのかな?いや無理でしょうね;描画処理の重さの方が・・・。SH902iにおいては、はじめてすぐだと処理時間1ループ15㍉秒くらいです。D902iS(兄と前持ってたD903iTVを交換。D902iだと思ってたら、よく見たらD902iSなことに今気づく)だと・・・。まぁ15fpsでなんとか、ですね。タイマの解像度もよろしくないようで意図したものには遠かったです。sleepなくしてビジーループにしたらひょっとしたら気持ち改善されるかも。期待はしない。

 フォグを消すとSH902iで2~3㍉秒速くなります。ボタンを押してOnOffでもよかったのですが、後日オプションで設定できるようにするつもりなのでやってません。ご了承ください。

 結構変わったかもしれませんが、どこ変えたか覚えてないので放置で・・・。fpsの青文字表示は規定のfpsの80%を割った場合が青表示になります。青表示が頻繁になる方は設定を変えるか機種変してください。

 どうでもいいですが、VSYNCって表記おかしいですよね;別に垂直同期してないし・・・。垂直同期するメソッドは一応あるのですが、P905iのみです。項目を画像にするとき簡単なんでそうしてるんですが、いいですよね?うん、いいよな。

 今回、3DCGに関する部分でつんさんに非常にお世話になりました。背景の3DCG化をしてくださらなかったら無理だったと思います。この場でお礼申し上げます☆
2007.12.28 Fri
 少し使ってみた&調査したことなどを書いておきたい。(間違い指摘などお願いします)

・オプションと標準のGraphics3Dの違い

→オプションのGraphics3Dは902i以降削除されてるみたい。オプションの実装状況を参照。使うなら標準のものにしとく方が無難。

・mbac、mtra、d4dって何?

→mbacはモデルデータなど、mtraはアニメーションデータと考えていいかと。語頭のmはmobileのmかな?MascotCapsuleのサイトに変換プラグインがあるのでそれを使って作る。元になるモデルデータなどは各種3DCGソフトで作成する。

→d4dは複数のモデルデータやアニメーションデータ、さらにはテクスチャも含められる形式。DoJa4.0?から対応している。mbacを使う場合、テクスチャは256色bmpになるけど、d4dの場合はpngを使う。d4dは一端h3t形式に吐きだしたデータをD4D Converterで変換して作成する。512kB以上のd4dファイルは作れないので注意(作らんとは思いますが;)。

→DoJaで3D Graphicsを扱う場合はこの3の形式のファイルを使って行う。それぞれに一長一短があるので、MascotCapsuleのマニュアルを参照のこと。(てかここまで丁寧でわかりやすいマニュアルはじめて。素晴らしいです!)

・MascotCapsuleって何?バージョン何個かあるけど?

→マスコットカプセルはHI社が作成した3Dレンダリングエンジンみたいに書いてあったような。詳しくはけーねまで。DoJaプロファイルにも対応してる。Graphics3DのAPIを使って操作?

→DoJaの場合は特にバージョン気にしないでもいいのかな?V4から扱えるd4dはDoJaでは4.0以降なので、それ以前のプロファイルで作成する場合は注意。

・3DCGソフトって何がある?

→現在試行錯誤中。mbac、mtraを使うか、d4dを使うかで分かれると思われる。

→mbac路線だとフリーのblenderがプラグインで対応。(ただしβバージョン)。その他市販の高価な3DCGソフトが対応、もしくはプラグイン有りです。

→d4dの場合はフリーならメタセコイア。その他は同様に市販ソフトですね。メタセコいいんですが、複数の光源をもてない?っぽいのでそこだけしんどいところです。

→データをXSI modtoolなんかで作成して、他の形式に変換後、さらにそれを・・・なんてことできないですかね?


参考URL
MascotCapsule Developer Network
→マニュアルが丁寧でわかりやすい。サンプル(DLできなかったorz)もあるし、マニュアル読めばすぐコーディングできるかと。その他各種プラグインや仕様書みたいなのもおいてある。

 この調子で書き連ねようと思ったものの面倒なのでやめる(笑)上記サイト一つでほぼ大丈夫だと思います。Web上で見つけたGraphics3Dを使ったサンプルはオプションを使ったものだったので基本APIを使う場合は若干異なりますね。んま、しつこいけどマニュアルの最後にサンプルあるのでそれ読んだらわかると思います(^_^;)
2007.12.28 Fri
 やぁ。たまには更新しとかないとね。なんせクリスマスから気を抜いて遊んでますから(笑)
 
20071227.jpg


 さて、特に変わってませんね。






 ・・・・すいません。結構な時間費やしてます(^_^;) 

 卒論?何それ食えんの?

 とりあえず、Optionの3Dではない方の3Dでやってみたわけですが、平行移動のTransformおかしくないか?頑張ってみたもののクリッピングした分ズレたx座標をカメラ座標に適用できなかった。まっすぐした視点になってないです。こんな状態なんで、全然思い通りに表示できない。DirectXとかもっと楽じゃなかったっかなぁ。3DCG自体にも慣れてないのもあって結構ひどいですorz

 対応しようと思えば可能ですが、DoJa4.0以降で扱えるようになったD4D形式のオブジェクト?を読み込んでいます。アクセス解析見てると902i以前の方もアクセスしているようですが、動作してるのでしょうか?今後は対応しない限り間違いなく無理です。年明けには携帯変えるので、なかなか動作状況の把握ができないと思います。ということでご了承ください。

 さて、そう書いたものの3Dの背景使えるのか?SH902では余裕で描画できました。gifの背景+2msecくらいかな?(てかjpgの方が同じサイズgifより描画軽いんだな;)速度的には問題ないんですが、厳しいのはサイズ。テクスチャサイズに依りますがかなりデカイです。凝ったものを作るならスクラッチパッドでも難しいかも。現在はjarファイルが100kBに収まる程度にしてますが、もっとポリゴン増やして細かくしていくとわからないです。頂点データはしれてるとは思うんですが、増えるほど今度は処理が追いつかないでしょうし(^^;)3DCGは前々からやってみたかったのでこのまま続けてみようとは思いますが、いつ頓挫するかは不明(笑)フォグ出したら死亡しそうだけどフォグ出したい。どうしても無理な場合は対応機種を少なくするしか・・・(>_<)

 最後に、DLできるようにはしてませんがいいですよね?(^_^;)この程度の更新なら。画面遷移のウェイトがなくしてサクサクになったり、霊夢グラが変わってたり・・・。もうすぐスカートとかがヒラヒラするのでそれからでも遅くないですよね?

 さぁ、明日は頑張って論文書こう。そうしよう。年明けで今の状況は絶望的だな。今年中に提出条件満たせるように・・・・。
2007.12.24 Mon
 つんさんの記事

を見ていて非常に面白いことに気づいた。

 私は描画周期の制御に関しては、フレーム管理クラスが1フレーム(1ループ)ごとに何フレーム目かをカウントしているので、そのフレームカウントを使って

isDraw = frame % skip == 0 ? true : false;

という感じで、描画するかどうかのフラグを決定して回しています。skipというのは、例えば、内部処理が30fpsなら1フレームスキップする、つまり1フレーム描画を飛ばして15fpsとする、というようなものです。(もちろん0剰余を避けるために実際の値に+1しています。)これは描画処理回数に着目し、目的のfpsに描画を合わせるという発想で作られています。

 これに対してつんさんは、内部処理の走査に着目し、仮に内部処理が30fpsの場合なら2回内部処理を行わせてから描画処理を呼ぶという、描画ではなくその他の処理に基準をおいた手法です。詳しい実装に関してはわかりませんが(^_^;)

 で、何が面白かったのかというと、私は描画以外の処理を全く意識していなかった点です。しかしながら、私の手法も視点を変えてみると同様に内部処理を指定回数行わせてから描画という流れができあがっています。(描画処理とそれ以外の処理しかないので当たり前と言えば当たり前ですが;)



 この「描画以外の処理を指定回数させている」という点に気づいて私が思ったことは、仮に30fps->15fps(内部->描画)にするのであれば、二回も同じ走査や判定をするのは無駄ではないのか、ということです。移動量を例にしてみても、単純な乗算の構造になっている移動処理であれば、移動量を2倍するだけでもう一度走査した後の結果と同じになります。したがって、走査を1回で済ませることができるのです。

 もちろんそんなことをしてしまえば、いくつかの問題が生じます。
 まず、速い弾などは自機に衝突する軌道であっても判定が自機を通り超してしまい、所謂すり抜け現象が起こってしまいます。これを解決するには、描画スキップ回数分の座標配列をクラスに用意して、その回数分、次フレームの座標と判定すれば目立ったすり抜けはなくなるでしょう。
 次に、最大の問題ですが、入力精度が変わってしまいます。30fps->15fpsではキー入力のタイミングが15fps、30fps->10fpsでは精度が10fpsです。これでは描画周期を変更すると難易度まで変わってしまいます・・・。解決方法としてはキー入力は別スレッドにして、スレッドセーフに自機の位置を操作できるようにするという手が思いつきました。



 結局、私は処理速度改善のためにこのような面倒なことはしません(笑)複雑になりますし。ただ、少し視点を変えるだけでも今まで全く思いつくことのなかったアプローチの存在に気づくというのは面白い。そんなどうでもいい話でしたm(_ _)m
2007.12.24 Mon
 『入門 Luaプログラミング』がついに届いた!パラパラした感じ、前半は言語仕様などが丁寧に書かれているっぽい。この辺りは半年くらい前にマニュアル読んでたので、ちょっとしたリファレンスに使えそう。(一応巻末に索引がついているのを確認) 個人的に興味を持ったのは第三部からですね。特に第十章は面白そう。まぁ薄そうなので内容は薄いとは思いますが、いいヒントが得られそう。

 最近は言語処理に対する興味がかなり大きくなってきているので、時間ができたらその手の本を読んでおきたい。その前に前々からアルゴリズムの勉強をきっちりやりたいと思っていたのである程度のレベルのテキストを見定めてやるのが先ですね。Javaだと最初からいろんなデータ構造に対応するクラス群がライブラリにあるので苦労はしないけど、どんなコードになっているのか気になる。Cで書くなら・・・なんて考えてると、こうだろうなぁってのはあるものの、やはりきちんとテキスト使って知っておきたいところ。言語処理やるなら尚更ですね;

 とまぁ思うところはいろいろありますが、Lua本、ひとまず積読なものの、年初くらいには読みたいですね。
2007.12.22 Sat
 中途半端になってしまいましたが更新してます。

[変更点]
・内部処理の周期を30fpsに。
・内部処理周期変更に伴いオプションで選択できるVSYNCを30fps、15fps、10fpsに変更。
・小弾のサイズを1ドット小さくした。当たり判定も同様に小さく。
・ショットのOn / Offを可能に。ソフトキー1です。
(従来の弾がたくさん出てくるのは忘れて下さい)
・簡単に敵が行動する。パターンはもちろん1種類orz

 こんな感じです。パワーアイテムによるショットの強化がハンパないので少し粘れば画面上部張付きでふるぼっこできます。はい、すいませんm(_ _)m
 本当は自機のミスもつけてゲームオーバー画面への遷移やっとくはずでしたが、時間的に厳しいので後日にします。

 さて、これ以降の更新については1月8日以降までない方向でお願いします。本業がまずいことになってますのでご容赦下さい。一応掲示板のようなものを設置しましたので、動作機種、バグ、要望などなど、どんどん下さい。復帰後の参考にさせていただきます。(重大なバグ修正などに関しては明日以降も時間みて行います!)
 

 機種によってはUIExceptionが出る件ですが、原因は2つ考えています。①Jargによるバイトコード最適化、②7-Zipの圧縮により画像が読み込みできない、です。①については今日更新したものは行ってないので問題ないです。②に関しては当分は対応できません。②のおかげで9kBくらいは圧縮できているのでスクラッチパッドに画像を読み込むようになるまで待っていただきたいと思ってます。(勝手言って申し訳ありません)

 ちゃんと卒業できるようになって帰ってきます(T_T)ノシ
2007.12.21 Fri
 とりあえず真っ黒ばかりではアレなのでちょっと明るい背景つけてやってみた。案外雰囲気出ますね。結構気に入りました。

20071220_4.jpg

20071220_5.jpg

20071220_6.jpg

 さて、実機では・・・・?




 ・・・・散々でしたorz

 まず弾の加算合成は当然カット。無理。弾を出してみる。黒背景になじませるための中間色によりジャギ出る。おまけに出せる弾数も結構減りました。特にキー入力による遅延がかなり描画をoffにしてくれる。(=カクつく)困りました。東方遊夜雀の人が20fpsくらいで作ったのが納得いった。先人はエライ。

 これは大きな危機。私がやりたいのはこれにさらにスクリプトエンジンを積むってこと。実は現時点でもjarファイルが50kBオーバーしてたりする(うちいらない画像が10kB弱)。・・・。厳しいな。ゲーム中ならスクリプト実行はそこまで気にならないようにできると思うが、ここまで描画関連が厳しいとちょっと凹みます。モバイルで割と普及してる&開発環境有りってのは他にないんだろうか?ショック!



 しかしながら、逆に考えるとそれだけ拘れない分コーディングに集中できるのはメリット?もう背景の3D化とBGMと効果音の3gp化とかぜ~んぶ却下。妄想しすぎた。⑨だった。Graphicsが割合抜けて苦手なので少しくらいしょぼーんでも・・・=3

 はぁ・・・。今までの妄想を返して欲しい。卒論そっちのけにしてきたことを悔いたい。そして、今ある重い気持ちをコーディングにぶつけて発散したい(笑)ってことでフレームアニメーションとステージ実装を本格的に設計しだしました。
2007.12.21 Fri
 パワーアイテムによるショットの強化をやってみた。ショット画像は妖々夢っぽいのにしたものの、回転描画によるジャギが目立ちまくる・・・。わかりにくいですが加算合成にしてます。60fpsでやってみたら弾数100くらいで50fpsちょいになりました(^_^;)無理ですかね?

 とりあえずパワーアイテムを取ってパワーが上昇すればショットが強化されるってのをやりたかっただけなので、コピペしてショット増やしてみました。一応実現してるのでいいのですが、問題はバランス調整。パワーアップのタイミングは風神録を真似てますが、オプションは2つで妖々夢みたいにしようと思ってたので、この差異をどう埋めるか。難しいですね。ボム(霊撃)は比較的たくさん使えるようにしたいので、風と妖を参考にしてたものの、ボム後にパワーが減るとなるとパワー1.00でのボス戦も考慮しないといけないんですよねぇ。

んー、結局風神録ライクに行く?

 得点に関しても少し詰まる。シューターと自称できる程STGやってないので(単なる東方厨)得点計算をどうすれば幅広く楽しめるかわからない。風と妖は割と得点の入り方が似てる方だけど、やっぱりGrazeすればするほどしてない得点とは差がつくようにしたいんです。

自機位置による得点(上部程高得点)+Graze×10とか?

 考え出すとキリがない。この辺りはSTGやってないのが如実に出てしまいますね(^_^;)ゆっくり考えたいと思います。助言あればご教示願いますm(_ _)m

 SS置いておきます。パワーが上昇すればショットが強化されるようになりました。調整は後にしてどんどんバグ取りと機能追加していきます。

20071220_1.jpg

20071220_2.jpg

20071220_3.jpg

2007.12.20 Thu
 昨日に引き続いて今日も更新してみた。ほんとはキーコンフィグもつけるつもりでしたが、保存はまだ作る気ないんで意味ないかなぁと思ってやめました。

20071219.gif

 今回の目玉というか一番の新機能は描画周期の変更ができるようになったことです。それをするためにタイトル画面からオプション画面への移動を追加しました。上のSSがそのオプション画面。デフォルトは機能させてません。キーコンフィグつけたときにでも使えるようにします。一度設定するとアプリを終了しない限り設定が有効になります。
 デフォルトでは30Hz(30fpsになります)で、20Hzと高性能な後世の端末のために60Hzも用意しときました。基本的に30が安定してると思いますが、機種によりけりなので一概には言えないところです。私は30fpsでの動作を基準に弾幕を張ろうと思います。ちなみに、内部処理を120fpsにして細かく選べるようにしようとしましたが結構重くなって処理速度が心配になってきたので60fpsです。

 その他、細かい修正入れてます。得点アイテムをまた小さくしたり、得点表示が復活したり。つんさんのアプリやってていいなぁって思ったので得点のアニメーションと弾の発射時高速モードを露骨にパクってみた(笑)すいませんm(_ _)mいいものは欲しい!ということで正当化。

 オプションつけたいところだけど、結構ややこしいことになりそうなので一端中断。画像関連をレイヤー対応にしたいなぁって思ってるのでそっち先にやりそう。いつになったらステージとかつくんでしょう(^_^;)
Template by まるぼろらいと
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。