1

Closed

Switch to force power of 2 textures in MakeSpriteFont?

description

Feature Level 9 allows you to use non power of 2 textures if you aren't mipmapping (not an issue with SpriteFont) and aren't using any wrap sampler modes. SpriteBatch defaults to not using wrap, but someone could set it to do so.

It makes sense to have sprite fonts default to the smallest size possible, but some people could conceivably be using SpriteBatch with linear wrap and if so then they'd either need a power of 2 sprite font texture or else they'd need to "end - begin - draw text - end - begin" in order to draw some text.

Seeing as MakeSpriteFont is already wired up internally to be able to generate power of 2 textures, it would be a nice feature addition to make it a command line switch. It's nothing critical though as it's easy enough to fiddle with it and force it to generate power of 2 textures if you really need them.

(For anyone wondering, you can edit the ArrangeGlyphs method of GlyphPacker and change the false in 'outputHeight = MakeValidTextureSize(outputHeight, false);' to true (the GuessOutputWidth method is already currently setup to create a power of 2 width so you don't need to worry about that; you can add a suitable Console.WriteLine into ArrangeGlyphs right before the return statement if you want to see what width and height you ended up with).
Closed Feb 5 at 11:17 PM by ShawnHargreaves
Closing due to lack of a plausible use case for drawing text with wrap addressing mode.

comments

ShawnHargreaves wrote Dec 13, 2012 at 7:22 PM

I'm struggling to see the value of this feature. You can't mipmap a sprite font texture (because different characters would blur together, producing totally wrong rendering results) and I also can't think of any useful reason to wrap the texture (in fact the SpriteBatch text rendering API will never generate texcoords where address modes make any difference at all). What else is there where a pow2 texture would be worth having? I don't get why you'd want to waste the extra memory...

BobTacoInd wrote Dec 15, 2012 at 4:25 PM

The only use case for it would be if you were using FL 9.1, 9.2, or 9.2 and you were in a draw block where you were using, e.g., linear wrap for drawing sprites and wanted to draw text without needing to do call End, then Begin with linear clamp, draw the text, then End again, then go back to linear wrap.

I bumped into this with the BasicHLSL11 code; for drawing controls, classic DXUT was drawing the non-text parts with linear wrap so when I switched it to SpriteBatch, it complained when drawing a button because the text texture wasn't pow2. I looked at it more and ultimately decided that there was no reason for it to be using linear wrap for the non-text parts of any of the controls so I just used the SpriteBatch default of linear clamp, thus also solving the problem.

Anyway, the question for whether it'd be worth having is really (to me) one of whether or not someone would ever have cause to use SpriteBatch with a wrap mode for drawing textures while also wanting to draw a SpriteFont in the same batch. The answer is, I don't know since I don't know if there'd ever be a use for a wrap mode with SpriteBatch even for drawing textures (absent a custom shader, which you likely wouldn't want to try to draw text with anyway unless you were going for some weird effect, in which case you should probably be able to figure out how to get a pow2 text texture anyway).

Just because I can't think of a reason doesn't mean one doesn't exist. But if you can't think of one either then I'd be pretty sure that (excluding bizarre edge-case usages) there's no need for it.

Sign in to add a comment