ラベル PixelCrew日記 の投稿を表示しています。 すべての投稿を表示
ラベル PixelCrew日記 の投稿を表示しています。 すべての投稿を表示

2008年8月2日

PixelCrew日記 - Perlin Noiseを写経する、の巻き

perlinnoise

最近、ここ以外が忙しかったりネタが無かったので書けませんでした。
が、やっとこ書けそうなネタが出てきたので。

雲模様のテクスチャが作りたくて、アルゴリズムを探していました。
とはいってもテクスチャが欲しかっただけなので、ツールで作るなりWebで探すなりしてもよかったのです。
ですが、ゆくゆくPixelCrewに載せるんだろうし、と言うことでコードで生成することにしました。

画像処理のアルゴリズムは、WindowsCE(GameAPI)でニアレストネイバーやバイリニアによる拡大/縮小を書いたことがあります。
そのときは、ピクセル間の距離や三角関数がどういう計算をしているか把握できなくてとにかく週末徹夜進行だったなと覚えています。
今回はその甲斐あってアルゴリズムの解説もすんなり理解できました。たぶん。

ただ、Frequency(周波数)と言う単語を見て、画像の端々を正規化(0.0と1.0に丸める)して扱うのかと勘違いしていくら演算結果を重ねていってもサンプルみたいにならなくて悩みました。
別に周期に収めることは無くて、どこまでもノイズを作っていけばいいんですね。

あと、このアルゴリズム解説を読んでいて驚いたのが、ピクセル単位で重ねこみをしていること。
解説文では、「これらの画を重ねると、次のようなパターンになる」とあるので、回数が増えればバッファもたくさん要ると思っていたのですが、そんなことはありませんでした。

まだまだ覚えることがあるのだなと思いました。

2008年2月6日

PixelCrew日記 - レイヤの始まり

なんとか重ねるところまで出来たー。

次は描画機能各種の作りこみかな。

2008年1月30日

PixelCrew日記 - レイヤのためにその2。作りこむうちに他の機能に目移りするでござる

なんとか、1枚のレイヤと背景をブレンドする様になった。
いろいろいじり倒してるうちに対応漏れがあったミスなども直しながら、次のステップに移ろうかと考えた。
次のステップ・・・2枚以上のレイヤを重ねる。
初期段階から、画像はキャンバスという親クラスが各レイヤをリストで管理する設計にしてるんで楽勝だ。と思っていたら。

レイヤを管理するダイアログが無い。

さっくり作り、コンテキストメニューを実装。泥臭いことが手早く出来ることに軽く嫌悪するw
で、重ねると表示が真っ黒。
画像は黒で、アルファ値が1.0。追加したレイヤが手前なので奥が見えないorz
で、これは直すとして、確認をする環境が無いことに気づいた。
前後のレイヤにフリーハンドで線を描こうかと思っていたんだけど、黒しか出ない。
パレットのバンクはあるけど色が作れない。
ずいぶん前に「まだ先だからとりあえず256色画像のパレットが見れればいい」とか「減色処理の生成パレットが見れればいい」とか言って先送りにしたところだ。
他にもレイヤ単位で位置を動かせる用意があるんだけど、これもやんなきゃいけない。
むかしざっくり考えた案だと、選んでるレイヤとそれを挟んでるレイヤの3枚(奥、カレント、手前)を更にブレンドする。だったような。
更に思い出すと、フォント描画はプライベートフォントをサポートしたいと考えていた気がする。
フォント描画のためのUIは今から作るなー。
どれからやろうかとりあえず悩む状況になってしまったorz

2008年1月25日

PixelCrew日記 - レイヤのためにその1。フルカラーアルファブレンド

フォント描画も必要だけど、レイヤも欲しいよね。
フォントは書き込んだ後に動かすよね?
ということで、レイヤを先にはじめることに。
昔、8ビットカラー(256色)をBitBltのラスタオペレーションで透過したな。あれをマスキングじゃなくて、アルファブレンドに使えんかと寝ぼけた事を考えて、やるだけやってみたらやっぱりダメだった。
RGBの値をマスクすることはブレンドすることは違うよね、青が赤にもなるorz
ということで、GetDIBitsしてごりごりブレンドするコードを書く。
DirectDraw時代からこの構成やってるな。今の時代にこんな泥臭いことやってる人はいないだろう。
・・・GBA/NDS HomeBrew向けBMPコンバータとかでやったな。意外にいるかも。
閑話休題。
とりあえず、複数枚のレイヤを重ねるのはまだ先なんだけど、画像表示のロジックを次のように変更。
StretchBltなどAPIを駆使して比較的楽に表示
↓
アルファ値のビットマップを作り、それと合成したものを表示
で、変更したら早速表示が重くなる。
InvalidateRect/ValidateRectをがんばって使ってみたところが原因だった。
がんばったコードをほとんど消してInvalidateRect→UpdateWindowで一発更新する形にして更に高速化。
体感的に余裕のある速度になりました。むしろ早くなったorz
それにしても、技術的なことはいっさい書いてないなー。

