そして、このソフト、絵の周りの色選択ツールやペン選択ツールなどのそれぞれのウィンドウが、
それぞれ独立して動くような仕掛けになっていて、
キャンバスやレイヤーが格納されているメイン部分（カーネル）には内部定義してあるメッセージを飛ばしてやりとりする構造となっています。
また、頻繁にアクセスするオブジェクトに関してはエクスポートされている関数を呼び出すことでアクセスできるようになっています。

そしてそして、ペンについても同様の構造になっていて、それぞれが独立した物体になってます。

なんでそんな構造にしたのかというと、将来的にプラグイン方式を付けたいと思ったため。
そして、絵がへたっぴで、授業の「美術」と聞いただけで身の毛がよだつほどの私ですから、
なるべくそういう部分を、慣れている人に作ってもらえたらいいなぁ。なんて思っていたり思わなかったり。

・・。でもそういう人って大抵、自分でソフト書いちゃいますよね。むぅ。

ある程度プログラムが固まったら、SDK付きで公開してみようかなぁ。なんてことを考えています。
心優しい方がいましたら、プラグイン作って、すばらしいペンやツールを作ってもらえると有難いです。
プラグインの製作はあんちゅことないですし、デフォルトのツールもあんちゅことないです。

まぁー。そんな感じで。

とりあえず、現時点では描画時に CPU を ~~100%~~ 50%取られるので、（手持ちの Eee PC 901-X にて）
（製作用マシン [C2Q Q6600] では 22%ほど持って行く。）

最適化しないとなぁ。と考えています。 DIB で自分で数式演算書いた方が早いのかなぁ。
それとも DDB で BitBlt とかガリガリやった方がいいのかなぁ。むぅ。

助言お待ちしています。

02/10編集。

あ。何寝ぼけてたんだろう。 Eee-PC 901-X はデュアルコアですから、100% 取ることはないです。
（シングルタスクのプログラムのため）

それでも50% 近くは取っていきます。シングルコアの100％みたいなところですね。

隣で眠ってるシングルコアのマシンで動かすと、他のプログラムの処理分が多少ありますが、
合計値としては１００％になります。何れにせよ、構造を見直さないとまずいですよね。

CUDAコンパイラはマクロに弱い。

コメントを残す

覚え書き。（突っ込み入ったので、語弊がないように一部書き直し。

弱いんだかなんだか、評価は出来ませんが、
とりあえず、CUDA コンパイラ(nvcc) はマクロ展開に際して非常によろしくない挙動を取ります。

CUDAコンパイラは糞。マクロを正常に展開しない。 – 簡潔で覚えやすいタイトルを3秒で思いつく程度の能力
詳細については上記リンクの記事を参照して頂ければとおもいます。

とりあえず、

HWND hwnd = CreateWindow(lpClassName, // CLASS NAME

lpWindowName, //WINDOWNAME

というような、引数が複数行にわたって記述される場合で、コメントを1行コメントなんぞ付けたりすると、
マクロが良い感じで展開してくれないよ－。ということ。

C コンパイラというから、きっと、全部コメントは /* */ だろ！ということで、
NVIDIAの中の人がかなり手を抜いているような気がしてなりません。

/* ～ */ で括れば、とりあえず、コメントの範囲はわかるし！みたいな。うん。
なんかそんなこと考えたら余程ステキな仕様な気がしてきた。うん。

ま・・まぁ、とりあえず、
ユーザはコメントを /* */ で書いて、
NVIDIAの中の人にはマクロ展開部分をきっちり作ってもらって。と。

でも、C99 って1行コメント使えるよなぁ・・。
Cでも使える時代が到来しているのに・・。むぅ。

MFC と WIN_VER

コメントを残す

うーん。MFC には相当の裏がありそうだなぁ・・。・・。ども Mimura です。

STEP_M のフォントサイズ問題で悩んでいたのですが、
ソースコードは一緒なのに、なんでコンパイルした結果が違うのさ。と。

MFCは奥が深いです。Microsoft のパンドラの箱。のような気もしないでもないですが、
どうなんでしょうか。
少なくとも、SDKプログラミングばっかりやってた自分には、ちょっと謎です。

Vista の動作結果ではほぼ変わらないのですが、
XPで動かすとすばらしく変わります。なんで。と思うほど。

（同じソースコードですが、頭に WIN_VER 指定をかけてあります。）

現在公開中のもの (WIN_VER = 0x600 (Windows Vista))

XP 宣言したもの(WIN_VER = 0x501 (Windows XP or 2003))

なんでこー。ツールチップのサイズがここまで変わってくるのさー！！

・・そんなわけで、最初の修正の時にはツールチップのフォント取得部分がおかしいんだろう。
と思って、フォント設定をシステムフォントから取得するようにしましたが、

まさか、本当の答えは WIN_VER だったとは。
・・。挙動が変わられても困ります。本当に。

MFC怖いなぁ。と思った今日この頃です。

（Microsoft さん。教えてもらえるとありがたいです。このあたりについて・・。
あ。あれですか。 .NET つかえ！っていうことですか。多分そうですか。）

GetMessage の書き方について。

2件の返信

GetMessage について何かおもしろい使い方がないかな・・。と調べてみましたら、
おもしろい記述が見つかりました。

GetMessage はメッセージループの部分に書かれており、大抵は

while (GetMessage(&msg, NULL, 0, 0)){
TranslateMessage(&msg);
DispatchMessage(&msg);
}

という風に書かれています。

私がいつも見に行く解説サイトを見直してみてもそうでしたし、
過去に書いたソースコードもそうなっていました。

ですが、 MSDN の GetMessage 関数の説明を見てみますと、
MSDN:GetMessage 関数

エラーが発生した場合、-1 が返ります。

たとえば、hWnd パラメータで無効なウィンドウハンドルを指定した場合や、
lpMsg で無効なポインタを指定した場合は、エラーが発生します。

拡張エラー情報を取得するには、関数を使います。

ということで。
そして、英語版MSDNではこんな感じのサンプルが上がっていました。

BOOL bRet;
while((bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0) {
         if (bRet == -1) {
              // handle the error and possibly exit
        }
        else
       {
             TranslateMessage(&msg);
             DispatchMessage(&msg);
       }
}

うーむ・・。
GetMessage の戻り値は BOOL のはずでは・・？と。思ってしまったり。

でも、BOOL って結局 int になってますから、型としてはあっているんでしょうけど。

にしても・・。 BOOL だったら、 == 0 or != 0 でせう。と。
まぁー・・。そんな感じで。

みむらの手記手帳

ときどき Developer ときどき Researcher そんな社会人のいちにち。

「開発」カテゴリーアーカイブ

HSP3 でマシン語変換。

お絵かきソフト作成中だったりします。

CUDAコンパイラはマクロに弱い。

MFC と WIN_VER

GetMessage の書き方について。