スポンサーサイト

--年--月--日 --:--

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

シェーダー開発ツール 2

2006年07月24日 23:53

終電が近いので取り急ぎ画像だけうp
記事は帰ってから書きます( ・`ω・´)


・・・ってことで今帰宅(*´Д`)ハァハァ

今日はテキストエディターをシェーダー開発ツールに載せました。
元々このために作ってたんだしね。

んで、こんな完成図になりました。

ShaderEditor060724.jpg

画面は開発中です


実際にやってみるとテキストエディターのバグがあったり、エディットボックス管理クラスとテキストエディタークラスのインターフェースが違うおかげで
実装を修正しなければいけなかったりと、エディットボックス管理クラスからテキストエディタークラスに入れ替えるだけで4時間ぐらいか懸かっちゃいました('A`)

しかもテキストエディタークラスの OnDestoy 関数にテスト用で仕込んでた PostQuitMessage を消すの忘れてて(っていうか存在を忘れてて)テキストエディタークラスのデストラクタでアプリケーションが終了するっていうバグで2時間ほど嵌って判った瞬間かなり脱力しましたよ。。。

テストで仕込んだプログラムはちゃんとコメントで囲まないとダメですね('A`)


あとは検索処理を検証してみました。
strstr は遅いと決め付けてたんだけど、コレがなんのその、結構速い。。
13MBあるファイルでも30msecぐらいしか懸からなかった。

あるけ が速いと思って実装した「単語単位で大まかに検索してある程度マッチしたら細かく検索する」手法が物凄い遅い・・・。
13MB あるファイルだと単語単位に区切るだけでかなりの時間を消費し、終わった後、検索だけ測定してみても 200msec を超えました orz


ほかに自前で strstr みたいなのを書いてみたところ、今度は 2msec ヘ(゚∀゚ヘ)アヒャ
・・・なんでだヽ(`Д´)ノウワーン


ってことで、結局検索処理には strstr を入れてみました。
単語単位の方だと双方向リンクで単語をつないでる分、キャッシュ効率が悪いんだろうなぁ・・・。


検索処理(実装だけ)も終わったので明日以降はUIを作ろうかと思います。
ダイアログ自体は今日設計したからあとはクラスを書いて OnCommand を処理すれば終わり!


もうちょっとがんばります(`・ω・´) シャキーン


blog_rank
スポンサーサイト

にゅーてきすとえでぃたー4

2006年07月23日 17:30

ってことで、基本的な機能はさすがに全部終わりました~(´∀` )

結構バグが出てたんですけど、丹念につぶした結果、出なくなりましたъ(´д`)グッ

最後に実装した機能は
 ・範囲内の文字列の削除
 ・指定した位置に文字列を挿入
 ・指定した範囲の文字列の取得
 ・選択処理の補助
 ・マウスでの選択処理
かな。


バグで一番厄介だったのが「カレットの残像が残るバグ」でした。
これ、解決策がいいのが無いんだよね。。

SetCaretPos を短い間隔で呼んだとき、カレットがあった位置を TextOut とかで描画しなかった場合にカレットの残像が消されないままになることがあるってバグです。

回避方法はわかったんですけど、余りにも面倒なのと将来的に汎用性をなくしちゃうのでその回避方法は取れませんでした。

回避方法っていうのは、InvalidateRect や InbvalidateRgn を呼ぶときはカレットを消しておく(HideCaret を呼ぶ)っていう方法です。
カレットを表示する(ShowCaret を呼ぶ)タイミングは OnPaint の一番最後で呼んでやればOK

こうすればカレットの残像は残りません。


んが!全ての InvalidateRect や InvalidateRgn を自前のメンバ関数に置き換えるのも面倒だし、まして外部から呼ばれた場合はどうしようも無いのです。
では、どうすればいいのでしょうか。


上にも書きましたが、カレットのあった位置を描画しないから起きるわけです。
ですから、カレットのあった位置を描画しちゃえばOKなんですね。
要するに行末まで文字を描画しても、その後も背景色で塗りつぶしちゃえばOKなわけです。
あるけ は ExtTextOut 関数で文字列を渡す部分を NULL にして描画してます。
こうすればカレットの残像は残らないわけです。


あとは置換処理と検索処理のUIを書けば大体終わりなんです。
始めは FindText とかAPI使おうと思ってましたが、なぜか あるけ のシステムに乗せた場合メッセージ処理でバグが出るので自分でUIを作るはめになりそうです( ´Д⊂ヽ


けれども、今現在の機能で完璧にエディットボックス以上のものがあるので、実装は後回しでもいいかな~?って思ってます。



・・・・さて、いよいよチャレンジかな。。


blog_rank

にゅーてきすとえでぃたー3

2006年07月18日 22:50

やっとこさ3回目です。

っていうのも、3連休をしっかり休んだからあまり進んでなかったんですねヽ(°▽、°)ノ
映画「サイレントヒル」見てきたよ~。シーンを細かく作ってたりとナカナカですた。


さて、今日は先週の続きです。
アレから2、3日で入れないといけない機能は大体いれました。
・・・んが!大事な項目を飛ばしてるのに気づきました。・゚・(ノД`)・゚・。

この前書いた ToDo リスト、選択処理が入っていませんでした・・・。


結構面倒なのが選択処理。
文字ごとに処理しないといけないからです。
しかも、今現在は単語ごとに描画処理を行っているので単語の中間から選択されている場合などの場合、(処理を変更しないなら)別処理にしなければいけません。
とうしたことか・・・。。。悩むこと数時間。。


結局単語ごとに処理することは変わらず、単語描画部分だけを違う関数にすることで落ち着きました。
こうすれば後々他の強調表示を入れたい場合(たとえば検索で引っかかった文字のバックグラウンドの色を変更したり など)クラスを派生してオーバーライドすればいくらでも処理を入れることが可能だからです。

描画部分を分離したことでソースも見やすくなったし役割もすっきりしました。



これで「拡張することを念頭に置いた設計」に変更しちゃったので、全体の拡張性も見直しました。
今までドキュメント関連のクラスのインスタンスを作る時、単純に New してたところをファクトリークラス経由で作成するようにしたり、タブ描画処理も一緒に単語描画処理を担当しているクラスに委譲したりと。


そんなわけで軽く全体修正を施した結果!選択処理もできました~(´ー` )


後は選択時の再描画で背景が明滅しないように OnEraseBkgnd で背景の消去を行うようにしたり、現在指している文字がマルチバイト文字だった場合、キャレット大きさをマルチバイト用に大きくしたりしました。

デバックで必要だったついでに行番号表示も追加したので見栄えはバッチリになりましたよこれ(・∀・)



後入っていない処理は、、、
 ・置換処理(複数行対応の)
 ・WordBreak 処理
が最低限。


他に必要なのは、、、、
 ・検索(単語単位も)
 ・置換(単語単位も)
 ・キーワード登録
ってところ。

うーん、、、、木曜までには検索処理ぐらいまで絶対終わらせないと。
がんばるですよ( ・`ω・´)



ってことで、開発中の画面ですけど、公開します。
完成してもそれほど異なった画にはならない感じ。

Editor060718.jpg

画面は開発中のモノです



どうでもいいけどオーバーライドとオーバーロードって時々わからなくなるよねw
ちなみに
 オーバーライド:親クラスの仮想関数を子クラスが上書きして定義すること
 オーバーロード:関数名は同じでも、違う引数をとることで違う関数として認識されること。戻り値だけ違う場合はダメ
だす。


blog_rank

にゅーてきすとえでぃたー2

2006年07月12日 01:29

自前出入力処理のエディターの続きです。


今現在スクロールとキーボード入力までは終わりますた(´∀` )
なんでこんなに時間が掛かったかというと、、、。
「画面のスクロール処理」と「何百万行もあるテキストを読み込んだときの水平スクロールバーの文字幅を決める処理の検証」で嵌りました('A`)
特に後者の方はアルゴリズムを改良したり検証したり紆余曲折した挙句、結局バイナリサーチで処理するありきたりな方法が最適!ってことが判りました orz


キーボード入力は全然簡単でしたよこれ。

IME を使わない処理は OnChar で処理して、IME を使うときは WM_IME_COMPOSITION か WM_IME_ENDCOMPOSITION で ImmGetCompositionString を呼んでIMEが管理している文字列を取得して OnChar で処理してやればOKです。

OnChar で処理するとき、IME からの入力だと入力した文字数分だけ OnChar が呼ばれちゃうのでこれを制御しないといけません。
なんでかっていうと、 WM_IME_ENDCOMPOSITION ですでに入力文字は取得できてるので OnChar も1回だけ処理できれば (・∀・)イイ ワケです。

ってなわけで OnKeyDown とかで処理フラグを立てるようにして OnChar の中で処理フラグを消せば IME の入力完了から初めて呼ばれたのか?が判るようになり、文字入力はほぼ終わりました。


あとはキャレットの位置に IME のウィンドウを表示するようにしたり(ImmSetCompositionWindow を使う)キャレットの位置に文字を埋め込むようにしたりとか細かい処理をして終了。
案外簡単ですた('A`)



入力なんかより画面のスクロール処理の方で2日も掛かっちゃいましたよ・・・。
OnHScroll や OnVScroll の度に InvalidateRect( hWnd, NULL, TRUE ) とかやっちゃうと確かに簡単に表示もスクロールも実現できます。
(もちろん、表示するときは左の位置と上の位置がどの位置(または行)の文字を表示するのか? の制御は必要)
んが!これじゃいくらなんでも処理が重過ぎるわけです('A`)

そこで使うAPIが ScrollWindowEx 。
これを使ってやればスクロールして新しく描画しないといけない分の領域だけを OnPaint で書き直せばいいので、処理は格段に軽くなります。

しかし・・・。この処理を実装したときなぜかハマリました・・・。
はまった原因は、Tab 処理です。
ScrollWindowEx 自体は別に難しいところありません。
指定した分だけ表示画像がずれて新しく描画する場所が出るだけなので。

んが、エディターの場合 Tab 位置を考慮しないといけないので、現在の左端の文字は何文字目なのか?が重要なんですね。
単純にやっちゃえば Tab の文字数の剰余を保持して、あとは普通の Tab 処理でOKだとおもうんですけど、そうは問屋が卸しません。
結構面倒な処理が必要です。・・・説明するの面倒なのでやりませんけどw


ってことで、なんとか Tab にも対応してきちんと表示できるようになりましたーヽ(´ω`)ノ

あとは OnSize のときにスクロールする必要があるのかチェックしたり、余白制御を行ったり(これも OnSize の処理の中で GetUpdateRgn とか使って正確に余白分だけ拡張した)、行に含まれる最大文字幅を取得してからソートし、正確に HSCROLL の処理をいれたりしました。



あとやらないといけないことは、、、
 ・改行処理
 ・置換処理(複数行対応の)
 ・削除処理(DELETE、BackSpace の処理)
 ・キャレット位置のテキストを画面に表示する
 ・WordBreak 処理(っていうか描画は単語単位だからすでに出来てるけど)
 ・文字入力後の文字幅制御
 ・カーソル、HOME、ENDキーの処理
 ・ショートカットキーの処理
かな?

これができれば EditBox 相当(機能としては以上あるけど)のものは出来るか。


追加で欲しい機能としては、、、
 ・行番号の表示
 ・キーワード登録
 ・検索(単語単位も)
 ・置換(単語単位も)
ってところかなー。


あと2日ってところかな。このToDoリストだと。

一番面倒な部分は大体終わったのでラストスパートです。
がんばるですよ(`・ω・´)


blog_rank

にゅーてきすとえでぃたー1

2006年07月07日 17:34

タイトルがNEWになりました!
っていうのも、EditBox ではタブの設定すらマトモに出来ないので結局自前でエディターを作るようになったからです。

現在、単語単位での描画までおわりました (´∀` )


Editor060707.jpg

※画面は開発中のものです


あとはエディット機能とスクロール機能つければとりあえず終わりw
・・・って簡単に書いたけど一番面倒なのがエディット機能。

うーん、どうすっかなぁ。
IMEを使って書くやり方はわかるんだけど・・・。

まぁ、なるようになるか('A`)
10日ぐらいまでに完成できたらいいね。

blog_rank

シェーダー開発ツール

2006年07月04日 23:25

この前作ってたシェーダー開発環境ツール。
今思えば自前のフォーマットしか対応してません('A`)

なので公開してもまったく ('・c_・` )イミネ ですね(´・ω・`)ショボーン

一応、Maya のプラグインもあわせて作ってるので、こっちも公開すれば全然使えるんですけど公開しても(アマチュアプログラマの)需要が少なそうなのが痛いところ。。。

(他にも Height Map から Normal Map 作るツールとか
 中間フォーマットからバイナリフォーマットに変換する
 コンバーターとかありますけど、こっちも自前のフォーマットを
 核にしてるので、同じく ('・c_・` )イミネ です。)



メタセコイアとかに対応しないとダメポですね。きっと。。
同業者さんには需要があるかもしれないけど、まだまだ実際の現場で使えるレベルじゃないので( ;Д⊂ヽ

・・・っていっても、同業者さんなら FX Composer とか使ってるでしょうねw

COLLADA は「なんかわかりにくい」+「ハウスツール使う時に手を入れるのが面倒くさそう」だから、全部自前でやってるって会社、ウチ以外にどれぐらいあるんだろ?
なんだかんだいって、COLLADA を使った開発環境が最強になりそうだしなぁ。。。



まぁ、そんなことはさておき、今はシェーダー開発ツールをほそぼそとアップデートしてます。
やっとマトモに扱える段階まで来たのでバンプマップ処理を書いて見ますた。


20060704232455.jpg

20060704232502.jpg

※画面は開発中です


けど、まだまだ追加しないといけない機能が多すぎですよこれ('A`)

基本的な構成は SN Systems の ProDG みたいなレイアウトを Split Window で自由に変更できる感じになっています。
なんで、表示するウィンドウを4つとか持てます。

まずはちゃんとしたテキストエディタを作らなきゃ。
がんばろっと。


あ、そうそう。
もし何か質問があればお気軽にコメントにでも書いてください。
あるけ がわかる範囲でのことなら GL の質問だろうが Cg の質問だろうが DirectX の質問だろうが出来る限り答えますよ。
・・・さすがに実機の質問は怒られちゃうので答えれませんがw


blog_rank

出来た~!

2006年07月02日 23:40

がんばって開発してたアプリケーションが出来ました~(´∀` )
作ってたのは ATI の Shader Monkey や nVidia の FX Composer のようなシェーダー開発環境ツール。

っていっても、まだまだシェーダーを編集できるだけで、定数レジスタの配置やライトの配置、テクスチャの表示、パイプラインの制御とかも出来ません。
単純に「シェーダーを書いたら瞬時に繁栄される」だけのツール。

けど、モノが出るとやる気が出ますね。これからがんばりまふ。
とりあえずもうちょっときちんと使えるようにしてからテキストエディタの機能を拡張して、ファイル保存機能を入れて・・・

・・・山のようにやることあるや('A`)


とりあえず今日のところはここまで。
きちんとできたら公開しますよーっと。



今日は久々に「泣ける2ちゃんねる」を読んで涙腺を刺激されましたw
゚・*:.。. .。.:*・゜゚*・゜゚・*:.。..。・゜・(ノД`)・゜・。. .。.:*・゜゚・*:.。. .。.

一生懸命生きることと、人に優しくすること、信念を貫くこと。
色々難しいこと多いけど、全部自分に帰ってくることだから手を抜かず精一杯やらないとね。

久々に心が綺麗になった あるけ でしたw




blog_rank


最近の記事


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