【ウディタ】WOLF RPGエディター其の4

**名前は開発中のものです。** · 2008/09/20(土) 13:27:02

独自のシステムを作成することも可能なRPGエディタです。
RPGツクール系よりは手がかかる分、比較的細かい所まで作り込む事ができます。
RPGツクールでは物足りないけど、プログラミングはちょっと……という方にお勧めです。

WOLF　RPGエディター公式サイト
ttp://www.silversecond.com/WolfRPGEditor/
エディター説明書
ttp://www.silversecond.com/WolfRPGEditor/Help/

前スレ
WOLF RPGエディター　其の３
http://pc11.2ch.net/test/read.cgi/gamedev/1219480611/l50

以下、公式サイトから抜粋。

・高度なRPG開発が可能な、完全無料のゲーム作成ツールです。
・作成したゲームは自由に配布したり、コンテストに投稿することが可能です。
　また本ソフトを持たない人でもプレイ可能！ファイル暗号化も完備しています！

次スレは>>950が立ててください。
テンプレートは>>1-3

**名前は開発中のものです。** · 2008/10/08(水) 00:05:08

>>744
乙
俺はああいうノリ好きだぜ

**名前は開発中のものです。** · 2008/10/08(水) 00:58:54

あげ

**名前は開発中のものです。** · 2008/10/08(水) 02:59:19

>>737
「動的なフィールド」ってググった上で読み直したら、余計意味がわからなくなった。

とりあえずアニメーションならオートタイル、背景なら遠景、チップ変更ならイベントでいいんじゃないかな。

マップチップのIDは通行判定くらいにしか使えない。
んで、タイルセットのIDはマップファイルに保存されてるから、シームレスにマップごと変更するのが最短ルート。

**名前は開発中のものです。** · 2008/10/08(水) 13:36:58

ウディタってファイルの書き出しや移動ってできる？
例えばゲーム中で使った画像ファイルを出したり、新しくテキストをつくったり。

**名前は開発中のものです。** · 2008/10/08(水) 13:39:57

＞ゲーム中で使った画像ファイルを出したり
㍉

＞新しくテキストをつくったり
おｋ

**名前は開発中のものです。** · 2008/10/08(水) 14:02:23

60フレーム使うくらいのアニメーションがゲーム中になけりゃ30FPSで十分だよな

**名前は開発中のものです。** · 2008/10/08(水) 15:33:59

点と線、白丸表示に騙されないようにしたらとんでもなく簡単になった
処理単位よりも速くマウス動かせばどんな弾幕も抜けられるのなｗ

**名前は開発中のものです。** · 2008/10/08(水) 17:19:06

オートセーブは可能ですか？

**名前は開発中のものです。** · 2008/10/08(水) 17:22:23

考えたことなかったけど出来るんじゃない？
終了する時とかに勝手に処理はさめば
×とかで消す場合とかは…詳しい人おねがい

**名前は開発中のものです。** · 2008/10/08(水) 17:27:24

定期的にセーブ処理すればいいんでないの

**名前は開発中のものです。** · 2008/10/08(水) 17:33:00

最悪常にシステム変数25「現在ｾｰﾌﾞﾃﾞｰﾀ番号(0～)」使ってセーブデータに上書きする処理を常に起動しとけばいいわけだけど
それでは重くなりそうだからシステム変数35「主人公移動中？(1=YES)」とかシステム変数13「ｲﾍﾞﾝﾄ実行中？(1=ON)」とかを条件に使った方が良いかも

**名前は開発中のものです。** · 2008/10/08(水) 17:39:11

関係ないけどｼｽﾃﾑ変数にイベント実行中があったとは…自分で作って立てたりしてた
何があるか眺めてみよう…そういやｼｽﾃﾑ変数自体ほとんど見てなかったorz

**名前は開発中のものです。** · 2008/10/08(水) 18:20:40

そういえばシステム変数なんてものもあったんだな

