Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In Andrew's comment on my other question, he noted that it was possible to render text to a Texture2D using the Windows API, instead of drawing the text directly with a SpriteBatch. How is this done? I'm guessing there's an intermediate step before writing the image data to a Texture2D.

I'm asking because this would allow me to render Unicode characters on-the-fly, instead of needing to pre-render all the needed glyphs using a SpriteFont (too many glyphs in Korean and Japanese to make this route infeasible, sadly). Thanks!

share|improve this question
Any chance of you accepting an answer? – Mike Strobel Oct 4 '10 at 18:40
up vote 4 down vote accepted

Using some reflection, you can grab the Direct3D surface pointer from a Texture2D. From there, you can use any APIs that can render to a DX surface. I did this recently to host XNA content with WPF's D3DImage (with alpha channel support). DirectWrite can render to a DX surface, and you might even be able to use managed APIs. The DirectX .NET wrappers in that link only support Direct3D 10 and 11, and not Direct3D 9 (which XNA uses AFAIK). However, you still might be able to get it to work. On a side note, if you want to render vector graphics, you may be able to use a similar approach to interoperate with Direct2D. Naturally, none of this will work on any XNA-supported platform other than Windows.

share|improve this answer
I just want to point out that you can also get the window handle for xna and tell it to render to something like a win32 panel instead. Then you can use any method you want to render on top of the game since you are simply drawing the backbuffer to a win32 control. This is very dirty but it worked well for me when I merged the Tablet PC input panel with XNA. The result was what appeared to be a standard XNA window but with invisible handwriting recognition. I simply displayed strokes on top of xna. Of course text/labels/buttons will work too. However, I have not tried this with WPF. – zfedoran Oct 1 '10 at 0:58
I would think there would be "airspace" issues with your method, Arriu. Were you able to render content on top of an XNA window with the alpha channel intact? The general rule is that a pixel can only be "owned" by one graphics API, which causes problems with transparent or translucent content. If this holds true for your method as well, then it would be problematic for rendering text atop anything other than a solid color background. – Mike Strobel Oct 1 '10 at 18:14
Sorry, I may have been a little confusing. The method I described does nothing more than tell the panel to draw a texture on its background. Similar to how you can tell an imagebox what image to draw. But instead of the texture/image being a file it is the xna backbuffer. I was not drawing ontop of or over the panel/window. So there were no issues with "airspace". – zfedoran Oct 18 '10 at 17:04
Ah, I see. So your approach is very similar to how I've hosted XNA content in WPF (using D3DImage). Instead of a typical bitmap source, the image source is an XNA/Direct3D surface. I agree that this is the best approach given the options available--there are no airspace issues, and the performance is pretty good because no unnecessary copying/blitting is required. – Mike Strobel Oct 18 '10 at 17:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.