2008年1月24日

PixelCrew日記 - ポップアップコンテナを実装してみる、の巻き

先日、ピックアップした項目を実装し始める。
とりあえず、ポップアップウィンドウに各種ツールダイアログをしまいこむコンテナ的ダイアログを作る。
現時点でも十分邪魔なツールダイアログが多いので。コード上で位置あわせを毎回書くのにうんざりしてきたし。
といっても、プレーンなダイアログを作ってそいつをオーナウィンドウにしただけ。
Enter/ESCで閉じるし(再表示不可)、そのダイアログ内で移動できる(触れない場所まで移動すると助けられない)。
とりあえず仕舞い込めたのでよし。
なんか部屋の掃除とよく似たアバウトさを感じる・・・。気のせいだけど。

2008年1月22日

PixelCrew日記 - 次にいるのは何だろう、の巻き

大味ながら実装した領域選択とトリミングで便利度が上がったPixelCrew。
便利度が上がったハズなんだけど、いまいち自分が乗り換え切れていない。
なんでかと考えたんだけど、まだまだ機能不足な気がする。
では、どんな機能を作れば乗り換えるようになるのか、軽く思いついたものを挙げてみた。
- レイヤ対応
- フォント描画
- アンドゥ/リドゥ
- ポップアップウィンドウを格納するコンテナポップアップ
- コンテナポップアップのドッキング
本当は全部上げようかと思ったんだけど、半ベソになりそうなのでこれぐらいにしておいたんですが、それでも辛そう。
レイヤってどうやるの? と、とぼけつつも重ね合わせの方法を暇なときに考えたりしてます。
アンドゥ/リドゥも双方向リストで実現できないかなとうっすら思っていたり。
んでもって、実装のボリュームを考えるとそれだけで疲れてしまう。
歳なのか一時的なものなのか・・・。

2008年1月7日

PixelCrew日記 - 案の定仕事に使えるレベルじゃないよ、の巻き

最低限の実装で大喜びしていたのもつかの間、まだまだ使い難い領域選択とトリミング。
選択領域の手打ち調整ダイアログを実装途中で持ってきたのが悪かった。
選んだ領域の値まで出る。スピンボタンも回せる。変更は領域に反映されないorz
領域選択がキマればトリミングは便利なので、がんばって使うけど。
ここから始まる、ここから始まる・・・と心の中で泣いてたけど。
これではダメだね。

さらにこんなものを目にしてしまうともうだめだorz
2Dスプライトアニメーションデータ作成ツール SpriteStudio
impressにもリリースのお知らせが載るツール、OPTPiX iMageStudio。
別に対抗意識とか不要なんだけど。

2008年1月6日

PixelCrew日記 - トリミング機能実装、の巻き

NDS開発の難所だったところが解決したので、何か作ろうかと思ったんですがツール整備をさっぱりしてませんでしたorz
このツール、実は仕事場でも使っていてトリミングが欲しいなと思っていました。
が、実装方法を考える気力を欠いていてようやく実装を始めました。
トリミングを実装するためには領域選択を実装しなければいけません。
領域選択は、始点と終点を取得するところまで作ってありました。ここからを考えていませんでした。
領域の管理と作成にはリージョンを使うことにしました。
短形はCreateRectRgnでいいのですが、円弧はパスAPIを使う予定でいます(まだ実装してない)。
とりあえず短形選択だけの領域選択が準備できました。
このリージョンのサイズはGetRgnBoxを使って取得します。
このサイズにトリミングするようにします。
ツールが少し便利になりました。
カーソルキーで選択領域を移動できるようにしたり、領域を手打ちで指定できるようにしたいという、当初から思っていた昨日を作るためのスタートラインにようやくやってきました。

2007年11月20日

PixelCrew日記 - 画像バッファの反転、の巻き

