Can anyone identify this strange behavior? It's not causing any serious problems, but I've never seen it happen before. I use double buffering, and it normally works correctly, but when I tab out of full-screen mode, then tab back in, I can see the first frame being drawn, one 3D mesh object at a time. My resources load on demand - the first time they're used, otherwise I probably wouldn't even notice this. Does anyone know the circumstances that would make this possible? I manage my own resources, so when the device is lost, I completely free it and create it again. And I've checked to see that this is definitely happening when I tab out. Is it possible for the back buffers or swap chain to be linked to the wrong buffer when the device is first created? In other words, the reason I can see things being drawn is because I'm rendering to the front buffer instead of the back? Are there any device states that I should be initializing when I create the device that would explain this? It doesn't happen when my app starts up the first time. Only when I tab out then in. Thanks for any help.

It sounds like "Present" is being called between each time a new resource is loaded, or possibly a typo is causing you to present the scene early each time a resource is missing.

Try watching to see if you're actually going through multiple entire rendering passes, or if it really IS showing you a slowed-down render of a single frame. Put a breakpoint anywhere you do a 'Present' (or any other version of the backbuffer swap).

I only have one monitor, so I can't use breakpoints without causing Visual Studio to lock up on me. However, I've used my debug logging system to verify that Present is not being called in between the object renders or loading. It's happening in one frame.

I also placed a "Sleep(10)" below all draw primitive functions so I could more easily observe what's happening. I can still only visually observe the very first frame I render after I initialize the device.

However, I was wrong that it only happens when I tab out and in. It also happens when I first start it up. As soon as I initialize the device, I have this code to draw an initial blank screen (to avoid v-mem garbage):

Device->BeginScene();Device->Clear( 0, null, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, GREY_COLOR, 1.0f, 0 );Device->EndScene();Device->Present(null,null,null,null);

When I remove this code, the problem stops. Is there anything wrong with rendering this type of scene right after setting up the device? Something that might fool the device into not swapping back buffers?

After more exploring, I believe this will happen anytime I present a scene without rendering 3D geometry. Afterward, the first scene I render something in 3D space, I can see the frame being drawn, object by object.

EDIT: While the above is true, the visual effect only happens one time after I create the device.

This is most likely something that I am doing wrong that causes the API to malfunction, but I could use some help narrowing it down. Has anyone seen this behavior before?

[Edited by - Kest on January 11, 2009 9:07:57 PM]

I've never seen that problem before, but it does sound very strange. Can you try the reference rasterizer instead, and see if it does the same?

Also, when you say "As soon as I initialize the device, I have this code to draw an initial blank screen (to avoid v-mem garbage):", do you actually get garbage if you don't present a blank frame? That sounds wrong to me, and may be a driver bug or some other problem.

Quote:Original post by Evil Steve
I've never seen that problem before, but it does sound very strange. Can you try the reference rasterizer instead, and see if it does the same?

It doesn't happen. It doesn't even happen when I use the debug D3D runtime. It only seems to cause the problem in release mode. Maybe it's a problem with my video card driver. ..or maybe ref/debug mode is accidentally curing the glitch.

Quote:Also, when you say "As soon as I initialize the device, I have this code to draw an initial blank screen (to avoid v-mem garbage):", do you actually get garbage if you don't present a blank frame? That sounds wrong to me, and may be a driver bug or some other problem.

When I use the debug D3D runtime, I get a flash of very bright green on the first frame, and assumed that was a warning to show that an uninitialized display was visible.

I've also seen it in some commercial games - when the full screen mode first pops up, there's sometimes a single frame of random bright diagonally-aligned pixels that flash on the screen. The longer it takes the game to load the first display, the longer that is shown. I can't seem to get my engine to display anything but black on the first frame in release mode, but I assume there must be something on the display buffer before I mess with it, and assume one of those buffers must be visible if the display is set up. Do you know whether or not D3D clears the front and back buffers on allocation?

Quote:Original post by Kest

Quote:Original post by Evil Steve
I've never seen that problem before, but it does sound very strange. Can you try the reference rasterizer instead, and see if it does the same?