**名前は開発中のものです。** · 2008/10/08(水) 19:43:44

主人公を事前に変数で取得させた場所に移動させたいんだけど、
主人公が0.5マス歩いた状態で、0.5マス単位の精密な位置(x.y)を取得
した変数の場所に、主人公を移動させるにはどうすればいいですか？
場所移動だと１マス単位でしか移動できなくて壁にハマっちゃいます…

**名前は開発中のものです。** · 2008/10/08(水) 20:18:55

まずは1マスくぎりで瞬間移動させて残り半分追加移動させればいいんじゃね？

**名前は開発中のものです。** · 2008/10/08(水) 20:47:31

>>759
ごめん、、
最初はそうやって移動させた後に半分移動させようとも考えたんだけど、
取得した変数の場所が固定されてるならともかく、変動する場合にはどんな処理をすればいいんですかね？

**名前は開発中のものです。** · 2008/10/08(水) 20:56:05

まずは精密座標で取った数値を２で割って標準座標で瞬間移動だろ？
その後に精密座標％２をして１出たら右と下に半歩移動でおｋ
何か文字じゃ上手く伝わらんな。

**名前は開発中のものです。** · 2008/10/08(水) 21:21:40

>>761
おお、移動出来ました！ありがとうございます！

**名前は開発中のものです。** · 2008/10/08(水) 21:33:44

瞬間移動するまでは同じだが、その後の処理は
■変数操作:可変DB[-1100:91800:2] = 移動先X座標
■変数操作:可変DB[-1100:91800:3] = 移動先Y座標
で動かしてやった方が楽そう。条件分岐とかしなくていいし。
ってかこの変数操作で瞬間移動出来りゃいいのに

**名前は開発中のものです。** · 2008/10/09(木) 14:44:29

どうでもいいけど何で半歩移動って0.5x0.5じゃなくて1x0.5なんだ？

**737** · 2008/10/09(木) 17:36:57

説明が上手くいってなかった
要は歩数をカウントしておいて時間経過とともに暗くしたり明るくしたりしたいのかな
完全なDQクローンシステムを作ってるんで

マップチップだけ置き換えた同じMAPを必要分用意しておいて
そっちに飛ばすっていうのを考えたけどスマートじゃない気がするなあ
でも処理時間的に無理がないならこれでいこうかと思う

**名前は開発中のものです。** · 2008/10/09(木) 17:44:38

>>765
それなら画面処理で暗くするか、
ピクチャを画面全体に半透明表示させればいいだけじゃねーの？

**名前は開発中のものです。** · 2008/10/09(木) 17:53:52

>>766
それの方が処理は軽いけど再現性が落ちるかな
オリジナルゲーだったらそうしてたと思う

**名前は開発中のものです。** · 2008/10/09(木) 18:06:26

DQ3と同じシステムなら766の方法でいいんじゃない？
夜だけ光るランプなんかも歩数によって条件分岐してグラフィック変えてやればいいし。
再現性が落ちるってのがよくわからん。

**名前は開発中のものです。** · 2008/10/09(木) 18:09:44

完全クローンを作ってるから、かなあ
別の言い方をすると移植ってやつです

FCのDQ4をまるっと移植しております

**名前は開発中のものです。** · 2008/10/09(木) 18:11:49

FCのパレット制限は色々ときついので
ただ暗くするだけじゃ色彩が合致しないんですよね
なので置き換えっていう手に頼らざるを得ないかなと

本当はマップパレット単位で交換できたら一番スマートなんだけど

**名前は開発中のものです。** · 2008/10/09(木) 18:42:06

なるほど
それならマップ複数作って移動しかないかなぁ

あとツールで完全移植は不可能に近いから、ある程度妥協しないと死ぬよ

**名前は開発中のものです。** · 2008/10/09(木) 20:18:47

>>771
ありがとう
やっぱりそれしかなさそうですね
完全移植を目標にしないとこのエディタの有用性が示せないかなって思うんで
出来れば完全、かな

