上記の広告は１ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

一ヶ月位前になるが、上司から２ＤＣＧの回転描画ルーチンを作成するよう言われた。
無論私は色々とぐぐってみたのだが、どうも具体的な方法を書いているサイトが見あたらなかったのでこれから２回位にわけて私が実装した方法を書いてみたいと思う。
その前に、2DCGの回転描画の必要性についてなんだけど、実のところ私の場合では実際には要らないんじゃないか？と今でも思わずにはいられない。
というのも、単に矩形をディスプレイ上に回転表示するだけという事なのでPlgBltで事足りるのだ。
実際回転描画ルーチンを実装するまではPlgBltで描画していたのだし、PlgBltが上手く機能しないカードを今のところ見ていないので結構多くの場合にPlgBltで十分なんじゃなかろうか？と思っているのだがどうなんだろう？
まぁともあれ、社内用ツールではなく納品する為の物なのでどんな環境でも動く事が保証されてるわけじゃないPlgBltを嫌ったようで、2DCG回転ルーチンを書かされる羽目になったわけだ。
で、回転なんだけど、どうやって実装すれば良いかをまず考えてみて欲しい。
もし元画像の各ピクセルに単純に回転計算を施して描画すれば済むじゃん、と思った人はきっと実際に回転描画ルーチンを実装した事の無い人だろう。
じつのところ、それでは上手く行かないのだ。
回転計算すると当然座標に小数部が出てくるわけなんだけど、実際の画面には小数点のついたピクセル座標なんてものは存在しない。
従って、単純にピクセルに座標回転計算を施しただけでは微妙な計算誤差によりほぼ必ず微妙に穴が空いた画像になる。
ではどうすれば良いのか？
それをこれから書いていく。

さて、ピクセルに回転計算を施しただけでは上手く行かない事はわかったと思うが、では回転計算は要らないのか？
無論そんな事はない。
最初にやらなければいけないのはやっぱり回転計算なのだ。
回転する画像データの４頂点に対して移動/拡大/回転/フリップなどの計算をまず施しておく。
わかっていると思うが、これらの計算は順序に注意しなければならない。
座標移動を施してから回転させると、移動座標ごと回転する。
それが目的なら構わないが、回転と移動とは別々に管理したい場合は拡大縮小、回転を計算した後で移動を行わなければならない。
ちなみに拡大縮小と回転は同時に行う事が出来る。
単純に回転計算でsin/cosを行う際に拡大/縮小率をかけてやればよい。

void rotate(double degree) {
//	標準のsinとかはradianベースなのでradianに変換しなければならない
	double rad ;
	rad = degree * 0.017453292519943295769236907684886 ;
	para[0][0] = cos(rad) ;
	para[1][0] = sin(rad) ;
	para[0][1] = sin(rad) * - 1 ;
	para[1][1] = cos(rad) ;
}

//	XY夫々の拡大率を指定してマトリクスを初期化(2x2)
void scale(double xScale, double yScale) {
	para[0][0] = xScale ;
	para[0][1] = 0 ;
	para[1][0] = 0 ;
	para[1][1] = yScale ;
}

//	現在の回転マトリクスに拡縮要素をかけあわせる
void addScaleAttribute(double xScale, double yScale) {
	para[0][0] *= xScale ;
	para[0][1] *= yScale ;
	para[1][0] *= xScale ;
	para[1][1] *= yScale ;
}

こんな感じのmatrix計算ルーチンを作ってやれば簡単だろう。
多分ここまでは誰でも出来ると思うので、この辺りはサクサク行こう。
頂点を回転させた後は、その頂点が描く描画範囲を割り出す作業に入る事になる。
つまり頂点座標をラスタライズ処理するわけだ。
という辺りで次回にまわしたいと思うｗｗｗ

最近私が経験した失敗談を書いてみる。