グレースケール化や、PNG保存、ぼちぼち出来の悪いツールとして使えるようになってきたPixelCrewですが、前々から思っていたことがあります。
8x8のビットマップフォントを使ってメッセージを表示しよう。
UIをレトロゲーム風にしたいなとも考えたのですが、あまりやりすぎると使いにくくなってしまったりするので、ちょっとしたところだけやってみようと思っていました。
てことで、古き時代のBitBltでの重ね合わせをするための準備を進めていました。
・・・マスクが作れない(いま仕事場www)。
というわけで、画像バッファの反転機能をさっくり作って実装しました。
画像のモードによって、色そのものが反転したり、パレットのインデックスが反転したりするので意表をつく色になって面白いです。
では、本来の目的に戻ります。

2007年11月2日

PixelCrew日記 - PNG保存対応(暫定)、減色処理(標準編)実装

最近、忙しいときは猛烈に忙しい。で、その逆は終日自由になったりします。
ということで、PixelCrewの機能実装をすすめています。
その甲斐あってPNGの保存が実装できました。フルカラーだけですけど。
ツール全体が、インデックスカラーに対応していない状態なので、次なる課題はこれの対応です。
これに対応することはパレットアニメーションとかの足がかりになるので出来ることが増えます。
さらにその足がかりとして減色処理を行えるようにしてみました。
# 先は長い・・・
とりあえず、減色処理をするために必要なリソースは次のものです。
- 標準的な256色のパレット
- 実際の色とパレットの近似値を探すアルゴリズム
DirectDraw時代(懐かしい・・・)に256色モードのパレットをとりあえず作る方法をBBX(これも懐かしいなw)で教えてもらったハズなんですがすっかり忘れていました。
約10年前のCマガのバックナンバーとかを頼りに探してなんとか実装。
近似値検索もCマガのバックナンバーから情報を探して実装。
バックナンバーってありがたいなー、としみじみ思いました。
グレースケール化についても載っていたので助かりました(RGBにかける係数の値がわからなかった)。
ファイル保存も対応するぞー。

2007年10月31日

PixelCrew日記 - IJGのlibjpegについて

プラグインによるファイル読み込みが繋がりました。やっとこ。
次の目標としてファイル保存があるわけですが、減色とか依存関係にある機能もありどの順番で実装しようか考えるのに疲れます。
そんなわけで、ちょっと寄り道。
jpeg読み込みのプラグインぐらいさっくり出来ないかと思い、ライブラリを探してみました。
Independent JPEG Group
昔、仕事で使ったことがあるんですが、これしかないの? 他のライブラリがヒットしない気がする。
以下不満。
- UNICODE対応してない。
- ファイルアクセスが標準関数。悪いことでは無いけど、APIに差し替えたいときにコードにがっちり組み込まれてると差し替えが不便。
- エラー時に、exit(0)で終わる箇所がある。悪ふざけか何かか?
手軽に出来る感じじゃないことが判明。
さぁ、減色処理の仕事に戻るんだ>自分
あと、判明した問題として同じフォーマットでも複数の拡張子がある場合にプラグインが対応できない。
JPEGは、*.jpegの他にも*.jpgとかいろいろなタイプの拡張子がある。
これも検討課題。

2007年10月26日

PixelCrew日記 - ファイル選択ダイアログで選んだ形式と実際の保存形式について

久しぶりにいじってます。
ファイルプラグイン(DLL)とプログラム本体(EXE)を結びつける部分を作ってます。
んで、思ったんですが、以下のような条件化ではどのようにするのが正しいのでしょう。
- ファイル選択ダイアログのファイル種類で"BMP"を選ぶ
- ファイル名は拡張子含めて"ImageFile.PNG"とする
これまで使ってきたアプリケーションを思い返すと、3種類パターンが挙がります。
(1). ImageFile.BMPで保存(拡張子を差し替える)
(2). ファイル名は ImageFile.BMP だけど、内容はPNG(ユーザ入力を一切変えない)
(3). ImageFile.PNG.BMPで保存(拡張子を後付けする)
まぁ、(1)と(2)は良いとしても、(3)はギャグかと思う人もきっといるでしょう。
が、エクスプローラのファイルオプションで拡張子を表示しないようにしてメモ帳を使うと hoge.c.txt みたいなファイルができます。
(1)はフェールセーフする(一般的なユーザに優しい)で、(2)はフェールセーフしない(パワーユーザ向け)といったところでしょうか。
このように、ひとつの機能が実装者によって複数の挙動(仕様)になる場合、どちらが正しいか? という議論は個人的にしたくないと思います。
上述の3パターン、個人的にはすべてアリです。でも・・・(3)はアリでも避けるかな。
拡張子を偽装して保存を強行したいこともあり、そんな考えはまったく無くてポカだから警告して欲しいこともある。
面倒じゃなかったら全部実装してユーザに挙動を選ばせたい。
マイノリティは淘汰される理由にはならないと思います。
まぁ、優先順位は低いけど。

