ハードウェアRAIDとは、RAIDの処理をRAIDコントローラーと呼ばれる半導体チップで行う方式をいう。 マザーボードのチップセットの機能で実現するRAIDもハードウェアRAIDの一種であるといえる。 ハードウェアRAIDはRAIDカード上に搭載された専用のASICやFPGAで処理されるため処理速度がほぼ一定で推移する傾向が強いという特徴がある。 急激な落ち込みなどは発生しづらく、高負荷が継続するようなシステムにおいて窒息するような速度低下を引き起こさないという利点がある。 また、専用のASICやFPGAで処理されるため、その電子回路にバグが無い限り、外部からの影響を受けずに安定して動作するという利点もある。 なお、バグがあると改修が難しいため残念なことになる。 最近ではASICやFPGAではなく、RAIDケース自体がLinuxなどを搭載した単体のコンピューターになっており、その中でソフト

ソフトウェアRAIDとは、RAIDの処理をソフトウェアで行う方式をいう。 一般的には、OSの機能、またはデバイスドライバーの機能として提供されている。 ソフトウェアRAIDではストレージに対して負荷がかかると比例してコンピューターにも負荷がかかることになる。 ただ最近のコンピューターはアホみたいに速いので、ソフトウェアRAIDであっても下手なハードウェアRAID製品より速いことも多く、高負荷時でも圧倒的なパワーで押し切る傾向も強い。 ソフトウェアRAIDを動かしているコンピューター上では他のアプリケーションも同時に動いているため、それらの影響でOSまで巻き込みシステムダウンを引き起こすと、データが吹っ飛ぶ可能性が強いという欠点を抱えている。 家庭用の安いRAIDケース製品などでは従来はデバイスドライバーでソフトウェアRAID機能を提供している製品が多かった。最近ではRAIDケース自体がLi

名前空間[編集 | ソースを編集] Microsoft.Xna.Framework.Graphics名前空間 構文[編集 | ソースを編集] public enum SurfaceFormat フィールド[編集 | ソースを編集] 値 概要

主な3D座標系[編集 | ソースを編集] 3D座標系とひとことでいってもXYZ軸の向きによって色々な種類がある。 モデリングソフトで描いた3Dモデルをゲームエンジンなどで表示しようとする際にこの違いで残念なことになることが多い。 この他にも長さの単位の違い（センチやインチ）でグダグダになることも多い。 Yアップ左手座標系[編集 | ソースを編集] X軸プラスが右 Y軸プラスが上 Z軸プラスが後 主な採用事例 DirectX Unity Yアップ右手座標系[編集 | ソースを編集] X軸プラスが右 Y軸プラスが上 Z軸プラスが前 主な採用事例 OpenGL MonoGame Xenko Shade3D MonoGameもXenkoもDirectX系プラットフォームであっても右手座標系となる。 Yダウン右手座標系[編集 | ソースを編集] X軸プラスが右 Y軸プラスが下 Z軸プラスが前 主な採