InvalidateRectをして、画面が更新されないなぁと思って調べてみたらメッセージが沢山溜まっていてWM_PAINTがきてなかった、という事があった。
これの対処の為にUpdateWindowを差し入れてみたんだが、これが失敗の元だった。
UpdateWindowは、それを実行した段階でWM_PAINTを強制的に実行するわけなんだが、ちょっと待って欲しい。
元々WM_PAINTがきてないのはメッセージが沢山溜まっていた為なんだから、実際にはそっちをなんとかしないといけなかったんだけど、対処療法的にUpdateWindowを入れてしまったもんだから表面上は上手い事動いているように見えても裏はすごい事になってしまっていた。
もうひっきりなしにメッセージが発行されまくり、しかも(比較的重い処理である)WM_PAINTが頻繁に実行されてしまうもんだから実行速度は格段に落ちていき、しかもどこかでメッセージ処理が滞ってしまうと途端に処理されないメッセージの山が溜まっていく事になる。
実際、ちょっと重い処理を実行させてしまうとメッセージ処理のせいでしばらく止まってしまう状態になってしまった。
結局のところ、無駄なメッセージ発行をある程度減らし、その上でUpdateWindowを全部取っ払ってやると嘘のようにスムーズに動くようになった。
つまるところ、その場を対処する為にUpdateWindowをしたのがそもそもの失敗であり、何かに対して対処する場合はその場しのぎではなく根本の原因を取り除かないと結局上手く行かない、という話でした。

さて、久々にエロゲの感想でも書いてみよう。
前作、Honey Comingの感想を書いた関係上、これも書いとくべきかな〜と思ったのがHoney Comingのファンディスク「@Honey Coming Royal Sweet」
まぁ苺ちゃんのシナリオがあるって事で購入に踏み切ったわけですが、正直微妙だった。
というのも、シナリオという物が無く、イベントが沢山並んでるだけで時系列的にどの順番で進めれば良いのか全く不明な為純粋に楽しむのが中々難しいというのが原因。
今作では日常イベント、恋愛授業イベント、Ｈイベントとそれぞれのカテゴリーで日常１、２とか恋愛授業１，２みたいな感じで並んでいるのだが、日常イベントの中では一応前から順番に並んでいるっぽいものの日常イベントと恋愛授業イベントの時系列での関係が不明となっている。
実際苺シナリオではどう考えても日常１と日常２の間に恋愛授業１が挟まると思うんだが、だからといってじゃあ日常２と３の間に恋愛授業２があるのかといえば(まぁそもそも苺には恋愛授業２は無いんだが)どうやらそういうわけでもなさそうっぽい。
そういった関係上、時系列で順番に日常イベントや恋愛授業イベントを楽しんでいくというのが難しく、その為前後ばらばらになったイベントを頭の中で再構成する羽目になりシナリオを純粋に楽しむのが難しくなっている。
実際問題として、１つのイベントの長さはセーブが特に不要な程度の長さになっており、またどのイベントでもいつでも好きに楽しめるというのは一々イベントの前でセーブを入れたりする必要が無いので良い事ではあるのだが、しかし時系列順で楽しむのが難しいというのはやはり頂けない。
こういった、イベントの頭出し機能をやりたいのであれば素直にセレンやサーカスのような、超高機能回想機能として実装すべきであって最初から回想モード状態でやらせるというのはやはり違うと思うのだ。
ちなみに肝心のシナリオそのものは悪くない。
まだ苺シナリオと朝陽シナリオしか完遂していないが、全体的にファンディスクとして必要十分と言える程度のシナリオは入っていると思う。
ただそれだけに、純粋に楽しむのに障害となる要因があるのがやはり惜しい。

最近やっとローランドRMS音楽教室がやって欲しい事が分かってきた気がする。
以前私はローランドRMS音楽教室の講師資格がオーディオを扱わない云々等と書いたが、そうじゃなかった。
オーディオを扱わないのではなく、ただ単に使用楽器をローランドのDTM機器に限定して、その上で最高のMIDIデータ、ではなく最高の曲データを作る事を求めているんだった。
最終的にオーディオにするにしても、元データであるMIDIの状態から良い物であるに超した事は無いので、結局それを求めているのだろう。
であるなら、こちらもそれとしてSC8850(教室で使用している音源がこれ。自宅ではSC88Proしかないんでそれを使ってるが)用の最高のデータを作ろうという気にもなる。
ただ、NRPNの連続的変化の編集なんかもしたいんだが、SONARでやろうとすると直線しか引けないし余計なデータを間引くのも手動でしか出来ないんで、CALが使いたかったのだがマニュアルには定義されてないので使えないと思った。
でも違ったみたい。
今、CALのリファレンスマニュアルとしてはSONARの公式サイトから落とせる物しか無いと思うんだけど、これには載っていないがEvent.Kindに対してNRPNという値が密かに定義されている。
ただ、NRPNイベントの時の種類、値等がどうやって引けるのかがよくわからない。
どうもNote変数になにやら値が設定されているっぽいんだが……違うみたい。
どうやらただ単に直前のNOTEイベントの値がそのまま残ってるだけみたいだ。
であるならやはりNRPN用変数があってよさそうなんだが、わからん……
誰か知らないか？