まあ欲張りなのは最初だけですので、最終的に無理な所はカスタムして実装してみますね！
今回の夜の表現にしても、最終的に処理速度が不十分ならイベントで明度をいじって積むかもです

全レスはしてないけど全部しっかり検討させてもらいましたし、参考にさせてもらってます
みんな色々アドバイス感謝です

**名前は開発中のものです。** · 2008/10/10(金) 08:43:36

あげ

**名前は開発中のものです。** · 2008/10/10(金) 15:09:37

何度もageてみたが、荒らしが来る気配もない。
まあもう少し実験を続けてみる。

**名前は開発中のものです。** · 2008/10/10(金) 17:32:48

それはひょっとしてギャグで言ってるのか（ＡＡｒｙ

**名前は開発中のものです。** · 2008/10/10(金) 17:34:13

来る訳じゃなくて来易い感じがするから好かんってだけだろ
話題に出たのは知ってるがどうでもよくね？
そんなことよりウディタの話しようぜ！

**名前は開発中のものです。** · 2008/10/10(金) 17:39:30

ウディコンが終わった途端に過疎った気がする

**名前は開発中のものです。** · 2008/10/10(金) 17:40:17

全部釣り針にしか見えないな。

ツクール関係触れたこと無い俺がウディタでゲーム作ろうと思うんだが
コモンイベントを覗く→一つ一つの命令を理解するが全体像が見えてこない→わけわからん！
という繰り返しに陥ってる。

これは無茶なことせずに大人しく基本システム流用するか、
時間かけても少しずつシステム理解してくのかどっちが良いかね？

**名前は開発中のものです。** · 2008/10/10(金) 17:45:26

基本システムはブラックボックスとして扱うより理解しちゃう方がいい。
どうせやってる内に不満が出て改造したくなるんだから。

**名前は開発中のものです。** · 2008/10/10(金) 17:50:13

んじゃ頑張ってみるか。
性格的に俺はシステム屋だろうから納得のもんが出来る様努力してみるよ。

**名前は開発中のものです。** · 2008/10/10(金) 17:50:54

俺もツクールとかやってないんだが
理解しちゃおうと頑張ってたけど途中で諦めたわ

一から自分で作ってる（勿論参考に出来るところはしつつ
個人的にはその方が分かりやすいし楽しい

**名前は開発中のものです。** · 2008/10/10(金) 18:19:08

ツクールいじったことない人はデフォルトシステムを解読するより自分で一から作っていったほうが理解がはやい
ソースは俺

**名前は開発中のものです。** · 2008/10/10(金) 20:04:03

ああ、あくまでも>>779は基本システム使うならって話ね。1から組むならそれはそれでいいと思うよ。

**名前は開発中のものです。** · 2008/10/10(金) 21:21:17

ぶっちゃけウディタって一から作ることで生きてくるかんじがする。
（基本システムはそれはそれで普通に使えるけど）

自分で一からつくって言ったほうが、大変ではあるけど楽しいよ。
ぶっちゃけ今でもデフォルトシステムのバトルのあたりとか見てるとわけわかんねー！
ってなるけど自分で組むと（力技だけど）納得いくように作れるんだよな。

**名前は開発中のものです。** · 2008/10/10(金) 21:46:14

ドット絵描くのが上手くいかないぜ……

**名前は開発中のものです。** · 2008/10/10(金) 21:49:58

1から組める力量ある人は是非やるべきと思うけど
ないならないでも面白いのはできるからなー。

ツクールデフォ戦って時点でバカにするのが最近のフリゲスレの風潮だったけど、
純粋に楽しめてる＋自作の手間を知ってると複雑だわ。

というかウディタの場合、デフォキャラやファイアⅠみたいな見本がないから
どう足掻いても試行錯誤が必要になると思う。

**名前は開発中のものです。** · 2008/10/10(金) 21:52:31

