日記ちゃんaiff(2)

　mmioDescendが使えそうだなと試してたんだけど、これがぜんぜんうまく動かない。
ビッグエンディアンがいけないのか、関係ないのか分からんが
しょっぱなの'FORM'を'MROF'とかやっても無理だった。
　
　しかたがないので各チャンクの頭に飛べるよう以下みたいな、
4バイト一致するデータへのアドレスを取得する関数を書いて、自分でreadしてテストしてみたところうまく読み込めた。
高速化とかはしてない。変数名は自分でもどうかと思うがテストだったからつい。
最初はstrstr()を使おうとしたんだけどバイナリに0があったら終わるということ失念してたよ……。


char* memSearch( char* buf, int bufSize, DWORD bin )
{
  const int n = bufSize - sizeof(bin);
  for (int i=0; i<n; ++i)
  {
    DWORD now = static_cast(buf[0]) |
      static_cast(buf[1])>>8 |
      static_cast(buf[2])>>16 |
      static_cast(buf[3])>>24;
    if ( now == bin ) return buf;
    buf++;
  }
 
  return NULL;
}


　
　これで各チャンクのデータは取れるようになったはずなので、
バイトオーダーと80bit浮動小数点数をどうにかすれば読み込み可能になるかも。
CommonChunkが18Byteとサイズが半端でちょっとひっかかった。
構造体にすると20Byteに肥大化する。

日記ちゃんaiff

　ビッグエンディアンをリトルエンディアンに変更する必要があるのと、
80bitの浮動小数点数を用意するのが大変面倒だ。
80bitってどうするんだ……、ご自分で頑張れって感じか。
　
　80を64に落とすのは案外簡単かも分からん。
15bitの仮数部をげたぬがせたあと11bitにしてげたを履かせなおす、
指数は52bitだけコピーとかでいけないかな。
あふれちゃう部分はもとより表現不能だったんだといいわけして。

型	全体	符号	仮数	指数	げた
float	32	1	8	23	127
double	64	1	11	52	1023
extended	80	1	15	64	16383

　
　ああ、データはそのままコピーすりゃいいやとか思ってたらぜんぜんバイナリ違うからどういうことかと思ったら、
無音がwavだと0x80なのに、aiffだと0x00なのね。signedとunsignedのちがいかなにかか。
（8bitの場合）
16bitはwavでもsignedだからバイトオーダーに気を使うだけでいいと思われる
　
　しかしこう勉強だの学習だのは
やればやるほど学習範囲が増えて次第に把握できなくなって、にぎゃーってなるんだけど、
普通の人はどう回避してるんだろうか。
自分の場合寝ると直るけど、いちいち睡眠とるのはかなりコストが高い。うむ。

日記ちゃん

　複数のaifファイルをwavに変換したい。
キーボードにも触りたくないし、アプリケーションのインストールなんてもってのほか。
アンインストールが面倒だからね。
という要望に答えてくれるソフトを探してみたが見つからなかった。
　D&Dで.aifを.wavにリネームしつつ同フォルダに吐き出してくれればそれでいいのに、
たいてい保存しますか？とかいってウィンドウ出してきて、
しかもファイル名が入力されてなかったり.aifまで全部入ってたりで超使いにくい！　
　
　午後のこ～だで変換できると記述をみつけたが、wavではなくmp3だった。
でも、これぐらいサクッといってくれるのはないものか。インストールいるけど。
　Winampでwav出力にすれば、同じくらい簡単に変換できそうだが、
ちょっと前にfoobar2000に乗り換えてしまったので実験できなかった。タイミングが悪かった。
　
　妥協案としてoggdropXPdで高音質なoggに変換後、wavに再変換というのが今のところ一番スマート。
インストールもリネーム作業もいらず、複数ファイルD&Dするだけ。
ただ、理屈の上では音がちょっと悪くなるのが気になる。
　
　自分で作ろうかとAIFFのファイルフォーマットを探してみたが、これが見つからない。
かなり単純らしいから頑張れば解析できそうではある。
が、半日頑張ってみたもののダメだった。根性値が不足してる。
とりあえずお昼ごはんだ。
　
　おお、ようやく生きてるサイト見つけた。
Sound File Formats
http://nagasm.suac.net/ASL/sound05/#aiff-1

日記ちゃんデモ

　デモ画面関係を作成、タイトルで放置するとデモ画面に移行する。
うっかり上下入力をスルーして選択直前にデモ画面にいっちゃうといった初歩的なミスもありつつ、
なんやかんやと実装してみればあっという間だわ。
どう組むか考える時間が一番長い。4日ぐらいかかる。

小節数から再生時間を計算する

　テンポ、拍子、小節数から演奏時間を計算します。
　
計算式は
　60*拍子*小節数/テンポ
　
*要javascript
　

BPM

拍子

小節



秒

Frame

　
例
　テンポ120、拍子４、小節数８で計算すると16秒
　テンポ150、拍子４、小節数64だと102.4秒
となります。
　
　ゲームに使う場合はさらに60をかけて、秒をフレーム数に変換してから使う。
32小節目で中ボスをだそうとするとステージ時開始から3072F目に、
64小節目でボスをだすなら6144Fに、といった感じに使えます。
処理落ちを多少考慮する必要があるかもしれないけど。
　
/** 20110316追記 */
　Frame出力を追加。Frameは秒に60かけた値です。秒→FPS。

