Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Rendering to Texture Surfaces Using DirectX 7
arrowPress Releases
April 19, 2021
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Rendering to Texture Surfaces Using DirectX 7

November 12, 1999 Article Start Page 1 of 4 Next

Developing for the current generation PC platform rewards software developers working in 3D with both blessings and curses. On the positive side, PCs are delivering rocket-fueled levels of performance, allowing developers to accomplish amazing feats on inexpensive consumer machines. The downside is that developers have to code their applications to scale across hardware with an increasingly wide range of performance differences and to accommodate significantly different hardware feature sets.

The Microsoft DirectX7 API offers the opportunity for programmers to tap into some fairly remarkable graphics capabilities, including the ability to render primitives to texture surfaces. This article explores some of these possibilities and explains the techniques that can be used to take full advantage of this capability. To do this successfully in a real application, you need to exploit the latest advances in graphics chips for effects processing, while gracefully handling systems that lack these advanced features, by either scaling down the effect, or performing the effect at a slower speed.

Detecting support for hardware that can render to texture surfaces is necessary if you want to know when to work around hardware that isn't capable of rendering to textures. To this end, this article introduces an approach to detecting support for rendering to texture surfaces and how to achieve similar functionality on hardware that doesn't directly support it. I will also be presenting a number of examples of special effects that can be achieved using this capability.

Rendering to Texture Surfaces

Rendering to texture surfaces with today's 3D hardware provides the opportunity for some dazzling effects, including reflection/refraction, rendering soft-edged shadows, mip map generation, motion blur, and TV-style transitions, and much more.

There are several ways to render to textures on current generation 3D hardware. Applications aiming to exploit this capability will need to detect which method can be used on the end user's system, and provide codepaths to handle the different methods. (Not all paths need be handled. An application could choose to only support methods A and D, as I have done in my example. The executable and source for this can be found in TESTRTT.ZIP)

The different methods can be summed up as in Table One:

Method A
Use the HW to render to a vidmem surface that is both a render target and texture surface.
Fastest method, least memory used
Only supported by some HW
Method B
Render to a surface that is a render target, but not a texture. Then blit the surface to a texture surface of the same size and format.
Can be fast, no sysmem copy,
Not supported by all HW, uses extra texture memory
Method C
Render to the back buffer, and blit a subsection of the backbuffer to a texture surface
Can be fast, no sysmem copy
Not supported by all HW, can break concurrency
Method D
Render to the back buffer, and blit a subsection of the backbuffer to a system memory surface, and then blit the system memory surface to a video memory surface
Works on nearly all HW
Slow method
Method E
Render to a surface in system memory using software, and then blit that to a texture that the graphics hardware can use. This is the least desirable method for obvious reasons
Works on all HW
Slowest method, limits app to using low res texture
Table 1. Fallback methods for rendering to texture surfaces

The first method offers the fastest and most efficient approach, but it is not supported by all hardware. The last of the methods listed will work on all systems, but places the rendering burden on the CPU, creating processor overhead when we would prefer to have the graphics hardware do the work. Additionally, Methods B and D require extra video memory to be allocated.

Under DirectX6, some graphics hardware could render to texture surfaces, but application developers were unable to take advantage of this feature. Because of the way the surface creation flags were implemented and interpreted by certain hardware vendors and by some application developers, a Catch 22 was created. Driver writers implemented the flags incorrectly, but fixing them would have risked breaking currently functional applications already out in the market.

The solution was to make a fresh start with DirectX7, and this time, interpret the flags correctly when used with the new interfaces. Consequently, in order to make use of this capability, and to detect its presence, applications must be using the DirectX7 interfaces (IDirectDraw7, IDirect3Ddevice7, etc).

When using the new interfaces, applications can test for the render-to-texture capability in two steps. The first way is by creating a DirectDraw surface that is flagged as being both a render target surface and a texture surface. The second way is by attempting to set this surface as the render target for the Direct3Ddevice. If either of these steps fail, the application must fall back to one of the alternate solutions discussed in table one.

At the time of this article's authoring, there were still issues when attempting to render to texture surfaces with legacy DirectX6 display drivers running on the DX7 runtime DLLs. If an application wants to render to texture surfaces and will ship while a significant number of DX6 display drivers are in end users systems, the application will have to resort to cruder methods of checking for the capability or lack thereof. Examples of such crude methods could include rendering to a texture and then locking it and comparing pixels to the expected result, or worst case, checking device names. In my TestRTT sample, I created a black texture, set it as the render target, cleared it to white, and then rendered some primitives to it. If after doing so it contains only black pixels, I know the render-to-texture attempt has failed, and resort to an alternative method. I do this test at start up, and when the rendering device is changed.

The next few sections explain how each of these methods is implemented. Once the methods have been explained, this article presents a method for detecting which method is supported.

Article Start Page 1 of 4 Next

Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Experienced Game Developer
Sony PlayStation
Sony PlayStation — San Francisco, California, United States

Sr. Product Manager, Player Engagement & Social Experiences
Playco — APAC, Remote, Remote

Senior Product Manager
Playco — Japan, Remote, Remote

Senior Product Manager - Games | ?????????????? - ??????? (Bilingual)

Loading Comments

loader image