システムを考えるのに煮詰まったら素材作ってるなあ
素材作る作業に疲れたらシステム構築に逃げるのエンドレスループ

**名前は開発中のものです。** · 2008/10/10(金) 21:57:38

実際ウディコンでは
基本使ってるのも使ってないのもどっちも凄かったと思うわ

**名前は開発中のものです。** · 2008/10/10(金) 21:59:30

慣れるまでしんどいなあと感じるのがシステム周りの環境変数のアドレスが不明瞭なことかな

タイトル画面でよく使われるであろうセーブデータ有無の判定も
セーブデータ何番の9000024を読み出してセルフ変数へ読み込みっていう処理が必要
これを知らないといつまでたってもとっかかりさえ掴めないっていうね

頻出というかかなり誰でも扱いたがる部分かと思うんだが、これは純粋に覚えなきゃいけないこのエディタ独自の部分であってさ
こういうものを網羅したのが説明書なんだろうけど、どうにも網羅されてる感じがしないのは気のせいか

**名前は開発中のものです。** · 2008/10/10(金) 22:07:56

そういや話は変わるんだけど、最初に定義されてるシステム変数の中に面白いものがあるね
ネット周りの項目なんだけどさ

これがネットワーク対応になったらいいねえ
小規模（2～4人）くらいでネットワークを介してドラクエしたいわ
出来れば直に（P2P）つなげたらサーバーステータスに左右されなくて済むね

**名前は開発中のものです。** · 2008/10/10(金) 22:08:54

アドレスのみで計算できるようになるとかなり楽になる。
だがアドレスのみで計算させてくれないところがちらほらあるのは困り者。

**名前は開発中のものです。** · 2008/10/10(金) 22:13:00

>>791
ですよねー

あと困るのがイベントエディタがコピペできなかったりする細かい使い勝手かな
マップエディタも置いたチップがずれちゃったら一から書き直しなのはこまるね
切って貼ってが出来ない部分が多すぎるのがどうも不都合を感じるかな
使いたいシステム変数ももっと多いし（例えばマップチップだけ交換できたらいいのになど）

でも、このツールは今も更新が滞ってないから単なる愚痴より要望した方がいいかなと思ってる
ここで言ってるだけじゃだめだよね
あとでメールしとくわ

**名前は開発中のものです。** · 2008/10/10(金) 22:16:17

あとコンテストの作品群におしっこちびった
あれ全部ソースを読み解いたらかなり習熟できそうです

特にDragon Tearsっていう作品のソースが美しかったかなあ
コモンイベントの切り分けが明瞭になっててサンプル作品よりわかりやすいです

**名前は開発中のものです。** · 2008/10/10(金) 22:17:43

１つずつならコピペ出来ね？
まぁまとめてしたいけど…言ってる場所違う？

俺はとりあえずDBとかの場所ずらしたら呼出を全部直さなきゃいけないのがめんどう
でもまぁそれは自分で気をつけたりするしかないか

**名前は開発中のものです。** · 2008/10/10(金) 22:19:24

>>794
複数選択もできる

**名前は開発中のものです。** · 2008/10/10(金) 22:20:50

>>794
コピペできるのかあああ
知らなかった
まだ使い始めたばっかりだからわかってない所も多いと思う
ごめん

あと、コモンイベント一切なしでもキー入力はしっかり受け付けてることもさっき知ったよ
そのキー入力判定をどう生かすかがコモンイベントの仕事なんだね

**名前は開発中のものです。** · 2008/10/10(金) 22:25:04

>>796
＞あと、コモンイベント一切なしでもキー入力はしっかり受け付けてることもさっき知ったよ

これの意味が良く分からん。
コモンイベントは「どのマップからでも呼び出せるイベント」以上の意味を持たないが。

**名前は開発中のものです。** · 2008/10/10(金) 22:28:35

>>797
すまん単なるイベントでやる方がいいのか

**名前は開発中のものです。** · 2008/10/10(金) 22:34:17

じゃないな
そういう話じゃなくてあれか

