ゲーム制作や雑記などをきまぐれに
Twitter
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
案の定昨日中に完成には至りませんでしたが大分できてきているのは確かです。地獄のバグ潰しタイムです。
効果音とループ関係で苦労しました。ウェイトが絡んでくるこの2つは分かりにくいんです。ループはまだいつもに比べるとあっさり直りましたけどね。結構バグもつぶれてきたのであとは同時再生機能あたりができれば完成です。
ついでに実際に使ってみたSSを載せておきます。
文字列アニメと移動と色変更と残像を組み合わせたものです。どうみてもぐちゃぐちゃですがこれで正常。今までどおりの使い方もできそうです。
フラッシュや残像は曲者かと思いきや案外スムーズにできましたですよ。フラッシュはインチキフラッシュなので普通のフラッシュと少し色が違ってきますが気にしないであげてください。
ver1.11の話。
超高速化と噂のver1.11ですがこのコモンではあまり効果は見られませんでした。残像を出しまくるなどしないかぎりはそれほど重くはならないのでいいんですけど。
これとは別に現在公開しているコモンで効果が見られました。多機能版に円状など特殊な移動をさせる機能があるのですが、以前のバージョンでは重過ぎて使い物にならなかったのにver1.11では平然と使えてしまいました。これはうれしい誤算というやつなのでしょうか。リメイク版はもう内容に空きがないので実装できないんですけど。
さて、それでは続きを作ってきます。
P.S
（；´・ω・｀）同時再生機能がうまくいかない・・・なぜだ！なぜ昔作ったバージョンの方法が通用しない！？
同時再生機能を削る必要性がでてきてしまいました・・・
効果音とループ関係で苦労しました。ウェイトが絡んでくるこの2つは分かりにくいんです。ループはまだいつもに比べるとあっさり直りましたけどね。結構バグもつぶれてきたのであとは同時再生機能あたりができれば完成です。
ついでに実際に使ってみたSSを載せておきます。
文字列アニメと移動と色変更と残像を組み合わせたものです。どうみてもぐちゃぐちゃですがこれで正常。今までどおりの使い方もできそうです。
フラッシュや残像は曲者かと思いきや案外スムーズにできましたですよ。フラッシュはインチキフラッシュなので普通のフラッシュと少し色が違ってきますが気にしないであげてください。
ver1.11の話。
超高速化と噂のver1.11ですがこのコモンではあまり効果は見られませんでした。残像を出しまくるなどしないかぎりはそれほど重くはならないのでいいんですけど。
これとは別に現在公開しているコモンで効果が見られました。多機能版に円状など特殊な移動をさせる機能があるのですが、以前のバージョンでは重過ぎて使い物にならなかったのにver1.11では平然と使えてしまいました。これはうれしい誤算というやつなのでしょうか。リメイク版はもう内容に空きがないので実装できないんですけど。
さて、それでは続きを作ってきます。
P.S
（；´・ω・｀）同時再生機能がうまくいかない・・・なぜだ！なぜ昔作ったバージョンの方法が通用しない！？
同時再生機能を削る必要性がでてきてしまいました・・・
PR
昨日はやたらと調子がよくて深夜3時まで作業できました。
ぶっ通しでやってるわけじゃないんで実際の作業時間は大したことないんですけど、あとループ関係の処理を入れたらテストに移れそうです。
まぁいつも苦労するのは何でかループ処理なんですけどね。
わりとどうでもいいですが行数は今のとこギリギリ1000行いってません。少しは無駄が減らせたのもありますが、効果音処理をループで済ませたのと、膨大な条件分岐の原因であるシェイク機能をなくしたのが大きいです。シェイクはアニメだけ揺れないってのもアレだし、そもそもデフォルトと同タイプの戦闘システムじゃピクチャ以外更新停止されてるから意味ないじゃんということで撤去されました。
コメントが多いんで全部消してしまえばもう少し減る・・・というかコメントは処理されないとはいえあるとそれだけ動作が重くなるんですよね。今度からは注釈入りと全部削除済みのものを同梱する予定です。
これからが本当の地獄ってやつですがやっと少しだけ完成の光が見えてきました。明日にはウェイト版だけでも完成できたらいいなあ
ぶっ通しでやってるわけじゃないんで実際の作業時間は大したことないんですけど、あとループ関係の処理を入れたらテストに移れそうです。
まぁいつも苦労するのは何でかループ処理なんですけどね。
わりとどうでもいいですが行数は今のとこギリギリ1000行いってません。少しは無駄が減らせたのもありますが、効果音処理をループで済ませたのと、膨大な条件分岐の原因であるシェイク機能をなくしたのが大きいです。シェイクはアニメだけ揺れないってのもアレだし、そもそもデフォルトと同タイプの戦闘システムじゃピクチャ以外更新停止されてるから意味ないじゃんということで撤去されました。
コメントが多いんで全部消してしまえばもう少し減る・・・というかコメントは処理されないとはいえあるとそれだけ動作が重くなるんですよね。今度からは注釈入りと全部削除済みのものを同梱する予定です。
これからが本当の地獄ってやつですがやっと少しだけ完成の光が見えてきました。明日にはウェイト版だけでも完成できたらいいなあ
突然ですが、私はうそつきです。
ばばーん、これでこの記事の内容が本当かどうか分からなくなりました。でもよく考えるとこの記事以外にも影響が出るし、そもそもエイプリルフールは午前までだからもう嘘をついてはいけないのでした。がっくし。
制作はそこそこ順調なんですが実験の結果、ちょっとうーんな結果が出てしまいました。
文字列ピクチャを用いて画面を覆いつくすほどの巨大な■を表示して、それの色や不透明度をアレコレする方法で擬似的にフラッシュさせる予定だったんですが、案の定重かったです。設定にもよりますが、フラッシュ単品でFPSがだいたい30～45まで落ち込みました。
ウェイト版では処理ごとにウェイトをはさむので多少はマシになるとおもいますが、発動ディレイを用いてアニメさせるとなるとそうはいかないのでフラッシュ機能がかなり重くなることが懸念されます。
作ってみないとわかりませんが大きな不安要素ができてしまいました。
ちなみにどうでもいい情報ですが文字列をピクチャとして表示した際、フォントサイズ変更文字で大きくするよりも拡大率で大きくした方が処理は軽く感じました。10000％を超えるとなにやら動作が怪しくなりましたけど。
ばばーん、これでこの記事の内容が本当かどうか分からなくなりました。でもよく考えるとこの記事以外にも影響が出るし、そもそもエイプリルフールは午前までだからもう嘘をついてはいけないのでした。がっくし。
制作はそこそこ順調なんですが実験の結果、ちょっとうーんな結果が出てしまいました。
文字列ピクチャを用いて画面を覆いつくすほどの巨大な■を表示して、それの色や不透明度をアレコレする方法で擬似的にフラッシュさせる予定だったんですが、案の定重かったです。設定にもよりますが、フラッシュ単品でFPSがだいたい30～45まで落ち込みました。
ウェイト版では処理ごとにウェイトをはさむので多少はマシになるとおもいますが、発動ディレイを用いてアニメさせるとなるとそうはいかないのでフラッシュ機能がかなり重くなることが懸念されます。
作ってみないとわかりませんが大きな不安要素ができてしまいました。
ちなみにどうでもいい情報ですが文字列をピクチャとして表示した際、フォントサイズ変更文字で大きくするよりも拡大率で大きくした方が処理は軽く感じました。10000％を超えるとなにやら動作が怪しくなりましたけど。
もう少しで4月ですね。鬱です。にしても関西は最近寒いですな。花粉も減って助かりますけど。
現在公開しているアニメコモンにも実装されている角度を移動速度と連動する機能。
精度はそこそこ良いです。そこそこ良いってことはつまりはなかなかにいい加減なのです。
学がないので数学的知識も全く活用してません。無理矢理ってやつですね。
ちなみに仕組みは次のようになってます。
※ ↑ ←この状態が0度です。Xが正なら→に移動、Yが正なら↓に移動。
移動速度とはパターンごとに表示座標を何ドットずらすかの値のことをいいます。
まず、X座標Y座標それぞれの移動速度の正負を判定します。
符号によって角度を求める式が変わってきます。
XYともに正なら135度＋15(X－Y)度になります。
さらに引き上げ引き下げを使って90度以上180度以下におさめます。←ここがいい加減
この場合は右下へ向かって移動するからです。
Xが正でYが負なら45度＋15(X＋Y)度。0度以上90度以下になります。←ここｇ（ｒｙ
この場合は画面右上へ向かって移動するからです。
Xが正でYが0なら90度になります。
この場合は画面右へ向かって移動するからです。
Xが負でYが正なら225度－15(X＋Y)度。180度以上270度以下になります。
この場合は画面左下へ向かって移動するからです。
XYともに負なら315度＋15(X－Y)度。270度以上360度以下になります。
この場合は画面左上へ向かって移動するからです。
Xが負でYが0なら270度です。
この場合は画面左へ向かって移動するからです。
Xが0でYが正なら0度です。
この場合は画面下へ向かって移動するからです。
Xが0でYが負なら180度です。
この場合は画面上へ向かって移動するからです。
書いてるこちらまでがゲシュタルト崩壊を起こしそうです。もう少しマシな書き方はなかったものか。
作り手としてはやはり正確に処理したいものですが分からないところはこんな感じにごまかしたりします。
さーてエイプリルフールに
アニメコモン作るのやめます→うっそぴょーん
という流れの嘘がつけるように遅いですが頑張ってきます。
現在公開しているアニメコモンにも実装されている角度を移動速度と連動する機能。
精度はそこそこ良いです。そこそこ良いってことはつまりはなかなかにいい加減なのです。
学がないので数学的知識も全く活用してません。無理矢理ってやつですね。
ちなみに仕組みは次のようになってます。
※ ↑ ←この状態が0度です。Xが正なら→に移動、Yが正なら↓に移動。
移動速度とはパターンごとに表示座標を何ドットずらすかの値のことをいいます。
まず、X座標Y座標それぞれの移動速度の正負を判定します。
符号によって角度を求める式が変わってきます。
XYともに正なら135度＋15(X－Y)度になります。
さらに引き上げ引き下げを使って90度以上180度以下におさめます。←ここがいい加減
この場合は右下へ向かって移動するからです。
Xが正でYが負なら45度＋15(X＋Y)度。0度以上90度以下になります。←ここｇ（ｒｙ
この場合は画面右上へ向かって移動するからです。
Xが正でYが0なら90度になります。
この場合は画面右へ向かって移動するからです。
Xが負でYが正なら225度－15(X＋Y)度。180度以上270度以下になります。
この場合は画面左下へ向かって移動するからです。
XYともに負なら315度＋15(X－Y)度。270度以上360度以下になります。
この場合は画面左上へ向かって移動するからです。
Xが負でYが0なら270度です。
この場合は画面左へ向かって移動するからです。
Xが0でYが正なら0度です。
この場合は画面下へ向かって移動するからです。
Xが0でYが負なら180度です。
この場合は画面上へ向かって移動するからです。
書いてるこちらまでがゲシュタルト崩壊を起こしそうです。もう少しマシな書き方はなかったものか。
作り手としてはやはり正確に処理したいものですが分からないところはこんな感じにごまかしたりします。
さーてエイプリルフールに
アニメコモン作るのやめます→うっそぴょーん
という流れの嘘がつけるように遅いですが頑張ってきます。
タイトルに意味はあるけどない。残像機能についての話。
残像といっても個人的には2種類あります。↓の2種類です。
三（（（（（（（（（（（ ＾ω＾）
（ ＾ω＾） （ ＾ω＾） （ ＾ω＾） 三（ ＾ω＾）
んまぁ前者は後者をより細かくしてるだけですけど。
今公開してるコモンは基本前者しかできません。何故か1枚1枚消してはピクチャ番号を増やして新たに表示するという形で作ったので、消す際に処理時間を設定することでいとも簡単に作れました。
リメイク版は基本ピクチャ番号は一定という形をとっているので同じ方法ではできません。というか新しい機能が増えたため、1枚1枚消して～の方法では面倒になるのでやめました。なので、残像発生フレームと残像残存時間という設定欄を用いて後者のような残像になっています。
残像発生フレームを1フレーム毎に設定すれば、多分前者のような風にもできます。ただ、残像残存時間を長めに設定すると、ループ機能を使った際にピクチャ番号が重なって消えてしまう可能性が出てきます。それの対処方法を考え中。同時再生機能のことも考えないといけません。
腱鞘炎がいたひ。
P.S
文字列条件って比較するだけでもどれだけ重いのかな
残像といっても個人的には2種類あります。↓の2種類です。
三（（（（（（（（（（（ ＾ω＾）
（ ＾ω＾） （ ＾ω＾） （ ＾ω＾） 三（ ＾ω＾）
んまぁ前者は後者をより細かくしてるだけですけど。
今公開してるコモンは基本前者しかできません。何故か1枚1枚消してはピクチャ番号を増やして新たに表示するという形で作ったので、消す際に処理時間を設定することでいとも簡単に作れました。
リメイク版は基本ピクチャ番号は一定という形をとっているので同じ方法ではできません。というか新しい機能が増えたため、1枚1枚消して～の方法では面倒になるのでやめました。なので、残像発生フレームと残像残存時間という設定欄を用いて後者のような残像になっています。
残像発生フレームを1フレーム毎に設定すれば、多分前者のような風にもできます。ただ、残像残存時間を長めに設定すると、ループ機能を使った際にピクチャ番号が重なって消えてしまう可能性が出てきます。それの対処方法を考え中。同時再生機能のことも考えないといけません。
腱鞘炎がいたひ。
P.S
文字列条件って比較するだけでもどれだけ重いのかな
カレンダー
プロフィール
ブログ内検索
カテゴリー
最古記事
最新記事
最新CM
バーコード