DFPSR

DFPSR

David Forsgren Piuvaが作成したSSE/Neonを使用したC ++ 14の最新のソフトウェアレンダリングライブラリ。最新の主流の流行を探しているなら、他の場所を見てください。これは、数十年にわたって開発され、最小限のメンテナンスで孫を生き残ることを目的とした高品質のソフトウェアのライブラリです。あなたの遺産を石に刻むのと同じように、スキルを習得するにはもっと努力が必要ですが、遠く離れた図書館に頼らないことで、より堅牢な結果をもたらします。最大ユーザーエクスペリエンスと最小システムの依存関係。

クリエーターの背景

モバイル業界からのデジタルビデオ安定化におけるDxomark世界記録。民間の空港交通規制のための安全性のロボットビジョンを担当しました。モバイル、医療、ゲーム業界のさまざまな企業で最適化の講義を行いました。 GPU、CPU、DSP、ISP、FPGA、ASICの最適化を扱った。

最適化には、時間を節約するための適切なツールが必要です

コードの最適化に関する最も重要な部分は、科学者がアルゴリズムを設計することはできず、ハンドライティングアセンブラー（最も一般的な間違い）を変更する余地がないため、科学者にアルゴリズムを設計することができないためです。アルゴリズムの設計は、品質とパフォーマンスの間に良いトレードオフができ、すべての最適化が整っているまで行われません。速度と品質の両方を向上させるために、どこかで低コストで品質を上げることにより、1つの場所で品質のコストでの時間の節約を補うことができます。アルゴリズムのほぼ最適なベクトル化をより速く作成できるほど、設計プロセスをより速く反復させることができます。あなたが本当に近似しているものについて考えてください。できるだけ多くの完全なストレートポリゴンを描くというあなたの目標ですか、それとも、あらゆるテクニックを使用して複雑な現実の形に近似するという目標ですか？

公式ウェブサイト：dawoodoz.com

あなたのゲームが等尺性CPUレンダリングを使用しているように見えるかもしれません

深さベースのキャストされた影と、CPUで実行されている800x600ピクセルで453フレームでの通常のマッピングを備えたリアルタイムダイナミックライト。より高い解像度はレトロなスタイルを破り、実際には悪く見えるでしょうが、ゲームロジックと追加の効果には多くの時間が残っています。 3Dモデルを事前にレンダリングして拡散、通常の高さ、高さの画像を使用することにより、データを読むことは、自由な視点を使用するよりも最新のCPUではるかに効率的です。これにより、画面上にピクセルよりも多くの三角形があり、静的ジオメトリのパッシブ更新を行うことができます。低極性の3Dモデルは、動的な影をキャストするために使用されます。

ポリゴンを使用した従来の3Dレンダリングもサポートされています

3Dレンダリングは、CPUでの2Dまたは等尺性レンダリングほど高速ではありませんが、低決定的なグラフィックスの場合、1920x1080ピクセルで60 Hzに達することがよくあります。より高い詳細レベルとその他の機能のために、レンダリングパイプラインをコピーして変更して、必要な機能のみにハードコードし、特定のレンダリングエンジンの数学を簡素化することをお勧めします。

GPUが非常に速いのに、なぜオープンソースソフトウェアレンダラーを使用するのですか？

• ソフトウェアレンダラーを使用した堅牢性は、青画面になりやすいGPUのグラフィックスAPIとは異なり、間違いを犯したときにシステムを台無しにしないでしょう。
• 決定論は、あるコンピューターで機能した場合、おそらくオペレーティングシステム間でわずかな違いを持つ別のコンピューターでも同じように機能します。ただし、OpenGLには、ドライバーの実装にバグがあるすべてのものを削除すると、ゼロ機能が残ります。
• 視覚的なスタイルやロボットビジョンの低解像度が必要な場合は、GPUが遅くなる場合に静的にリンクされたソフトウェアレンダラーで最小限に抑えることもできます。
• すべてのデータがソフトウェアレンダラーで処理されている場合、簡単にデバッグすると、デバッグ中に何がうまくいかなかったかを見るのがはるかに簡単です。
• CPUサイクルとメモリ以外のハードウェア制限はないため、簡単に変更できます。そのため、コードをコピーして貼り付けてレンダリングパイプライン全体を変更できます。
• ピクセルの正確な2Dポリゴン上で奇妙な回避策を作成する代わりに、ソフトウェアレンダラーを使用すると、最初にピクセル全体で作業できます。