要はこういうことね
最初はサンプルを見ながら改変して仕様を確認してた
でもとてもじゃないが入り組んでてわけがわからないので
作りながら覚えようと思って全部１から作るDATAセットに置き換えて試行錯誤してたんだ

最初は置き換えだからかVer.1.04の仕様か俺の勘違いかわからんけどキー入力が判定されてなかった気がする
しかし1.06に置き換えたら普通に動いてるけど

さっきまでキー入力待ちって処理がキー入力に必要なんだと思ってたほどわけがわかってなかったな
入力関係のカスタマイズは変数があるから気付くけど、操作自体は別にこっちで組む必要がないのな

**名前は開発中のものです。** · 2008/10/10(金) 22:40:48

>>799
ああ、つまりコモンイベントで主人公の動きまで制御してると思ってたってことか

**名前は開発中のものです。** · 2008/10/10(金) 22:47:49

逆に言うと、使うボタンの数とか増やせないだろうし
操作にまつわる制御は全くもってエディタにおまかせ＝仕様ってことでもあるんだろうけどね

今メニュー作ってるけど、メニューが起動してる間はプレイヤーの足を止めてやらないといけないよね
いい加減変数と分岐を使えってことか
簡単な所から作ってきたけどやっぱこういう部分がしんどいなあ

動きのあるオープニングなんかはピクチャ置き換えでアニメーションさせれば楽々なんだけど

**名前は開発中のものです。** · 2008/10/10(金) 22:50:07

>>795　な、なんだってー…試した気がするがたまたま押しミスってたとかか…orz
ありがとう、試してみる！

**名前は開発中のものです。** · 2008/10/10(金) 22:50:36

>>800
そうそう！
上手く言えてなくてごめんね
プログラム経験だけじゃなくてこういうツクール系に不慣れなせいだと思いますｻｰｾﾝ

ピクチャっていう仕様があればおおよそなんでも出来るなあと考えてこのエディタを選んだんですよ
しかし・・・やっぱ数学的素養というかそういうものが必要なんだなあと痛感しています

**名前は開発中のものです。** · 2008/10/10(金) 22:54:25

>>801
イベント実行中なら主人公は動かない
キーボード入力パッド入力を使えばほとんどのキーは使える(同時押しは出来ないけど)
oｏＯ(書き込む前に説明書くらい熟読したらどうだろう)

あと>>802
ヒント:shiftキー
これも説明書良く読んだらのってるけど。

**名前は開発中のものです。** · 2008/10/10(金) 22:58:20

>>804
どうやら離れた所（Ctrl）が出来なかったから複数は出来ないと思い込んでたもよう
今まで一行ずつ行ったり来たりしてたよ…

ま、まさかこれすら思い込みだったりはしないはず…

**名前は開発中のものです。** · 2008/10/10(金) 22:58:31

>>804
動きますよ

キー入力待ちさせて決定顔されたらメニューピクチャを出力
これだけの処理ではキャラが動いてしまいますね
きちんと判定を作ってやらないとダメだと思います

**名前は開発中のものです。** · 2008/10/10(金) 22:59:38

そしてそれは起動条件の問題だと思う

**名前は開発中のものです。** · 2008/10/10(金) 23:24:19

あと問題はメニューピクチャに重ねるカーソルがもし明滅していたらどう処理すればいいかとか
まあ実際に考え中なんですけどね

メニューは若い番号のピクチャを貼って、その上にメニューより大きな番号のピクチャを貼ればいいわけですよね
分岐を使ってキー入力によってピクチャの座標を移動すれば実装は可能…なはずなんですけどね
カーソルの明滅処理をループに頼っていいのかとかそもそもループの書式が明示されてないよとか
ループを抜け出す条件とかどこに書くのとか色々
さらにキー入力は常に待っていないといけなかったりややこしいです

これはフローチャートを書けということか
なつかしいけどちょっとやってみよう

