fc2ブログ

Luaメモ(FAM)

2009.10.26.Mon
主に自分用メモ。

・空要素を配列に入れたいときはnilではなく""(空の文字列)で。
 nilだと配列を操作する時になにかと困る。


・多次元配列は実質可能。ただし、最初に定義せずに一気に入れるのはダメ。
 例1:data[3][2][10]="error"--これはエラー
 
 例2:data={}
    data[3]={}
    data[3][2]={}
    data[3][2][10]="success"--これはできる

 テーブルの値にテーブル型の値を入れることができるが、入れる値は事前に『data={}』のようにテーブル型の変数だということを明示する必要がある・・・ということかしら、多分。


・変数をインデクスに指定できる。
 例:index="first"
   data={[index]=7}

 これはdata={["first"]=7}と同じ。
 data.first=7やdata[index]=7とも同じだけど、こちらの書き方をする場合はdata={}のようにdataがテーブルであることを事前に明示することが必要。


とりあえず以上。
スポンサーサイト



やはりNスクの上で画像を表示させることに(FAM)

2009.10.21.Wed
効率のいいNスク→なでしこの通信法をずっと探していました。
おかげで開発ペース落ちまくったのでもうあきらめます。
正式版がリリースするまでこの件は触らないことにします。

んで。
二重起動防止解除が実装されていないにも関わらずこんなことをずっとやっていたのは表示画面はNスクにすると決めたからです。
Nスクのプラグインを使った演出を確認できるから、ってのはありますが、以前書いたなでしこによるαチャンネルがうまくいかない一番大きかったです。
表示画面をNスクにすることになるとまたなでしこを表示画面にするときのために作った関数が無駄になっちゃうんですがそれはそれ。いつものことだし。
むしろNスク使うと今後機能を追加するときに修正する範囲が増えるということのほうがきついかも。
まあがんばる。


最近は昼休みにLuaとか勉強中。
レイヤーの扱いを今までとちょっと変えるんですが、その処理がNスクのみだとやりにくいので。
変数の数に制限なくなるだけでも結構ありがたいのですが、それ以外の恩恵が受けられるなら受けたいですし。

自分が取ってた方法(FAM)

2009.10.16.Fri
なんかスクリプトの読み込み直しがどうのっていう話があったので。


自分の場合はデバッグモードの時はクリックごとにオートセーブし、再起動用のボタンを押したらNスクを1秒後に起動するプログラムを起動させ、Nスクを一旦終了させる仕組みにしていました。
時間差で起動させることで二重起動を避けて最新スクリプトを読んだNスクを立ち上げることができるようになります。
デバッグモードにしている時は起動時に自動的に最新から3~5個前のオートセーブのデータを呼び出すようにしてあったのでボタン1つで変更直前の箇所に戻れて演出の確認も容易でした。

こちらにそのときのツール(の改良版)およびもうちょっと詳しい説明を置いてあります。
適当に作ったものなので余り期待しないでください。
ちゃんと自分でカスタマイズできる人にお勧め、ということで興味があったらどうぞ。


本当はそーいうのをペンぷろでできるようにしてやるぞ、くらい言えればいいんだけどね。
元々ペンぷろは止まっている状態の立ち絵の位置と表情を確認するためのものなんで、動的な演出は確認できないんですよ。
そもそも対象テキストファイルを監視し続けて読み取りなおすってのも大変そうですし。

試しにちょっと作ってみた(FAM)

2009.10.14.Wed
さて、他のツールでもarc.nsa内のデータを利用できるようにする例としてこんなものを作ってみました。
や、単にペンぷろに付ける機能となでしことNスク間の連携をテストしたかっただけなんで、画像の透過形式は:a;のみとか800×600までの大きさしか変換できないとかoggのループ時に戻る点を指定できなかったりとか手抜きしまくってるんでこれ単体では使い物になりませんが、それはそれ。
画像ファイルを入力するとarc.nsa内の画像ファイルをαチャンネル付きのjpgに変換したものをフォルダ内に作り、音声ファイルを入力するとarc.nsa内の音を鳴らします。
停止と入力すると音楽を止め、取消ボタンを押すと終了します。
付属のarc.nsa内にはtest.bmpとtest.pngだけ入っていますが、適当に各自のarc.nsaも利用できます。

んで、これはウインドウが見えないようにしてNスクを立ち上げていろいろ処理しているわけですが、こんな風に他のツールでNスクを利用する場合なんかは同時起動がネックになりますよねってこと言いたいんですが、そもそもこんな使い方する奴はいないか。
自分で作ったarc.nsaだったら元データがあるわけだからそっちを使わせればいいわけだし、他人が作ったarc.nsaだったらげふげふ。



それはそれとして、見たかったのは通信速度の件です。
(画像作成の時は個々の動作が遅いから参考にしないとして)音楽を演奏させたときのタイムラグを見るに、なでしこ→Nスクはまったく気にならなかったけど、Nスク→なでしこはちょっと気になる遅さです。
どっちもやってることはほとんど変わらないんだけど、csvwriteがネックになっているのかなあ。
Nスク→なでしこの通信で速度が必要な箇所があるようだったらLuaの機能でもうちょっとなんかできないか調べてみます。

