コンテンツ パイプラインを使用して を使用してテキストをレンダリングする代わりにGraphics.DrawString
、(かなり静的な) テキストの束をオフスクリーン ビットマップにレンダリングし、それを 1Texture2D
回に変換してから単に を呼び出すことに欠点はありますか? これは基本的に「1 枚の紙」に描かれたテキストのページですが、ユーザーはフォントのサイズを変更することもできるため、さまざまなサイズのスプライトフォントを含める必要があります。SpriteBatch.Draw
SpriteFont
これは Windows 専用のアプリなので (移植する予定はありません)、単純な古い WinForms アプリのようにすべてのフォントにアクセスできます。また、スプライト フォントを使用するよりGraphics.DrawString
も (または を使用した場合でも) レンダリングの品質がはるかに優れていると思います。TextRenderer
また、各反復でテキスト全体を「レンダリング」する必要があるため(つまり、各文字の頂点を個別に送信する)、パフォーマンスが向上する可能性がありますがSpriteBatch.DrawString
、ビットマップを使用することで一度だけ実行するため、 CPU側。
- ここに表示されていない問題や欠点はありますか?
- スプライトフォントを使用してアルファ ブレンド テキストを取得することは可能ですか? Nuclex フレームワークが言及されているのを見たことがありますが、Monogame AFAIK には移植されていません。
[アップデート]
技術的な面では、スプライト フォントよりもはるかに優れたテキスト レンダリングで、完全に機能しているようです。それらが水平にレンダリングされる場合、ClearType も取得します。存在する可能性のある問題の 1 つは、フォントのスプライトシートは、テキストのページ用に別のテクスチャを作成するよりも、テクスチャ メモリの点で効率的である (そうかもしれません?) ことです。