【SB】Shooting Game Builder ver9【ｼｭｰﾃｨﾝｸﾞ】

8192*8192ぐらいの無茶なサイズで無ければ大丈夫でしょ



たぶんだけど

>>927
ここやニコニコに依存してない奴はいるだろ。
確か過去スレで紹介されてなかったか？

そら、スレに参加する義務もニコにうぷする義務もないからね

作品をうぷろだに挙げた順に会員番号でも付けていくか

顧問：ＳＢ氏
名誉会員（ハンドル名あり）：Ｓぷ氏、トリフィド氏、バニ氏、わんけ氏、729氏、ＮＳＳ氏など
一般会員（ハンドル名なし）：・・・

メモがエラーになるバグ修正されたけど既に壊れたメモを直すのは無理？

>>951
目安というか、2048*2048が限界。

・・・だったはず。
要検証です。

ビデオカードにより、最大1024ピクセルまで、2の階乗サイズのみなどの制限あり
・・・とのこと

ありがとう！でもせっかく大きなフィールドを手に入れたのに
試しに弾丸とかとか、アニメを作ろうとして挫折したよ(T_T)

>>959
せっかく弾丸素材の提供あったんだから、使ってみたら？

>>960
静止画ではなくて、ちょっとでもアニメーションする弾が良いなぁ〜って
また間を空けて挑戦してみます^^;

あ、それまで素材借りようかな…そうしよう

>>948
タスク表示に限らずプルダウンで表示が出る選択項目は
選択されている状態でホイール動かした時にその選択内容が変わってしまうので
ついうっかりタスクが選択されているものと勘違いしてホイール回して
設定項目が切り替わってしまう事が度々あった。
しかも変わったこと自体に気付きにくい。

>>957
406×2973というキャラを使ってるけど問題なく動いてるよ。

俺も縦1200だったけど動いてた
つーか1024までっての見てびっくりした

ビ・デ・オ・カ・−・ド　によっては・・・なので、
もし配布が前提であれば、2の2乗サイズで1024までにしておいたほうが無難。

相手のグラフィックカードがわからないわけだから・・・

ビルドした後は関係ないのかな
上限1024*1024の環境でそれ以上のサイズを使ったゲームを動かしてほしい

普通はグラボなかったらメモリを
VRAMの代わりにするから基本的に問題はないよん
速度は著しく低下するが

1024*1024越える画像とか使ったこと無いんだけど

画像がでかいからSBの拡縮機能使って小さくします＞＜
とか、
フルHDで作ります！！
とかそんな馬鹿な理由ででかくなってるわけじゃないよな

グリーンインフェルノみたいなのを作ります！！
とかだったらデカくなってもしゃーないかも
まあそれもパーツ分けすれば解決だけどね

>>966
敵のグラフィックが多すぎていいかげん画像わけんの面倒になったから、一枚一枚をできるだけ大きい画像にしてみた

でかすぎて困るから分けるのに・・・

次スレ立てた
http://hibari.2ch.net/test/read.cgi/gamedev/1285327418/
スレタイ、ver10　でいいのか・・・

スレ立て乙
10でいいと思う

>>969
多すぎて管理しきれないより大きい方がいいよ

HD6000系のラデは16384x16384まで対応するんだっけ・・・

2048x2048オーバーの画像を適用しようとしたら
2048x2048の範囲までしか読み取れず
はみ出た部分は描画されなかった？覚えがある

やってみた
　スプライト編集でイメージを取り込み、4分割
　スクリプトでボタン押してパターン番号の変更をつけた自機でテストプレイ
テスト結果
　1024×1024　→　問題なく使用可能（スプライト編集およびデバッグでのテストプレイ）
　2048×2048　→　問題なく使用可能（スプライト編集およびデバッグでのテストプレイ）
テスト環境
　Windows Vista SP1
　Celeron 1.73GHz
　2.5GB
　ATI Radeon Xpress 1250

あんまり問題はないみたい
イメージ取り込みのファイル指定欄の下の「画像のプレビュー画面」をドラッグすると、
画像の全貌が見れることに、はじめて気が付いた or2

検証乙

2048でもグラボがそこそこならいけるんだろうけど
オンボードの人もいるだろうから1024以下で2の累乗が無難なのかな

975だが、、、

3072×3072では、スプライト編集で2048×2048までしかプレビューできず、
3×3で自動分割をしたところ、682×682が9個できた

おそらく、前記環境での最大読み込みサイズは「2048×2048」と思われる