自分以外にNスクでNスクの製作補助ツール作ってる人、どれくらいいるのかしら(FAM)

2009.10.13.Tue
以前Nスクについての関連サイト回りまくっていた時にはプラグインやスクリプトや他のプログラムを使った補助ツールは見かけたけど、Nスク使った補助ツールって見かけなかったような。
つか、Nスクを純粋なゲーム以外の使用法ってプログラムそのものを楽しむような使い方しか見かけなかったかも。
時間ができたらまた探してみようかな~。


あ、某所の書き込まれた内容を見て検索してきた方へ。
ペンぷろった~は冬コミ用のゲームの開発に役立たせれるような時期には完成させれそうにないです。
ですので、『そーいうものがあるんだあ』程度に思っていてください。すみません。
決してサボっているわけではなく、自分がへぼなだけです。
毎日試行錯誤してるんで、いくら時間があっても足りない・・・。
今アップされているバージョンはエラーが出る方もいるみたいですし、できるだけ早めにバージョンアップします。


さてさて、Nスクを多重起動ができるようになるかも、ということで実現すれば音楽は今まで通りNスクに全部投げれそうです。
なでしこではoggが演奏できないので、Nスクを起動させないこと前提にするならばここだけHSPと連携させる必要あるんかなあ、とかと思っていたところなので手間が省けてよかった。
まあ、HSPでNスクと同じ方法でループを指示できるようプラグイン調べたり使い方覚えたりに時間かけた後なのでかなり今さら、って感じですが。
もうちょっと早めに多重起動の要望をだしておくべきだったか。

多重起動問題とちょこっと関連して、再び描画ウインドウをNスクにするかなでしこにするかで悩んでます。
メッセージ送信に伴うエラーが起きないなでしこからNスクへの通信法としてなでしこ側でフラグ用のファイルを作り、Nスク側は待ち時間にフラグ用のファイルの存在を監視、存在してたら内容読み込んで最後にフラグ用のファイルを削除ってやり方を試してみたんですが、当初の予想よりもずっと短い間隔で送れたので是が非でもNスクの使用を回避しなきゃいけない理由がかなり少なくなってしまいました。
あとはなでしこのみだとスプライトの管理がえらく楽になることくらいかも。
先日書いたスプライトの上下関係を保持したまま1つのスプライトにスポットライトを当てる、というのも、必ずしも必要なものでもないし。
今はそれ以外の部分を作っているんで、そこを直すまでには決めなければ。



話変わってスポットライト云々のこと。
いつも拝見している永字八法さんのところでスポットライトを実現できそうなプラグインが公開されていたので、早速試してみました。
確かに実現できたし、使いこなせばいろんな演出が可能だと思える素晴らしいものでした。さすが偉い人は使えるものをぱぱっと作ってしまってすごいな~。

・・・でも、Visual C++ 2008 Express Editionで作られたプラグインだったのでMeでは動きませんでした。
おかげでペンぷろでは使えません。
うわ~ん、マイクロソフトのばかー!!


NスクのLuaの機能でスプライトの画像をバッファに取り込めればスプライトを任意に変えれそうなんだけどなあ(できればアルファチャンネルもいじれるように)。
こっちの方法だと上記プラグインの手の届かないこと(永字八法さんでやってた透視眼鏡のようなこととか)もできるようになるし、どちらも存在価値があるような気がする。
気が向いたらまた要望として出してみようかしら。
(追記:その後、これらは機能追加によって実現されたみたいです。これで掲示板に書き込んでまで要望する大義名分はなくなったなあ。)

なでしこで完全なα合成できないんだった・・・(FAM)

2009.10.10.Sat
連休だ、作るぞーとがんばっていて、ちょっと疑問になっていたことを試した結果が次の図。

200910101.jpg

一番右のマスク画像(グラデーションをかけたやつ)で画像をα合成をしようとしたもの。
本当は一番左のようにしたいのですが、実際の結果は中央のように色がおかしくなってしまいます。
これはなでしこで画像の乗算合成ができないのでAND合成とOR合成を活用して透過させているんですが、これだと透過はできても細かい色のα合成がうまくできないみたいなのです。
ビット演算の結果が変わってくるからかも、と思いましたが、詳しいことはわからんし、わかっても対処できるものじゃなさげなので無視。

だいたい透過している見えますし、グラデーションをつかわず普通の立ち絵をα合成で表示させる分には申し分なさげにみえるので、今回はこのままで行くことにします。
ただし、将来的にはペンぷろの描画ウインドウにあたる部分自体を他のプログラムに頼ることになるかもしれません。なでしこで統一するメリットが大きいのでできればやりたくないですが。
もしくは望んだ画像だけ別画面に写す挙動にするか、ですね。
普段はそのまま編集、スクリーンショットのように見栄えが必要な時は画面の構成情報をNスクに移してちゃんとした画像を反映させる、とか。
いろんな手間を考えたら完成するまではこの方式になりそうです。