なぜこのソフトウェアレンダラーを使用するのですか？

• 最小システム依存性特定のシステムAPIに関連するすべてが、将来のオペレーティングシステムに簡単に統合できる必要がある重要な機能を統合する別のラッパーモジュールに配置されます。他のソフトウェアレンダラーとは異なり、これはグラフィックドライバーを必要としません。これは、ほとんどのコアがとにかくアイドル状態であるときに背景スレッドにキャンバスをアップロードすることでマルチスレッドを使用して同じパフォーマンスを得ることができるためです。
• バイナリなしライブラリ全体がソースコードから自動的にコンパイルされます。プロジェクトを構築する前に、ビルドシステムでさえ自らをコンパイルしています。これにより、プログラムを構築しようとする際に、将来誰も世紀の古いバイナリをリバースエンジニアリングする必要があることを確認し、すべてを読み取り可能なコードで検査できる場合、マルウェアに対してより安全になります。
• 静的リンクライブラリ全体は、自分でコードを書いたかのように、プログラムと静的にリンクされています。何十年も生き残ってきたコアシステムAPIのみが、依存関係、GPUドライバー、外部メディアレイヤーとして依存しています。 Unicode文字をエンコードし、フォントをレンダリングする方法から、最大の信頼性と決定論のために、コンパイルされたC ++プログラム内にポリゴンのラスター化された方法まで、すべてが存在します。ビルドシステムにより、可能な場合はC ++標準ライブラリを静的にリンクできます。
• レガシーの作成ソフトウェアは、将来の世代が、独自のグラフィックスドライバーのエミュレーターやリバースエンジニアリングを必要とせずに、ポート、コンパイル、およびネイティブに実行できる可能性がある可能性があることを作成します。

このライブラリの機能

