パッと見で思っただけだけど、全部1番じゃ困るのかな
いや、システム的な話じゃなくてアニメーション描けるなんて凄いなー、と
>>820 どうなんでしょうねえ
でもこうする方が対応がしやすく、環境依存もしにくいかなとか
書き換えの際にちらつく恐れがあるので僕はこの方法をオススメします
ピクチャ番号は本当のことを言えば1番と2番だけでいいんですが便宜的にこのようにしました
>>821 書いてません\(^o^)/
コピー作品を作ってるだけです
処理的に面倒になりそうなものはピクチャで代用することにしました
本当はピクチャに頼らなくても可能は可能なんですよね
オートタイルで代用が効いちゃったりするレベルのものです
っていうか実際そっちの方もテストしてますね
>>820 1番張って1番消して1番入れ替えてを繰り返すって事?
それだとガッタガタになるよ
処理は裏で全部やって完成した裏を表にもってくるってのは必須テク
>>823 ああ、ドラクエか
確かにピクチャで代用した方が早そうだね
>>822 書き替えの際にちらつくはないよ。
ピクチャ表示とか移動とかのコマンドは、内部値を書き替えてるだけだから。実際の表示は全ての処理が終わった後で一括してやってるから、1枚のピクチャで書き替えいい。
画面外でやっとけばピクチャ番号は二つで済むか
>>826 なるほどー
参考になります
それは本エディタの仕様なんでしょうかね?
自分は画像処理は明るくないんですが書籍などでは大抵このやり方かと思って
>>828 エディタの仕様だね。
プログラミングやるなら画面の更新停止して描写して画面更新ってのが基本だけど、ウディタのピクチャ表示はピクチャ情報を内部値に格納するだけのコマンドだから描写自体は勝手にやってくれる。
まあ別にソースを覗いた訳じゃないから間違ってる可能性もあるけど、表示したピクチャを後から移動させられることからしても情報が変数に入れられてる事は明らかだし、そう外れた予想じゃないと思う
ごめんなさい
1番と2番だけだと余計なプロセスが増えますね
やっぱ順繰りに送っていった方がスマートなソースになりそうです
何故古い画像を残すのかというと、新しい画像の表示までには僅かなタイムラグがあるんですね
それは古いオンボロマシンみたいな環境で遊ぶユーザにとっては無視できない(もしかしたら視認できるくらいの)
ちらつきになる恐れがあると思ったんですよね
>>831 え、本当にラグある? だとしたら俺の認識が間違ってるみたいだけど
>>824 なんで1番を消去するんだ?
いったん消去しないとどんどん重なって表示されると思ってるのかもしれないけど、同じピクチャ番号でそのまま表示すれば置き換えられるよ。
それを踏まえて、あとは
>>826の通り。
元々メモリにピクチャを格納してあるっていう仕様であるならそれはまた別なのであまり気にしないでくだしあ
おそらく毎時読み込みを行っていると思いますよ
ですからちゃんと消去っていうメモリ開放のコマンドも持っているわけです
ですのでラグが発生しているのは確かだと思います
それが体感できないのは環境が整っているからでしょうね
1番だけで出来ると思ったから言ったんだけど配慮って大切だよね、なるほど
俺も
>>833と同じ考えだったんだがとにかく全面的に配慮を意識するようにするよ、ありがと
あ、そか。
そういえば、表示ウェイト入れると、一度ピクチャ消えてから表示されるしね。
めちゃめちゃ弱いPCなら0フレ表示でもラグができるかもしれない。
この機に、いろいろと考えてみることにします。
こちらこそ一度作った処理を改めて考えてみることでさらに理解が深まりました
ありがとうございました
ホントに為になるスレだなあ
1番だけじゃなくて2,3,4・・・としていくのなら
1.必要な数だけ事前に各番号にピクチャをセットし透明表示させておく
2.必要になったピクチャを移動で表示させる
3.不要になったピクチャを移動で透明にする
の方が処理が軽くなるようなキガス。メモリの消費量は無論あれだが
ウェイトがいるかどうかは、各ピクチャの表示させる時間とかその他諸々で決まるだろうけど
>>838 滑らかさを重視する大きなアニメーションなどではそうかもしれないですね
メモリに格納しておく事でカクツキを抑えることが出来そうですね
やっぱ大事なのは発想なんすねー
その発想はなかったです
wikiの第一回ウディコンの欄にテンプレ方式の評価全部載せといた!
抜けがあったらスマン。
つかれた。ねる。
乙!
んー、主観的な予想が入っていることを始めに断っておくよ。あと長文になるかも。
ウディタのピクチャ表示コマンドは、さっきも言った通り変数に情報を格納するだけの物なんだ。
格納された情報を見て、ウディタのプログラムが後は勝手に表示してくれる。
これはメモリ解放に関しても自動でやってくれるから、もう使われてない読込みピクチャ情報があればそれも勝手に解放する。
F8を押したら読込みピクチャ情報を表示できるから確認してみるといいよ。
ピクチャ1を使って画像Aを表示、適当にウェイトして画像Bを表示という操作をする時は、
ピクチャ1の情報を入れる構造体にAの情報が入っていて、そこにBの情報を上書きする
という操作をすればいいだけ。
間に消去コマンドを挟むと、その分2度手間になる。
イベントコマンドを読み込んで操作をするってことはウディタの内部処理より確実に遅いから、消去コマンドは挟まない方がいい。
あと、ピクチャ1枚表示するたびに読込にかかる時間なんて、どんなマシンでもウディタ製ゲームが動く環境ならほぼ確実に1フレームより短い(これにはソースはないけど)。逆に
>>838みたいな方法を取るともしかしたら読込みにラグが生まれるかもしれない。
結論としては、タイムラグはピクチャ大量表示とかする訳じゃなければ気にしなくていいよってこと。
フレームバッファってありますよね?
まさにその発想ですよね
自分ならこうですか
画面外に予め数枚のピクチャを読み込んでおく
↓
絶えずピクチャの読み込みをしながら1番から順に移動表示させ、次のピクチャを表示する際に消去していく
なんかアニメーション系のコモンイベントがWikiとかにありましたけどこういう感じなのかな
変わった処理といえば事前に数枚のピクチャを先読みしておく事でしょうか
おそらく、メモリから消去する事自体はそんなに重い処理ではないと思うんですね
というかむしろ軽いかなって
重いのはファイル読み込みじゃないかと
PNGっていうのは可逆圧縮コーデックなので読み込んだ後にデコードするわけですよね?
その処理負荷がアニメーションに追いつかなくならないように数枚のバッファを取る
これはいい発想だと思います
>>840 乙!
自分がゲーム作る上でも参考になる評価が多いから助かるよ
>>843 だから使わなくなった画像はウディタ側で解放を勝手にしてるから気にしなくていいと。
表示する必要ないのにずっと透明で表示させたりするのは確かにダメだけど(透明なら描写自体はスルーされるからメモリがあれば大丈夫だけど)。
画像の読込みを含めたイベント処理時間が1フレームに収まればいい訳であって、どんなに大きくても640×480程度の画像1枚読込むだけならそれほど時間はかからないし、
その点に関してはそれほど気にしなくていいと思う。というか画像関係で一番時間がかかるのは実際の画面描写だし
むしろ画像1枚読込みでタイムラグが発生するような機械だと、ハナから他の処理も重過ぎてまず動かないよ。
>>845 ・使用しないピクチャを表示したままにしておくと画面描写する量が多くなり、
処理速度が落ちますのでご注意下さい。
テストプレイ中にF8キーを押しっぱなしにすると現在使用中のピクチャ番号一覧が表示されますので、
それも利用して無駄なピクチャ表示を省くようにしてください。
だそうで
アニメーションが数秒単位だとしても秒間30フレームとして120とか150とかそういう枚数になってしまいますね
そもそもプログラムの常識としてメモリって言うのは開放しなかったらいつまでもそのままです
コンピュータはこちらの指示に対して忠実すぎるほど忠実なんです
言わば究極の指示待ち症候群なんですよね
盛り上がってる所すまない。
途中から流し読みしかしてないが、
片方はプログラムの常識といういわば一般論をを主張し、
もう片方はウディタの仕様に基づいた、ウディタを使う場合に効率が良い方法を主張しているように見えてしょうがないんだが
相手の主張における前提を理解しているか、理解しようとした上でレスを書いているかが疑問。
>>847 っていうか起動時に全てのピクチャを読むなんてトンデモ仕様のわけもないんでね
そこはハッキリしておいた方が良かろうと
普通にメモリに読んで使い終わったら開放するっていうのはどんな言語でもツールでも共通です
プログラムが勝手に判断してメモリから開放してしまうってどんだけ行儀悪いんだって話
意図がどこにあるのかわからないのに勝手なことはしません
>>846 プログラムならそうだよね。でもこれは"ウディタ"なんだよ? そのメモリ解放の部分は意識しなくてもウディタ内部に"使わなくなったピクチャ情報は解放する"って処理が入れられてるの。
例えばピクチャ1で画像Aを表示していて、画像Bを新たにピクチャ1で表示した結果画像Aが使われなくなった場合、画像Aは勝手に解放されてるから。
ってか話が噛み合ってない。前半で言ってることは俺も言ってるじゃないか。F8も知ってるよ。試しに
■ピクチャ表示:1 ファイル[AAAA]X:0 Y:0 0(0)フレーム
■ピクチャ表示:1 ファイル[BBBB]X:0 Y:0 0(0)フレーム
ってコマンドを実行してみなよ。でF8押してみなよ。
画像AAAAの情報は残っていないのがわかるだろうからさ。
>>849 それってまったく重なり合ってる場合って事ですかね?
部分書き換えは想定の外なんですか?
>重いのはファイル読み込みじゃないかと
その通りだと思う
PNG云々じゃなくて、画像が大きいほど&多いほどHDDの物理的な遅さが影響してくるでしょ
ていうか、ウディタのピクチャには分割数という便利機能があるんだから
必要なアニメーション分だけまとめた画像を一個用意して
分割してパターンで表示すればピクチャ番号は1つですむでしょ
ていうか、そういう使い方をしないと作者が泣くと思う
パラパラ漫画みたいに全部取り替える話だったと思うのに
急に部分利用の話になったのはなんで?
>>850 部分書き替えってなんなんだ。
座標移動してもいいのかって話ならいいけど。
>>852みたいにパラパラアニメかと思ってたけど違うのか?
背景とキャラクターを別々に動かしたいとかならピクチャ2枚使わなきゃいけないけど
というよりウディタのピクチャ表示とプログラミングにおける画面描写を同じと捉えちゃいけないよ。そこらへんが噛み合わない原因じゃないかと思う。
ここはウディタのスレだし、俺はウディタの仕様について話してるからな。
>>818 すいません、体調があまり最近よくなく、ちょこちょこと更新しているもので…;
シナリオ別順位などもつける予定です、すいません;
感想云々、時間ありましたらつけたいと思います。抜ける部分も多そうなので良ければ他の方も編集にご協力頂ければ幸いです;
全取替えを前提にしてたわけでもないんですよね
もちろんキーフレームは丸々書き換わると思うんですが
実際は部分的に書き換えるっていうのは普通に手法として存在します
やっぱり汎用性って大事かなと
でも実際試してみて確かにおっしゃるとおりでした
描画範囲全てが上書きされた場合、勝手に消えていますね
納得しました
ことウディタにおいては、最後に画面上に(表示範囲外でも)描画されているピクチャだけを消去すればいい
これだとアニメーションっていう手法をとる場合は消去っていうステップが無駄に多いって事ですか
なるほど、ピクチャ番号が1つでいいというのもなんとなくわかってきました
ウェイト(エラー防止用)
↓
ピクチャ1番を読み込み表示
↓
ピクチャ1番を上書きして次の画像を読み込み表示
↓
最後だけ画面上の不要なピクチャを全て消去
えらいシンプルになりましたが、書き換えの際の処理がどうなってるかですね
1ビットずつ上書きしていく形って事を主張されてるんでしょうけど
ってうわ、過去ログまともに見てなかった。
編集してくれた方ありがとうございます……!
寝ぼけ眼で携帯で見てました、すいません。
>>855 > 全取替えを前提にしてたわけでもないんですよね
いや、そもそもウディタの仕様はピクチャ1枚ごと全取替え前提だよ。ピクチャの部分書き替えって操作はできないし(そんなことやったらセーブデータがどうなるか!)。
> 書き替え
ピクチャ表示における情報書き替えってのは、別にメモリ上の画像データを書き替えるって意味じゃない。
ここで言うピクチャ情報ってのは、
画像ファイル名
分割数
表示座標
拡大率
etc
の事だ。
表示の際には画像ファイルを読み込んで(もし既に読み込んであれば読み込まない)、ピクチャ情報に照らし合わせて再描写してる。
そもそも画面はマップからイベントから主人公からピクチャから全部毎フレーム更新されてるんだから、当たり前だけど1フレーム前の状態は残らないよ。
>>855 だから、分割数を使えばピクチャ番号は1つで画像の読み込みも1回だけ
後はアニメーション分だけ移動でパターンを移動させればいいのだが
ID:pVEw3DViにもID:eZGdf/DZにも無視された俺涙目
>>858 分割数を使わない前提でアニメーションさせる話なんだろう
なんか盛り上がってるとこ悪いんだけどさぁ、
ウディタがどういうプログラムで動いてるとか、そういう考察は自分のサイトとかでやってくれんか?
ピクチャ表示だけでこうも長々と語られると正直鬱陶しい。
>>858 ああゴメン。もちろんアニメーションは分割でいいんだけど、なんだか話の中心からずれてる気がして。いや、むしろ今の話が中心からずれたのかな。
ID:pVEw3DViが思い描いてる言語における画面描写(ここらへんに俺の誤解があるかも)とウディタのピクチャ表示はだいぶ違うんだということを言いたかったんだけど。
>>860 パラパラアニメなら使用するピクチャは1枚でいいよとか消去の直後にまた同じ番号でピクチャ表示するなら消去はいらないよとかそういうウディタの仕様について言いたかっただけなんだが、変な流れになってしまったな。スマン。
説明するのにウディタの処理方法を出した方がいいかと思ったんで、別に積極的に考察とかするつもりはなかったんだ。結果的にミスった気がするな
>>860 まぁいいじゃん。一応ウディタの話題だし、他に対して話すこともないし。
アニメーションなんか使わねーよって人も多いだろうけど。
しかし読んでも全てを理解できないのが悔しいな。
ある程度完成したらソースとかみしてくれないのかなぁ
なんか新しい機能とか追加してみたいんだが
糞しかいないのにスクリプトを公開する意味がない
>>863 ってもなぁ、ウディタで一通り試してみればわかることを、自分の理論だけで想像して見当違いのことを延々書いてるんだもの。
しかも、それを指摘してもらっても見事にスルーだし。
俺には「ID:Y58QAAVT=ID:pVEw3DVi」が、ただ自分の理論を語りたいだけのようにしか見えなかったんだ。
それが2chだ。嫌なら見なければよい。
恥ずかしい馬鹿丸出しのチラ裏オナニーは叩かれて当然だな
それが2chだから
軽くツッコミを入れたつもりがかなり盛り上がっちゃってるな…