09/08/09 01:44:05 Y/yZrPUf
>>322
ゲェー最近はVIPツクスレも見てるからプレイしたことあります
画面スクロールを使えばピクチャなしで
1ドットスクロールできるというのに驚かされた
ピクチャだと縦横同時にはできてもマップはもちろん敵などのイベントも
ピクチャで表示しないといけないのが面倒 ピクチャ枚数も厳しいし
ともかくツクールでロックマンゲ期待
324:287
09/08/09 18:31:16 dz2sSA8R
>>322
やっぱりイベント呼び出しは重いのか。。
この際敵の行動や配置もテーブルで作ろうかと思った
あと1ドットスクロールの作者様だったのかー、驚きだ
未だにどうやってやってるのか分からんw
自分もロックマンゲ期待
325:名前は開発中のものです。
09/08/09 19:20:40 Q40t2ezq
>>323
なんと!既に見ていたか(^o^)スマン
>>319
まだ気になる部分があったので、追加します↓
当たり判定の処理にコストをかけすぎだと思う。
四角形の判定は大変。円形の判定ならずっと節約できる。
自分は円形の判定を使ってる。まあ、四角形の判定に何か
こだわりがあるならしょうがないけど。
あと、ポーズの処理が良くない。色々なところでポーズ用の条件分岐を
つけてラベルで飛ばしてるけど、そんなことする必要は無い。
定期的処理の中で「文章の表示」を使うと、その定期的処理は
「文章の表示」でせき止められて先へ進めないから、これを利用する。
326:名前は開発中のものです。
09/08/09 19:25:23 Q40t2ezq
たとえば、3つのコモンイベントcommon0,common1,common2を
それぞれ定期的処理で回すときは、次のように組む。
var stopID=0;
funcion common0(){
if(stopID!=0){return;}
処理;
stopID=1;
}
funcion common1(){
if(stopID!=1){return;}
処理;
stopID=2;
}
funcion common2(){
if(stopID!=2){return;}
処理;
stopID=0;
}
要するに、各コモンイベントの先頭にif(stopID!=**){return;}をつけて、
末尾にはstopID=***;をつける。
こうすると、1つの大きな定期的処理を回しているのと同じことになる。
この状態で、common0~common2のどこでもいいから「文章の表示」を
入れてやると、この文章が出ている間は、どのコモンイベントも動かない。
つまり、ポーズ用の処理が要らない。単純に「文章の表示」をするだけでいい。
327:名前は開発中のものです。
09/08/09 19:38:28 Q40t2ezq
ちなみに、この組み方をすると
・各コモンイベントの間で、処理の順番がズレることが無い。
・各コモンイベントそれぞれが10000ステップまで処理できる(実験済み)。
というメリットがある。
特筆すべきようなデメリットは、今のところ見つかってない。
でも何か落とし穴があるかもしれない(^o^)
次は注意点。この組み方を使うときは、コモンイベントを作る順番に注意が必要。
定期的処理のコモンイベントを複数個作ると、上から順番に処理される。
従って、たとえば次のような順番で組んではいけない。
common1
common0
common2
この順番で組むと、
・最初のフレームではcommon0だけが実行される。
・次のフレームではcommon1,common2が実行される。
という挙動になってしまい、処理が2フレームに
分散してしまう(スローモーションになる)。
328:287
09/08/10 10:38:01 CWNSd8zx
>>325-327
当たり判定は四角より円形のほうが良いのか、意外だった。やってみる
ポーズの処理は訳があって、
文章の表示はピクチャーの回転を止められないという罠があったりする。
それで、わざわざ全部の弾を回転速度0で更新させる処理を入れてある。
(多分>>311では直ってなくて悲惨…
それと並列処理は分割しても全然大丈夫だったのか、かなり参考になった。
329: ◆vipRGqvJxg
09/08/10 18:32:38 Btld7FHe
定期的に並列処理のコモンイベントはマップイベントとは違って
スイッチOFF、ONすると、スイッチOFFで中断されたところから処理が再開されるから、
ポーズの処理は
スイッチOFF→回転速度を0で更新するイベント呼び出し→文章の表示とか→スイッチON
でなんとかならないかな
330:287
09/08/10 21:47:52 CWNSd8zx
>>329
その方法は、回転速度だけ変える処理を組むのが面倒臭くて遠ざけてたけど、やっぱり少しでも軽くするには必要かー。やってみる。
いつもアドバイス頂いてばかりで申し訳ないです
あと、これからしばらく書き込み停止します。
いろいろすみません。。
完成したらまたアップさせて頂きます。
来年とかになりそうだ。
331:名前は開発中のものです。
09/08/11 00:31:24 iy4ey55s
携帯から失礼。
>>328
なんと、それは盲点だった(^q^)
>>329
定期的処理のコモンイベントは、その中身の行数が多いと、
そのコモンイベントの出現条件に登録したスイッチのON・OFFが重くなる。
つまり、 ポーズをかけるとき・ポーズを解除するとき に一瞬もっさりする(はず)。
まあ、あまり気にならないけど。
332:名前は開発中のものです。
09/10/04 12:47:29 K0q9ZJCw
剣シリーズマダー(´・∀・`)
333: ◆vipRGqvJxg
09/10/05 02:02:04 dvGQH5Ga
剣6途中までを出した後に作りたいゲームが増えちゃって中々続きが作れてないです
申し訳ないことだけど今年中は他に一つ気合い入れて作ってるゲームがあるので出せそうにない
ところで改めてハードのダークエルフと戦ってみたけど正直強くしすぎたなと反省
味方がしょっちゅう黒く点滅するの前提な強さに調整してたから
全く黒くならない場合が運ゲーすぎる
続き作るときにはマシにしておこうと思う
334: ◆vipRGqvJxg
09/10/13 22:31:03 AvdNBFFY
制作中のゲームでよくある、制作進行度の
シナリオ~%、システム~%等の数字ってどうやって決めているのか気になる
335:名前は開発中のものです。
09/10/14 23:01:20 4fzKb1Jj
>>334
ようやく作業に入った→10%以下
なんとなく半分くらいできた気がする→50%前後
もうすぐ完成しそうな気がしてきた→85%以上
あんなの実際には本人にとっても気分でしかない
336: ◆vipRGqvJxg
09/12/11 22:57:50 edUTlX9i
カービィ150体やったけど、マップイベント減らすと重さが随分と違うのか
早速減らしてみようかな
337: ◆vipRGqvJxg
09/12/11 23:33:33 edUTlX9i
やっべえ面倒くさい
でも反復作業ほど何故かはかどる
338:名前は開発中のものです。
09/12/13 00:01:24 jeo8vMu2
点滅しすぎてよくわからなかったら、もう一度自分で組んでやってみたら
12-13kあたりで微妙に重力がかかり始めていたかもしれない(気付くか気づかないかくらい)
Turion 64 X2 TL-52 1.6 GHz / メモリ2Gのメーカーノート使って
もう一度カビやってみたら100くらいからやっぱり怪しくなり始めた、かも
マップイベントだと問答無用で10kステップでウェイトかかるのかな、
マップイベント定期で各処理順番制御したけど、ダメだった
339: ◆vipRGqvJxg
09/12/20 16:04:02 VaIsBILu
ステージの雑魚敵配置が意外と難しい
こうもりさんの中冒険は初見殺しが多いけどステージの構成がしっかりしてていいなあ
340:名前は開発中のものです。
09/12/23 23:17:09 +9Zh+Ea+
>>338
・作り方を間違えて、1万ステップの壁で遮断されている
・1万ステップは突破できてるけど、PCのスペックが不足している
のどちらかだと思います。自分の環境では、
マップイベントでも1万ステップを突破できます。
でも、自分はマップイベントでは定期的処理しません。
txtに書いたとおり、1万ステップを超えると、
マップイベント1個でも大きな負荷になります。
341: ◆vipRGqvJxg
09/12/25 19:30:00 yfXopFh9
>>340
スイッチ発動条件ありのコモン定期的処理増やしても負荷ってそんな増えないかな?
大丈夫そうなら今作ってるゲームのマップイベントを全部コモンにしようかなって思う
ラスボス作る時間ねええええ
342:名前は開発中のものです。
09/12/25 21:53:47 OPvmO1i9
>>341
問題ないです。
最初の1回目の起動だけ、一瞬だけ重くなって、
その後は全く重さに影響しません。
例:
スイッチ1で起動するコモン定期的処理を作る。
↓
スイッチ1をオンにする。オンにした瞬間だけ重くなる。(注1)
↓
その後、1をオフにする。
↓
さらにその後、1をオンにする。今度は、オンにした瞬間も重くない。
注1:どのくらい重くなるかは、中身の行数によって変わる。
行数が多いほど重くなる(イベント呼び出しに似てる)。
以前、10万行のコモンイベントで実験したら、起動するのに
1秒くらいフリーズした。その後は、何回起動しても一瞬で
起動できた。
343:名前は開発中のものです。
10/01/16 23:08:06 0LnkaQ7N
あら、じゃあイベント記述にミスがあったかなあ
イベント破棄してしまったし、自分も最近のプロジェクトでマップイベントは
初期値設定にしか使っていないから再実験は……いいか
重さと言えば、イベントの呼び出しが知れば知るほどきついものなんだなあと。
自分の環境だと重さが、
呼出1000行+15500step≒呼出3000行+8500stepとかに。
(↑正直PC環境で左右されまくりで殆ど参考にならないけど……)
とりあえず進行中のものは1000行/fr位まで呼び出しても問題ないだろうと結論付けたけど
やっぱり投下時には呼び出し元に行を統合したいところ。