• 完全自動C ++ビルドシステムプロジェクト内のソースファイルの長いリストはもうありません。含まれているビルドシステムには、含まれているヘッダーが見つかり、名前ごとに対応するソースファイルが自動的に見つかります。メインからクロールするように言って、残りを自動的に把握させてください。ライブラリのさまざまなバックエンドは、ライブラリのプロジェクトヘッダーを含めて処理され、各プラットフォームに使用するバックエンドを伝えます。チェックサムは、変更されたもののみを構築するために使用されるため、コードの一部に静的ライブラリを作成する必要はありません。
• 2D描画ピクセルの正確な標準描画ライン、長方形、ソリッド画像コピー、アルファフィルタリング画像図面、深さバッファードローイング、およびステンシル描画の呼び出し。
• 3Dレンダリングは、箱から使用した場合、双線形テクスチャサンプリング、Mipmapping、LightMaps、およびAlphaフィルタリングを備えたDirect3D 7とほぼ同等ですが、テクスチャにシェーディングを使用すると、Direct 3D 9のように変更できます（マルチスレッド付きSIMDを使用し、距離を表示することに基づいてスケジュールできます）。
• 閉塞システムマルチスレッド用のレンダリングタスクのコレクションには、オクルージョン形状を描くことができるオクルージョングリッドも含まれています。エンジンがculingおよび閉塞テストのために広い相を実装する場合、三角形、オブジェクト、またはグループ全体の描画をスキップできます。この完全に動的な閉塞は、各カメラの場所からどの領域を見ることができるかについての情報を使用して、特定のゲームの静的な最適化と組み合わせることができます。
• このグラフィックスAPIは、視点にフローティングポイント深度バッファーのみを使用するため、整数ベースの表現の深さ値を正規化する必要はありません。これにより、シーン全体を一度にレンダリングする余裕がある場合は、カメラを作成するときに無限の遠いクリップ距離を選択できます。
• 堅牢性のために設計されたメディアレイヤークロスプラットフォームメディアレイヤー。 ALSAとWinmmサウンドバックエンドは、システム固有のものを自分で呼び出すことなく、サウンドミキシングを完全に制御するためにバックエンドです。 Window Managementはマルチスレッドを使用してキャンバスをアップロードするため、結果をアップロードするためだけにGPUグラフィックスドライバーと重い依存関係を必要としません。フルスクリーンにボーダーレスウィンドウを使用するため、重要な電子メールまたはインスタントメッセージがバックグラウンドに表示されると、他のプログラムに簡単にアクセスできます。 Upscalingは、CPUで行われ、ピクセルに間違った補間を与えるか、存在しない可能性のあるグラフィックスドライバーに依存することなく、画面解像度で動作します。 CTRディスプレイ用に設計された古いメディアレイヤーは、グラフィックスドライバーがインストールされておらず、ディスプレイが解像度の任意の選択を受け入れない場合、範囲外のエラーを発生させる可能性があります。目に見えないカーソルアイコンを使用してマウスを非表示にするため、プロセスを殺そうとするときにクラッシュプログラムがカーソルを奪わないようにします。
• グラフィカルユーザーインターフェイスフレームワークレイアウトファイルまたは文字列を読み取る単一のコードを使用して、ウィンドウに視覚インターフェイスをロードします。名前または名前とインデックスの組み合わせを使用して、コンポーネントに一般的なハンドルを取得します。 Lambda関数をコンポーネントとウィンドウコールバックに添付してイベントを追加します。
• タイマーは、タイマーへの最初の呼び出し以来、2倍の精度秒を獲得します。そのため、時間のリセット時に真夜中のバグを心配する必要はありません。
• SIMD抽象化レイヤーは、 SIMD.Hを使用して、完全に読みやすいMath構文から非常に効率的なSSE、AVX、Neonの内在性を自動的に生成します。ベクトル化されたコードは、参照実装のように見え、未知のターゲットアーキテクチャのコンパイルはスカラー操作を生成します。これは、CPUハードウェアで最も頻繁にサポートされる基本操作でアルゴリズムを作成し、キャッシュラインに沿ったメモリにアクセスし、命令ウィンドウがタスクで詰め込まれたメモリを維持し、将来の様子を描写している場合に非常に簡単に登場する場合に非常に簡単に簡単にすることができる場合に、命令ウィンドウを維持することでパフォーマンスを向上させることができます。
• Safe PointersはSafePointer.hを使用して、ポインターにどの部分が機能するかを指示することにより、より多くのエラーをキャッチします。リリースバージョンにオーバーヘッドを残さないため、生のポインターをいつでもSafePointerに置き換えて、何か悪いことが起こったときにポインターの名前と詳細情報で有益なエラーメッセージが表示されることを知ることができます。
• 文字列はUTF-32を使用して文字をメモリに保存し、すべてのアルゴリズムが非ラチン文字（U ""文字列リテラルと互換性がある）と動作することを確認します。ファイルへの保存は、BOM（どの形式が使用されているかを明示的に言っている）およびCR LFラインエンディング（どこでもエンコードされたテキストファイルをどこでも読み取ることができる）を使用してUTF-8（コンパクトストレージ）にデフォルトでデフォルトです。共有メモリバッファーを自動的に使用して、小さな割り当てでヒープをあふれさせることなく、文字列のリストに分割します。
• バッファーすべてのファイルは保存され、バッファオブジェクトを介してロードされます。これにより、設計するすべてのファイル形式がバイトのエンコード方法を心配する必要があることを確認し、ファイルシステムからの外部副作用を伴わないことで回帰テストを簡単にすることができ、保存関数に相当するバッファーを使用してファイルを独自にバンドルできます。
• C ++ 17のSTD ::ファイルシステムとほぼ同等のファイル管理は、C ++ 14で動作し、すべてのプラットフォームで同じ文字列とReadablestringタイプを使用し、 /（POSIX）と（MS-Windows）の間でフォルダーセパレータを自動的に修正できます。
• プロセス管理は、他のアプリケーションを開始し、そのステータスを追跡できます。そのため、結果をファイルに書き込む関数などのアプリケーションを呼び出すことができます。

ライセンスの概要

