Render to texture & fullscreen bug in Irrlicht 1.4

[agt]

Hi,

RTT seems to cause problems at fullscreen-mode using Direct3D9 when you swith windows. Application cannot "re-open" window after that.

The bug can be re-produced easily, eg. by using fullscreen-mode at Irrlicht's RenderToTexture -example.

Change:

Code: Select all

	IrrlichtDevice *device =
		createDevice(driverType, core::dimension2d<s32>(640, 480),
		16, true, false);

1. run the example (in full-screen mode)
2. press alt+tab
3. Return to the application -> doesn't work.

Here's error log:
Irrlicht Engine version 1.4
Microsoft Windows XP Personal Service Pack 2 (Build 2600)
Using renderer: Direct3D 9.0
RADEON X600/X550 Series ati2dvag.dll 6.14.10.6641
Loaded mesh: ../../media/faerie.md2
Loaded texture: ../../media/faerie2.bmp
DIRECT3D9 device lost.
Resizing window (640 480)
Resetting D3D9 device.
Resetting failed.
Resetting D3D9 device.
Resetting failed.
Could not get previous render target.
Resetting D3D9 device.
Resetting failed.
Could not get previous render target.
Resetting D3D9 device.
Resetting failed.
...

The same bug was also present in Irrlicht v1.3. Tested on Windows XP and Vista.

[hybrid]

Yes, this showed up quite some time ago already. But a proper reset is pretty complex, and the solutions presented last time had some other problems IIRC. Try to restrict resolution changes to some initial dialog for now.

[agt]

I managed to create an application level work-around. I hope that someone implements more robust solution to the engine, because IMO this is quite critical bug.

Based on MSDN documentation:
Responding to a Lost Device - "Reset will fail unless the application releases all resources that are allocated in D3DPOOL_DEFAULT, including those created by the IDirect3DDevice9::CreateRenderTarget."
http://msdn2.microsoft.com/en-us/librar ... S.85).aspx

Call to driver->createRenderTargetTexture causes the problem, because rendertarget is not destroyed before calling d3ddevice->reset.

Work-around for the RTT example. Replace beginScene row with the following code:

Code: Select all

	if(!driver->beginScene(true, true, 0)) {
			// reset failed, propably because render target wasn't destroyed.
			if(rt) {
				// remove rendertarget.
				rt->drop();
				driver->removeTexture(rt);
				rt = 0;
				test->setMaterialTexture(0, 0);
				
				// this should call d3ddevice->reset.. now it should work because rendertarget was destroyed.
				driver->beginScene(true, true, 0);

				// and let's create rendertarget again.
				rt = driver->createRenderTargetTexture(core::dimension2d<s32>(256,256));
				test->setMaterialTexture(0, rt);
			}
		}

ps. seems that Ogre people have had a similar problem also: http://www.ogre3d.org/phpBB2/viewtopic.php?t=11890

[merovingian]

Sorry to bump such an old thread.

Due to Irrlicht wrongly flipping RTTs when used with OpenGL, I've been experimenting with Direct3D9. It solves the flipping, but now I see this reset failure anytime I try to resize my window. My error messages are as follows:

Resizing window (1313 800)
Resetting D3D9.
Resetting failed.
DIRECT3D9 clear failed.
DIRECT3D9 being scene failed.
Could not get previous render target.
Could not get previous render target.
DIRECT3D9 end scene failed.
DIRECT3D9 clear failed.
DIRECT3D9 being scene failed.
Could not get previous render target.
Could not get previous render target.
DIRECT3D9 end scene failed.
...

So I have two RTTs. Unlike the OP (agt), I do not get the "Resetting" messages everytime I call beginScene(), but only the first time beingScene() is called after the resizing. Consequently, agt's proposed workaround does not work for me (because there is no second reset attempt). I don't understand why this is so. I am using Irrlicht 1.4 (the pre-compiled Mingw32/gcc DLL that includes the DIRECT3D9 driver).

Resizing is not critical for me at this moment, so I can live with the problem for a while. But I thought my observations might help with the bug resolution.

[BlindSide]

Due to Irrlicht wrongly flipping RTTs when used with OpenGL, I've been experimenting with Direct3D9.

You can just "unflip" them using a TextureMatrix (Or by inverting the Y coord if you are using a shader material.).

[hybrid]

Doesn't work for draw2dimage, though... We need some solution for those methods, too.

[BlindSide]

Doesn't work for draw2dimage, though... We need some solution for those methods, too.

Should be pretty trivial to do something similar to this and modify the texcoords of the quad in draw2DImage by testing the texture passed in using isRTT() (Or whatever the equivalent method name for that was.).

[Nadro]

Yes, I think than modify texcoords for quad is very good idea and very easy in implementation.

[scotchfaster]

I think this thread took a tangent...

However, the above fix didn't work in my application. I tried a number of different approaches, and none of them worked. Actually, the exact scenario in my case was that beginScene() would fail (and the call to reset() would also fail) after my computer hibernated and woke up.

What I ended up just doing was to exit if beginScene() failed and have the app restart. In this particular case this solution made perfect sense, but it's a pretty unusual stateless application.

While I'm okay with the solution I'm using, I thought I'd give this a bump, 'cause it's butt ugly.

[pera]

I have this problem with render to texture and resize window, (Irr 1.4, D3D9) and I tried workaround, but beginScene is not inducing device reset.

Can I somehow call device to reset?