Re : [DDRAW] Only detach surfaces when releasing a non-texture surface attached to a complex root.
Le 28.08.2006 18:10:37, Stefan Dösinger a écrit :
Do you mean the game releases the texture manually until it is destroyed??? Urgh. Can you verify that this doesn't come from DllMain() in dlls/ddraw/main.c?
Nop I checked, and anyway can't be because this occurs also when switching resolutions.
The msdn suggests that destroying the root destroys all sublevels, and it would be sane, because you create all surfaces with one call, so you should destroy them with one call.
If you are right, then every single ddraw application that works on wine now would leak memory on windows.
Well I don't understand, what leaks ? Complex attached surfaces are still destroyed when we fire the root. The new patch takes Moto Racer 2 memleak issues in hand, and Nomad Soul leaks may not be related to this — not a regression because exiting led to crash before ( and remaining surfaces are simple surfaces ). In fact i was a bit unfresh when i posted the patch :P ..
I suspect that something else, like a bad capatiblity flag, causes weird behavior by the app, so it behaves differently in wine then on windows, or that the real refcouning issue is that the front buffer shouldn't be destroyed when the app messes with the back buffer. The other thing could be that this application has an registry hack on windows: Windows XP has ddraw compatiblity regitry entries in HKEY_LOCAL_MACHINE\Software\Microsoft\DirectDraw\Compatiblitity. Can you check if you find Nomad Soul there? I have no idea what these entries mean, can you try to remove the whole compatiblity key and try nomad soul again? (well, backup first :-) )
Hmm I'll try as soon as I procure it. But first tell me if i misunderstood something ;-)
It is hard to prove that a surface is really destroyed or not, but you can write a regression test which accesses a back buffer which belongs to a complex back buffer / front buffer compound after the front buffer has been destroyed?
Hi,
Well I don't understand, what leaks ? Complex attached surfaces are still destroyed when we fire the root. The new patch takes Moto Racer 2 memleak issues in hand, and Nomad Soul leaks may not be related to this — not a regression because exiting led to crash before ( and remaining surfaces are simple surfaces ). In fact i was a bit unfresh when i posted the patch :P ..
My wait, I think I still do not really get what happens here...
Nomad Soul calls Release on the back buffer until it returns 0? Something like
while(Backbuffer->Release()); ?
Does it do that before releasing the front buffer, or after? I thought after releasing the front buffer, because that was some odd behavior reported with dune2000 which went away mysteriously...
Your patch, if I get it correctly, calls DeleteAttachedSurface only on the surface that is actually destroyed. If a surface is destroyed that is attached to a complex root then nothing else is done.
Just some questions to make sure I understand correctly:
* If the front buffer is destroyed and a z buffer attached to the back buffer, the z buffer will not get detached when back buffer is destroyed? So the reference to the z buffer will hang and the app crash will eventually when zbuffer->first_attached is accessed?
* If the back buffer is explicitly released so its refcount falls to 0 before the front buffer is destroyed, the z buffer is detached but nothing else happens. The back buffer will be destroyed when the front buffer is destroyed?
What does nomad soul do if you just return 0 when the ref of the back buffer falls to 0?
E.g
if(ref == 0) { if(This->first_complex != this) { WARN("Attempt to destroy a surface that is attached to a complex root\n"); return 0; } }
And leave the rest as it is. That would be correct according to the msdn("A complex attached surface can only be destroyed by destroying the root"). I always thought this is enforced simply by the refcount, but well...
DDraw refcouting is horrible :-/ MS placed a lot of appcompat hacks into it(see the tests), and I already had loads of fun with it. I'm afraid that this will be fun for the future too...
-
Elie Morisse -
Stefan Dösinger