XNA BMFont Renderer, Logo and Some Screens
October 24th, 2006 by proj
I’ll start this post with some XNA dev screenshots:
When I was very young I did some coding in logo on an apple II. It has a very simple syntax and was fun to experiment with, a little turtle moved around the screen as you entered your program. As I was thinking about how to make procedural content for an action game I remembered those old times so I implemented a graphical editor for a simplified logo language interpreter. You use a 360 controller to alter the opcodes and operands and the scene updates in real-time.
I dropped the ziggyware font stuff from my project and went back to using BMFont from angelcode. The ziggyware stuff was pretty good but it lacked the precision I wanted and when I noticed that the XNA sprite batch stuff doesn’t batch the prim submission I was going to have to rewrite that anyways. It took me a little while to write the variable width rendering logic, kerning and line wrapping but now I have more control over the font layout and display. The textures generated from BMFont are very effeciently packed.
Watch out for the SpriteBatch it does not currently do any batching. Every call to draw a quad is a seperate batch. Check it out in PIX. It does however collect all the state changes into a state block but I’m not impressed. It’s really not hard to manage your own collection of quads in a buffer and generate them off the font information. I might share the BMFont renderer at some point. I’m still working on a level editor right now.
Related posts:
SpriteBatch isn’t batching? WOw that must be a bug in the beta or something as its certainly supposed to and I’ve not see the sort of perf issues I would expect if it wasn’t. Unless you need something very special its not worth writing your own 2d sprite stuff IMO.
You can run a simple frame capture experiment in PIX to see what I’m referring to. Every SpriteBatch.Draw() call that is enclosed in the begin and end will translate to an individual DrawUserPrimitive.
2D sprite stuff in DirectX is a lot easier to write than a whole slew of other 3D code. There are some nice upsides to writing your own.
When you send the sprite prims through your own shader you can use a texture atlus and of course do the submission batching yourself pretty easily.
Also there are some fun tricks you can do in image space when you send the sprite quads through your own shader code
I didn’t mean to say you were incorrect, just that its most defintly a bug if thats what you are seeing and should be reported to MS since most people won’t want to do any special stuff. Yes I’m sure you can have fun shader wise if you write your won.
I was just sorta thinking out loud. Ideally I shouldn’t right my own if the built-in stuff is good enough which it probably is for my purposes. Maybe I’m just trying to justify the time I spent on it. I’ll let the XNA team know but they might not be too interested in fixing this issue right now, I haven’t stress tested it but I bet you can use the sprite batch as-is to render thousands of sprites on marginal hardware. And that would be the ‘very special’ something you were referring to in your oringinal comment.
Well, there is still value to re-inventing the wheel even if at worst it’s worse than the wheel that exists.
That value is a more intimate knowledge of how the wheel works so you can better utilize it to it’s full potential, or make a new kind of wheel which does something nobody else has thought of yet.