**名前は開発中のものです。** · 2008/10/10(金) 23:31:56

基本システムいじるのって一から作るのより難しく感じるぜ。

**名前は開発中のものです。** · 2008/10/10(金) 23:31:59

>>808
うん、1から作るのも結構だが君はやっぱり基本システム解析した方がいいと思った。
とりあえず今までに上がった問題は基本システムのメニューにまつわる処理部分見れば全て分かる。
ついでに公式過去ログとか、このスレのログとかも見れば十分
知識はあるみたいだからチラ裏みたいに書かずに色々読みながら試行錯誤してみたらどうだろう。

**名前は開発中のものです。** · 2008/10/10(金) 23:35:59

一応主なFAQとか説明書・解説サイトはローカルに保存してありますよ
処理を考える際に毎回読んでいますが、もっと沢山欲しいなあと

学校の授業とかでもそうなんですけど
1つの角度からしか説明を受けないとあまり頭に入らないんですよね
たとえ話とか応用問題とかを経てようやく腑に落ちる

とりあえずネット回線が不安定なので使える時に使っとけみたいのがあるかもわかりません
お目汚し失礼しました

**名前は開発中のものです。** · 2008/10/10(金) 23:42:45

>>801
変数も条件分岐も使わずよくそこまで出来たな
タイトルとかどうやったん？

**名前は開発中のものです。** · 2008/10/10(金) 23:47:06

>>812
タイトルはメニューを作ってる段階ですね

オープニングのアニメーションは普通に頭にウェイトをかけておけば問題なく起動直後からでも動きました
ぶっちゃけピクチャ機能のみですね

**名前は開発中のものです。** · 2008/10/10(金) 23:47:49

写経がオススメ
狼煙様の書いたありがたい基本システムを
読みながら書き写す（ウディタを二つ同時に起動する）

**名前は開発中のものです。** · 2008/10/10(金) 23:55:22

公式にウディコンきてるｗ

**名前は開発中のものです。** · 2008/10/10(金) 23:56:06

アニメーションですと
なんか物凄い物を作ってるんだな

**名前は開発中のものです。** · 2008/10/10(金) 23:58:44

でも躓く所がとても初心者ですよね
まあここからなんとかウディコン作者様のレベルまで自分を持っていければいいなあとか

**名前は開発中のものです。** · 2008/10/11(土) 00:02:05

wikiの結果発表を初めてみたけど味気なさ過ぎないか。
レス全部載せろとは言わないけど、テンプレに沿った感想が結構でたんだからそれだけでも載せない？

**名前は開発中のものです。** · 2008/10/11(土) 00:03:43

アニメーションは凄く簡単なんですよ

ウェイト（まず頭にかけないと起動でこけます）
　↓
１番のピクチャを表示
　↓
ウェイト
　↓
２番のピクチャを表示←この時点で１番のピクチャは２番の裏に隠れてしまいます
　↓
１番のピクチャを消去
　↓
ウェイト
　↓
３番のピクチャを表示
　↓
２番のピクチャを消去

後はこれを終了まで繰り返すというロジックなんですね

**名前は開発中のものです。** · 2008/10/11(土) 00:06:02

パッと見で思っただけだけど、全部１番じゃ困るのかな

**名前は開発中のものです。** · 2008/10/11(土) 00:07:30

いや、システム的な話じゃなくてアニメーション描けるなんて凄いなー、と

**名前は開発中のものです。** · 2008/10/11(土) 00:08:37

>>820
どうなんでしょうねえ
でもこうする方が対応がしやすく、環境依存もしにくいかなとか
書き換えの際にちらつく恐れがあるので僕はこの方法をオススメします

ピクチャ番号は本当のことを言えば１番と２番だけでいいんですが便宜的にこのようにしました

**名前は開発中のものです。** · 2008/10/11(土) 00:11:27

>>821
書いてません＼(^o^)／
コピー作品を作ってるだけです

