にやっとカンパニーのBlog

小キャラを動かしてる時にフキダシを出したいんだけども、
そこで出現させる位置をどうしようかと計算式を考えた。

アクティブの方向が、

左＝16　【キャラ】　右＝0

と数値が振られてるので、
例えばキャラが右or左向いてる時に前方+100にフキダシを作成するとする。

キャラが右向き時【フキダシ作成】キャラ位置　+　100
キャラが左向き時【フキダシ作成】キャラ位置　-　100

これで終わる。が、2行が辛い。
では、これを1行で書くには？
16と0をそれぞれ使った場合に、答えが-100と100になるように持っていく。

0×αが0になるので、

【キャラの向き】×　-12.5　+　100

と書くことが出来る。
掛けた時に距離が-2倍になるようにして最後に距離を足す。

キャラの向きが左（16）の時に*-12.5＝-200　+100で　-100
キャラの向きが右（0）の時に*-12.5＝0　+100で　+100

更に、キャラの向きの所をランダムにしてみたりとかすると
ランダム左右出現とか応用が効く。

↓ランダムで0か1を選択
random(2)　*　-200　+100　　　◆解が　-100　or　+100　になる

これでランダムで右に100の所か、左に100の所か、と選択できる。
距離も計算する数値を変えればなんとでもなる。


キャラの向き切り替えも忘れないように再度書いとこう。
【キャラの向き +16 mod 32】◆0→16 or 16→0 　

※modは割った時の余りを出力する。
16÷32の余り＝16　32÷32の余り＝0


忘れないようにメモメモ。計算式ってすごいわぁ'`,、('∀`) '`,、

上限100のゲージがあって、
1度の行動で10上がるけどこの行動で95以上上げさせない、
という変数の増加を考えてたんだけども、
変数を増加するに着目しすぎてまるで気がつかなかった事（;´Д｀）

最初は2行で書いてた。

1・変数を10増加
2・変数が95より上の時95に変更

ここで、変更する＝増加する　に出来る事に気がつきはしてた。が、
増加を使って計算式をうんぬんかんぬんに縛られてた。

けどよくよく考えれば　変数を増加する　を使わなくてもいいわけで。。
例えば、

変数を1増加する　＝　変数を（変数+1）に変更　と書けば同じ動作になるので、
ならば、min（2つを比べて少数を選択）を使って、

変数を変更　min( 変数+10 , 95 )

と書けば、ああ、上昇が95で止まるわ、1行だわ、と。

oh・・・・・・( ﾟДﾟ)

いや、分かってれば単純だしどうってことない事ではあるんだけども
メモメモ'`,、_φ('∀`;) '`,、

バイナリデータ使えばうんたらかんたら・・・ってのは知ってたけど
やり方がさっぱりだった。

が、調べ直した結果、やり方を発見。
バイナリに格納してそこから画像を読み出す方法で生ファイル状態を抜け出せるっぽい。

セーブデータやら何やらでバイナリファイルに格納がどうとかやってたはずなんだけど
その時もさっぱり分からなかったけども、そうか、ここに格納するのか～

どうもピクチャとかアクティブピクチャはバイナリファイルに対応しているとかなんとか
・・・しかしこれも分からなかった。

が、何回か試行錯誤したら出来たので手順をメモ。

まず
←これを押してバイナリデータってのを開く。







次に、画像ファイルをここに指定して格納。





で、格納した画像ファイルを命令で呼び出す。


BinFileTempName$("F:\H\jump_" + Str$( 変数 ) + ".jpg")

※BinFileTempName$　＝　バイナリファイル格納場所の指定
※Str$( 変数 )　＝　変数を文字列に変換

↑の書き方だと、バイナリファイルに格納された、

F:\H\jump_「変数の番号」.jpg

を呼び出す事になる。
ただ、ビルドするまでは格納の指定のみだから、
ビルドしないとexeファイルに格納されない。