2007年7月23日

pixelCrew日記 - プラグインを早く

減色とかいろいろやりたいことがあります。
とはいっても、アルゴリズムとかまったく知らないので調べてみました。
ざっくり検索してみたらメジャーといわれるメディアンカット法の解説がヒットしました。
解説を読んでみたのですが、今度はヒストグラムがわからなかったorz
これはこれで調べてわかったのですが、ヒストグラムの結果からなぜ色が減らせるのかがわかりません。
実際にヒストグラムを表示させてじっくり把握しないとダメか?
ということで解析用ダイアログをプラグインで実装して呼び出したいなと。
PNG保存の件もあるし早めに実装したほうがいい模様。
というか、仕事以外でも仕様設計って・・・忙しいなー。

2007年7月6日

pixelCrew日記 - 現実的な目標レベルを定めること

コードを書く時間より、仕事しながら設計を練っていることが多い「pixelCrew」ですが、遠巻きにいろいろ出来上がってきました。
あるときはプラグインのサンプルを作ってみたり、またあるときはパレット付きBMPファイルに対応してみたり。
そんなプラグインについて考えをまとめてみた反省が今回のトピックです。
前回、画像の読込みについて書いたんですが、いきなりレイヤ画像もサポートしたいと書いたんですが、無茶な気がしてきました。
そもそも暇プロの延長という勢いで書き出したものだから要件の詳細がほとんど固まってません。
昨日までUIに四苦八苦してたし、未だにドット画作成ツールなのにドットが打てませんorz
超絶に長いアルファ版開発というか、今後楽するための努力を今猛烈に要求されている感じです。
ビットマップもDDBからDIBに変換するのに落とし穴があるしパレットもディスプレイ(HDC?)のものと画像のものとあって、どっちがどっちの情報が必要かわからなくなります。
# ちなみに、前者はHPALETTE(PALETTEENTRYの配列を保持してるリソース)で、後者は単なるRGBQUADの配列
やりたいことは、うっすら脳内にある。ちょっとずつがんばろう。
とりあえず、会社に出す定期券の控えをスキャナで取り込んでPNGで保存できるところぐらいまでが第一目標かな。

2007年7月5日

pixelCrew日記号外 - CCSIZEOF_STRUCT現る、の巻き

先日のWindows SDK for VistaのComCtl32.libに関する件ですが、MSDNのフォーラムに投稿しました。
そこで、りょーいち氏(りょーさん)に助けてもらいました。
りょーさんをはじめ、以下で詳細な紹介をしている記事を紹介しますが、情報を広める意味でこの投稿を書いています。
自分は困っていただけです。いつか助ける側に回りたいものです。
MSDNのフォーラムに投稿をするのと同時に、SDKを新しくしたり、統合したり、アンインストールしたり、さらにVisualStudio2005再セットアップしなおしたりゴタゴタしてるので試せてませんが鉄板だと思います。
とはいえ、コントロール(構造体)のバージョンごとのサイズを示す定数ってどんな風に書かれてるの? と思いました。
そんなわけでREBARBANDINFO_V3_SIZE、REBARBANDINFO_V6_SIZEの正体だけでも探ってみました。
構造体のサイズの取得 (CCSIZEOF_STRUCT) - Windows SDK
この投稿書いている本日(2007/07/05)現在、日本語で取り上げているところはここだけでした。
# 各地のアンテナにはひっかかってる
REBARBANDINFO_V*_SIZE定数はCommCtrl.hに書かれているのですが、その定義をさらに辿っていくとCCSIZEOF_STRUCTマクロにたどり着きます。
#define CCSIZEOF_STRUCT(structname, member) \
    (( (int)( (LPBYTE) (&((structname*)0)->member) - \
            ( (LPBYTE)((structname*)0) ) )) + \
    sizeof( ((structname*)0)->member) )

まさにマクロです。すげー。

2007年7月3日

pixelCrew日記 - Windows SDK for Vistaのcomctl32.libが怪しい、の巻

