2006/05/13(土) [n年前の日記]
#1 [prog] _ファイル検索イテレータ Find::File::Iterator って便利かも？ :: Drk7jp
こんなものがあったのか…。
と思ったけど、ActivePerlのドキュメントを見たらそれらしいものがなかったので、面倒だから File::Find で処理。＜モノグサ。
…ん？ サンプルを眺めたら、our と map なるものが。一体何だろ。
_perlのourに関すること - **ourについて
_vars.pm 探検
_strictプラグマ使用時における変数【全般】
なんだかよくわからんが、use vars qw( LIST ) とやらを使う代わりに、our を使える、ということなのかな。
と思ったけど、ActivePerlのドキュメントを見たらそれらしいものがなかったので、面倒だから File::Find で処理。＜モノグサ。
…ん？ サンプルを眺めたら、our と map なるものが。一体何だろ。
◎ _our宣言 :
our宣言は、グローバル変数をパッケージ名で修飾せず使用できるようにします。our宣言はmy宣言と似ていますが、新たにローカル変数を生成するかわりに、カレントパッケージに所属するグローバル変数をパッケージ修飾なしで使えるようにしてくれます。our宣言の有効範囲は、my宣言と同じです。つまり、ourによって宣言した変数は、宣言が置かれているブロック、eval、またはファ イルの末尾まで有効です。
_perlのourに関すること - **ourについて
「my の」という表現はピンとこないのですが、グローバル変数の定義ってことでいいと思います。our 宣言した変数は、確かに前の値をずっと保持してます。僕は use vars qw() の代わりに使ってます。perl にビルトインされてるぶんだけ、vars を使うより our のほうが速いんじゃないかな。僕は困った経験はないですが、package との兼ね合いが vars で宣言したときとは違うかもしれません。それから vars で宣言したときも同じですが、クロージャの対象にならないので注意が必要です。これはよく引っ掛かります。
_vars.pm 探検
Env.pm を調べていたときに use vars qw( LIST ) という表現が出てきました。use vars は組み込み関数ではなく、use で vars.pm モジュールを読み込んでいるだけなのです。vars より
_strictプラグマ使用時における変数【全般】
use stirct 'vars';
とした場合、或いは単に
use strict;
とした場合、グローバル変数は全てパッケージ名で完全に修飾しなければなりません。Perl Tips より
なんだかよくわからんが、use vars qw( LIST ) とやらを使う代わりに、our を使える、ということなのかな。
◎ _Perl Tips - loop処理 :
[ ツッコむ ]
#2 [iappli] _AirWiki: FOMA/SA700iS
SA700iS の音源チップは、他機種で言えばどのへんに相当するんだろう…。
ていうか、音源チップ別に分類していくと、iアプリ端末って14だか15種類だかあるんだけど。しかも端末は _こんなにあるし。 機種判別をして、どのデータを使うか判断させるだけで、iアプリの容量を使い果たしてしまうではないか。いや、そこまでアレではないけど。とはいえ、プログラム部分で使えるのが、10K〜30Kbyteてな世界なわけだから、結構不安になってくる。
さておき、分類をしなきゃいけないわけだけど。音源別に分類するための端末一覧を眺めつつ、条件分岐を書こうとして、頭がこんがらがってきた。Dxxxだから 505のDになるかといえばそうではなくて、505のFになったりするし。SH50x や SO50x は、iとiSで別音源らしいし。…あかん。わけがわからん。ちょっと後回し。
ていうか、音源チップ別に分類していくと、iアプリ端末って14だか15種類だかあるんだけど。しかも端末は _こんなにあるし。 機種判別をして、どのデータを使うか判断させるだけで、iアプリの容量を使い果たしてしまうではないか。いや、そこまでアレではないけど。とはいえ、プログラム部分で使えるのが、10K〜30Kbyteてな世界なわけだから、結構不安になってくる。
さておき、分類をしなきゃいけないわけだけど。音源別に分類するための端末一覧を眺めつつ、条件分岐を書こうとして、頭がこんがらがってきた。Dxxxだから 505のDになるかといえばそうではなくて、505のFになったりするし。SH50x や SO50x は、iとiSで別音源らしいし。…あかん。わけがわからん。ちょっと後回し。
この記事へのツッコミ
[ ツッコミを読む(4) | ツッコむ ]
#3 [iappli] ステージのBGデータをresourceに移動した
ステージ数が2.x倍になったので、各ステージのBGデータの並びも2.x倍に。…容量的に不安。
ということで、ソース中に記述していた byte 配列を、バイナリファイルにして resource 以下に置いてみたり。どこかで読んだアレだけど。ソース中に byte配列として並べた場合、実は byte じゃなくて int として並んでる、てな話も見かけたので。仮にそれが本当ならば、resource にバイナリファイルとして置いたほうが容量は食わない可能性が高い。ような。や、今はさすがに、byte を int で並べてる、なんてことはしてないのかもしれんけど。まあ、BGデータの並びを変更するたびに、ソースにコピペしていくのも危ないなと思ったりもするし。別ファイルにしてあれば、スクリプトを実行するだけで、そのへんの更新作業ができるし。
ということで、バイナリを出力する Perl スクリプトを作成。 _Platinum で出力した .csv を読み込んで処理をする。…まあ、$s .= pack("C",$x) して出力してるだけだったり。
iアプリ側も修正。resource///filename から、1byteずつ読み込んでBG用のバッファに描画。一応、表示できてるように見える。
最適化ツールを使って .jar を出力してみたけど。劇的な容量削減に繋がった様子はなく。あまり意味はなかったか…。まあ、更新作業が楽になるメリットはあるから、いいか。
全然関係ないけど、Platinum で書き出した bmp って、謎の縦線が入るんだけど…。なんでやろ。自前でチップを並べて書き出すツールでも作らないとダメかな。…Platinum が出力する .csv 中に、チップ用画像のファイル名も入っていれば、そういうスクリプトも比較的簡単に作れそうな予感。や、Platinum の保存ファイル .ppj を対象にして処理してもいいのかもしれんけど。内部フォーマットが今一つわからんので、そこから調べていかなきゃならんのは、ちと億劫で…。ていうかこういうのって、極力テキストで出力してあるほうがいいよな。たしか POVRAY の pov ファイルなんかも、中身はテキストだったりするし。…人間がパッと見で、開発関連ツールの記録ファイルの内容を確認できるというのは、スクリプト・ツールをサクサク書いていく・データの転用が楽になることに繋がるような気もする。とかそんなことをぼんやりと。
ということで、ソース中に記述していた byte 配列を、バイナリファイルにして resource 以下に置いてみたり。どこかで読んだアレだけど。ソース中に byte配列として並べた場合、実は byte じゃなくて int として並んでる、てな話も見かけたので。仮にそれが本当ならば、resource にバイナリファイルとして置いたほうが容量は食わない可能性が高い。ような。や、今はさすがに、byte を int で並べてる、なんてことはしてないのかもしれんけど。まあ、BGデータの並びを変更するたびに、ソースにコピペしていくのも危ないなと思ったりもするし。別ファイルにしてあれば、スクリプトを実行するだけで、そのへんの更新作業ができるし。
ということで、バイナリを出力する Perl スクリプトを作成。 _Platinum で出力した .csv を読み込んで処理をする。…まあ、$s .= pack("C",$x) して出力してるだけだったり。
iアプリ側も修正。resource///filename から、1byteずつ読み込んでBG用のバッファに描画。一応、表示できてるように見える。
最適化ツールを使って .jar を出力してみたけど。劇的な容量削減に繋がった様子はなく。あまり意味はなかったか…。まあ、更新作業が楽になるメリットはあるから、いいか。
全然関係ないけど、Platinum で書き出した bmp って、謎の縦線が入るんだけど…。なんでやろ。自前でチップを並べて書き出すツールでも作らないとダメかな。…Platinum が出力する .csv 中に、チップ用画像のファイル名も入っていれば、そういうスクリプトも比較的簡単に作れそうな予感。や、Platinum の保存ファイル .ppj を対象にして処理してもいいのかもしれんけど。内部フォーマットが今一つわからんので、そこから調べていかなきゃならんのは、ちと億劫で…。ていうかこういうのって、極力テキストで出力してあるほうがいいよな。たしか POVRAY の pov ファイルなんかも、中身はテキストだったりするし。…人間がパッと見で、開発関連ツールの記録ファイルの内容を確認できるというのは、スクリプト・ツールをサクサク書いていく・データの転用が楽になることに繋がるような気もする。とかそんなことをぼんやりと。
[ ツッコむ ]
以上、1 日分です。
携帯の音源はFM音源系とPCM音源系の２系統だけ分類して
あとは各機種共通部分だけ使う、でいいのでは？
どうせ６４和音とか１２８和音とか使い切れないし。
> あとは各機種共通部分だけ使う、でいいのでは？
おそらく、曲を作る方は
そういう感じでやってるだろうなとは思うのですが…
あ、そうか。音源の種類がわからなかったら曲も作れるはずがないから、
曲を作ってる人から情報をもらえばいいのか。なるほど。
それにしても、携帯の音源はてんでばらばらですな…
例えばFM音源系のチップでも、
http://smaf-yamaha.com/jp/tools/nec/handsets.html
こんな感じで色々あるわけで。
しかもこれで、「Nxxx」だけだもんな…。
なんかもう、後先考えずにハードを作ってる感が。
とはいえ、ヤマハ音源増えてきましたねぇ。
昔はまだまだ群雄割拠だったイメージがあるんですが。
KORGの音源とかもあったりとか。
着メロとかは大雑把なところは２系統しか用意して無いですよね？
たぶんそうなんだろう、と自分も思うであります。
MA-5 用に作っておけば、MA-7 もそれなりに鳴るんだろうなと…。
> 昔はまだまだ群雄割拠だったイメージが
なるほど。まだ今のほうが、状況は良くなってるほうかも、
ということなのですな…。
> 着メロとかは大雑把なところは２系統しか用意して無い
なんと。それは嬉しい話かもしれず。そのぐらい大雑把でもいいのか…。
と思ったけど。iアプリって曲だけじゃなく、
効果音があるのも忘れてました…。
効果音をMIDIデータ(?)を元にして鳴らすか、
ADPCMで鳴らすかでも違ってきそうですね…。
(ADPCMは、音源チップによって対応フォーマットが違うとかなんとか…）
まあ、結局は、
どのくらい各端末の性能をギリギリまで引き出すか、
てな「職人としての姿勢」によって違ってきそう…。
鳴ってればOK、なのであれば、
結構大雑把に作業できてしまうのかもしれんし…。