後、これが落とし穴だったのか分からんけども、
ファイル名が長いとどうにも読み込んでくれなかった。
何度かの試行錯誤で結構な長い名前（E：￥フォルダ￥フォルダ￥名前。jpgとか）で
やってたんだけどもこれが全然読み込んでくれなくて訳が分からなくなってた。。
調べてみてもよく分からん。。
スペルミスか・・・ファイル嵩むとダメなのか・・・文字制限に引っかかってたのか・・・？

なので格納する場所はなるべく短い名前にしたほうがいいかもしれない。
とりま変数を使ったバイナリ呼び出しも出来たので忘れないうちにメモしとく。


ちなiniファイルとかも同じように格納できるんだけども、
iniファイルは命令で抽出しないとどうにも使えないらしい。
さらにアプリケーションが終了する時にこれを命令で解放しとかないと
Tempフォルダ？にゴミが残るとか何とか・・・

で、画像ファイルだとその抽出と解放の命令無しでバイナリ参照して呼び出せる。
ああ、バイナリに対応してるってのはこういう事だったのか。なるほどな～


とりあえず画像データはバイナリに格納だな！
出してしまった0515はまぁ置いておくけども、
次からは生ファイル状態が回避できそうだわぁ'`,、('∀`) '`,、

CF2.5で試しにパラパラ絵を全部JPGにしてフォルダ作って連番にして突っ込み
連続で読み出してみたんだが・・・

普通に読み込めた。

一応処理を変えてver上げた物をEntyのほうへ。→これ。
処理が変わっただけで内容は変わってない。

うおお今まで悩んでた重さのあれやこれやが嘘のように消えた！！！
マジか～・・・・・・

ロード絵が要らないくらい軽いわ。驚いた。
あとpngとjpgの連続表示の差がかなりあった。

なるべく軽くしてjpg保存したものと同じ大きさで保存したpng画像を
同じ命令でアクティブピクチャで呼び出して1フレーム交換で再生させてみると、
目に見えてpngのほうが再生速度が落ちた。

アクションで動作を保存したものはjpgもpngも変わらず。
まぁアクションに保存した時点で絵の保存方法がアクション依存になるんだろう。
そして重い。。

つーわけで、1280*720でパラパラ絵の再生をするときは
連番でjpg保存してアクティブピクチャで呼び出す！！
ってのを覚えた。

あと連番のゼロの表記なんだけども、変数を文字列として呼んだ場合に
上のケタのゼロが消えてしまう。

例えば、ファイル名が　くっころ_001.jpg　とかだったとして

”くっころ_”+Str$( 変数A )+".jpg"

で呼んだ場合、変数Aが1になって「くっころ_1.jpg」となり呼び出せない。
うわぁファイル名のゼロを一々消さんとあかんのか～、と思ったけども、
連番なんだから考え方を変えればい～じゃない、ってのに気づいたのでこれもメモ。

0が消えるなら消えない数値から始めればいいじゃない、と。
001だと0が消えて1になるけど1001ならゼロ消えない！！

ファイルが200枚あったとして1000もしくは1001から始めて終わり1200にすれば
普通に読み込めるし間違いも減る。無理してゼロから始める必要も無い。

新たな視点が開けた気分だわぁ'`,、('∀`) '`,、

どうにもうまく動かせなかったので結局また新規で素材を作り・・・
素材作る時に、あれも出来るこれも出来る、という枝を
あんま増やさないほうがいいな、と思った(´・ω・`)

で、こんな感じのを描いてLive2D使って動かして
それを1枚ずつちょこちょこ吐き出して動画として繋げていく。
とりま200枚ほど。200も増減は後で考える。今は保留。。

この画像は小さくしてあるけど、動かすのは1280×720の大きさ。

モザイクは・・・1枚ずつ手作業でやってみたが
めんどいものの、割といけるかもしれん、割と。めんどいけど(´・ω・`)
まぁこの体制だとあれが隠れてるので内容は実質100枚くらいだったか？

一応メモると、

