I need to take High Definition Screen shots in my directx(C#) application. and i found out the solution in Game Programming gems2 book, and i implemented it in my application and it is working fine, but the problem is they gave the algorithm for Perspective view , now i need to take same HD screen shots in Orthogonal View...

The idea behind tis is we are splitting the screen into 9 quadrants and set the projection matrix then take screen shots and we get 9 pictures then we are stitching it to one picture, and the below alogorithm values works well for perspective view but it doesnt work for orthogonal view, i need to know the left,right,top,botom values for orthogonal view..!!

You could try rendering to texture - any modern card will support 16384x16384 for stupidly high quality output in a single pass. Note that a 16384x16384 RGBA texture requires 1GB of video memory.

Yes you are probably correct, modern cards will support very large render textures.

However I have to use this same technique myself on some platforms.

The OP should have an equivalent to glOrtho in his code base, from his post I'll take a guess at GpgOrtho.

Use that instead of the perspective matrix and he should be okay

You could try rendering to texture - any modern card will support 16384x16384 for stupidly high quality output in a single pass. Note that a 16384x16384 RGBA texture requires 1GB of video memory.

This can, by the way, even be done even with considerably smaller render targets, and at virtually any resolution (not limited to anything in particular, except the space on your harddisk) if you don't mind doing the final composition by hand.

Instead of one @163842 render, you can do 16 @40962 renders of the same scene, with a sub-pixel jitter (i.e. you are effectively supersampling the scene). Or you could do 256 renders @40962 which gives you the information necessary to create a 655362 image. Of course that would be a 16 GiB image, so doing the final composition is a bit of a challenge, you'd either have to do it in smaller tiles, or on the CPU (maybe even out of core, if your machine doesn't have that much RAM).

Doing several identically-sized shots and compositing them may have benefits in terms of mipmaps and differentials, too. If you render something at a different resolution, you won't be using the same mipmap levels, and your procedural content that uses dFdx() or the like will not be the same either.

Lastly, the supersampling technique allows you to cheat on your posters. You can for example trivially add a high quality motion blur (simply render a very, very slowly animated scene instead of a single static one, and crank up the numbers of screens by another few dozen).