個人的な要望ですまんが、2048×2048の全体像が見れるように、
プレビュー画面を、倍率変更可能にして欲しい
具体例）
　小：256×256の全体像を縮小表示（現在の縮尺）
　中：512×512の全体像を縮小表示
　大：1024×1024の全体像を縮小表示
　特大：2048×2048の全体像を縮小表示（おそらく最大サイズ）

スプライト編集のプレヴューは倍率変更できると思うけど・・・
＋−のボタンで

>>978
orz...　orz...
　orz...　orz...
　　orz...　orz...
プレビュー画面の下にある「-」と「+」ボタンは、プレビューの拡大・縮尺だったのか・・・
　押すたびに、×1/2または×2になる様子

2048×2048以上のサイズの画像は、縮小表示した際に、
2048×2048を超える部分がクリップアウトされていることを確認

要望をする時は十分に調べ吟味するように

まあ、検証してくれただけ良いじゃないの

倍率変更できたのに気が付かなかったのは、単にケアレスだし

そういや信号送信で変数送れるようになってるけど、あれって何の意味があるの？
単に条件分岐を親側でやるか子側でやるかの違いだけに見えるんだけど

たとえば親の向いてる方向と子の向いてる方向を同期させたりとか
少なくともあって困るものでは無い
”見える”だけじゃ分からない。使ってみて初めてその利便性が分かる

信号の便利な点：
・信号送信では加算代入ができるので、カウンタ変数で変数計算のパネルを節約できる
・システム変数を介さずに、変数の保持や受け渡しができるので、親子間やセルフでのフラグ管理がしやすい
・信号受信では受信と同時に分岐できるので、変数の条件分岐のパネルを節約できる

とにかく、フラグ管理やボタン判定の条件分岐などで、省スペースで展開できるのがシグナルの強み
変数を取り込めるようになったので、例えば武器インデックスの参照→条件分岐を親子で共有したり、
やり取りしてるシグナルの中身を変数を介して外へ出力したりできて、便利になったよ

勉強になります

送れるのが即値だけなら、条件分岐してオンオフ的なシグナルを送るのがメインになるんだろうけど、
変数を送れる様になったので、より柔軟な数字の送受信が可能になったということだろうね。

欲を言うならば、シグナルが今受信している値を取り出して送信することが変数を介さないと出来ない
ので、「即値」、「変数」に加え、「受信値」なんかも送れる様になれば、さらに万能って感じはするけど、
まあ、そこまでなくても困らないかも？というのはあるな。

つまり

親：変数が○○だったら信号0-1を送る
子：信号0-1を受信したら分岐

これが

親：変数○○を信号で送る
子：信号が○○だったら分岐

になってパネルが1枚だけ節約できるってことなんだな
たった1枚節約のためにわざわざ変数送信を導入する意味はあったのだろうか
親側で変数が○○かどうかをループで監視してる場合、子にループで信号を送り続けることにならないか？
その間は他の信号送れなくなるよね
それと、子側で変数で受け取って分岐するのと信号の値が○○だったら分岐するのに違いってあるの？

>>983
もちろん使ったうえで言ってるよ
親と子の向き同期は別に信号送信しなくても始めから設定出来るよね

>>987
パネル節約の効果は、分岐が多くなればなるほど、じわじわ効いてくるよ

他の信号は独立してるから送信できるよ
むしろシステム変数はゲーム内共有だから、複数のキャラクタで共有されてしまって、変な挙動して困っていた
信号は親子間では共有だけど、別の親子間には影響しないから、とても使い勝手が良い

逆説的だけど、親子間の向き同期フラグをあえてオフにした上で、あるタイミングになった時だけ、
親子の向きをいずれかの向き（親→子，子→親）に揃えたい時がある

>>986
加算値0で送信すると、受信値がそのままの値で送信されたような？

そうじゃなくて、受信値をシグナルへ代入ってこと？
だったら、ローカル変数パネルで、シグナル→変数で良いかも

かなり初歩的な質問で悪いんだけど、
弾が壁に当たって跳ね返るってどうすればいいの？

>>987
＞親：変数が○○だったら信号0-1を送る
＞子：信号0-1を受信したら分岐

変数の値が1〜100の範囲だったとして、変数が1ならシグナル１を送る
変数が2ならシグナルで2を送る、変数が3ならシグナル3を送る〜〜100なら100

シグナルで送りたい値が0か1かみたいな場合だったらそれでもいいんだろうけど、
親の持ってる変数情報を直接送れた方が、より応用性に富むよね？って話。
分岐でオンオフ的使い方ではなく、変数情報を共有する的使い方。