できる限りNスクを同時に使えるようになる方向に(FAM)

2009.10.09.Fri
Nスクの二重起動禁止っていらないと思いませんか?
これがなければペンぷろと制作中のゲームを平行して起動できるのに、と前から思っていましたが、描画ウインドウをなでしこに任せて常時起動させておく必要がなくなってからはますますその想いが強くなりまして。
思い余っていろいろいじった結果、一部の必須部分(nsa.arcがからむ部分)以外はNスクを使用しないことになり、無事ペンぷろとNスクを同時起動できるようになりました。

nsa.arcがからむ部分は画像を取り出してキャッシュ作る時と音楽を演奏する時。
画像は最初に一括してキャッシュ作ってしまえるし、nsa.arc内のファイル使って音楽鳴らすことにした場合に同時起動できないのが不満ならnsa.arc使わずに裸のファイルから再生すればいいわけだし。
まあユーザーにそこまで不便を強いる仕様ではなくなった、と思います。


それにしても、Nスクの機能をNスク抜きで実現しようとするたびにNスクの偉大さがわかりますね。
なにげな~く使えるようになっている機能を他の言語で実現しようとしたら面倒なことになることも少なくないです。
ペンぷろの基本概念として「Nスクでできることはペンぷろでもやる」っていうのがあるんですが、Nスクを普段起動させない設定にしたおかげでその実現がちょいと難しくなりました。
ま、それはあくまでも目標と割り切ってマニュアル等ツールとしての体裁を作るのが優先すべきですがね。

画面の再現も問題なし(FAM)

2009.10.03.Sat
試しに10体以上の立ち絵を並べてぐりぐりっとドラッグさせても大丈夫でした。
自分の古いノパソではある程度立ち絵が多くなるとドラッグした際に画像が1拍ぐらい遅れてついてくる感じになりましたが、ちゃんとしたスペックのパソコンでは立ち絵が多くなってもカーソルの位置と同調するように移動してましたし、そもそも素早い書き込みが要求されるような場面もここくらいなんで許容範囲内かなと。
明日からNスク側でやっていた画像処理をなでしこでやるようプログラムを書き換えていきます。
これでnsa.arcから(まっとうな方法で)音声ファイルを取り出せるようなら裏でNスクを立ち上げる必要もなくなるのですが。


画像処理をなでしこでやることで実現できるようになったことの1つにスプライトの上下関係を保持したまま1つのスプライトにスポットライトを当てれるってのがあります。

200910030.jpg
この画像が

200910031.jpg
こんな風にできるってこと。
今までは選択したスプライトを最前面にもってきてそれ以外のスプライトに効果をかけるしかなかったわけですが上下関係を保持しながらのほうが都合がいい場合もあるわけで。
従来の最前面においやるほうがわかりやすいという人もいるかもなのでどちらでも選択できるようにしますが。

それ以外にもいろいろとやりたいこともありますが、いつもの「完成しないうちに作り直したくなっちゃう病」が完全発動する前に止めるようにします。
自分のモチベーションを保つために、画像処理の変更とそこそこの機能を追加したらペンぷろった~を更新します。
多分、ゲーム内時間の設定を変更したら画像も自動的に挿し変わる機能が追加されるかと。
前回凍結した機能を次回復活できるかは検証する体力次第です。

nsa.arcの中の画像を裸の状態に保存しなおすのは問題なしでした(FAM)

2009.10.01.Thu
ついでにいえばLua使う必要すらなかった(使える部分がなかったともいう)。
ファイルそのものを直接吐き出すことができなかったのでファイル名を直接指定して画面表示し、スクリーンショットを保存してなでしこで各画像の大きさに切り取り、それをキャッシュとして保存するという工程にしました。これでnsa.arcの中の画像をなでしこで利用できることはわかった。
ペンぷろを使うならどのみちファイル名は登録しなきゃいけないからこの作業で手間が増えることもないし、著作権的(?)にも問題ないと思う。
キャッシュ作成は一度で済むからそれに必要な時間もまあ、我慢できる程度だろう。
あえていえばよけいに容量が食うのが問題ですが、それならnsa.arcに入れる前のデータを使えということですし。

キャッシュ作成する時、一時的にスクリーンショット画像を大量に作るために起こりうる空き容量対策はペンぷろ側でやっておいたほうがよさげ。
試しに800×600のスクリーンショット500枚用意したら700M近くも食ったので、ただ必要な分作るだけ作って途中で空き容量不足でエラー起きる可能性を無視するよりも、空き容量少ないようなら自動的にこまめにキャッシュに変換していらないスクリーンショットを順番に削除していくようにしたほうが親切だろう(本当はまとめて変換のほうが早くていいのですが)。


なでしこでNスクの画面の再現ができるかの調査はまだなので、今週末までには結論づけなければ。
明日(もう今日か)から仕事なんで進行は9月の時より遅くなりますが、目標持ち続けながら作業して少しずつ自分に課したノルマを達成していきます。