It doesn't happen. It doesn't even happen when I use the debug D3D runtime. It only seems to cause the problem in release mode. Maybe it's a problem with my video card driver. ..or maybe ref/debug mode is accidentally curing the glitch.

If anything happens on the HAL device but not on REF, you can be pretty sure it's a driver glitch. The fact that the debug runtime causes it not to happen makes me 99% certain it's a driver bug.

Quote:Original post by Kest

Quote:Also, when you say "As soon as I initialize the device, I have this code to draw an initial blank screen (to avoid v-mem garbage):", do you actually get garbage if you don't present a blank frame? That sounds wrong to me, and may be a driver bug or some other problem.

When I use the debug D3D runtime, I get a flash of very bright green on the first frame, and assumed that was a warning to show that an uninitialized display was visible.

I've also seen it in some commercial games - when the full screen mode first pops up, there's sometimes a single frame of random bright diagonal pixels that flash on the screen. The longer it takes the game to load the first display, the longer that is shown. I can't seem to get my engine to display anything but black on the first frame in release mode, but I assume there must be something on the display buffer before I mess with it, and assume one of those buffers must be visible if the display is set up. Do you know whether or not D3D clears the front and back buffers on allocation?

If you use D3DSWAPEFFECT_DISCARD, you're telling D3D / the driver that you're always clearing the backbuffer before presenting the scene, so it doesn't have to worry about keeping the previous contents of the screen handy. In release mode, that means that you'll frequently see the previous frame's contents if you don't Clear(), since usually flipping is used. The debug runtime enforces this policy by clearing the backbuffer to green and magenta on alternate frames to remind you to clear the backbuffer.
When you come back from an alt+tab, the video memory is probably full of gibberish, hence the green flash and diagonal pixels.

I'd make absolutely sure that you're not calling Present() without rendering at any point in your app (I gather that Pix can give you a call list, so you can check that way). If you're always clearing the backbuffer before presenting, give it a go with the reference device - if it doesn't show the green flash, then I suspect it's another driver bug.

What graphics card do you have, out of interest? I know Intel integrated chips tend to have particularly terrible drivers.

So if I set up the D3D device, back buffers, and a full screen display, but don't touch or render anything, what's visible on the screen? Is it the front buffer? Or is it my window/desktop (tested for this by using a white window background, and it doesn't seem to be)? If it's the front buffer, and D3D doesn't clear it, there would definitely be visible garbage until a first scene is rendered.

My card is just a generic GeForce 7300 LE. The driver is pretty stable and reliable, but it looks like there might be tiny holes here and there where it doesn't matter.

Quote:Original post by Kest
So if I set up the D3D device, back buffers, and a full screen display, but don't touch or render anything, what's visible on the screen? Is it the front buffer? Or is it my window/desktop (tested for this by using a white window background, and it doesn't seem to be)? If it's the front buffer, and D3D doesn't clear it, there would definitely be visible garbage until a first scene is rendered.

It'll be the front buffer, yes. I would expect the driver to clear it to black on device reset, since otherwise you'd always get the behaviour you describe, which is obviously not very nice.

Do you have the latest drivers for your card? It's probably worth checking that first and then seeing if there's any change in behaviour.

Quote:Original post by Evil Steve

Quote:Original post by Kest
So if I set up the D3D device, back buffers, and a full screen display, but don't touch or render anything, what's visible on the screen? Is it the front buffer? Or is it my window/desktop (tested for this by using a white window background, and it doesn't seem to be)? If it's the front buffer, and D3D doesn't clear it, there would definitely be visible garbage until a first scene is rendered.

It'll be the front buffer, yes. I would expect the driver to clear it to black on device reset, since otherwise you'd always get the behaviour you describe, which is obviously not very nice.

Do you have the latest drivers for your card? It's probably worth checking that first and then seeing if there's any change in behaviour.

Yeah, I have the latest drivers. But the "visual artifacts on start up" is something I've been noticing for a long time, while starting up several games, with different cards/OS/PC. I'm surprised you haven't seen it before.

If it wasn't for the initial green display while using the debug runtime, I would just assume those games did something quirky to cause the effect. Whatever the case, it's not a big deal. But it's probably not a bad idea to render something ASAP on startup anyway, to show that the game engine is loading initial files.