「システム変数は、キャラクタすべてで同じ数字を共有できる」だけど、
「シグナルは、各親子間毎で同じ数字を共有できる」←この部分がやりやすくなった
といえる。
パネルが１枚節約できるというのは、やりやすくなった部分の一つにすぎないと思う。

＞その間は他の信号送れなくなるよね
なんで？
シグナルナンバーはいくつもあるのだから、他のシグナルを使って送信すればいいんじゃないの？

>>989
＞ローカル変数パネルで、シグナル→変数で良いかも

もちろん、今は変数が送信できるので、それで事足りる。
だけど、それをするために、変数１個を使うってどうなのよ？って意味で。

シグナルってさ、変数を使わなくても計算できるじゃない？でもその計算結果を取り出して
送信するのに変数を使うって、じゃあ初めから変数使って計算すればいいじゃんってことに
なるんだよね。

シグナルって、現在の受信値がなんであれ、送信する毎にその場で指定した「即値」だけしか
送れなかったところが、短所でもあり長所でもあったんだよね。

「変数」を送信できるようになってより柔軟性を増したと思うんだけど、「受信値」を送れるように
なれば、よりシグナルの短所を補える形になると思ったので、「受信値送信」の案を書いた。

＞加算値0で送信すると、受信値がそのままの値で送信されたような？

Ω　Ω＜な、なんだって〜！？

もしそうなら、「受信値送信」はなくてもいいな。
ちょっと試してみるか。

>>990
ろだにサンプルがあった気がする

＞加算値0で送信すると、受信値がそのままの値で送信されたような？

試してみた。

シグナル0に100を受信している子が、親に対してシグナル0を加算0で送信

結果：子のシグナル0受信値「100」は、親に送信されなかった。
　　　　ただ単に、「加算」での「即値0」、いわゆる「+0」が送信された。

自機で試してみたら、自機内のスクリプトでは、加算0で受信値がそのまま送信されていることを確認
Aボタン：送信）代入 0　→受信値に関係なく、常に0が代入される
Bボタン：送信）加算 1　→受信値に、1が加算されて代入される
Xボタン：送信）減算1　→受信値に、1が減算されて代入される
Yボタン：送信）加算 0　→受信値に、0が加算されて代入される（受信値がそのまま代入される）

親子で受け渡しすると変わるのかな？
試してみよう・・・

＞加算0で受信値がそのまま送信されていることを確認

それは、解釈を少し取り違えてないかな？
受信値はそのままで、加算0のみが送信されているってことだと思うんだけど。

すでに受信値が入っている自スクリプト内で、加算が0されても受信値のままってのは、
ある意味当たり前。

その受信値を、他の親や子に受け渡そうと思ったら、なにかの形でその受信値を送信
してやらないといかんでしょ？

現在の受信値に何かの数値が入っているとして、親や子にその受信値そのものを
送信値として送信することは、変数を介さないとできませんよ、って話なんだけども。

親（自機）と子の間でやってみた
シグナル→ローカル変数→システム変数にして、デバッグウインドウで確認

親（自機）
　信号送信：子へシグナルに加算1
　→�@親のシグナルを確認すると0のまま

子
　→�A子のシグナルを確認すると1,2,3,4・・・と増えていく
　信号送信：子へシグナルに加算1
　→�B子のシグナルを確認すると�Aの時のままで変わりなし

親（自機）
　→�C親のシグナルを確認すると、子とは独立して1,2,3,4・・・と増えていく

>>986，>>996
確かに、解釈が間違っていたよう・・・

確実に言える事実：
・親と子では同じシグナルでも独立している
　「親→子」で受け取った「子のシグナル」，「子→親」で受け取った「親のシグナル」は共有されていない
・信号送信の加算は、現在のシグナルの値とは無関係
　前回送信したシグナルの値に加算される

確かに、受信値を送信することは、通常（信号パネル送受信のみでは）できない
セルフで信号を受信している場合は、受信値ではなく、前回の送信値に加算が行われているだけ
親と子では同じシグナルでも独立している（お互いにすれ違いで送りっぱなしの状態）

>>997で間違いあり訂正
（誤）
＞子
＞　→�A子のシグナルを確認すると1,2,3,4・・・と増えていく
＞　信号送信：子へシグナルに加算1
＞　→�B子のシグナルを確認すると�Aの時のままで変わりなし
（正）
子
　→�A子のシグナルを確認すると1,2,3,4・・・と増えていく
　信号送信：親へシグナルに加算1
　→�B子のシグナルを確認すると�Aの時のままで変わりなし

1000get

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。