・新規レイヤー作成
・その新規レイヤーを透明度75％くらいにして隠したい部分を確認しつつベタで塗りつぶす
・元の無修正レイヤーを複製
・複製したレイヤーに効果→モザイク加工
・加工したレイヤーをベタ塗ったレイヤーの上にマスキングとして乗っける
・ベタレイヤーの透明度を100％に戻す。
・画像を統合

これで修正完了。というのを忘れないようにメモ。


マスキングし辛くてあれが1ドットやら2ドットやらはみ出たりとかあったりするが
大元が隠れてるのでこれで多分大丈夫だろう。
大丈夫だよな！？これ引っかかったら泣くぞ！！

とりあえず動かすと割といい感じに動くんだけども
ロードされなかったりで不安定とか
今の時点ではセリフがまったく入ってなくて面白味が全くないとかで
コレ上げるのどうすっか・・・(;´д`)

とりまセリフ入れんとあれだしなぁ、作って入れたら久々に上げられるか。

ふふ、しかしコレも横に置いて年賀状描くか。。。
やべぇよもう28日だよ今年もあと3日かぁ'`,、('∀`) '`ぁ"ぁ"ぁ"orz

画像データを直接持ち込んで印刷してみたんだけども、
ものすごい綺麗に印刷されて正直びびった( ﾟДﾟ)
時代は進んだもんじゃのぅ、と思ったのでメモ。


まず画像の保存形式はjpgかtiff。
USBメモリースティックにデータ突っ込んで印刷機に直接刺す。
はがきは普通紙はがき。間違ってもインクジェット紙を使ってはいけない。

で、後の細かい事は印刷機の説明を見つつやればいい。


これで、はがき1枚フルカラー印刷で60円。
自宅プリンタのインクジェット印刷と比べると出来が雲泥の差。
綺麗に刷れるし、そう何枚も刷るわけじゃないからコスト考えても破格に感じる( ﾟДﾟ)！
そいつに自宅のプリンタで宛名印刷すれば完成。


やばいわぁ、コレもっと早く使っとくべきだったなぁ'`,、('∀`) '`,、 

親子関係はどんどん追加できるってのに気づいた（ﾟДﾟ）！
というか、なんとなくモヤッとしてたのが確信になったと言うか。

元ポリゴンを変えずにデフォーマを操作して絵を変えるってのを前に書いたんだけど、
親子関係をデフォーマで繋げば子のパターンを纏めて動かす事が出来る。


具体的には、

曲線デフォーマ1
　　┗デフォーマ2
　　　　　┗デフォーマ3
　　　　　　　　┗ポリゴン絵 

として親子関係を作ると、デフォーマの1から3のどれを弄っても絵が動く。
で、子関係のそれぞれの場所を弄った場合は上の親のデフォーマに影響が無い。 

1を弄った場合は、2、3、絵のすべてに影響を及ぼし、
2を弄った場合は、3、絵に影響を及ぼし、1に影響を及ぼさず、
3を弄った場合に絵には影響があるが1と2に影響が無い、って感じ。
絵を直接弄った場合もデフォーマには影響が無い。

更に、この子をどんどん繋げる事によってパターンがいくらでも増やせる。

どうにも分かり辛いんだけど、これが重要な理由は、
複数パターンを作成しなきゃならないとこを曲線デフォーマに割り振る事で
パターン作成の数を劇的に減らせるって事。


ああっ、さらに分かり辛いっ_no

なんというか、コレ極意なんじゃね？くらいに思える事なんだけど
うまく説明が出来なくて再びモヤッとしてきた・・・

一応メモっておくけど後で見た時分かるだろうか自分'`,、('∀`;) '`,、 

単純な形でできるかもしれない（ﾟДﾟ）！　（フラグ


0から1へのモーションへ移動する際の、
その途中のモーション数は決まってるってのに気づいた。

0から1に至るまでに、途中のモーションがいくつも補完されるわけだけど、
その最小単位は　「0.001」

つまり、0から1までに、0.001～0.999までのモーションが補完されている事になる。


えらい滑らかに動いてるからまるで気づかなかったんだけど、
なるほどモーションの補完数は無限ではない訳か。
当たり前っちゃ当たり前なんだけども。。


では、最小単位での移動ならば、モーション補完はされない（物理的に出来ない）のでは？

と考えて、パラメータを、　0～0.001　と設定して絵を動かしてみると・・・
途中の補完全く無しで絵がぱっと入れ替わる。

お？　うおお！？　コレはパラパラアニメいけんじゃね( ﾟДﾟ)！？

つまり、パラパラアニメさせたい時は、
その中間点が作られないようにパラメータを最小値で収めればいい。

手をグーからパーにするパラパラアニメを描いたとしてそれが5枚とした場合に、
値を、　0、　0.001、　0.002、　0.003、　0.004　と設定して動かしてやれば
上手くいくに違いない！！！






と思っていた時期が俺にもありました・・・（;´д｀）（遠い目

モデラーのほうでは確かにそれでうまくいく。
しかしアニメーターに移行して動きを制御してみると、
なんと途中のモーションが補完されてしまうではないですか！！


ああ、だめだ、アニメーターのほうでぽちぽち制御するしかなさそうだ・・・。
まぁ失敗ではあるんだけど、挙動が少し理解できたのでメモっておくか。

この手間を無くす方法があればいいんだけども、どうしたもんかなぁ'`,、('∀`;) '`,、 

ただ単にデフォーマに対して指定してないだけだった。
うわしょっぱい(´・ω・`)


とりあえずデフォーマは大元になるとこを回転あたりで一つ入れといたほうが処理がしやすい。
こいつを動かすと全体が動くぞ、という元を。

で、それを基礎にしてデフォーマで親子関係を設定してからその親は動かさずに
子を動かしてパラメータに組み込む。

そうすると、パラメータ上で子デフォーマは動くんだけど、親デフォーマは干渉しない、んだけど、
パラメータ無しの親デフォーマを動かす事でその子デフォーマをパラメータごと移動できる。
親からなら移動とか回転とかしても、ちゃんと子デフォーマ側のパラメータは生きてる。


後、パラメータでの指定を、ポリゴン直指定と、デフォーマ指定で分けられる。
これは分かりにくいんだけど、例えば、瞳を左右に動かすパラメータを設定して、
そいつを曲線デフォーマを使って指定する。

パラメータ上で動かすのは曲線デフォーマの位置で、
瞳ポリゴンをこのデフォーマの子に指定。これで瞳が左右に動く。

次に、瞳の大きさパラメータを設定して、これは瞳ポリゴンを直に弄って
大きさを変える。

すると、同じ瞳を指定してるけど、
・曲線デフォーマに対する瞳の「位置」と、
・ポリゴン直弄りによる瞳の「大きさ変更」が、パラメータで重ならないので、

瞳移動パラメータ、瞳の大きさパラメータが大幅な書き換えをしないでも同時に存在できる。
すべての位置を合わせて大きさを変える、なんてことをしないでも、
この指定だけでびっくり瞳しながらきょろきょろ、とかできる。


もちろん、デフォーマとポリゴン直弄りを両方行って一つのパラメータにすることもできる。
ただこれは非常にめんどくなる。やりすぎるとパラメータが被りすぎて
訳分からんくなる( ﾟДﾟ)！ので注意が必要。


やばいね！ 超便利だから覚えとくべし。メモメモ　'`,、_φ('∀`) '`,、 

通常の蹴りから連なる5連撃とか
組み付きの膝攻撃からの派生とか。


ただ思いついただけの、どこかで見たことあるような気がする動作。。
忘れそうなのでメモするが実装するかは謎。
けど、ベルトスクロール面も作りたいんだよなぁ・・・。

ただでさええろいシーン出来てないってのに、やる事を増やしてる感がだだ有りでまずいまずい。

しかしメモする分には構わんよね多分'`,、('∀`) '`,、