このライブラリは、主にZlibオープンソースライセンスを使用していますが、寛容なデュアルライセンス（MIT / Unlicense）を備えた画像を保存およびロードするためのSTB画像ライブラリも含まれています。 STB画像ライブラリはパブリックドメインとして使用できるため、ZLIBオープンソースライセンスの下でライブラリ全体を使用することに法的影響はありません。すべてのライセンスを備えたすべてのソースコードにより、ソースコードの非公開変更を含む、商業的および非営利的な使用の両方が可能になります。ソースコードを再配布していない場合、不誠実な承認には価値がないため、このライブラリを使用していることを誰かに伝える必要はありません。

まだパブリックベータ版

テーマ、GUI、フォント、およびサウンドAPIは依然としてアクティブな開発中であり、安定したバージョン1.0の準備が整う前に大きな変更がある可能性があります。これは、高度な実装がそれを置き換えるまで、いくつかのコードが原始的なプレースホルダーであり、ユーザビリティの問題が明らかになる前に実際にライブラリを使用しようとする必要があるからです。ただし、バッファ、ファイル、画像、描画、フィルター、文字列、および時間APIは、すでに非常にバージョンで安定しています。新しいプロジェクトごとに特定のバージョンに固執するか、最新の変更を更新し続けるか、安定したバージョン1.0を待つことができます。

どのようにあなたが助けることができるか

• 同じ原則を最小限の依存関係に使用して、MacintoshまたはWaylandへのポート。
• このベータバージョンをテストし、バージョン1.0がリリースされる前にデザインに関するフィードバックを提供します。
• オープンソースツールを使用して、さまざまな種類のゲームエンジンを作成します。

サポートされているCPUハードウェア：

• SSE2内因性とオプションの拡張機能を使用して、 Intel/AMD 。
• ネオン・イントリストニクスを使用した腕。
• フォールバックソリューションとしてのSIMDベクトル化なしの不明なCPUアーキテクチャ。

プラットフォーム：

• Linux 、Mint、Mate、Manjaro、Ubuntu、Raspberrypi OS、Raspbian（バスター以降）でテストしました。 Linux MintにはコンパイラとX11ヘッダーが必要なので、コンパイルする前に「sudo apt install g ++」と「sudo apt install libx11-dev」を実行します。現在、X11とWaylandをサポートしていることは、将来のバージョンで計画されています。
• Microsoft Windowsですが、Windowsにはバックグラウンドプロセスがたくさんあり、スレッドとメモリ管理が遅いため、Linuxよりも遅くなります。

作業するかもしれません：

• BSDとSolarisには、アプリケーションフォルダーを取得するためにfileapi.cppのプラットフォームをターゲットにするコードがありますが、ビルドスクリプトを実行するためのアプリケーションが欠落している可能性があります。将来のPOSIX準拠システムには、X11サーバーがある場合、整理するためのわずかな癖しかありません。
• DSR_BIG_ENDIANマクロをグローバルに有効にする場合、理論的にはビッグエンディアンがサポートされていますが、これは、現代のコンパイラを持つこのような古いシステムをターゲットにするのが難しいために実際にテストされたことはありません。

まだ移植されていません：

• MacintoshはX11を使用しなくなったため、ポーティングの努力が必要になります。 Macintoshには、実行プロセスのバイナリへのシンボリックリンクがないため、アプリケーションフォルダーを要求するときに現在のディレクトリに戻ります。

ターゲットにはなりません：

• 携帯電話。モバイルプラットフォームでの逆方向の互換性を破る絶え間ない変化は、一生に一度のフレームワークを使用する目的を打ち負かすからです。モバイルプラットフォームには、カスタムC ++コンパイラ、信号プロセッサへのアクセス、スクリーンの回転、バッテリーの保存、仮想キーボードの表示、セキュリティ権限の表示、強制フルスクリーンなどが必要です。
• Webフロントエンド。このライブラリのこのようなラッパーは、独自の画像フィルターを定義するためにSimd Intrinsicsの力を得ることができないため、ダイナミックスクリプトに適したブラウザからGPUシェーディング言語をターゲットにする方が良いでしょう。