I would recommend not doing it the way described above (no offense). The reason is that using the GDI to draw is very slow compared to other methods. And although it''s just for debugging, there''s no point in looking at artificially low rates. I believe the above method was indeed the quickest and dirtiest in DX7, but:

A texture based font is already implemented in DX8 - look at CD3DFont. If for some reason it doesn''t suit you, look at the source code for CD3DFont and reproduce it to fit your needs. Basically, it uses GDI (once) to draw a font to a texture and then uses that texture to do some fast rendering. Should be much faster than GDI.

Here''s a line of my code:
m_pPerformanceFont->DrawText(2, 0, D3DCOLOR_ARGB(255,255,255,255), m_strFPS);

Your could dump the FPS to a file (or your debug output file), or use D3DXSprite and a bitmap containing digits 0 to 9.
My D3DXSprite wrapper and app has the stuff to do this, download it at:

  Game Download  ZeroOne Realm

Yup, I agree with CrazedGenius here - NEVER use GDI calls (or any code which does - some of the D3DX calls do) to display your framerate or anything else where you want good performance.

The problem is that when you GetDC for a surface, internally it calls Lock() - which flushes all pending rendering on the chip and also spins the CPU waiting for the chip to finish the flush.

After that it writes to the locked memory using the CPU - the locked memory is video memory so you''re going to be limited by the AGP bus speed, and to an extent by the cache. (Although VRAM does get the benefit of WC burst writes IIRC).

Even worse, often video cards store pixels in memory in a different order than you think (known as "swizzling" - re-ordering pixels to allow faster hardware access to memory) - when you lock the surface (or GetDC does) the data must be converted from the internal device format into one you can use (ie. into traditional RGB data). It must also be re-swizzled when Unlock()ed.

Worse still, the GDI text drawing routines are setup for scaling outline fonts, doing colour masking operations on them, handling output to other forms of DC (such as a printer), antialiasing etc - which isn''t good if you want to display a bitmap font fast

As you can guess all of this can kill performance - I''ve seen cases where a simple GetDC/TextOut/ReleaseDC took approximately 20fps off an app which was really running at 60fps (ie. the onscreen framerate counter said 40fps, I removed the GDI calls and used IPEAK to get the true frame rate and got 60fps!).

Best way by far is to do it yourself - draw a small font to a single texture (say 256x256) either offline or when the application starts up. Then when you need to draw the text draw a list of indexed screenspace quads (D3DTLVERTEX), one for each character you want to display - this will work very nicely with hardware acceleration, and give you the flexibility to use coloured fonts etc.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

To Freshya - Yes, for DX7, your method is perfect as a "quick and Dirty" way. My only explanation for your performance is that perhaps (???) you are doing things in such a way that your incremental cost of rendering the GDI stuff is negligible - if you are locking for the text drawing, then your shape drawing might not cost much more (???) For you D3D issues, try using MadOnion''s benchmark for High Polygon scenes. Their numbers are very close to what I get in my code. You can use them to see if you are doing something suboptimally. 4000 triangles per frame at 100 fps = 400000 tri/s, which seems really low depending on your hardware.

To zennehoy: Before writing files, look at the C3DFont class. It''s in the SDK, and basically takes 3-4 lines of code to use:

When you initialize:
//Create the font

Per Frame:
//figure out your frame rate
//display the rate - very similar to TextOut!

Cleaning up:
//destroy the font

Super easy!