処理的に面倒になりそうなものはピクチャで代用することにしました
本当はピクチャに頼らなくても可能は可能なんですよね
オートタイルで代用が効いちゃったりするレベルのものです
っていうか実際そっちの方もテストしてますね

**名前は開発中のものです。** · 2008/10/11(土) 00:12:25

>>820
１番張って１番消して１番入れ替えてを繰り返すって事？
それだとガッタガタになるよ
処理は裏で全部やって完成した裏を表にもってくるってのは必須テク

**名前は開発中のものです。** · 2008/10/11(土) 00:15:24

>>823
ああ、ドラクエか
確かにピクチャで代用した方が早そうだね

**名前は開発中のものです。** · 2008/10/11(土) 00:16:07

>>822
書き替えの際にちらつくはないよ。
ピクチャ表示とか移動とかのコマンドは、内部値を書き替えてるだけだから。実際の表示は全ての処理が終わった後で一括してやってるから、1枚のピクチャで書き替えいい。

**名前は開発中のものです。** · 2008/10/11(土) 00:17:02

画面外でやっとけばピクチャ番号は二つで済むか

**名前は開発中のものです。** · 2008/10/11(土) 00:18:50

>>826
なるほどー
参考になります

それは本エディタの仕様なんでしょうかね？
自分は画像処理は明るくないんですが書籍などでは大抵このやり方かと思って

**名前は開発中のものです。** · 2008/10/11(土) 00:21:40

>>828
エディタの仕様だね。
プログラミングやるなら画面の更新停止して描写して画面更新ってのが基本だけど、ウディタのピクチャ表示はピクチャ情報を内部値に格納するだけのコマンドだから描写自体は勝手にやってくれる。

**名前は開発中のものです。** · 2008/10/11(土) 00:25:08

まあ別にソースを覗いた訳じゃないから間違ってる可能性もあるけど、表示したピクチャを後から移動させられることからしても情報が変数に入れられてる事は明らかだし、そう外れた予想じゃないと思う

**名前は開発中のものです。** · 2008/10/11(土) 00:28:54

ごめんなさい
１番と２番だけだと余計なプロセスが増えますね
やっぱ順繰りに送っていった方がスマートなソースになりそうです

何故古い画像を残すのかというと、新しい画像の表示までには僅かなタイムラグがあるんですね
それは古いオンボロマシンみたいな環境で遊ぶユーザにとっては無視できない（もしかしたら視認できるくらいの）
ちらつきになる恐れがあると思ったんですよね

**名前は開発中のものです。** · 2008/10/11(土) 00:32:12

>>831
え、本当にラグある？　だとしたら俺の認識が間違ってるみたいだけど

**名前は開発中のものです。** · 2008/10/11(土) 00:33:07

>>824
なんで１番を消去するんだ？
いったん消去しないとどんどん重なって表示されると思ってるのかもしれないけど、同じピクチャ番号でそのまま表示すれば置き換えられるよ。
それを踏まえて、あとは>>826の通り。

**名前は開発中のものです。** · 2008/10/11(土) 00:33:19

元々メモリにピクチャを格納してあるっていう仕様であるならそれはまた別なのであまり気にしないでくだしあ

おそらく毎時読み込みを行っていると思いますよ
ですからちゃんと消去っていうメモリ開放のコマンドも持っているわけです
ですのでラグが発生しているのは確かだと思います

それが体感できないのは環境が整っているからでしょうね

**名前は開発中のものです。** · 2008/10/11(土) 00:38:29

１番だけで出来ると思ったから言ったんだけど配慮って大切だよね、なるほど
俺も>>833と同じ考えだったんだがとにかく全面的に配慮を意識するようにするよ、ありがと

**名前は開発中のものです。** · 2008/10/11(土) 00:42:38

あ、そか。
そういえば、表示ウェイト入れると、一度ピクチャ消えてから表示されるしね。
めちゃめちゃ弱いPCなら0フレ表示でもラグができるかもしれない。

この機に、いろいろと考えてみることにします。

