Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Lost Device issues

1 view
Skip to first unread message

jbacigal

unread,
Feb 3, 2005, 8:47:04 AM2/3/05
to
I'm using an ID3DXMesh and when I create it I use the flag D3DXMESH_MANAGED
so my vertex/index buffers should not need to be destroyed and recreated
every time my device is lost. This, however, seems not to be the case, as I
still need to recreate them everytime I lose my device (alt-tab or
alternating between windowed and fullscreen mode). From what I have read on
MSDN I should not need to reload all my resources every time, it says only
memory in the D3DPOOL_DEFAULT is cleared during a lost device. Can anyone
think of a solution for keeping a mesh through a lost device? In my case, the
mesh is very large, and I simply can't afford to reload it everytime the user
alt-tabs... Thanks in advance for any suggestions.

-Joe

Phil Taylor

unread,
Feb 3, 2005, 12:48:59 PM2/3/05
to
dont some samples use managed meshes?

why can they persist thru a lost device and you cant?

does the debug runtime output tell you anything?

"jbacigal" <jbac...@discussions.microsoft.com> wrote in message
news:324C16C8-AF76-4355...@microsoft.com...

Rioshin an'Harthen

unread,
Feb 3, 2005, 3:18:25 PM2/3/05
to
We've been having this same problem with ID3DXMESH and the managed pool with
lost devices. Running with full debug information just says that the
vertex/index buffers must be released prior to resetting the device.

Since we've made sure to use managed pools with all our objects, it seems to
us to be a bug in the D3DX library...

"Phil Taylor" <ph...@private-citizen.com> wrote in message
news:evHtiihC...@TK2MSFTNGP09.phx.gbl...

Eyal Teler

unread,
Feb 3, 2005, 4:22:29 PM2/3/05
to
Rioshin an'Harthen wrote:
> We've been having this same problem with ID3DXMESH and the managed pool with
> lost devices. Running with full debug information just says that the
> vertex/index buffers must be released prior to resetting the device.
>
> Since we've made sure to use managed pools with all our objects, it seems to
> us to be a bug in the D3DX library...

Are you sure it's the meshes? Try writing the simplest program you can
which recreates the problem.

I've had several cases when I thought that I had everything in the
managed pool and therefore my program was safe, and then it turned out
that I wasn't releasing render targets correctly, or was using state
blocks (IIRC these need to be recreated). If I'm not misremembering,
even vertex declarations need to be recreated (though not shaders).

Eyal

Phil Taylor

unread,
Feb 3, 2005, 8:16:20 PM2/3/05
to
this gives you an alloc-id then right?

use the break-on-alloc-id feature of the control panel to figure out what is
being allocated that D3D thinks still has a reference.

usually just from whose is at fault you can figure out how an extra
ref-count got added then to some object, causing a single Release() to not
be enough.

"Rioshin an'Harthen" <rio...@breakthru.com> wrote in message
news:O0JiB2i...@TK2MSFTNGP09.phx.gbl...

Rioshin an'Harthen

unread,
Feb 4, 2005, 4:12:41 AM2/4/05
to
"Eyal Teler" <e...@nospam-et3d.com> wrote in message
news:%23MVzrZj...@TK2MSFTNGP14.phx.gbl...

> Rioshin an'Harthen wrote:
>> We've been having this same problem with ID3DXMESH and the managed pool
>> with lost devices. Running with full debug information just says that the
>> vertex/index buffers must be released prior to resetting the device.
>>
>> Since we've made sure to use managed pools with all our objects, it seems
>> to us to be a bug in the D3DX library...
>
> Are you sure it's the meshes? Try writing the simplest program you can
> which recreates the problem.

It's definitely the meshes. Rigorous testing of the game engine causes the
device reset to fail only when meshes have been loaded - without the meshes
alt-tabbing etc. works as expected.

Our team is positive we're calling D3DXLoadMeshFromX with the Options DWORD
as D3DXMESH_MANAGED (ie. D3DXMESH_VB_MANAGED | D3DXMESH_IB_MANAGED), and
checking through Mesh.cpp I see we certainly pass 544 into it. Note the
numeric format, since we're using configuration files that can override
defaults, although no configuration file contains a line for the options at
the moment.

Eyal Teler

unread,
Feb 4, 2005, 6:30:19 AM2/4/05
to
> It's definitely the meshes. Rigorous testing of the game engine causes the
> device reset to fail only when meshes have been loaded - without the meshes
> alt-tabbing etc. works as expected.

I don't see this as totally convincing evidence, since I have no idea
what other things are done apart from loading the meshes. If you only
add a single D3DXLoadMeshFromX (into managed memory) to your program,
but do nothing with it (i.e., it's not loaded the same as you normally
load and isn't rendered at all) and don't load the meshes you normally
render, does this still cause a problem with the reset?

Eyal

Eyal Teler

unread,
Feb 4, 2005, 6:38:19 AM2/4/05
to
> If I'm not misremembering,
> even vertex declarations need to be recreated (though not shaders).

I was wrong on this account. They need not be recreated.

Eyal

0 new messages