サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Pixel 9
www5d.biglobe.ne.jp/~noocyte
DirectX Graphics に関するメモ (Direct3D,Direct2D,DXGI ほか) 準備中 CG 素人が DirectX Graphics について調べたことのメモです. 主に MSDN のマニュアルやサンプルコードを読んだり, 自分で実験して確認したことをまとめています. 注意:最近の CG 業界用語は英語をカタカナにしただけでよくわからないものが多いので, 他の科学技術分野の用語 (特に数学・物理) や勝手訳語を使っています.
入力 E (eye):カメラ (視点) 位置 (カメラ座標系の原点でなくてもよい.) C (center):注視点 up:カメラの上方向を指定するベクトル カメラに対して前後に傾いていてもよいが,視線と平行であってはならない. OpenGL や DirectX のソースコードで up ベクトルをワールド座標系の真上方向 (0, 1, 0) に固定しているものをたまに見かけるが, これだとカメラを真上や真下に向けたときに何も見えなくなってしまう. (up と f が平行になるので,ビュー変換行列が定義できない.) OE (origin of eye):カメラ座標系の原点 P:任意の点 出力 カメラ座標系の正規直交基底 f (forward):カメラ前方向 (視線方向) の単位ベクトル u (up):カメラ真上方向の単位ベクトル r (right):カメラ右方向の単位ベクトル その他 (中間結
O:原点 OA:回転軸 P:回転前の点の位置 P':回転後の点の位置 Q:点 P を含む回転面と回転軸の交点 a:回転軸の方向・向きを表す単位ベクトル θ:回転角 回転方向は,座標系が右手系ならば a に対して右ネジの向き,左手系ならば左ネジの向きとする. p ≡ O→P p' ≡ O→P' u ≡ Q→P v ≡ a × u (u を +90°回転させたベクトル) 注意:右手系と左手系では外積の向きの定義が逆になる. O→Q は単位ベクトル a に対する p の平行成分,u は垂直成分なので, ……………………………………… (2.2.1) ………………… (2.2.2) v は定義より, …………………(2.2.3) a⊥u かつ |a|=1 なので,|u|=|v| である点に注意. 以上と u⊥v であることを考慮すると,回転後の位置 p' は2次元の回転の式を使って次のように書ける
VSQ ファイルはフォーマット1の SMF (標準 MIDI ファイル) である. チャンクの出現順序は次のとおり. ┏━━━━━━┓ ┏━━━━━━━┓ ┏━━━━━━━┓ ┃ ┃ ┃ Track Chunk ┃ ┃ Track Chunk ┃ Start ─→┨Header Chunk┠──┨ Track #0 ┠─┬─┨Track #1~n-1┠─┬→ End ┃ ┃ ┃(Master Track)┃ ↑ ┃(Normal Track)┃ │ ┗━━━━━━┛ ┗━━━━━━━┛ │ ┗━━━━━━━┛ │ └───────────┘ n:トラックの総数 (マスタートラック + 通常トラック) 通常トラックの本数は 1~16 (n=2~17). VSQ ファイル内での使用が確認された MIDI メッセージは次のとおり. Control Change (通常トラックのみ) CC#006
自称・リバースエンジニアリング技術のホビー研究家です.(^^; 逆コンパイラ (デコンパイラ,decompiler) の可能性と限界, プログラムの自動解析の難易度等について日頃考えていることをまとめてみました. (こうすること自体が研究を進めることにもなるので.) 注意: このページの内容の多くは現時点での私の直観・主観・推測等に基づくものであり, 正当性は全く保証の限りではありません.また,今後の研究の進展 (または行き詰まり(苦笑)) により,内容が変化する可能性は大いにあります. ■関連ページ OKWave QNo.3043962:デコンパイル?について (回答 No.5~) ソフトウェアのリバースエンジニアリング技術の必要性 (そしてJavaとCの逆コンパイラについて) 逆コンパイルについて Web 上で調べてみると, 洋の東西を問わず「C/C++ の逆コンパイルは可能か?」とか
気が向いたら書く. 特定のメモリアドレス範囲にマップされたデバイスのエンディアン判定. デバイス (アドレス) が異なればエンディアンも異なる可能性がある. (実際にそういうデバイスを使ったことがあるわけではなく, 可能性として考えてみているだけ.) レジスタ演算だけでエンディアン変換ができ,メモリアクセス不要. (バイト単位の) シフトが高速に行える CPU,あるいは (シフトに比べて) メモリアクセスが遅い CPU 向き. (バイト単位の) シフトが高速に行えない CPU では, 任意エンディアン変換はエンディアン反転以上に効率が悪い. データ長が長いと,それだけレジスタを多く使用する. ⇒ 同時進行中の,レジスタを使う別の処理の速度を低下させる場合がある. レジスタ長より長いデータは効率良く扱えない. 符号付整数型にトラップ表現が存在する処理系では, エンディアン変換の途中結果がトラ
自分で考案した任意多角形の面積,重心 (図心),断面モーメント,慣性モーメント計算の公式集 PDF ファイル および Excel ファイルを,DLmarket 様にて委託ダウンロード販売しています. (各 \514,セット割引 \771). 任意多角形の重心 (図心) および1次以上のモーメントの公式の無料公開は終了しました. 現在は面積の公式のみ公開しています. 表示確認ブラウザ:FireFox 3.6.10,IE8 注意:画像表示を ON にしないと,図と数式が表示されません. 本家:http://www5d.biglobe.ne.jp/~noocyte/Programming/Geometry/PolygonMoment-jp.html Mirror:http://www.geocities.jp/iafuu/Programming/Geometry/PolygonMoment-jp
●お知らせ グレゴリオ暦/ユリウス暦計算用C言語のソースコード・ ライブラリ Calendrier を販売しています. (\1,000 (個人用ライセンス) ほか) Calendrier リファレンス (Ver.1.0) 公開しました. このページの主な更新は Blog でお知らせします. このページでは, グレゴリオ暦またはユリウス暦の日付と,ユリウス日などの通算日数 (通日) を相互変換するアルゴリズムについて説明する. これらは1989年頃に自分で考えたアルゴリズムを再度整理したものである. 一応「ユリウス日」と書いてはいるが,これは通算日数の代表として挙げているだけであり, 基準日注1 (通算日数の第0日とする日付,epoch) は自由に選択できるので,ユリウス日 (Julian Day,JD) や 修正ユリウス日 (Modified JD, MJD) 以外にもさまざまな通算日数を
「生涯一プログラマ」志望の中年プログラマ noocyte (ヌーサイト) です. 主にプログラミングやアルゴリズムの話題と,自作フリーソフトを扱っています. 自分で考案したことを中心として,なるべくここにしかない情報を書くようにしています. よそに書いてあることは,そこを見ればすむことなので, わざわざここで同じことを書く気力が湧きません. (私はズボラなので.) 自分で考案したアルゴリズムやデータ構造を中心に解説します. メモリ管理 アラインメントの大きなメモリ領域を確保する方法 アラインメントの大きなメモリ領域を用いて, 高速かつメモリ効率の良い多数の集合を実現する方法 幾何学・CG のアルゴリズム集 3点の座標から簡単に角度と回転方向を求める.(2・3・N次元,外積を用いる方法) 多角形の面積,重心(図心),断面N次モーメントの公式と,向き (頂点列の回転方向) の判別方法 (Win
文字コードについて調べたことや実験したこと, テストプログラム,データファイルなどを随時掲載する予定です. ただし筆者の理解不足や誤解により誤りがあるかもしれませんので, ご利用は自己責任で. このページの主な更新は Blog でお知らせします. 表示確認ブラウザ:FireFox 22.0,IE8. 0.目次 シフトJIS Shift_JIS と Windows-31J (CP932) の違い シフトJIS 2バイト文字の判定 謎の検索ワード集 (シフトJIS編) 「Shift_JIS(SJIS,Windows-31J,CP932) 3バイト文字」 「Shift_JIS(SJIS,Windows-31J,CP932) サロゲート(ペア)」 「UTF-8 4バイト文字 Shift_JIS(SJIS,Windows-31J,CP932) 変換」 「Unicode(UTF-8,UTF-16) か
YLUG の 「第67回カーネル読書会 (glibc malloc について)」の ビデオで, 「mmap()/munmap() を使って 1MB アラインされたメモリ領域を得る方法」 が紹介されていた.発表者の kosaki さんは, その方法を知って「腰を抜かした」と言っていたが, 私は1985年頃に同じようなことを考えたことがあるので, 出しゃばってここで整理・解説しておこう. 「同じようなこと」といっても,当時 mmap()/munmap() を使ったわけではないので, 以下の説明は mmap()/munmap() に依存する話ではなく, 一般のメモリ割り当て関数 (malloc() など) でも通用する話である. また,mmap()/munmap() はいまだに使ったことがないので,以下の説明で mmap()/munmap() に関する部分は間違っているかもしれない. もしそうで
作成中 スマートフォン (Android,iPhone) など最近のモバイル機器には3軸地磁気センサ (電子コンパス) と3軸加速度センサ (モーションセンサ) を搭載しているものがある.これらを用いると,基準となる3方向 (水平磁北方向,水平東方向,鉛直方向) をそれなりの精度で求めることができ, さらにその結果を用いて端末の姿勢 (向いている方向) や方位角 (azimuth), 傾き角 (roll,pitch) を計算することができる. 余談だが,Android のマニュアルにある azimuth の定義はおかしい (はっきり言って間違っている) のでセンサアプリ開発者は注意. この定義によると水平面に対する画面の傾きが大きくなるほど azimuth の誤差が大きくなり,画面を垂直にすると全く方位とは無関係な値になる. 実際,ストリートビューに定義どおりの azimuth を渡した場
本当は「malloc() が返すアドレスは8の倍数って知ってます?」 にしたかったんだけど,「8」というのは CPU 依存の数字だし, 一般には2の冪乗なのでこういうタイトルにした. そもそもこの記事を書くきっかけは, YLUG の 「第67回カーネル読書会 (glibc malloc について)」の ビデオと資料を見たこと. 1985年頃に Lisp の処理系を作ろうとして (結局作らなかったけど(^^;)) メモリ管理方法について色々考えたアイディアと同じものもいくつか出てきて, 懐かしくもあり,またとても面白かったが, 私にとって目新しいアイディアは少なかった. malloc() の内部実装に興味を持つ人であっても, 意外と上記タイトルに書いた事実を知らない人が多いようなので, 「ビデオと資料」のページに色々とコメントした. この記事はそれを整理してまとめたものである. 2016/0
S ≡ (Px - Cx) * (Qy - Cy) - (Py - Cy) * (Qx - Cx) とする.S>0 なら左回り,S<0 なら右回り,S=0 ならば C,P,Q は一直線上にある.(注) なお,この判別方法は,CP と CQ が同じ長さである必要はない. θを求めたい場合はこちらへ. この問題を見て,逆三角関数 tan-1 (C言語では atan() や atan2()) を使って CP と CQ の角度をそれぞれ求め, 両者を比較しようと考えた方が多いのではないでしょうか. しかしこの問題では,角度そのものではなく角度差の符号を求めればよいので, 逆三角関数を使う方法よりも簡単で優れた,外積を使う方法を紹介します. 2つの2次元ベクトル A=(Ax, Ay), B=(Bx, By) の外積を次のように定義する. A × B ≡ Ax * By - Ay * Bx ここで O
●BMPファイル内の構造体に関する注意 メンバはすべて Little-Endian である. メンバ間に隙間 (パディング) はない. BMP ファイルを読む際,アテにすべきでない (というより,してはいけない) メンバがいくつかある. これについては下記のページが参考になると思う. 参考:BMP 画像の扱いかた #include <pshpack2.h> typedef struct tagBITMAPFILEHEADER { WORD bfType; DWORD bfSize; /* DWORD (4バイト) 境界にアラインされていない点に注意.*/ WORD bfReserved1; WORD bfReserved2; DWORD bfOffBits; /* DWORD (4バイト) 境界にアラインされていない点に注意.*/ } BITMAPFILEHEADER; #include
生の Windows API (および関連 API) を C/C++ で使用するために調べたことのメモおよび Tips 集です.随時追加します. Main:http://www5d.biglobe.ne.jp/~noocyte/Programming/Windows/WindowsTips.html Mirror:http://www.geocities.jp/iafuu/Programming/Windows/WindowsTips.html
以前このサイトとブログに,何度かアラインメントに関する記事を書きました (サイト内関連ページ参照). そのせいか「アラインメント」で検索して来てくれる人が多いので, 過去の記事に加筆修正してこのページを新たに作成しました. 加筆した点は次のとおりです. アラインメントとメモリアクセス回数の関係をわかりやすくするため, (ほんの少し) 図を導入しました. 「データがアラインされていないとメモリアクセス回数が増える」 と言葉で説明しているサイトは多いのですが, 図で示しているところはまだ見たことありません. アラインされていないアドレスにデータを書き込む場合, 読み出しの場合以上にメモリアクセス回数がかかる可能性があることを追記しました. 以前は「複合データ型 (配列,構造体,共用体) のアラインメント」はほとんど自明のことだと思っていたので軽く流していましたが, 意外なことにこれを解説してい
「C/C++ 関数・マクロ集」というタイトルですが, そのうちのいくつかはC専用だったりします.(苦笑) 2007/06/24(日) 追記 高木さんより, Cの規格上移植性に問題がある点をご指摘いただいたので, 現在修正中です. (たくさんあります….orz) とはいってもその多くは, めったにお目にかかれないような珍しい処理系とか, 「そんなの実在するの?」という処理系に移植する場合の話なので, 実用上ほとんどの場合は問題ないと思います. (一部そうとはいえないものもありますが.) Cの規格に照らして完全に「処理系・OS 非依存」 にするのは困難な場合もあり, 完璧な移植性にこだわるあまりプログラムが書けなくなっては本末転倒なので, タイトルに「ほぼ?」を入れました.orz 2007/06/21(木) 追記 このページを含め,私が C/C++ 関連記事を書くに当たりたびたび参考に&リンク
このページを最初にブックマークしてみませんか?
『noocyte のプログラミング研究室』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く