なんとなく自分に当てはまるような気がして、インターネット上のアスペルガー症候群診断テストをやってみた。
結果、閾値を余裕でオーバーしてアスペルガー症候群と診断されたｗ
いや、まぁいいんだけどさ。
友人作るのは苦手だし、間違っても社交的とは言えない性格と自負しているからな。
ただ、この状態で元来目指していた音楽教室なんかを開こうとするのは如何な物かと自分でちょっと考えてしまったｗ
自閉気味な人間がそんな比較的社交的な人間がやるような職につくと果たしてどうなるコトやら。
ひょっとしたら今のままプログラマやってる方が色々良いのかなぁ。
でも忙しいんだよな、プログラマってｗ

並んでいるオブジェクトを範囲選択する為にラバーバンドを実装する事になって、エクスプローラーみたいな中が青いラバーバンドを簡単に作ってみたかったのでレイヤーウィンドウを使って実装してみた。
思った通り、意外と簡単に見た目の良いラバーバンド効果が実装できたんだけど、問題点が１つあった。
ラバーバンドをウィンドウで実装しているせいで、ラバーバンドが出ている時にはアプリケーションのウィンドウが非アクティブになってしまうのだｗ
これってEnableWindowでラバーバンドウィンドウをDisableにしてやれば問題無くなったりしないかなぁ？
まぁ、ラバーバンドが終わればアクティブに戻るのでそれ程の問題でもないんだけど、見た目がね。
ちなみにWS_CHILDをつければいいじゃんというのは無い。
何故ならチャイルド属性を持ったレイヤーウィンドウというのはどうやら作れないっぽいから。
WS_EX_LAYERDを指定している時にWS_CHILDを指定するとCreateWindowExはNULLを返す。
GetLastErrorをとってもエラーらしきエラーコードは返さない(操作は正常に終了した、になる)

何故だかわからないが、タイトルバーにタイトルが出ないようにしたレイヤーウィンドウ(オーナーを持たせたりWS_EX_TOOLWINDOW属性を持たせたり)を複数作ると、どんな内容を描画しようとしていても真っ白のウィンドウになる。
これが、タイトルバーに出てしまう、普通の、オーナーを持たないポップアップ等のウィンドウだと複数作っても普通に表示されるのだが、タイトルバーに出さないようにしようとすると途端に真っ白になる。
原因はわからないのだけど、これこのままだと不便だなぁ。
まぁカラーキー等を使って色々と出来るのは出来るんだけど、複数作れた方が絶対楽なんだけどなぁｗ

デザイナーさんにグラフィック作ってもらう為の素材として、プログラムで書いてる部品の一部をビットマップで出そうとしたんだけどCreateDIBSectionで作ったHBITMAPいくら試してもクリップボードにちゃんと入らない。
その時は結局CreateCompatibleBitmapで同サイズのDDBを作ってCreateDIBSectionで作ったビットマップからコピーして、そのDDBをクリップボードに入れたら普通に使えたんだけど、結局多分CreateDIBSectionで作ったHBITMAPってのは何かシステムに特殊な意味を持つ値なのだろう。
そういえば似たような事例がプロセスハンドルでもあった。
GetCurrentProcessで得られるハンドルはHANDLE型ではあるが擬似ハンドルで、みてみると大抵同じ値になっていた。
なのでそのままプロセスハンドルとして使うとちょっと挙動がおかしくなる場面もあったのだがもしかしたらCreateDIBSectionで得られるハンドルも普通とはちょっと違うのかも？
まぁ、値自体は特殊な定数とかそういう物ではないのでハンドルが実際に指しているオブジェクトが通常のHBITMAPが指している物とは違うとかそういう事なのかもしれないけど。
(確か、ハンドルってのはなにかのポインタだった気がする)