日記ちゃん

　メモリマップドファイルを使用したパックファイル読み込みを仮作成してみたが、
最初にパックファイル内のファイルリストを作成する部分がかなり遅くなった。
56個ファイルが含まれているパックファイルのリストを作るのに、
今まで50msかかっていたのが110ms程度と、2倍程度の速度低下。
ReadFileの代わりにMemoryCopyを使ったが却って遅くなるみたい。
　
　今、書きながら思いついたが、
ファイルマッピングするまえにリストを作ればこれまでどおりの処理速度を維持できそうな気がする。
ファイルマッピング後はReadFileとかが使えなくなるのだけど、
ファイルマッピング前に使えるだけ使ってしまおうという発想はどうかな。
msdnを見た感じ、開いた直後のファイルじゃないとマップしちゃだめよとは書いてないっぽいし。
　
　ファイル全体をいったんメモリに読み込んでそこから各種処理する場合にメモリマップドファイルは向いていると思われるが、
たとえばCSVデータの読み込みなんかだと1Byteづつデータにアクセスするから普通にメモリに読んでからのほうが速そうだ。
画像データとかある程度まとまりで読み込むデータだと恩恵がありそうだけど。
もっとシンプルにメモリの節約になるぐらいなのかね。ひょっとして。
うーん、思ってたより使いどころに困る。プロセス間で共有するでもなし。
　
　唯一恩恵を受けられる効果音の読み込み部分に使用してみた。
いったんメモリに読み込んでからoggをwavに変換、その後DirectSoundにデータを渡すという処理を
ファイルのままoggをwavに変換、という処理に変更したところ処理速度大差なしだった。
　ウィンドウズにメモリを貰わず、
あらかじめアプリケーションで確保した作業用のメモリに対して行うので、
メモリ確保の処理もほぼ最速。
結局ファイルを読み込む速度に引きずられるので差が出ないようで。
しかも効果音読み込みは起動時のロゴ表示中に裏で行うから別に速い必要はないという。
　メモリからの読み込みとファイルからの読み込みを統一できるから、
プログラムの記述面で楽が出来るとかそういう感じのありがたみは受けられる。
が、もういまさらなのが悲しい。

日記ちゃん

　-27乗のほう、
XPが出た直後ぐらいのノートPCでデバッグしてみたところ、
等倍表示で60fps、４倍表示では8FPS程度で動いた。
PatriotDarkより処理をかなり食ってるが、
固定小数点数を浮動小数点数にかえてるのが影響してたりするのかな。まあいいか。
　
　拡大すると遅くなるなあと実感したところで、
拡大表示に使用した関数を変えたら速度は変化するかな？　と思いためしてみた。
DIBをHDCに描画するのに　StretchDIBits
DIBSectionをHDCに描画　StretchBlt
を使っているがどちらでもいけるので、両方試してみたところ、差はなかった。
　
　音をまるっとカットするとどうなるかなと思い、
DirectSoundを使用しない版も作ってみたが処理速度に変化は見られなかった。
音はあまり影響を与えていないらしい。
　
　あれこれさわっていたら、時折処理速度がアップする謎現象が発生。
なんなの？　といろいろ試してみてたら
マウスカーソルをウィンドウの上においておくと4倍表示でも60FPSを維持するらしい。
意味はわからんがこのPCは何かおかしいということはわかった。
　
　ちなみにLUXのほうは０FPSで、動くとかそういう次元じゃなかったな。
一応タイトルの表示までは出来たけど。
　
　
　メモリマップドの存在を今更思い出してちょいちょい調べてみてるが、これはいいな！　
ニヨニヨする。

「いめーじぺたぺた」 v1.07

「いめーじぺたぺた」v1.07
http://cid-8cd7cf5ea9fbca55.office.live.com/self.aspx/Public/program/imgPt107.zip
size: 1.01 MB
　
　
■更新履歴
2010-08-21 ver1.07
　　「範囲外を超えて貼り付け」機能を追加
　　「半透明合成」機能を追加
　　「下地を不透明で半透明合成」機能を追加
　　「拡大縮小処理の動作」設定を可能に
　
　
　
　今回はどうにも気になってた機能を追加実装。
特に拡大縮小あたりはかなり不便だったので大雑把に４タイプ選択できるようにして幅を持たせた。
　あと半透明は割りと不要だとも思うが、
パーツもちの敵グラの位置を確認するときいちいち別のソフトで確かめてたのでデバッグ要員として実装。
プログラムでは大雑把な位置で表示するようにして、細かい位置調整はグラフィック側で行うのが吉だと最近気が付いた。
　さすがにグラフィックソフトとして計算誤差が大きいのは不味いかと思って、
不動小数点数を使い誤差を小さくしようと試みた所、思ったより高速に処理できて驚く。
　
　付箋紙に次にやること書いてをディスプレイにはりつけてるのだけど、凄い邪魔。
俺マジ頭悪いな！

