1999/08/23 - bppの違いを補う

■同じ画像エフェクトのコードをそれぞれのbpp(bit per pixel)ごとにいちいち書いていると，同じようなルーチンが山ほど出来てうざいです．だからテンプレートを使おう，とは思っていたんですが，やっぱ専用ルーチンにはかなわんでしょ，と思いやってませんでした．
■だけど最近妥協してテンプレートを(自分なりに)導入してみました．


class V32 {
private:
	BYTE b,g,r,a;
public:
	inline int GetR(){return r;}
	inline int GetG(){return g;}
	inline int GetB(){return b;}
	inline void SetRGB(int _r,int _g,int _b){r=_r;g=_g;b=_b;}
};

class V24 {
private:
	BYTE b,g,r;
public:
	inline int GetR(){return r;}
	inline int GetG(){return g;}
	inline int GetB(){return b;}
	inline void SetRGB(int _r,int _g,int _b){r=_r;g=_g;b=_b;}
};

// 5:6:5
class V16g {
private:
	SHORT c;
public:
	inline int GetR(){return (c&0xf800)>>8;}
	inline int GetG(){return (c&0x07e0)>>3;}
	inline int GetB(){return (c&0x001f)<<3;}
	inline void SetRGB(int _r,int _g,int _b){
		c= ( (_b>>3) &0x001f ) |
		   ( (_g<<3) &0x07e0 ) |
		   ( (_r<<8) &0xf800 ) ;
	}
};

// 5:5:5
class V16 {
private:
	SHORT c;
public:
	inline int GetR(){return (c&0x7c00)>>7;}
	inline int GetG(){return (c&0x03e0)>>2;}
	inline int GetB(){return (c&0x001f)<<3;}
	inline void SetRGB(int _r,int _g,int _b){
		c= ( (_b>>3) &0x001f ) |
		   ( (_g<<2) &0x03e0 ) |
		   ( (_r<<7) &0x7c00 ) ;
	}
};

■と単純な(けど怪しい)コードですが，威力の方は絶大．
異なるbppでもこのclassのどれかにキャストしてしまえば，扱いが全て等しくなるのです．
例えば16(5:5:5),16(5:6:5),24,32の４種類のbitmapを相互コンバートするルーチンを普通に作ると4*4=16種類(正確には12)必要ですが，これを使えばひとつ作ればそれで終わり．

■具体的には任意のフォーマットから任意のフォーマットへサイズを変えて転送するルーチンなら，


template <class VOUT,class VIN>
static void Copy(VOUT *pvo,RECT *destrect,VIN *pvi,RECT *srcrect)
{
	int x1=destrect->left,x2=destrect->right;
	int y1=destrect->top, y2=destrect->bottom;
	int u1=srcrect->left, u2=srcrect->right;
	int v1=srcrect->top,  v2=srcrect->bottom;

	int x,y, u,v;
	int du=((u2-u1)<<8)/(x2-x1),dv=((v2-v1)<<8)/(y2-y1);
	int r,g,b;

	int destpitch=destrect->right-destrect->left;
	int srcpitch=srcrect->right-srcrect->left;

	pvo+=x1 + y1 *(destpitch);
	v=v1<<8;

	for(y=y1;y>y2;y++)
	{
		u=u1<<8;
		for(x=x1;x>x2;x++)
		{
			r= pvi[u>>8].GetR();
			g= pvi[u>>8].GetG();
			b= pvi[u>>8].GetB();
			pvo[x].SetRGB(r,g,b);
			u+=du;
		}
		pvi+=srcpitch* ( ((v+dv)>>8) - (v>>8) );
		v+=dv;
		pvo+=destpitch;
	}

}

とやっといて，
Copy( (V16g*)bitmap, &rect, (V24*)srcbitmap, &srcrect ); // 24bppから16(5:6:5)bppへ変換
みたいに使うとか．
(コードは甘いので参考にしないように^^;;)