新しい仕事に就き忙しい毎日を送っている今でも、ローランドRMS音楽教室のコンピューターミュージック科講師養成コースという物に通っているのだが、これについてちょっと思った事があるので書いてみる。
まず第１に言いたい事。
ローランドRMS音楽教室におけるコンピューターミュージック講師の資格試験、それからそれに伴い、養成コースでもそうなんだけど標準の音源としてローランドのDTM音源、を採用している。
まぁ、DTM講師の試験なんだからある意味当たり前なのかもしれないのだけど、でもちょっと待って欲しい。
ここでいうDTM音源というのは、ローランドやヤマハが昔出していた、GSやXGに対応したMIDIのマルチティンバー音源の事を指す。
これは実に便利な代物で、曲のスケッチなんかを作りたいと思った時にあまり音に悩まずサクサク作れて良い物なんだけれど、時代はソフトシンセ主流になりつつあり今ではもう生産されていない代物となっている。
そう、生産されていない、廃盤商品なのだ。
だから、これらの音源を正規の流通ルートで入手する手段が無かったりするわけだ。
これって良いのか？
講師の試験なんで、当然曲をMIDIで打ち込んでそれを提出する試験なんかもあったりするわけなんだけど、その為に使う音源はもう普通に買う事が出来ない音源ときたもんだ。
この時点でいきなりハードルがあるってのはどうなのよ？と思わずにはいられない。
私の場合は幸い？にも昔買った物を今でも使っていたから問題無かったんだけれど、音楽はずっとやっててコンピュータでの音楽もやってたけどROLANDのMIDI音源は持ってない人、とか普通にいそうな気がするんだけど。
(Rolandは持ってないけどYamahaは持ってる、なんて人も普通にいそうな気がする、というか実際私の知り合いに一人いる)

もう１つ言いたい事。
講師試験がそうなもんで、講師養成コースも自然とそうなるんだけど、そしてこれは上に書いたことにも関連する事なんだけれど、作品の主体がMIDIベースだって事。
正直、ソフトシンセを山ほどつけてくる事で有名なDAW「SONAR」のメーカーの音楽教室のDTM講師とは思えない、オーディオという概念を殆ど無視してもうほんとにMIDIだけで１本作っちゃうのだ。
当然打ち込んだ後でイコライザをかけたり逆再生かましてみたりといったオーディオデータ用の技は一切使えない。
DTMという言葉は、確かに昔はMIDIで音楽をやる事だった。
でも今は違うだろ？
今の時代にDTMって言って、期待するのは寧ろオーディオ関連のテクニックじゃないのか？
これって俺の感覚がおかしいのか？DTMって言ったら今でもMIDI主体での音楽活動の事を指すのか？
更に言えばそもそも講師の資格名はDTM講師じゃなくてコンピューターミュージック講師だ。
ますますオーディオを含めない所に違和感を持ってしまう。
ついでに言うと、このMIDI打ち込みの方向性。
私は昔、フリーゲームやHP用にフリーのMIDI素材集を提供していた事があった。
その時に気をつけていた事は、兎に角どんな音源で聴いても破綻しないデータを作る事。
Rolandの音源で聴いたら凄く格好よく聞こえるけど、Yamahaの音源で聴いたらデタラメだった、なんて事は非常によくある。
だからそういった点について特に注意していたんだけど、流石にそこはローランドのDTM教室。

音源の互換性なんて概念は最初から無視ですｗｗｗ

「この音源」で聴いて格好よく聞こえるデータ、という物を作る事が求められる。
これに最初戸惑ったものだ。
何しろ、どんな音源で聴いても破綻しないように作る為には、まず基本としてNRPNは使わないこと、となる。
当然だな、NRPN使っちゃうともうそれだけでそのデータの対照機種が絞られてしまうから、目指す方向性とはかけ離れてしまう。
でもローランドRMS音楽教室のDTM講師試験では、寧ろバンバン使っていった方がより好印象らしい。
まぁ、確かにこういった機能まで使って、音源を骨までしゃぶりつくしているという所を見せた方が良いというのはなんとなく、言わんとしている所はわからないでもないのだが、だったら最初からMIDIを基本とするんじゃなくてソフトシンセでもなんでも使って最終的に格好良いオーディオデータを作るテクニックの試験にしろよ、と思わなくもない。
機種互換性の無いMIDIデータを作るという行為に今の時代、果たしてどれだけのニーズがあるのだろうか？
全体的な印象としては、なんだか時代遅れなテクニックとニーズを対象にした資格試験だなぁと思った。
正直、もう今の時代のニーズにあんまりあってないんじゃないのかなぁ？
多分今の時代、DTM音源を格好よく鳴らすテクニックよりも、初音ミクを可愛らしく唄わせるテクニックの方がウケルんじゃなかろうかと思わずにはいられない。

マニフェストファイルでdependentAssemblyを設定し、Common-ControlsのVer6を使うように指定すると、何故かプログレスバーでスムーススタイルを設定していてもスムース表示にならない。
これってXPのテーマか何かと関係あるんだろうか？
というか、この状態でプログレスバーをスムースで表示するにはどうするんだ？