Hello Lionel,
Now that I think that the refcount crash is solved and I'm waiting for the
patch I've sent to be reviewed and commited, I've looked into the OpenGL
crash: I know the following cases
*Hardware accellerated, with fglrx: Crash in fglrx[1]
*Hardware accellerated, other implementation:
> Best would be to write a 'DDraw' test (integrated in the test suite) to be
> able to check reference counting in some 'standard' cases (surface
> creation, D3D object creation, ...).
I am afraid this will have to wait a few days, as I don't have access to any
Windows machine the next days.
> We
> *Windows increases the refcount of the DirectDraw7 object by 1 when a surface
> is created. When the surface is released, the refcount of the DirectDraw7
> object is decreased, obviously. Wine doesn't do so(yet), and to my current
> knowledge, this is what makes Empire Earth crash.
Yeah, this
Hello,
> What you could test is artifically increase the refcount of 'normal'
> surfaces and check if these are deleted or not.
Sorry for the delay, I was busy over the weekend, but here are some more
results. I hope I wasn't misslead by anything again ;-)
*Windows increases the refcount of the D
On Thu, Sep 08, 2005 at 10:37:56PM +0200, Stefan Dösinger wrote:
> I think you're right. After Releasing the DDraw object two times, as EE does,
> it's far from beeing freed: It has a refcount of 8!! In particular, creating
> the surface and performing QueryInterface on it increase the refcount b
Am Donnerstag, 8. September 2005 22:03 schrieb Lionel Ulmer:
> On Thu, Sep 08, 2005 at 09:20:39PM +0200, Stefan Dösinger wrote:
> > Do you mean on Windows or on Wine? How can I get these members from an
> > external application? I thought that apps can't look inside a COM object,
> > as the structu
On Thu, Sep 08, 2005 at 09:20:39PM +0200, Stefan Dösinger wrote:
> Do you mean on Windows or on Wine? How can I get these members from an
> external application? I thought that apps can't look inside a COM object, as
> the structures used by the libs and the structures exported to the app are
>
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hi,
> > Yeah, I suspected that the problem was in the 'force destroy' code. Could
> > you change your test script to get the reference count of the 'complex'
> > object before release of the DDraw object and after ? Could you do the same
> > for th
Hi,
> Yeah, I suspected that the problem was in the 'force destroy' code. Could
> you change your test script to get the reference count of the 'complex'
> object before release of the DDraw object and after ? Could you do the same
> for the 'normal' objects (mostly before as after it will crash :-
> Wine releases the surface in 5), Windows doesn't. It appears to me, that
> Windows doesn't release Surfaces which have a D3D object attached when the
> DDraw instance they belong to is freed.
Yeah, I suspected that the problem was in the 'force destroy' code. Could
you change your test script
Am Donnerstag, 8. September 2005 18:24 schrieb Oliver Stieber:
> --- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > Hi,
> > I think I've found the cause of the Empire Earth crash. This is not a
> > reference counting problem at all, Empire Earth releases the DirectDraw
> > and Surface objects on pu
--- Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hi,
> I think I've found the cause of the Empire Earth crash. This is not a
> reference counting problem at all, Empire Earth releases the DirectDraw and
> Surface objects on purpose. This is what happens:
>
> 1) EE creates a DDraw object
> 2) I
Hi,
I think I've found the cause of the Empire Earth crash. This is not a
reference counting problem at all, Empire Earth releases the DirectDraw and
Surface objects on purpose. This is what happens:
1) EE creates a DDraw object
2) It attaches a Complex Surface
3) It sets up a D3D device for thi
13 matches
Mail list logo