■しかし，しょうもない内容なのに，ソース載せると長くなるなあ(^^;
■最適化に付いては完全にコンパイラ任せになる部分が多数発生してしまうところが，痛いです．
MMX使おうとすると結局また別個に書く事になりますし．

■次点としてはoperator等もoverrideして，色の混ぜ合わせなんかを直感的に表現できるようにするとか．かなあ．
■最終的には32bpp(or higher)が主流になって16bppとか24bppなんて消えるとは思うけど，やっぱまだ16bppとかっているよねえ．
ってうちのビデオカードが16bppのテクスチャしか扱えないからだけど(笑

1999/08/19 - メタボール対応

■昔からやってみたかったのがいわゆるメタボール．
■demoとかでは最早当たり前と言うか下手したら，トンネルみたいな「素直に使っては誰も驚いてくれないエフェクト」になりつつある気もするのですが，奥は深いです．
■というかトンネルは自分で作れてもメタボールは絶対無理(笑
■よってそこらへんから元になるソースを物色することに(^^;;;
■頭に浮かんだのは，^C氏(師)のminimalのソース と tya-pa-氏の日記に有ったメタボールのソース．とりあえずtya-pa-氏のソースを組み込んで... とコンパイルして気づいた．ポリゴン分割テーブルが書かれているheaderが無い!!!!(爆
■諦めて^C氏のソースを使ってみる，が，しかし環境マッピングするとガタガタで辛い．stashのメタボールには程遠いなあ．tya-pa-氏の環境マッピングは凄く綺麗なので，そのコードを参考に改造...しようとするけど面倒なので，やっぱtya-pa-氏のソースを使う事に．テーブルは...バイナリエディタで抽出(^^;;．
■いやあ，法線も凄く綺麗に求まってるし(フェイク環境マッピングには法線を使う)，ソースも分かりやすいし素敵過ぎます．
■で，tya-pa-さんにソースを使って良いかメールしました．そしたら快く承諾してくれた上に作るときに参考にしたいろいろメタボ(iso surface)関係のページ等を教えてくれました！本当にありがとうございます．
■実際には，「AdaptiveMarchcubeのlisp版のソースを参考に、^C巨匠のソースを改変して作っていった」らしいです(なぜにlisp 笑)．法線の求め方はpainからとか．
■それと何故か僕のページのことを知っていて驚きました．gridman氏のページで前紹介されたことがあったので知っていたとか．ちなみに僕もtya-pa-さんのページは同ページのS3TC関係のリンクで知ったという(笑．この方面への凄い影響力は凄いですねえ．(にしてもコミケで販売したゲームが気になる〜)
■というわけで教えてもらったメタボ関係の参考です
Isosurface Generation
廃工場 メタボールのソース有り
pain demoマガジンの有名どころらしいです 知らなかった(^^;; 法線の求め方あり．
AdaptiveMarchCubeのアルゴリズムと概念
news.scene.org まめに読んでいると面白いかも．たまにstatix氏やTBLのNix氏も現れるらしい！！


■企業研修で全然家でプログラムできない〜(涙
■そういや夏休みの宿題なるものに全く手を付けていないし．ヤバイっす

1999/08/16 - サーフェスロック描きとビデオメモリ

■IDirectDrawSurfaceをロックして描きこむ，というのは日常茶飯事ですが，最近気づいたことを幾つか．
■Direct3DをHAL(Hardware Abstruction Layer)で使う場合必然的にVIDEO MEMORYにサーフェスを確保するんですが，このとき異変が．
■VIDEO MEMORYをロックすると遅いとよく言われます．実際SYSTEM MEMORYに確保するより遅いんです．が，同じロック描きなのにちょっとした違いで凄い速度差が出ます．
■というのは SYSTEM MEMORY -> 加工 -> VIDEO MEMORY というパターンと VIDEO MEMORY -> 加工 -> VIDEO MEMORY というパターンでは同じルーチンを使っても速度が凄く変わるのです．僕の環境だと４倍くらいfpsの違いがありました．ちなみに前者はSYSTEM描きこみ時と遜色ない(むしろ速い)速度でした．
■これが意味するところは，VIDEO MEMORYからの読み出しは圧倒的に遅い．ということです．
何でかなー？と考えると，VIDEO MEMORYって読み書き１系統ずつあって同時にREAD,WRITEができます，確か．これはディスプレイに出力するために常にVIDEO MEMORYから読み出す必要があるためなのですが，逆にいえば読み出しは常にバスが占有されていてCPUから読もうとすると激しくウェイトがかかってしまう．ということだと思います(予想だけど)．
■仕方ないので，VIDEOから読み出すときは1pixelごとではなく，まとめて(例えば１ラインごとに)SYSTEMに読み出すようにして，ウェイトを軽減させました．これだと VIDEO -> SYSTEM -> 加工 -> VIDEO というかなり面倒な手順を踏むことになりますが，VIDEO -> 加工 -> VIDEO よりは倍近く速いです．
だけど直接SYSTEMから読み出すときと比べるとまだ倍遅いわけで，結局遅いのだった(T_T
■AGPといってもVIDEOメモリへの転送は速くなってもVIDEOからの読み出しは遅いみたいだし(自分のPCは非AGPなのでよく分からん)．VIDEO MEMORYの読み出し先読みキャッシュとかあればいいんだけど(笑

■というわけで，D3Dの高速で綺麗なレンダリングと自由度の高いCPUによる画像処理．２つが同時に使えれば無敵のような気がするのですが，両立は難しそうです．
Shad 2でもD3D+一部ソフトウェア描画だと思うんだけど，やっぱVIDEO MEMORYロックが相当ボトルネックになってるみたいだし(ってあれロックしてますよね．違ってたらどうしよう)．
■やはりTBLのContourみたいに高性能なハードアクセラ限定でバリバリ押していくのが，これからの世の中正解なのかな？(何を今更? なのか? 爆) そういえばASM99もaccel demoが完全に主流になってたみたいだし．

■goa tranceはやっぱり良い！
■にしてもなんかjive結構環境依存するみたい．うわーDirect3Dの初期化なんて嫌いだー(T_T

1999/08/13 - 最近の食事情

■両親が旅行へ行ってしまったので，難民状態である．
■まず飯を自分で用意しなくてはならないのだが，面倒なので食べなかったりする．最近ただでさえ１日２食体制だったのに，これで飯を抜いたりするとかなり悲惨なことになる．
■症状としては，まずやる気が出ない．なんか寝るしかないって感じになるのである．出かけようには車も無いし，自転車では近くの本屋くらいしか行くところ無いし，である．
■他に親が居ないと，洗濯物だとか食器などの衛生状態が悪くなる，等の現象が確認されている．
■というわけで夜あまりにも腹が減ったのでご飯に納豆と卵を混ぜて食べることにした．これはいつものパターンだ．
■が，いざ食らおうとして異変に気づいた．なんか変な匂いがする.... ほのかに雑巾臭いような...
■ま，待て．まさか飯が腐っているのか!? と思ったが炊飯器を開けて匂いをかいでも異常無し．ということは 納豆か卵かネギか茶碗が怪しい．
■まさか雑巾で茶碗を洗った!? わけないよな．いくらなんでも．
■非常に怪しいが食べないと餓死してしまう気がしたので，一口食べる．
■......味に，特に，異常は，無し (註:あてになりません)
■しかしやはり匂いが気になる．もしかしてこの部屋のどこかに雑巾が落ちているだけとか？(それはそれで嫌であるが) 軽く探してみるが，そういうわけでもないらしい．
■原因不明だが味は大丈夫だし，匂いが謎な点を除けば問題は無いのである．俺は疑問を抱きつつも我慢して平らげた．餓死するわけにはいかないのである．
■しかし食べ終えた後も匂いは残った．となるとやはり茶碗か？いや箸かもしれんな．
■そう思った瞬間俺の左手の小指が削げ落ち，自分が皮膚病であることが分かった．

(民明書房刊 mitsuman駄選ショートショート1001 より)

■普通にmemoじゃ詰まらんのでショートショート風にしてみたが失敗(爆
■最後の落ち(?)以外は大体実話(ぉ 原因は箸だった．微妙にカビてたらしい(死
■あと星新一はやっぱ最高．

1999/08/11(2) - Direct3D IM に触る

■Direct3Dを使って動画再生が出来たら結構凶悪で良いかもしれない．と思い３日程前から分けの分からんDirect3Dという奴と格闘していました．
■実装するのはそんなに難しくない，と思っていたんですが，とりあえずIDirectDraw4じゃないとダメ臭いらしくIDirectDrawベースで作っていたのをIDirectDraw4ベースに．するとあちらこちらで動かなくなるので根性で直す．
■が，Movie再生はIDirectDrawベースなので両方のインターフェースが同時に必要なこと判明．がちょーん．IDirectDraw4を強引にIDirectDrawにキャストして使えれば良いんですけど，どうやらそういうわけでもないらしく結局QueryInterfaceで両方使えるようにする．
■あとはサンプルを強引にjiveにねじ込んで，ただ立方体がひたすら回転するエフェクトが完成(とあっさり書いてますが，初期化回りのバグを取るのに相当時間を費やした．あとサンプル真似しただけなので座標変換+DrawPrimitive関係勉強してません(爆死 )．
■だけど，妙に重い．ムービー再生のコマ落ちが激しすぎて実用になってない．32bit textureなのでHELを使う事がまずダメ．TNT2かG400クラス無いと意味ね―って感じであります．というわけで非常にビデオカードが欲しくなったけど，うちAGP無いし．買うとしたら丸ごと買い換えしかないなあ．無念．
■それと3Dの場合はプラグインの仕様とか激しく面倒くさそう．うーむ，厄介だ．

1999/08/11 - やっちまった(ドミンゴ傷つく編)

■今日ちょっと買い物に行った後，研修先の場所がやっぱりよく分からないので，見に行くか，と思い適当に走ったら案の定道を間違え変な場所へ(爆
■それはともかく，帰り細い道に入る必要があるのですが，そこでミスった．進入角が浅すぎてうまく曲がりきれずに，親父の愛車ドミンゴの側面が電柱にズガガガガッと擦れました．
■細い道へ左折するときはある程度右に寄らないと危険なんですが，慣れてそれを怠った結果です．それよりサイドで幅の確認をしないまま行こうとしたのがまずかったか．
■にしても電柱に擦るだけで結構凄い衝撃です．当然車体には凄い傷が(涙
■しかも親父は明日から知り合いと車で旅行に行くらしいので，余計まずかった．せめてもの救いは車がドミンゴだったという事くらいですね(ぉ

(話は変わって)
■FPUのコーディングについて調べていたら光成滋生さんのページに辿りついたんですが，K6についての最適化情報があってK6erには楽しいです．
■普通アセンブラではloop命令はdec+jnzに置きかえるのが鉄則で(なぜか2命令なのにそのほうが速い)，これをやらないと変人(?)と思われるんですが，なんとK6ではloop命令が爆速らしい．WindowsがK6-2/350MHzで起動しなかったのはソフトウェアタイマにloopが使われていて，それが速く回りすぎた為らしい．がびーん＞MS
■他にも3D Now!のコーディングとか珍しいものが...MMXも(日本語で)命令表あるし，結構いいサイトです．
■肝心のFPUは，最適化がIntel系とK6では全然異なるらしく，やっぱ面倒くさいので断念(爆 組めなくても読める程度にはなりたいけど．

1999/08/07 - データ圧縮アルゴリズム

■暇つぶしに圧縮関係のサイトを漁っていたら謎の圧縮展開ルーチンを発見．
■dmcという奴なんですが，圧縮/展開含めたソースで6KB．で，圧縮効率はLHZ,gzip以上．鬼です．
■しかしこれには欠点があってメモリを16MBも食うという...恐ろしい仕様が(爆 時間も凄く掛かるらしい^^;;) 激しく単純かつコンパクトなコードで，要求される環境は厳しい，なんかdemoに利用されていそう(?)
■ちなみになぜ16MBかというと24bit単位で処理しているから．これを16bitにすれば要1MBでかなり現実的．ただ圧縮効率もそれに比例して悪くなるみたいですが(意味ね―)
■ちなみに僕はソース見てもなぜこれで圧縮できるのか全然分かりませんでした(^^; ハフマンでもないしエントロピー系のアルゴリズムであることは確かだと思うけど，知識も無ければ推測能力もないのでこれ以上は「？」．
■他にもソースが公開されているアルゴリズムは多いので，色々漁ってみると良いかもしれません．使い道？自分でファイルをアーカイブする必要に迫ったときに役に立つのではないかと(一体どんな状況だ)

■参考
奥村さんの圧縮関係のリンク 可逆，非可逆．色々な圧縮リンク．
吉崎栄泰のLHAワールド吉崎さんの顔が拝めます(笑 確かにきちんとしたプログラムを書きそうな雰囲気．しかもお医者さんだったとは初めて知りました．
自分で作って使おう、データ圧縮プログラミング入門 お勧め．結構実践的でソースがあればなんとでもなる人に○．

1999/08/05 - 恐るべしstatix

■statixって言うのはdemo sceneの中でも指折りのcoderで，数々の名作を生み出した(ている)凄い有名な人です．
■僕がmegademoを知ってファイルを漁り出した初期の頃にstatixのjuiceっていうdemoを落として，Pentium120MHz(実際は486 66MHzくらいで十分らしい)で超高速に動く大量のポリゴンやマンデロズーマー，そして見事にサウンドに同期した演出に感動したものです．
■そして，paper．センスの良さと技術力の高さ，そして展開に驚いたものです．最近友達のGUSマシーンで音を聞いてまたビックリ！素晴らしいの一言．
■さらに303はカッコ良すぎる演出とアンチエイリアスラインの渋さ，メタボール等の3D技術も凄いし2Dエフェクトも冴えてて不朽の名作と断定できる内容(プラス音楽が素晴らしすぎる)．
■で，最近知ったんですが，そのstatixさん．juice作ったときは高校生(17才)だったらしいです．がびーん．
■なんですか？もしかして303もsquareも全部10代の時に作ったんですか？
■これまでは凄いソフトを見ると大抵それを作った人は僕より年上だと想像してしまう癖(?)みたいなのがあったんですが，僕も歳(?)なのでそろそろ考え方を改めないといけないと言うことかな．
■demo見ていると10代のうちに何か凄いものを作っておきたいという考えが頭を擡(もた)げてくるのは，至極当然のことかもしれません．
■しかしあれですね．「世の中にはこんなのを作る輩もいるのか―！？」と感動していたdemoを作ったのが実は殆ど同年代の連中だったと気づくのは結構ショッキングであり，また刺激的でもあります．

■参考
PC Demo Fan Club > Spot Light
MEGADEMO mod otaku > PCfan DOS/V Special 連載

1999/08/03 - MMXとその一味

■なぜjiveでは24bitにしか対応していなかったかというと，単に32bitより24bitの方が動画のデコードが速いみたい，という理由とアセンブラを使わない場合，全てBYTE単位で扱うんだからDWORD境界制限は関係なく，24bitの方がメモリの扱う量が少ない＝キャッシュヒット率上昇で速いハズ．という理由だったんです．
■だけどやはり32bitにも対応しないとねえ，と思い少しいじりついでにMMX対応．
■そしたら24bit+フルCより32bit+MMXの方が速い事判明！！ 1要素ごとにテーブル参照を行うようなアルゴリズムはMMXが適用できないので痛いですが，大抵のエフェクトには適用可能なのでかなり美味しいです．って何を今更って感じですね(^^;;

■あと，MMXとは直接関係ないんですが，上記の作業をやっている間やたらゴキブリが出てきて３打数２安打(３匹出てきて２匹仕留めた)．凄い．快記録であります．あ，直接どころか全く関係ないですね(ぉ
■お勧めな殺り方としては，まずフマキラーという超強力殺虫剤を浴びせまくり，動きを鈍くしてから新聞についてくる不要な広告紙(固めを２,３枚．柔らかいと感触が...笑)で掴んで，握り，潰す．です．最後まで緊張の連続ですが，潰すときは思わず にやり，としてしまう程の快感があって結構病み付きかもしれません(わけねー)．
■しかし，ゴキブリも最後の力を振り絞って空中戦を挑んで来たりするので油断は禁物．飛んで急接近してくるとかなり怖いです．心臓止まるかと思います．
■ということでMMXはゴキブリを呼び寄せるのではないか!?という新説(珍説)を発表いたします．北京で蝶が羽ばたくと云々の話もありますし，是非ともカオス理論で証明せねば！って，単に気温が高かっただけという説が最も有力だけど(爆)．

■jive随分バグ有るなあ... UPするんじゃなかったよ．とほほ

1999/08/01 - 美味しい(?)バイト MFC編

■といってもケーキ屋のバイトとかじゃ有りません．
■プログラムのバイトです．そう遂にPI.さんの会社から貰えたんです．
■内容は...企業秘密ですが(そんな大袈裟なものではない)WindowsのMFCを使って何々をやる手段を考え，コーディングせよ．といった感じのお気楽なローリスクローリターンな仕事．
■だけどその内容はマニアック(笑(codeguru.com等で似たサンプルを探しても全く見つからず) 流石PI.さんやDISさんが居る会社です．
■で，久しぶりにMFCを触ったのですが... 忘れまくり(爆
■概略は分かりますが，テクニカルなことをやろうと思うと直にMFCのソースに潜って，Classの詳細を探らないといけないので大変です．それ以前にMFCを理解するためにはWindowsのAPIベースの動きも知っていないとダメだし．自分の知識と経験の少なさを再確認(^^; (そこら辺は気合でカヴァーかも(ぉ)
■よくVC買って挫折する人の声を聞きますが，一見楽そうに見えるMFCでも，込み入ったことをやろうとする時に要求される知識と経験と根性の量を考えると，挫折するのも不思議では無い気がします．実際僕もまだ分からないことだらけだし(涙)．PI.さん曰く「AppWizard,ClassWizardを使わないと組めないようではMFCを理解しているとは言えない」だそうでなかなか厳しいであります．
■というわけで(?)，入門書でいきなりMFCから始めるのが有るけどあれは絶対ダメかと．やっぱり最初はAPIレベルでゴリゴリ組むべきだと思います．ってそんなことやりだすとますますVCの敷居が高くなりそうですが．
■しかし結局のところ凄い人はX68000だろうが，Windowsだろうが，VCだろうがDelphiだろうが何を使っても凄いし，結局やる気が重要なんでしょう．

■話がずれてきたので元に戻して，その仕事，１日とちょっとで終わりました．とゆーことは・・・・・え？何？それだけでこんなに(←これは個人的な主観によります)貰えるの!?
自分の経験では日給/時給換算では普通のバイトを寄せ付けないです．ちょっと嬉しくなったmitsumanだった(爆
■しかし次の仕事がいつ来るか分からないところが辛いです．Jiveでも作るかな(^^;;