2Dゲームの大きなビデオメモリ要件をどのように解決しますか？
2Dゲームの大きなビデオメモリ要件をどのように解決しますか？ Allegro C / C ++で2Dゲーム（Factorio）を開発していますが、ゲームコンテンツの増加に伴い、ビデオメモリ要件が増加するという問題に直面しています。 現在、最初に使用される画像に関するすべての情報を収集し、これらの画像を可能な限りすべてトリミングして、可能な限り緊密に大きなアトラスに整理します。これらのアトラスはビデオメモリに保存され、そのサイズはシステムの制限に依存します。現在、通常は最大8192x8192の2つの画像であるため、256Mb〜512Mbのビデオメモリが必要です。 このシステムは、カスタム最適化とレンダリングスレッドと更新スレッドの分割により、60 fpsで何万枚もの画像を画面に描画できるため、非常に有効です。画面には多くのオブジェクトがあり、大きなズームアウトを許可することが重要な要件です。さらに追加したいので、ビデオメモリの要件に問題が発生するため、このシステムは保持できません。 私たちが試したかったことの1つは、最も一般的な画像を含む1つのアトラスと、キャッシュとしての2つ目のアトラスを持つことです。画像は、必要に応じてメモリビットマップからそこに移動されます。このアプローチには2つの問題があります。 allegroでは、メモリビットマップからビデオビットマップへの描画が非常に遅くなります。 allegroのメインスレッド以外でビデオビットマップを操作することはできないため、実際には使用できません。 追加の要件は次のとおりです。 ゲームは決定論的である必要があるため、パフォーマンスの問題や読み込み時間によってゲームの状態が変わることはありません。 ゲームはリアルタイムであり、すぐにマルチプレイヤーにもなります。どんなコストでも最小のスタッターでさえ避ける必要があります。 ゲームのほとんどは、1つの連続したオープンワールドです。 このテストは、1x1から300x300までのサイズのバッチで、構成ごとに数回、10,000個のスプライトを描画することで構成されていました。Nvidia Geforce GTX 760でテストを行いました。 ソースビットマップが個々のビットマップ（アトラスバリアント）間で変更されていない場合、ビデオビットマップからビデオビットマップへの描画はスプライトごとに0.1usかかりました。サイズは関係ありませんでした ビデオビットマップからビデオビットマップへの描画、ソースビットマップの描画間での切り替え（非アトラスバリアント）は、スプライトごとに0.56usかかりました。サイズも関係ありませんでした。 メモリビットマップからビデオビットマップの描画は本当に疑わしいものでした。1x1から200x200のサイズはビットマップあたり0.3usかかったので、それほどひどく遅くはありません。サイズが大きくなると、201x201の9usから291x291の3116usへと、劇的に時間の増加が始まりました。 アトラスを使用すると、パフォーマンスが5倍に向上します。レンダリングに10ミリ秒かかっていた場合、アトラスを使用すると、フレームあたり100,000スプライトに制限され、それなしでは、20000スプライトの制限があります。これには問題があります。 また、シャドウのビットマップ圧縮と1bppビットマップ形式をテストする方法を探していましたが、Allegroでこれを行う方法を見つけることができませんでした。