日記ちゃん

　一人プレイ専用のゲーム場合、ゲームパッドのIDを設定できる必要ってあまりないなと今気が付いた。
入力されたパッドIDをそのままつかえよ。

日記ちゃん芋洗い

　某ゲームみたくオブジェクト同士がぶつかり合いつつも押し寄せてくる感じの実装を試験中。
画面に出したオブジェクトが画面内のオブジェクトにはじかれて画面から消えていく悪夢にどう立ち向かえばいいんだ。
　某芋は画面後ろに方向に重力がかかっているようで、うまいことやってる。
　
　組んでみたはいいが、これ使うの難しいな。
常時敵破壊状態でマンネリしやすい。敵がでてきてもプレッシャーがまぎれて半減する感じ。
　
　作用反作用の法則を馬鹿正直に適用してみたもののしっくり来ないので、
他のオブジェクトにあたったら自分だけ吹っ飛ぶってプログラムにしたらぼちぼちの動作で処理も食わない感じに落ち着いた。
　
　岩を大中小それぞれ作成し、大を壊したら中と小に分解するといったオーソドックスな部分を実装。
これだけしてようやくつまらなさが薄れてくるが、ゲームとして恥ずかしくないレベルにするにはさらに岩をつかむ敵だとか演出だとかを入れていかねばなるまい。
　でもまあ連続で敵を倒すと倍率があがるシステムと相性がよくて、
じゃんがじゃんが倍率あがる割りに点数は伸びない雑魚としての価値はありあり。
岩で自由に動けないから敵を出すとすぐ詰むので難易度調整的には　なしなし。
　
　ときおりBGMのロードに失敗するのかBGMタイミングでフリーズするのが気になる。
５０回に１回ぐらいで発生するからデバッグもろくに出来ない。

日記ちゃん

　録画テストとyoutubeへのアップロードテスト。
低解像度の恩恵をこんなところで受けるとは思わなかった。ノートPCでひょいひょい録画。
生成した生aviファイルをそのまま転送、youtubeはとりあえず２Gまで対応してるからエンコードいらずでこれはありがたい。
　録画にはカハマルカの瞳v3.3を使った。20F設定。
30Fでも試してみたが音ずれがひどかったのと点滅処理してる部分が不安定だった。
音はあとで自分で乗せないといけないもんだとおもってたから、ちゃっかり録音されてて吃驚した。手間要らず。
　
　たぶん携帯でディスプレイ越しに撮ったほうが綺麗なんじゃないかと思う。
あとyoutubeって検索しても動画全然でてこないよなと常々おもってたが設定で限定公開できるのね。
皆が知らないおもしろい動画があったりするのかもしれないと夢が広がるが、広がるだけで特に意味はないな見られないし。

日記ちゃんチカチカ

　いままで液晶ディスプレイだったから分からなかったけど、
CRTだと1Fおきの点滅ってかなりちかちかしてうざいのね。
液晶が残像してるのをまじまじと体感したわ。
大昔に音ゲーをプレイしてたときはオブジェクトに残像がのこっててこりゃ厳しい！　と思ったものだ。思っただけ。
　
　一応対策しないと不味いかなと思うが、16色じゃあ半透明不可能だし、
点滅しないようにすると敵が隠れて見えなくなるしで打つ手が余りない。
ネスケ全盛期の頃ややはやった、画像を格子状にする擬似半透明とかどうだろう。
まあ、やってみないとわからんか。

　ああああ、格子状だと上からちょっとずらして描画しただけで穴がうまっちゃうからだめかも。

　

　低解像度だと1ドットが大変重要なので除去してしまうと大変に大変なことになる。
ということがわかった。
何が書いてあるか分かるようにするため、除去しないパターンも組み込み、
格子A → 格子B → 格子なし　と、3フレームでパターンにすることにした。
格子Bは格子Aを横に1ドットずらし、格子パターンをかえたもの。
　つまり
■□■
□■□
■□■
と
□■□
■□■
□■□
の違い。
　
格子A → 格子Bだけではいまひとつ文字が読めない。
格子A → 格子なしではあまり下が透けて見えない。
と地味に試行錯誤が必要だった。
　
　それなりにがんばったものの結局ちかちかするので無駄だったなあ。
なかったことに。
　

　2面を実装中。
宇宙は表示物が余りなくて背景作成が難しい。
地球、月、太陽ぐらいしかないんじゃないか、周辺だと。
カメラワークで何とかごまかすしかないが、ぐりぐりうごかすとそれはそれで邪魔になるから、
大きいは正義でごまかす。
　
　

日記ちゃん

　ここにきてノートPCのディスプレイが死亡！
マジいい加減にしろよ富士通といいたいところだけど、6年稼動じゃあしょうがないか。
物置からCRTもってきてつないだ。
おもしろいことに電気とおして少し暖めないと表示されない。80年代か！

日記ちゃん

__argc, __argvだとリンクにスペースが含まれたファイルで地味に誤作動するのね……。

　修正しようと思ったら再現性がなくなった。なんなの。