名前空間[編集 | ソースを編集] Microsoft.Xna.Framework.Graphics名前空間 構文[編集 | ソースを編集] public class RenderTarget2D : Texture2D 使用例[編集 | ソースを編集] 2個のカメラ[編集 | ソースを編集] 2個のRenderTarget2Dにそれぞれ視点を変えて描画して、プライマリサーフェイスにスプライトとして左右分割表示してみた。 画面分割して2プレイヤーで遊べたりするゲームでよくあるパターン。 using System; using Microsoft.Xna.Framework; using Microsoft.Xna.Framework.Graphics; using Microsoft.Xna.Framework.Input; namespace TwoCamera { public cla

元のファイル ‎(752 × 614 ピクセル、ファイルサイズ: 43キロバイト、MIME タイプ: image/png)

備考[編集 | ソースを編集] PreserveContentsは遅い[編集 | ソースを編集] PreserveContentsはVRAM容量が少ない環境ではメインメモリへの保存と復元が発生するため絶望的なほど遅くなる。 PCではまず問題になることはないようだが、一部のスマホでは絶望的な速度になるようだ。 なるべくDiscardContentsを使ったほうが良さそうだ。 DiscardContentsの注意点[編集 | ソースを編集] DiscardContents設定になっていると「GraphicsDevice.SetRenderTargetするたびに破棄（初期化）される」という特徴がある。この特性があるためレンダリング系APIの呼出順序を間違えると残念なことになる。

固定機能シェーダーとは、ゲームフレームワークやゲームエンジンなどに標準搭載されている固定機能のシェーダーのことです。 固定機能シェーダーのうち、各種ライブラリ内部でソフトウェア実装されたものではなく、GPUにハードウェア実装されたものは「ハードウェアT&L」などと呼ばれます。昨今はどちらも「固定機能シェーダー」と呼ぶことが多くなっています。 対義語は「プログラマブルシェーダー」です。一部のプラットフォームでは「カスタムエフェクト」などとも呼ばれます。 概要[編集 | ソースを編集] 素人にプログラマブルシェーダーなど書けるわけもなく、そんなものを書いている時間があるなら、まずゲームの本編を作ろう。そもそも定番の描画処理はわざわざプログラマブルシェーダーを持ち出すまでもない。 という理由でゲームエンジンの開発者でもないかぎり低レベルAPIに手を出すこともなくなり、DirectXやMetalや

BasicEffectクラスは、MonoGameの組込エフェクト（固定シェーダー）のひとつである。 ほとんどの場合はこのエフェクトを使って描画する。 継承[編集 | ソースを編集] System.Object Microsoft.Xna.Framework.Graphics.GraphicsResource Microsoft.Xna.Framework.Graphics.Effect Microsoft.Xna.Framework.Graphics.BasicEffect 名前空間[編集 | ソースを編集] Microsoft.Xna.Framework.Graphics名前空間 構文[編集 | ソースを編集] public class BasicEffect : Effect, IEffectMatrices, IEffectLights, IEffectFog コンストラクタ[編集

継承[編集 | ソースを編集] System.Object Microsoft.Xna.Framework.Graphics.DirectionalLight 名前空間[編集 | ソースを編集] Microsoft.Xna.Framework.Graphics名前空間 構文[編集 | ソースを編集] public sealed class DirectionalLight コンストラクタ[編集 | ソースを編集] 名称 概要

SATA Express （通称：SATAe）とは、Serial ATA （SATA）とPCI Express （PCIe）を合体させたインターフェイスである。 正式名称は「SATA 3.2」。 従来のSATA6Gの端子を2個を使ってPCI Expressと10Gでの接続を実現するというキワモノ。 基本的な発想はSASに似ている。 M.2に比べて遅かったため、まったく流行らなかった。

Quantum Bigfootとは、クアンタムが1996年から1990年代後半まで製造販売していた5.25インチのハードディスクドライブのブランド名である。 製造は松下寿（パナソニック四国エレクトロニクス→パナソニックヘルスケア）が行っていた。 概要[編集 | ソースを編集] HDDでは珍しい5インチベイに格納する製品。 一般人のパソコンは5インチベイにCD-ROMドライブを1個付けたら後はガラガラなのに目を付けたらしい。 速度的にはクアンタムの3.5インチ製品よりも劣るが、3.5インチよりも大容量なのが特徴だった。 シリーズ[編集 | ソースを編集] Quantum Bigfoot (無印)[編集 | ソースを編集] 第1世代、同世代で同容量のQuantum Fireball （3.5インチ）よりも遅いという謎の製品。 発売は1996年5月頃 容量は1.2GB（1プラッタ、2ヘッド）と2

Quantum Fireballの歌である。Firefox Quantumとは一切関係ない。 「クアンタム」ではなく「カンタム」と表記されることもある。 もえあがーれー もれあがーれー もえあがーれー クァンタムー fsckよー 走れー まだまわりにもれるー動作音がするーならー 巨大なtableをー 読めよ、読めよ、読めよー シークのー アームをー ぶつけるー クァンターム きどぉー しーない (怒) クァンータムー クァ・ン・タ・ム！ よみがえーれー よみがえーれー よみがえーれー クァンタムー MBRをー 掴めー initへー むかぁってー トブなー クァーンターム きどぉー しーない (泣) クァンータムー クァ・ン・タ・ム！ 関連項目[編集 | ソースを編集] Quantum Fireball Quantum Bigfoot

i｀i ,-───´└─-、 (＿＿＿＿＿＿__ﾉ　　　　　　　　　|／ /　　　　　　　　 ｀、　　　　　　　／ / _,-‐-　　　-‐-､_ ヽ　　　　　／ /　,-t‐、 　 　 ,-t-、　ヽ　　 ／ ＿_/　 i　 | |　　|　 |　|　|　　.ヽ／ ＿,-´　 /　　 ヽ_|ﾉ　　|　 ヽ」ノ　　　ヽ ＼　　 /　　　　　　＿＿,　　　　　　　ヽ ＞./　　　　　　　　　　　　　　　　　　i ´　i＿＿＿＿＿＿＿＿＿＿＿＿＿_| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| |　　　　　　| .＿＿＿|　　　　　　|＿＿＿ .(＿＿＿|

IndexBufferクラスは、ポリゴンを表示するのに使う頂点バッファの無駄を省くインデックスバッファを効率的に管理するクラスである。 VertexBufferクラスと同様にグラフィックボード上のVRAMに事前に展開しておくなどの機能を持つ。

バーテックスバッファ 提供: MonoBook ナビゲーションに移動 検索に移動 バーテックスバッファとは、「頂点バッファ」の英語的な表記である。 詳細は「頂点バッファ」の項目を参照。 「https://monobook.org/w/index.php?title=バーテックスバッファ&oldid=9135」から取得 案内メニュー 個人用ツール ログインしていませんトーク投稿記録アカウント作成ログイン 名前空間 ページ議論 変種 表示 閲覧編集ソースを編集履歴表示 その他 検索 案内 メインページ最近の更新未作成ページおまかせ表示ヘルプ ツール リンク元関連ページの更新状況特別ページ印刷用バージョンこの版への固定リンクページ情報このページを引用 このページの最終更新日時は 2017年11月7日 (火) 04:03 です。 プライバシー・ポリシー MonoBookについて 免責事項 モバイル

IndexElementSize列挙体は、 IndexBufferクラスのSetDataやGetDataでやり取りするデータ型（データサイズ）が「Int16」なのか「Int32」なのかを指定するための列挙体なわけだが、数字で「16bit」などと書かれると一目瞭然なのに英語で「SixteenBits」と書かれるとわかりにくいね！何かと思ってググっちゃったよ。

VertexBufferクラスは、ポリゴンを表示するのに使う頂点のリストである。 MonoGameでは頂点構造体を単純な配列で保持しておいてもDrawUserPrimitevesメソッドで描画できるが、VertexBufferクラスを使っておくと頂点バッファをメインメモリからVRAMへ事前に転送しておけるので高速化が見込める。 C#でゴリゴリと頂点データを加工したい場合はメインメモリとVRAMを行ったり来たりが相当な無駄になるのであまり向いていない。 逆にほとんどのケースが該当する「頂点データを決めたら破棄するまで変形させないもの」には使ったほうがよいとされている。 また、C#ではなくHLSLの頂点シェーダーで頂点バッファの加工を行う場合は必須となる。 ちなみに一部のOpenGL系プラットフォームでは一度格納すると二度と取り出せない（GetDataできない）ものも存在している。 3Dモデル

三角形の秘密はね… 教えてあげないよ!! ＿n_＿ (＿＿＿)　ﾚ /ー#ーヽ／ ＜/(●､●)ヽ /# # ー# #ヽ ￣￣|￣|~￣ |　| (ﾆ）（ﾆ) ＿n_＿ (＿＿＿)＼ /# # #ヽ／ ＜/(o)､(o)ヽ /# # ＝# #ヽ ￣￣|￣|~￣ |　| (ﾆ）（ﾆ) ＿n_＿ (＿＿＿) /# # #ヽ ＜/(･)､(･)ヽ＞ /# # ー# #ヽ ￣￣|￣|~￣ |　| (ﾆ）（ﾆ) ジャン♪ 関連項目[編集 | ソースを編集] ポリンキー ポリゴン バーテックスバッファ インデックスバッファ コンスタントバッファ

インデックスバッファ（英語：indexed buffer）とは、主に3DCGで使われる用語で、頂点バッファ（頂点データの配列）の無駄をなくすための配列である。 ポリゴンの世界では四角形は「三角形が2個」で表される。 五角形でも六角形でもそれ以上でも基本は「三角形が◯個」という形式になる。 たとえば四角形があるとすると、それは三角形が2個、全部で6頂点のデータになる。 var vertices = new VertexPositionColor[6]; vertices[0] = new VertexPositionColor(new Vector3(-10, -10, 0), Color.Green); vertices[1] = new VertexPositionColor(new Vector3(-10, +10, 0), Color.Green); vertices[2] = ne