背景の素材が・・
Re:背景の素材が・・
匿名さん、こんにちは。
龍神録参考にしていただいて光栄です^^
道中の背景は私も困りました。
私も散々探したのですが、得た答えが「素材はウェブに無い」でした。
簡単な素材やちょこっとした素材はあるでしょうが、そのまま背景に使えそうなかつ、クオリティが高いものは見つけられませんでした。
ということで、自作した方が早そうです。
私は画力が無く苦労したのですが、写真を見ながら四苦八苦すればそれなりになんとかなったりするかもしれません。
龍神録ファンタズムの桜なんかは写真を見ながら書いていきました(違うレイヤーに写真をおいておき、その上から書いていく感じです)
また、ただ単に描画しただけでは全く見栄えのしない素材を描画の方法で映えさせるというのも手です。
見栄えがしているかどうかはわかりませんが、ファンタズムのボスの背景はただ単に白のグラデーションがかかっただけの画像を様々な色にしたりブレンド方法を変えたりして描画し、映えるようにしています。
後、単体ではクオリティの低い画像も、何か装飾を施すことで見栄えがするようにもなります。
これも見栄えがしているかどうかはわかりませんが、例えばサンプルプログラミングの館の川のサンプルをご覧いただけたら解ると思いますが、
川の画像だけでは見栄えがしませんが、キラメキを入れてやることで少し見栄えが上がるのでは無いかと思います。
そんな感じで変に探し回るより、大変ではあれど自作していく方針の方が良さそうな気がします。
龍神録参考にしていただいて光栄です^^
道中の背景は私も困りました。
私も散々探したのですが、得た答えが「素材はウェブに無い」でした。
簡単な素材やちょこっとした素材はあるでしょうが、そのまま背景に使えそうなかつ、クオリティが高いものは見つけられませんでした。
ということで、自作した方が早そうです。
私は画力が無く苦労したのですが、写真を見ながら四苦八苦すればそれなりになんとかなったりするかもしれません。
龍神録ファンタズムの桜なんかは写真を見ながら書いていきました(違うレイヤーに写真をおいておき、その上から書いていく感じです)
また、ただ単に描画しただけでは全く見栄えのしない素材を描画の方法で映えさせるというのも手です。
見栄えがしているかどうかはわかりませんが、ファンタズムのボスの背景はただ単に白のグラデーションがかかっただけの画像を様々な色にしたりブレンド方法を変えたりして描画し、映えるようにしています。
後、単体ではクオリティの低い画像も、何か装飾を施すことで見栄えがするようにもなります。
これも見栄えがしているかどうかはわかりませんが、例えばサンプルプログラミングの館の川のサンプルをご覧いただけたら解ると思いますが、
川の画像だけでは見栄えがしませんが、キラメキを入れてやることで少し見栄えが上がるのでは無いかと思います。
そんな感じで変に探し回るより、大変ではあれど自作していく方針の方が良さそうな気がします。
Re:背景の素材が・・
確かに自作した方がよさそうですね、
少し頑張ってみます。
あと、キラメキで思い出したんですが龍神録では背景に落ち葉が舞っていますよね、
私もあれをやってみようと思ったんですが、落ち葉を自然な位置に出現させるのがうまくできません、
他のエフェクトもうまく登録できないんです。
龍神録の "背景の落ち葉のエフェクト" "ボスの攻撃前の白い落ち葉が集まるエフェクト" "アイシャが変身する時に飛び散る落ち葉のエフェクト" の処理をどうやっているか教えていただけないでしょうか?
少し頑張ってみます。
あと、キラメキで思い出したんですが龍神録では背景に落ち葉が舞っていますよね、
私もあれをやってみようと思ったんですが、落ち葉を自然な位置に出現させるのがうまくできません、
他のエフェクトもうまく登録できないんです。
龍神録の "背景の落ち葉のエフェクト" "ボスの攻撃前の白い落ち葉が集まるエフェクト" "アイシャが変身する時に飛び散る落ち葉のエフェクト" の処理をどうやっているか教えていただけないでしょうか?
Re:背景の素材が・・
落ち葉の舞わせ方ですが、特にこれといった方法があるわけではなく、適当に舞わせてます。
私が取っている方法を下に書きますが、別にコレじゃなくてもいいと思います。
まず、青い部分が画面部分だと思って下さい。茶色の部分は画面外です。