ちょっと前から、ツールバーを実装しようと躍起になっていた「pixelCrew」ですが、開発をしていて妙な現象に遭いました。
自宅のVistaマシンでビルドするとReBerの高さ(垂直表示時の幅)がゼロになる、という現象です。
仕事場のXP(VisualStudio 6.0)、家のXPノート(VisualStudio2005)でも同じでVistaマシンでビルドした場合のみにこの現象がおきます。
ReBarをAPIでごりごり書くとコードが長くなるのでフォーラムにコードを張りづらいのですが、MSDN上に模範コードがありました。
MSDN Online Web & Internet Samples - Rebar Control
これでやっても同じでした。
とにかく、フォーラムで聞くのは最終手段だ(説明とか面倒だから)。と思いながらWebを散策していると、こんなエントリをみつけました。
Days with .NET Framework : Windows SDK for Windows Vista 日本語版
月例でアップデートしてるっぽい雰囲気のWindows SDK for Vistaです。
ダウンロードの詳細 : Microsoft Windows SDK for Windows Vista(6月版)
問題のマシンには4月版が入っているのですが、他のマシンには入っていません。
インクルードパスとライブラリパスのディレクトリ設定からそれぞれWindows SDKのものを最下位に落とす(VisualStudio2005添付のものを優先するように戻す)と、期待通りの結果になりました。
めずらしいからといって迂闊にSDKは入れ替えない方が良いということでしょうか。
それと、MSDNを巡っていて見つけたもの。
ダウンロードの詳細 : VS SP1 用 MSDN ライブラリ 2007 年 6 月版(isoイメージ(DVD)直リンク)
最近やることが豪快になってきたな、Microsoft。

2007年6月21日

PixelCrew日記 - 画像の保存をやっと実装、の巻

ドット書きをしたいのか未だによくわからんグラフィックエディタ「PixelCrew」の開発をだらだら進めてます。
先日、BMPファイルの保存をようやく実装しました。
それから大分経った昨日、BMPファイルの読込みを実装しました。
いままでどうやってソフトに画像を取り込んでいたかというと、クリップボードとTWAINから取り込んでいました。
画像読込みの流れは、次のようになります。
ファイルを読み込む→HBITMAP形式に直す→独自のクラス(ここではキャンバスと呼ぶ)に登録

この「ファイルを読み込む」という処理は、車輪の再開発的な作業で気が乗りませんでした。
その点、クリップボードはPrintScreenキーを押すだけです。
ずいぶん先送りしてきたのですが、プラグインのことを考えていて実装が必要になってきたと思い、重い腰を上げました。
独自クラスであるキャンバスは、レイヤもサポートする予定でいます。
# レイヤを持ったファイルでサポート対象になっているのは今のところリスペクトしているPhotoCrewのファイルだけですが
とりあえず読むだけの現状コードをもう少しラップしないといけませんが、個人でやってるコードぐらいエレガントにいきたいものです。

2007年6月11日

最近目論んでいるネタ

(XNAことはじめ、の続きです。)
優先順位の順に書いていきます。優先順位はモチベーションとはイコールでありません。
- グラフィックエディタ
- ファミコン風画面捏造
- NDSでなにかアプリ開発(oggプレイヤ、ファイルマネージャ、poboxを移植してメモ帳?とか)
- XNAでなにかゲーム(2Dでなにか、ちょっと変わったリバーシとか)
グラフィックエディタ以外のことに手を付けたいのですが、グラフィックエディタを真っ先になんとかしないと効率が見込めない予測が自分の中で立っています。
これまで自分は、PhotoCrewというエディタを使っていました。
このソフトの開発元であるMET'Sは数年前に権利移譲してしまいました。
権利譲受された先でも開発・販売は止まっている模様。
XPまでは対応していたので、今持っているものをそのまま使えばいいのですが、Vistaでは動きが微妙です。
スピンボタン付きのエディットが手入力で値が変えられなかったり、エフェクトをかけると待たされたうえにビジーになったり、よくわかりません。
また、グラフィックエディタ以外のネタで一番に用意するものが画像リソースです。
PhotoCrewは安価な割に使いやすいエディタだったのですが、欲しい機能がいろいろ欠けていました。
たとえば選択範囲の手入力指定(マウスでドラッグする方法しかなかった)とか。
自分が欲しい機能が他のエディタにあるのかはわかりませんが、ちょっと作ってみようかな? と思い、だらだらやっていました。
- MDIのスケルトン作成
- 拡張貼り付け(Shift+Ctrl+Vでクリップボードにある画像を新規画像として取り込む)の実装
- レイヤの実装に耐える画像リストの設計
・・・ここまでやって疲れてしまいました。
やめる気はないけれど、なんだか半端そうなものが出来そうで一人で抱え込むのは危険です。
俺様ジンクスに「カタチになる前に公言するプロジェクトは破綻する」というものがあるのですが、これに当てはまることもあり、静かにしていました。
が、黙っているものが確実に成功することもなくて、このままもやもやしてるのはダメな気がするのです。
というわけで、うっすらアナウンス。
グラフィックエディタ作ってます。