  |
はてなキーワード: DirectXとは
・snes9x-1.5.1-srcフォルダを入れるまとめフォルダを作る（ここにzlibとlibpngとfmodとnasmのフォルダを突っ込むため）。
・zlibはソースをDLして解凍する。できたフォルダをzlibにリネームしてまとめフォルダに突っ込む。zlibフォルダ内のcrc32.cをemucrc32.cにリネームする。
・libpngはコンパイル済みバイナリをDLして解凍する。できたフォルダをlibpngにリネームしてまとめフォルダに突っ込む。ソリューションエクスプローラでlibPNGフォルダ内の*.cをプロジェクトから除外する。プロジェクトのプロパティで追加の依存ファイル一覧にあるlibpngmt.libをlibpng.libにリネームする。
・fmodはver.3系（ver.4系でのビルドは未確認）のコンパイル済みバイナリをDLして解凍する。できたフォルダの中のフォルダをfmodにリネームしてまとめフォルダに突っ込む。
・nasmはコンパイル済みバイナリをDLして解凍する。できたフォルダの中のフォルダをnasmにリネームしてまとめフォルダに突っ込む。nasmはプロジェクト中の*.asmのビルドに必要になる。後の*.asmのビルド設定との整合性のためこの通りに配置すること。
・プロジェクトのプロパティでDirectX SDKのIncludeとLibフォルダにパスを通す。
・プロジェクトのプロパティで、「リンク前のイベント」に次のコマンドを追加する。
pushd "$(SolutionDir)..\"
del "i386\*.obj"
"$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\2xsaimmx.asm" "-oi386\2xsaimmx.obj"
"$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\bilinear.asm" "-oi386\bilinear.obj"
rem "$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\c4.asm" "-oi386\c4.obj"
"$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\fxemu2.asm" "-oi386\fxemu2.obj"
"$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\fxemu2b.asm" "-oi386\fxemu2b.obj"
"$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\fxemu2c.asm" "-oi386\fxemu2c.obj"
"$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\fxtable.asm" "-oi386\fxtable.obj"
"$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\sfxproc.asm" "-oi386\sfxproc.obj"
"$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\spc.asm" "-oi386\spc.obj"
"$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\zsnes.asm" "-oi386\zsnes.obj"
rem "$(SolutionDir)..\..\nasm\nasm.exe" -f coff "i386\zsnesc4.asm" "-oi386\zsnesc4.obj"
popd
上記のコマンドに出てくる11個の*.objファイルをプロジェクトに追加する。ただしコマンドがコメントアウトされている2つ（c4.objとzsnesc4.obj）はビルドから除外しておくこと。
・SARマクロ（sar.h）が原因でコンパイラが死ぬので、このマクロを不使用にするためにport.hの277行のRIGHTSHIFT_IS_SARマクロ定義を未定義にする。
ここまでの手順でビルドが通る。
TODO:
・プリプロセッサZSNES_C4を有効にする時の設定
いろいろ間違ってるかもしれないが、力尽きた
| 分類 | 開発環境 | 開発言語 | メーカー | GPU | OS | API | 備考 | URL |
|---|---|---|---|---|---|---|---|---|
| シェーダ言語 | _ | Cg | NVIDIA | GeForce | Linux Windows Mac OS X XBOX | OpenGL DirectX 8/9 | C言語ライクな言語 グラフィック用途向け シェーダープログラムの最適化 | http://developer.nvidia.com/page/cg_main.html |
| シェーダ言語 | _ | HLSL | Microsoft | GeForce RADEON | Windows | DirectX | グラフィック用途向け シェーダープログラムの最適化 | |
| シェーダ言語 | _ | GLSL | OpenGL ARB | _ | _ | OpenGL | C言語ライクな言語 グラフィック用途向け シェーダープログラムの最適化 | |
| GPGPU言語 | CUDA | C言語 | NVIDIA | GeForce GeForce 8100 mGPU以上 | Linux Windows XP/Vista Mac OS X | _ | 標準C言語 | http://www.nvidia.com/object/cuda_home.html |
| GPGPU言語 | Stream SDK | Brook+ | AMD | RADEON R600世代以降 (=RADEON HD2400以降) | Linux Windows | OpenCL(対応予定) DirectX 11(対応予定) | C言語ライクな言語 | http://ati.amd.com/technology/streamcomputing/index.html |
| GPGPU言語 | Brook for GPU | Brook | スタンフォード大学 | GeForce RADEON | Linux Windows | OpenGL DirectX 9 | C++ライクな言語 | |
| GPGPU言語 | Close to Metal(CTM) | アセンブリ言語 | AMD | RADEON | _ | Stream SDKのCALに移行 | ||
| GPGPU言語 | _ | Sh | _ | _ | _ | _ | C++ライクな言語 | |
| GPGPU言語 | RapidMind | C++ | _ | GPU マルチコアCPU Cell | _ | _ | Shの商用化版 |
参考文献
CUDAを使う：tech.ckme.co.jp
http://tech.ckme.co.jp/cuda.shtml
【特集】超並列プロセサ - GeForceアーキテクチャとCUDAプログラミング
http://journal.mycom.co.jp/special/2008/cuda/menu.html
Windows環境は、Visual Studioを用いてmakeを行うようになっている
のような、聞きかじった知識を自分の意見として発表していることで最近有名になってきているニュースブログサイトだ。
今日そのデジタルマガジンの記事を訂正するようにコメントで指摘したら、あっという間に消されてしまった。その経緯を書き残しておくとともに、デジタルマガジンの危険性をお伝えしたい。
「S.T.A.L.K.E.R. Clear Sky」の詳細が発表！DirectX 10に対応 | デジタルマガジン
最初の記事本文では
2007年に発売されたFPSゲームの中で一番売れたゲーム「S.T.A.L.K.E.R.: Shadow of Chernobyl」。
とあった。2007年セールスランキングによると、一番売れたFPSゲームはCall of Duty 4であるので、まずコメントで指摘した。すると、デジタルマガジンは、
2007年に発売されたFPSゲームの中で一番売れたPCゲーム「S.T.A.L.K.E.R.: Shadow of Chernobyl」。
と、PCという一言をこっそり付け加えた上で、「XboxとかPS3、NDSの総プラットフォームの話を持ち出すのはナシでお願いしますよ」とコメントを返している。その後、この訂正と、誤訳（one of the best-sellingを一番売れたと訳したこと）を指摘するコメントをしたのだが、全部消されてしまった。
ブログのコメントに対するデジタルマガジンの姿勢を書いた記事がある。
ブログのコメント対応マニュアル、これで悩みともおさらば | デジタルマガジン
記事に関連して活発な意見交流を読者間で行って欲しいと言う一方で、デジタルマガジンに不利なコメントは削除するという方針のようだ。ブログを運営している側からしたら、自分の庭の雑草を抜いているような感覚なのだろうか。「自分の思い通りのコメントをしてくれなきゃ嫌！」ということのようだ。
だが、そんなことをニュースサイトが行っていいのだろうか？ ましてや他のマスコミの、こういう隠蔽体質を批判しているくせに。
同じくこの記事には、「批判をしたい人は、自身のブログなりwebサイトなりで批判しろ」とも書かれていることだし、折角なのでデジタルマガジンが嫌っている「はてな」を使ってみんなに問いたいと思う。
でもね、今さらアセンブリ言語やC/C++を勉強するのは時代遅れだと思う。もちろん、携帯電話などの組み込み産業ではそういった言語はまだまだ健在だし、パソコンで何かを制御したりするようなニッチ産業でも生き続ける、「使える言語」であることに違いない。でも入門者にお薦めするような言語ではない。昔ならBasicじゃ遅いからCかアセンブリ言語で書くという動機があったが、今じゃPerl/PHPでも十分に動作は速い。ちょっとしたGUIを作りたいならTcl/tkか、Javaを使うべきだ。VBもいい。C++&DirectXはよっぽどプログラミングに熱中できる人が使えばいい。あくまでパソコンに限定した話だけどね。
携帯やパソコン制御はニッチだから初心者にお勧めできなくて、ＧＵＩ作りやすいから初心者にお勧めできるってのがよくわからん。
低級言語で頑張って"Hello World"作ってた自分から見ると、Java/PHP/Perl/Rubyのような超高級言語でさくさく高度なWEBアプリケーションを作ってる人がとても羨ましく見えると同時に、「大した苦労もしないで、俺はやったぞみたいな顔するんじゃねえよ。」とついつい思ってしまうことがある。アセンブリ言語ときたら比較命令を発行するたびに分岐先ラベルをいくつも定義しないといけないような面倒臭さがあった。それでも、それ以前のハンドアセンブル組や、機械後を生で見たり、パンチカード使ってたような人達から見れば甘いと思うだろう。
と、俺のひがみを書いてみるテスト。
でもね、今さらアセンブリ言語やC/C++を勉強するのは時代遅れだと思う。もちろん、携帯電話などの組み込み産業ではそういった言語はまだまだ健在だし、パソコンで何かを制御したりするようなニッチ産業でも生き続ける、「使える言語」であることに違いない。でも入門者にお薦めするような言語ではない。昔ならBasicじゃ遅いからCかアセンブリ言語で書くという動機があったが、今じゃPerl/PHPでも十分に動作は速い。ちょっとしたGUIを作りたいならTcl/tkか、Javaを使うべきだ。VBもいい。C++&DirectXはよっぽどプログラミングに熱中できる人が使えばいい。あくまでパソコンに限定した話だけどね。
プログラミングするのは何もパソコンだけじゃないんで。マイコンとか一杯あるから。線と線をつないで、発行ダイオードとかをピコピコ光らせるの。完成すると楽しいよ。よく、はんだごてあてすぎて、部品こわしちゃうけど(汗)。
もし、私が「アイツ、○○なんて言語使ってらー」なんて言って来たらぜひ、「○○言語を使うと、○○が簡単に記述できて便利だよ。」と、そのとき使ってる言語の利点を教えてください。私も所詮、いま使ってる言語のことしか知らないんで、ついつい、違う言語には拒否反応を起こしてしまうんです。
だいたい、セグメンテーションフォルトを起こすような言語は嫌い
Haskelわけわかんないし
Java重苦しいし、いちいちclass Hogehoge { public static void main() { ... } }書くのがめんどくさいし、API多すぎ
オブジェクト指向したくなるような複雑なプログラムは最初から考えない(作れない)
言語が提供するGUIのツールはOSとは別に独自のレイヤー、世界感を持っててとっつきにくい
マルチスレッド、排他処理を扱うようなプログラムは脳味噌がついて行かないので書かない
Ruby、、、そもそもLL言語で大規模でオブジェクト指向なプログラム書きたくない。小規模ならオブジェクト指向要らない。
俺のマシンで実行できないAda/Basic/Fortran/Pascal その他いろいろ
VHDL、Verilog？FPGAやゲートアレイなんて持ってない、持ちたくない(苦手だもん)
HTML、XMLは日本語とタグが入り乱れるので、そのつど日本語入力の切替えが死ぬほど嫌になった。
だから、HTMLとXMLは全部手入力なんて真似は絶対してやらねえ。
Flex(Action Script)はコンパイラがJavaで実装されてて重すぎる。(シェルを使えばまし)
JavaScriptはブラウザごとの挙動の違いを吸収しきれる自身が無いので使わない。
1プログラムにつき、(コメント含めて)250行以上書きたくない
(本文には触ったこともない言語を思い込みで罵倒しているなど、嘘、おおげさ、紛らわしいが多数混入しています。それが全部わかった貴方はプログラミング言語マスターです。)
すいません。「進むべき道」と言うのは言葉のあやで、そんな大層な思いは持っていません。
例えば元増田が買ってもらったパソコンがマックなら、VC/C++&DirectXの(実践を含めた)勉強をすることができないという程度の意味です。
きっとプログラム以前にパソコンのパの字のレベルだと思うから、
３Ｄをやってみたいだけというのであれば
まずは六角大王でも触ってみれば？
http://rd.vector.co.jp/soft/win95/art/se029598.html
http://www.youtube.com/watch?v=mOJOxFqVSmE
３Ｄゲームをつくる！みたいな本はいくつも出てるけど、
いきなりそこに飛び込むのは自殺行為だとおもうんだ。
ゲームなんて1人でつくれるものでもないしね。
言語はなんでもいいとおもうけど、DirectX使うのが資料もたくさんあっていいんじゃないかな。
でも六角大王でものが動かせるようになってからでも遅くはない。
当たり前だが何らかの言語を覚える必要がある。3DCGを扱う上ではデファクトになっているC++などがお勧めだ。
しかし、入門用の言語としては不適切の可能性がある。まずは別の言語を学んだあとでやるべきだろう。
最低限、線形代数の知識を必要とする。
そもそも３D空間で自由に物体を操作するには4次元での演算が必要となる。なぜか解らなければ数学の先生に聞いてみよう
DirectXやOpenGLなどのAPI知識を必要とするだろう。
また、それらを使う前提になる各環境依存のAPI(たとえばWindowsAPI)などの最低限の知識を必要とするだろう。
コンピュータグラフィックスがどのように演算されているか知っている必要がある。
そのためには前提となる２ｄCGの知識も問われるだろう。
http://anond.hatelabo.jp/20070803143914
（＊）このエントリでは増田がとっても感情的になって、C言語、SQL、JScript, JavaScript, Perlをけなす風潮に反発します。
確かにプログラミング言語やその周辺の技術は目的を達成するための手段でしかないのかもしれない。けれど、その手段を行使できるようになるために一週間そこらドキュメントやサンプルを読み書きするだけでおｋな人って実在するのか？JavaやCにしたってどれだけ標準搭載の関数やらAPIがあると思っているんだ？そりゃあ実装に必要な部分さえ分かればいいんだろうけど、、。ぐすん。
俺はオブジェクト指向を肌で感じ取れるようになるまで1年以上かかったが、それでも完全に理解できているといえるのかよく分からない。それを一週間程度で理解できるだとおぉぉ、許せん、嫉妬してやるぅ。
ついでに言うと、誰でもできる仕事を一般化してプログラムに落とし込むのがプログラマの仕事だあああ、、、、とも思う、、、、うん、思うだけ。中学生にでもできるといいながら、人間に外注するってどういうことよ。誰でもできるんならパソコンに頼めよ。そういうプログラムを組めよ。優秀な人はコンパイラとか作れるんでしょ。もっと言えば、プリミティブな部分とやらを最初からプログラミング言語でしゃべっておけば、外注すら必要ないよ。外国の人を作業するとき英語でコミュニケーションとるでしょ？システムの設計とかもプログラミング言語でやれば？まさか日本語で適当に要件定義書書いて、外注に丸投げとか言わないよね。それとも、優秀な人はみんな理論屋になるってこと？
ぐすん、、ぐすん、、そりゃあさ、僕はHDLでCPU設計とか、 Yacc/Lexでコンパイラ作成とか、OS作成とかやったことないし、できないよ。C/C++だってDirectXの3Dに関わる理論とオブジェクト指向が分からなくて挫折したよ。XoopsみたいなCMS作ろうとして要件定義や設計がぜんぜんできなくて挫折したよ。要件を決めずにプログラム組んでたら、後から次々と要求変更を思いついてしまって、手が回らなくなって頓挫したよ。データベース設計もまともにできないしSQL？なにそれって感じだよ。電子回路？トランジスタの使い方・つなぎ方とか、増幅率とかがうまく計算できなくて挫折したよ。
だから（？）「Perlなんて簡単だよね。そんなものにしがみついてるなんてレベル低いなお前」みたいなこと言うおまえなんか大嫌いだ。
16からプログラミングを始めた23歳
思えば最初からレベル2でのスタートだった。始めた当初からプログラミングが楽しくて仕方なかったのだ。
プログラミングを始めて3ヶ月ぐらいはC,C++を学び、Boost最強！とかと思っていた。パズルを解くのにはまる。
六ヶ月ぐらい経過したときには、MFCを使ってwindowsで色々作っていた。目に見える物が作れるのがうれしかった。
ふとWindowsAPIで直接組んでみたときにMFCの使いづらさを知った。
数ヶ月後、ソフトウェアレンダラとか、剛体シミュレーションとか作り始めた。OpenGLやDirectXにも手を出した。
ここら辺で一年ぐらい経過した。
いつの間にかmlやらschemeやらに手を出した。新しい地平を目にした気がした。
rubyやpythonにも手を出した。LLという新しいあり方を知った。
それでも完全に満足できなかったので新しい言語を作ってみた。
設計して、検討して実装した。とりあえずの最低限の機能をだ。
あまりの地道な作業に気が遠くなった。自分には言語を作るのが無理だと思った。
就職した。仕事をしてプログラマはプログラミングが好きじゃない人がいることに驚愕した。
今ではNEETをしている。
ちょっと酔いぎみですが勘弁。
Windowsでしか動作しないのはあれだよね、DirectXだよね。元をただせばWindowsにOpenGLを実装してたWindowsNTチームの陰謀が原因か。そのせいでDirectX作る羽目になったんだし。遠まわしに陰謀が成功しているわけで、Linuxとかの人には悪いけど、DirectX互換APIみたいなのも実装しないと移植できないんだろうなあ。
MESAってOpenGLだっけ? よくわかんないけど、SDL移植とかのQuake4はLinuxで動いてる。えーっと、つまりつまり市販品ではあまり見ないけれど、「技術的な壁はない」が、移植が困難あるいは採算が取れないってことかー。
freeciv？ こっちのほうで論破されてませんでしたっけ＞http://www.yamdas.org/column/technique/gamej_ind.html。クローンゲームだとWindowsに対抗すらできてない気が。なんでオープンソースゲームの品質が悪いのかについてのなぞも関係してくるのでしょうか。オープンソースで進捗が悪いところのほうが品質が驚くほどいい気がします。
ぷらぐいんとかよくわかんないです。じゃばもわかんないです。
MacにAdobe製品があって、Windowsにも一応移植されているのに、Linux/Unixの人はほしがらないのでしょうか？ それとも、そんな作業をする人がいない？ そんなばかな。