この茶色の部分に均等でありつつランダムな位置に分布させます。
ある角度で斜め下方向に移動させ、
X座標が画面左に差し掛かったら、Y座標はそのままで、茶色の右端へ移動させます。
Y座標が画面下に差し掛かったら、X座標はそのままで、茶色の上端へ移動させます。
この繰り返しです。スピードやサイズを最初に均等なランダムに設定するので、最初の座標は偏っていますがすぐいい感じにばらけてくれます。
別にこんな事しなくても、画面の中にランダムに分布させ、適当に斜め下方向に舞わせ、
画面端まで来たら上とか右とかに戻せばいいだけの話です。
上の方法は色々試した結果これがいいと思ったので採用しましたが、見た目対して違いません。
画面外の葉っぱの計算量が無駄に増える分こちらではない方がいいかもしれません。
で、「均等かつランダム」という矛盾した日本語を使いましたが、
例えば400ピクセル幅の中に40個葉っぱを舞わせようと、単純に
とすると、偏る可能性があります。
極端な話、全部左よりや右よりに来る可能性もあります。
しかし、乱数で生成される座標範囲を小さくして、中心座標をずらしながら決定すれば
「想定された乱数」が作れます。
例えば
こんな感じですね。
こんな感じで散らばらせるといいと思いますよ。
私が取っている方法を下に書きますが、別にコレじゃなくてもいいと思います。
まず、青い部分が画面部分だと思って下さい。茶色の部分は画面外です。
この茶色の部分に均等でありつつランダムな位置に分布させます。
ある角度で斜め下方向に移動させ、
X座標が画面左に差し掛かったら、Y座標はそのままで、茶色の右端へ移動させます。
Y座標が画面下に差し掛かったら、X座標はそのままで、茶色の上端へ移動させます。
この繰り返しです。スピードやサイズを最初に均等なランダムに設定するので、最初の座標は偏っていますがすぐいい感じにばらけてくれます。
別にこんな事しなくても、画面の中にランダムに分布させ、適当に斜め下方向に舞わせ、
画面端まで来たら上とか右とかに戻せばいいだけの話です。
上の方法は色々試した結果これがいいと思ったので採用しましたが、見た目対して違いません。
画面外の葉っぱの計算量が無駄に増える分こちらではない方がいいかもしれません。
で、「均等かつランダム」という矛盾した日本語を使いましたが、
例えば400ピクセル幅の中に40個葉っぱを舞わせようと、単純に
for( i=0; i<40; i++){ -.x = GetRand(400); }
とすると、偏る可能性があります。
極端な話、全部左よりや右よりに来る可能性もあります。
しかし、乱数で生成される座標範囲を小さくして、中心座標をずらしながら決定すれば
「想定された乱数」が作れます。
例えば
for( i= 0; i<10; i++){ -.x = GetRand(100) + 0; } for( i=10; i<20; i++){ -.x = GetRand(100) + 100; } for( i=20; i<30; i++){ -.x = GetRand(100) + 200; } for( i=30; i<40; i++){ -.x = GetRand(100) + 300; } こうすれば、少なくとも4領域に均等に10個ずつ散らばります。 0~100のピクセル内に10個 100~200のピクセル内に10個 200~300のピクセル内に10個 300~400のピクセル内に10個
こんな感じですね。
こんな感じで散らばらせるといいと思いますよ。
Re:背景の素材が・・
あ~なるほど
画面端まで来たら上とか右とかに戻す!!
私にはこの発想がありませんでした
画面端まで来たら、後は消すしか無いと思っていましたから・・
これはかなり参考になりました。
ところで少し話が変わりますけど
龍神録では一度に最大で何発の弾が出ているんでしょうか?
私は弾のアルゴリズムもまだ未確定な状態なので
とりあえずザコ敵の弾もボスの弾も一つの構造体配列で表現しているんですが
その構造体配列を50000個用意しています。
弾は被弾した時とかにアイテムに変わるので
アイテムの構造体配列も50000個用意しているんですが
さすがにこれは多いので一度減らして
弾の多い弾幕を作ったらまた増やそうと思うのですが
参考にしたいので龍神録での最大数を教えてください。
即席で作ったのでアイテムも敵の弾と同じ構造体を使っているんです・・
FPSが60にならない時があるんですが多分これのせいです。
明日あたりに直そうと思います・・
画面端まで来たら上とか右とかに戻す!!
私にはこの発想がありませんでした
画面端まで来たら、後は消すしか無いと思っていましたから・・
これはかなり参考になりました。
ところで少し話が変わりますけど
龍神録では一度に最大で何発の弾が出ているんでしょうか?
私は弾のアルゴリズムもまだ未確定な状態なので
とりあえずザコ敵の弾もボスの弾も一つの構造体配列で表現しているんですが
その構造体配列を50000個用意しています。
弾は被弾した時とかにアイテムに変わるので
アイテムの構造体配列も50000個用意しているんですが
さすがにこれは多いので一度減らして
弾の多い弾幕を作ったらまた増やそうと思うのですが
参考にしたいので龍神録での最大数を教えてください。
即席で作ったのでアイテムも敵の弾と同じ構造体を使っているんです・・
FPSが60にならない時があるんですが多分これのせいです。
明日あたりに直そうと思います・・
Re:背景の素材が・・
龍神録の館の方では以下の通りでした。
#define SHOT_BULLET_MAX 1000 //shot1つに対しての弾の数
#define SHOT_MAX 30 //shotの数
つまり、最大でも1000*30で30000発が表示可能ですね。(多分;
一方ボスは
#define BOSS_BULLET_MAX 3000 //3000発
でした。
しかし、最大30000発ですが、
こんなに弾を表示すると酷く弾が重なるか、画面が弾で覆い尽くされてしまうので
(添付画像が極端な例です。ちなみに6890発表示させています。)
実際に画面に表示する弾は3000発以下ぐらいで良いと思います。(東方系は
つまりボスの弾数ですね。
そんな制約は嫌だ!と感じたらメモリを動的に確保することをお勧めします。
#define SHOT_BULLET_MAX 1000 //shot1つに対しての弾の数
#define SHOT_MAX 30 //shotの数
つまり、最大でも1000*30で30000発が表示可能ですね。(多分;
一方ボスは
#define BOSS_BULLET_MAX 3000 //3000発
でした。
しかし、最大30000発ですが、
こんなに弾を表示すると酷く弾が重なるか、画面が弾で覆い尽くされてしまうので
(添付画像が極端な例です。ちなみに6890発表示させています。)
実際に画面に表示する弾は3000発以下ぐらいで良いと思います。(東方系は
つまりボスの弾数ですね。
そんな制約は嫌だ!と感じたらメモリを動的に確保することをお勧めします。
Re:背景の素材が・・
C++なら
vector等が便利ではないでしょうか・・・
(標準テンプレートライブラリで検索するとたくさん出てきます)
あまり使ったことが無いので詳しくは分からないのですが;
自分の場合は使ってみたら処理が若干重くなったのでただの配列に戻しました orz
何か間違えていたのかな~・・・
vector等が便利ではないでしょうか・・・
(標準テンプレートライブラリで検索するとたくさん出てきます)
あまり使ったことが無いので詳しくは分からないのですが;
自分の場合は使ってみたら処理が若干重くなったのでただの配列に戻しました orz
何か間違えていたのかな~・・・
Re:背景の素材が・・
>龍神録では一度に最大で何発の弾が出ているんでしょうか?
どの弾幕のことか教えていただければお答えしますよ。
しかし、結構な量出ているように見える弾も実はそうでもないことが多いです。

ファンタズムラストのこの弾幕、結構弾が出ているように見えますが、せいぜい数百だと思います。

この花火も恐らく数百だと思います。
龍神録で一番弾数が多いのはやはり通常ステージラストのこの瞬間です。

これは龍神録が計算出来る上限ピッタリになるようになっています。
4000位です。
しかしこの量を表示すると古いPCではまともに動かないようです。
4000も出すとわけがわからなくなるので、
この弾幕のように事前にチョン避けで避けられることを示していないような弾幕で
4000も出す必要はまず無いと思います。
しかし数だけでは言えない事があります。
弾が小さければ数が多くても多く見えないことがあります。例えば

このAA弾幕シリーズはどれも1000以上です。
4000個使っているAAもあります。
しかしそこまで密集しているように見えませんし、処理オチもしません。
ですから、遅くなる原因は軌道計算ではなく、描画関係なんですよね。
小さい弾なら少々量が多くなっても処理オチしません。
ただAA弾幕は特殊ですから、考慮しなくてもいいかもしれません。
上の通常ラスト弾幕で使っている弾は小さめの弾で、あの弾でこれだけ密集してみえるので、
2000も用意しておけば充分だと思いますよ。
動的確保はmallocを使ったリスト構造を使ったらどうでしょうか。
「線形リスト」って単語で調べれば出てきます。
後、匿名さんのお名前をお使いの方が複数いらっしゃるようですので、
もう少し独特な名前をお使いになってはいかがでしょう?
万一同じ名前の違う方が以前質問した内容と同じ内容を質問したりすると
「前にも言ったじゃん!」と思われたりと何かと不都合があると思いますので。
どの弾幕のことか教えていただければお答えしますよ。
しかし、結構な量出ているように見える弾も実はそうでもないことが多いです。
ファンタズムラストのこの弾幕、結構弾が出ているように見えますが、せいぜい数百だと思います。
この花火も恐らく数百だと思います。
龍神録で一番弾数が多いのはやはり通常ステージラストのこの瞬間です。
これは龍神録が計算出来る上限ピッタリになるようになっています。
4000位です。
しかしこの量を表示すると古いPCではまともに動かないようです。
4000も出すとわけがわからなくなるので、
この弾幕のように事前にチョン避けで避けられることを示していないような弾幕で
4000も出す必要はまず無いと思います。
しかし数だけでは言えない事があります。
弾が小さければ数が多くても多く見えないことがあります。例えば
このAA弾幕シリーズはどれも1000以上です。
4000個使っているAAもあります。
しかしそこまで密集しているように見えませんし、処理オチもしません。
ですから、遅くなる原因は軌道計算ではなく、描画関係なんですよね。
小さい弾なら少々量が多くなっても処理オチしません。
ただAA弾幕は特殊ですから、考慮しなくてもいいかもしれません。
上の通常ラスト弾幕で使っている弾は小さめの弾で、あの弾でこれだけ密集してみえるので、
2000も用意しておけば充分だと思いますよ。
動的確保はmallocを使ったリスト構造を使ったらどうでしょうか。
「線形リスト」って単語で調べれば出てきます。
後、匿名さんのお名前をお使いの方が複数いらっしゃるようですので、
もう少し独特な名前をお使いになってはいかがでしょう?
万一同じ名前の違う方が以前質問した内容と同じ内容を質問したりすると
「前にも言ったじゃん!」と思われたりと何かと不都合があると思いますので。
Re:背景の素材が・・
なるほど、弾の大きさの方が問題なんですね。
AA弾幕はうまくなってから作って見るとして
今は2000ぐらいでやってみます。
って言うか確かに匿名って紛らわしいですね・・
では私は学校でチルチルと呼ばれているので
次からチルチルで行きます。
すぐに「ぴよぴよ」から「上級者」まで昇進しますよ~
AA弾幕はうまくなってから作って見るとして
今は2000ぐらいでやってみます。
って言うか確かに匿名って紛らわしいですね・・
では私は学校でチルチルと呼ばれているので
次からチルチルで行きます。
すぐに「ぴよぴよ」から「上級者」まで昇進しますよ~
Re:背景の素材が・・
匿名改めチルチルです
私思ったんですが構造体のメンバって
容量を小さくした方がいいんでしょうか?
例えば弾のフラグですが、フラグって普通
0と1しかありませんからunsigned char型
とかでいいような気もするんですが
私の場合はフラグが2になる時もあるんですが
どっちにしても1バイトで事足りるわけですが
そこまで容量を小さくする必要があるんでしょうか?
何かint型が一番処理が早いって言うし
あとchar型ってもともと1バイトですけど
unsigned char型にすると何か変わるんですか?
私思ったんですが構造体のメンバって
容量を小さくした方がいいんでしょうか?
例えば弾のフラグですが、フラグって普通
0と1しかありませんからunsigned char型
とかでいいような気もするんですが
私の場合はフラグが2になる時もあるんですが
どっちにしても1バイトで事足りるわけですが
そこまで容量を小さくする必要があるんでしょうか?
何かint型が一番処理が早いって言うし
あとchar型ってもともと1バイトですけど
unsigned char型にすると何か変わるんですか?
Re:背景の素材が・・
よければ今までのポイント計算して加算しますよ。
後、チルチルさんは、Jさんとは別の方ですか?
メンバは小さくしていいと思います。
私の場合、charを使うと文字を扱うのでは?と誤解されると思ったのでintにしました。
windows環境ならBYTEでもいいですね。
なお、unsignedはマイナスがありませんから、マイナスを扱わない時はこちらにします。
後、チルチルさんは、Jさんとは別の方ですか?
メンバは小さくしていいと思います。
私の場合、charを使うと文字を扱うのでは?と誤解されると思ったのでintにしました。
windows環境ならBYTEでもいいですね。
なお、unsignedはマイナスがありませんから、マイナスを扱わない時はこちらにします。
Re:背景の素材が・・
加算してくださるんですか
ありがたいです、ぜひお願いします。
あと私はJさんとは別です。
unsignedを付けるとマイナスが無くなるんですね
って事は容量が軽くなるわけではないんですね
ありがたいです、ぜひお願いします。
あと私はJさんとは別です。
unsignedを付けるとマイナスが無くなるんですね
って事は容量が軽くなるわけではないんですね
Re:背景の素材が・・
そうでしたか、失礼致しました。
あと、お名前が改名して投稿されていないようですが・・^^;
unsignedをつけることで容量は変わりません。両方1バイトです。
スコアみたいにマイナスにならないものにはきちんとunsignedを付けて万一マイナスになったときの対処をしておかないと
龍神録のようなバグが起こります(ぇ
(参考:動画の最後 [nico]http://www.nicovideo.jp/watch/sm3031402[/nico])
あと、お名前が改名して投稿されていないようですが・・^^;
unsignedをつけることで容量は変わりません。両方1バイトです。
スコアみたいにマイナスにならないものにはきちんとunsignedを付けて万一マイナスになったときの対処をしておかないと
龍神録のようなバグが起こります(ぇ
(参考:動画の最後 [nico]http://www.nicovideo.jp/watch/sm3031402[/nico])
Re:背景の素材が・・
そうですね、投稿者が匿名になっているので
匿名にしておきましたが、途中に書いてあるから
大丈夫ですね・・
ちょっと表題からずれてきているんで
そろそろ解決にしようと思いますが
最後に質問を二つ
unsignedを付けた変数に負の数を代入するとどうなるんですか?
龍神録の弾幕名は大変すばらしいですが、何か考えるコツでもあるんでしょうか?
匿名にしておきましたが、途中に書いてあるから
大丈夫ですね・・
ちょっと表題からずれてきているんで
そろそろ解決にしようと思いますが
最後に質問を二つ
unsignedを付けた変数に負の数を代入するとどうなるんですか?
龍神録の弾幕名は大変すばらしいですが、何か考えるコツでもあるんでしょうか?
Re:背景の素材が・・
すみません、もう二つ
ステージ最初とボス出現時にBGMを読み込んでいるんですが、そこで処理が止まるんです。
龍神録でも同じように読み込んでいるようですが、見た目には止まっていません、
何か工夫をしているんでしょうか?
今のように複数の質問をする場合には一つのスレッドにまとめた方がいいんでしょうか?
それとも質問ごとにスレッドを立てた方がいいですか?
1人で3~4スレッド占領するのはちょっと・・
ステージ最初とボス出現時にBGMを読み込んでいるんですが、そこで処理が止まるんです。
龍神録でも同じように読み込んでいるようですが、見た目には止まっていません、
何か工夫をしているんでしょうか?
今のように複数の質問をする場合には一つのスレッドにまとめた方がいいんでしょうか?
それとも質問ごとにスレッドを立てた方がいいですか?
1人で3~4スレッド占領するのはちょっと・・
Re:背景の素材が・・
>unsignedを付けた変数に負の数を代入するとどうなるんですか?
どうなるかは実際にやってみるといいですよ。
疑問に思ったらまずやってみると、人から聞くより覚えがいいです。
>弾幕名
いや良くない・・、むしろありえないでしょう^^;
弾幕名つけるのはセンスなくて困りました~;
ファンタズムなんかは人に名前付けてもらうの任せましたしね^^;
これは何ともアドバイスできません、すみません・・。
>BGM
BGMを全部メモリに展開するとメモリの使用量もあがるし、読み込みに時間かかりますよね。
ですから、ストリーミング再生すればいいです。
メモリに展開しながら再生するって方法で、使った端から解放します。
参考にどうぞ
http://homepage2.nifty.com/natupaji/DxL ... tml#R15N25
>トピック
1トピック1質問が後から見る人の為にも見易いので、
トピは分けてもらったほうがありがたいですが、
トピを立てるほどのことでもない小さな疑問なんかは連続で聞いてもらっても大丈夫です。
ただ、なるべく1質問1トピがいいかなとは思います。
どうなるかは実際にやってみるといいですよ。
疑問に思ったらまずやってみると、人から聞くより覚えがいいです。
>弾幕名
いや良くない・・、むしろありえないでしょう^^;
弾幕名つけるのはセンスなくて困りました~;
ファンタズムなんかは人に名前付けてもらうの任せましたしね^^;
これは何ともアドバイスできません、すみません・・。
>BGM
BGMを全部メモリに展開するとメモリの使用量もあがるし、読み込みに時間かかりますよね。
ですから、ストリーミング再生すればいいです。
メモリに展開しながら再生するって方法で、使った端から解放します。
参考にどうぞ
http://homepage2.nifty.com/natupaji/DxL ... tml#R15N25
>トピック
1トピック1質問が後から見る人の為にも見易いので、
トピは分けてもらったほうがありがたいですが、
トピを立てるほどのことでもない小さな疑問なんかは連続で聞いてもらっても大丈夫です。
ただ、なるべく1質問1トピがいいかなとは思います。
Re:背景の素材が・・
>unsignedを付けた変数に負の数を代入するとどうなるんですか?
そうですね、実際にやってみます。
>弾幕名
って事は自分ではダメだと思っていても他の人が見ればそんなにダメじゃ無いって事・・かな?
>BGM
隣のトビでも同じ話題になってしまいましたが
龍神録でもそうしているなら問題なさそうですね
でも使った端から解放するって事は
DeleteSoundMem関数を使わないで
同じ変数にBGMを読み込んでも大丈夫って事でしょうか?
>トピック
解決にするって言いましたけど
小さな疑問が一つできてしまったので
もう一つお願いします。
龍神録のボスの2番目の魔方陣が赤~黄~緑~青って変化していますよね
私もあれをやってみたいんですが魔方陣の色を変化させる処理が思いつかないんです。
どうやっているか教えていただけないでしょうか?
そうですね、実際にやってみます。
>弾幕名
って事は自分ではダメだと思っていても他の人が見ればそんなにダメじゃ無いって事・・かな?
>BGM
隣のトビでも同じ話題になってしまいましたが
龍神録でもそうしているなら問題なさそうですね
でも使った端から解放するって事は
DeleteSoundMem関数を使わないで
同じ変数にBGMを読み込んでも大丈夫って事でしょうか?
>トピック
解決にするって言いましたけど
小さな疑問が一つできてしまったので
もう一つお願いします。
龍神録のボスの2番目の魔方陣が赤~黄~緑~青って変化していますよね
私もあれをやってみたいんですが魔方陣の色を変化させる処理が思いつかないんです。
どうやっているか教えていただけないでしょうか?
Re:背景の素材が・・
>って事は自分ではダメだと思っていても他の人が見ればそんなにダメじゃ無いって事・・かな?
う~ん、弾幕名は相当考えないとよい名前が付けられない気がします・・・。
私のような人間は・・。
>BGM
PlayMusicだったら解放する必要はありませんが、
一度ロードで読み込んで再生する形式ならDeleteする必要があると思います。
ハンドルを作るだけでも結構食うようです(1MB位?)
後、色の変化は輝度の設定で出来ますよ。
http://homepage2.nifty.com/natupaji/DxL ... html#R3N18
う~ん、弾幕名は相当考えないとよい名前が付けられない気がします・・・。
私のような人間は・・。
>BGM
PlayMusicだったら解放する必要はありませんが、
一度ロードで読み込んで再生する形式ならDeleteする必要があると思います。
ハンドルを作るだけでも結構食うようです(1MB位?)
後、色の変化は輝度の設定で出来ますよ。
http://homepage2.nifty.com/natupaji/DxL ... html#R3N18
Re:背景の素材が・・
ハンドルを作るのにも結構容量を使うんですね
では解放してから読み込む事にします
輝度なんですが赤、緑、青だけならともかく黄と白も入っているから効率の良い式が浮かばないんですよ・・
龍神録は見た感じ
まず( 255 , 0 , 0 )~( 255 , 255 , 0 )まで変化して
次に( 255 , 255 , 0 )~( 0 , 255 , 0 )まで変化して
次に( 0 , 255 , 0 )~( 0 , 0 , 255 )まで変化して
次に( 0 , 0 , 255 )~( 255 , 255 , 255 )まで変化して
っと言うような変化をしているようですが
この変化を作る式が浮かばなくて・・
カウンタで条件分岐すればできない事も無いですが
それだと効率の悪いコードになってしまうんですよね・・
では解放してから読み込む事にします
輝度なんですが赤、緑、青だけならともかく黄と白も入っているから効率の良い式が浮かばないんですよ・・
龍神録は見た感じ
まず( 255 , 0 , 0 )~( 255 , 255 , 0 )まで変化して
次に( 255 , 255 , 0 )~( 0 , 255 , 0 )まで変化して
次に( 0 , 255 , 0 )~( 0 , 0 , 255 )まで変化して
次に( 0 , 0 , 255 )~( 255 , 255 , 255 )まで変化して
っと言うような変化をしているようですが
この変化を作る式が浮かばなくて・・
カウンタで条件分岐すればできない事も無いですが
それだと効率の悪いコードになってしまうんですよね・・
Re:背景の素材が・・
あ~わかります。レインボーって案外難しいんですよね。 レインボーを7色と決めてしまい、その7色を決めた時間で遷移するようにプログラム組んでみてはどうでしょうか? 特に効率の良い計算式に無理にしようとしなくても、自分が見てわかりやすい計算式ならいいと思いますよ。 switch文で1パターンずつわけて書いていってもいいと思います。 おわかりかと思いますが、 例えば 以下説明では簡略化して、レインボーが赤・青・黄の3色だとします。 100カウントで1色変化するものとします。 赤→青→黄→ 赤→青→黄→ 赤 この繰り返しを行いたいわけですよね。ここで (R,G,B)において 赤=(255, 0, 0) 青=( 0, 0,255) 黄=(255,255, 0) だとしましょう。 赤から青にかけて変化するのは Rが255→0 Bが 0→255 100カウントで変化させるのですから、1回の処理で255/100.0ほど変化させればよいことになります。 ここで、この数値はintでは扱えないことに注意して下さい。 100カウントたったら赤は青になっているはずですから、そうしたら変化の計算式をかえ、 Rが 0→255 Gが 0→255 Bが255→0 100カウントで変化させていきます。このように、計算してはいかがでしょうか? 決めた色の数変化させおわったら最初に戻ればいいと思います。 もし効率よい計算式を考えたいなら、変化する色情報を配列に用意させて、いくつ変化させるか予め決めておけばいいと思います。 例えば 変化1(赤から青)ではRedは100カウントで255→ 0になり、 変化2(青から黄)ではRedは100カウントで 0→255になり、 変化3(黄から赤)ではRedは100カウントで255→255になり、 (変化1に戻る) ならば float AddRed[3]={ -255/100.0, 255/100.0, 0, }; ([0]は変化1でRedに加算する数値、[1]は変化2でRedに加算する数値、[2]は変化3でRedに加算する数値) このように、変化させる中でいくつ足せばいいかを格納してやり、常にその数値を足せばいいと思います。 変化1、変化2・・に当たる変数を int AddColState; とでも名づけるなら Red += AddRed[AddColState]; としてやり、AddColStateは100カウントずつ1増えていき、変化3が終わったら戻してやればいいでしょう。わかりにくいですかね。効率の改善は行うべきでしょうが、あまりにもコードを短くかこうとして
返ってみにくくなると本末転倒ですので、適度でいいと思いますよ。
最初はif文ばかり書いていても、そのうち自然に短くかけるようになってくると思います。
特に長期にわたって制作するときは、後からコードを見てすっと意味がわかることが重要だと思います。
Re:背景の素材が・・
どこまで計算して良い物かよくわからなかったので、過去ログを3つさかのぼって計算し、加算しておきました。
もし何か間違いがあれば教えて下さいm(_ _)m
もし何か間違いがあれば教えて下さいm(_ _)m
Re:背景の素材が・・
>>過去ログを3つさかのぼって計算し、加算しておきました。
手間をかけてしまってすいません、
もう少し稼いだ気もしますが、改名してから一日で
3000ポイント増やしてますから十分だと思います。
どうもありがとうございました。
手間をかけてしまってすいません、
もう少し稼いだ気もしますが、改名してから一日で
3000ポイント増やしてますから十分だと思います。
どうもありがとうございました。