**名前は開発中のものです。** · 2008/10/11(土) 00:43:34

こちらこそ一度作った処理を改めて考えてみることでさらに理解が深まりました
ありがとうございました

ホントに為になるスレだなあ

**名前は開発中のものです。** · 2008/10/11(土) 00:50:00

1番だけじゃなくて2,3,4・・・としていくのなら

１．必要な数だけ事前に各番号にピクチャをセットし透明表示させておく
２．必要になったピクチャを移動で表示させる
３．不要になったピクチャを移動で透明にする

の方が処理が軽くなるようなキガス。メモリの消費量は無論あれだが
ウェイトがいるかどうかは、各ピクチャの表示させる時間とかその他諸々で決まるだろうけど

**名前は開発中のものです。** · 2008/10/11(土) 00:53:24

>>838
滑らかさを重視する大きなアニメーションなどではそうかもしれないですね
メモリに格納しておく事でカクツキを抑えることが出来そうですね

やっぱ大事なのは発想なんすねー
その発想はなかったです

**名前は開発中のものです。** · 2008/10/11(土) 01:02:25

wikiの第一回ウディコンの欄にテンプレ方式の評価全部載せといた！
抜けがあったらスマン。

つかれた。ねる。

**名前は開発中のものです。** · 2008/10/11(土) 01:03:32

乙！

**名前は開発中のものです。** · 2008/10/11(土) 01:04:29

んー、主観的な予想が入っていることを始めに断っておくよ。あと長文になるかも。

ウディタのピクチャ表示コマンドは、さっきも言った通り変数に情報を格納するだけの物なんだ。
格納された情報を見て、ウディタのプログラムが後は勝手に表示してくれる。
これはメモリ解放に関しても自動でやってくれるから、もう使われてない読込みピクチャ情報があればそれも勝手に解放する。
F8を押したら読込みピクチャ情報を表示できるから確認してみるといいよ。

ピクチャ1を使って画像Aを表示、適当にウェイトして画像Bを表示という操作をする時は、
ピクチャ1の情報を入れる構造体にAの情報が入っていて、そこにBの情報を上書きする
という操作をすればいいだけ。
間に消去コマンドを挟むと、その分2度手間になる。
イベントコマンドを読み込んで操作をするってことはウディタの内部処理より確実に遅いから、消去コマンドは挟まない方がいい。
あと、ピクチャ1枚表示するたびに読込にかかる時間なんて、どんなマシンでもウディタ製ゲームが動く環境ならほぼ確実に1フレームより短い(これにはソースはないけど)。逆に>>838みたいな方法を取るともしかしたら読込みにラグが生まれるかもしれない。
結論としては、タイムラグはピクチャ大量表示とかする訳じゃなければ気にしなくていいよってこと。

**名前は開発中のものです。** · 2008/10/11(土) 01:06:23

フレームバッファってありますよね？
まさにその発想ですよね

自分ならこうですか

画面外に予め数枚のピクチャを読み込んでおく
　↓
絶えずピクチャの読み込みをしながら１番から順に移動表示させ、次のピクチャを表示する際に消去していく

なんかアニメーション系のコモンイベントがWikiとかにありましたけどこういう感じなのかな
変わった処理といえば事前に数枚のピクチャを先読みしておく事でしょうか

おそらく、メモリから消去する事自体はそんなに重い処理ではないと思うんですね
というかむしろ軽いかなって
重いのはファイル読み込みじゃないかと

PNGっていうのは可逆圧縮コーデックなので読み込んだ後にデコードするわけですよね？
その処理負荷がアニメーションに追いつかなくならないように数枚のバッファを取る
これはいい発想だと思います

**名前は開発中のものです。** · 2008/10/11(土) 01:20:07

>>840
乙！
自分がゲーム作る上でも参考になる評価が多いから助かるよ

【ウディタ】WOLF RPGエディター 其の4

【ウディタ】WOLF RPGエディター其の4