> Connecting the parents' refcounts wasn't really the idea, at least not
> directly. I think it's probably a good idea to have as little logic in
> the wrappers as possible. However, they are of course indirectly
> connected through wined3d; The connection between IDirect3DSurface9
> and IDirect3DT
Trying to install Oregon Trail from cnet download,
http://www.download.com/Oregon-Trail-5th-Edition/3000-7502_4-10301783.html
Cnet has you download a tiny .exe that invokes
IE via ActiveX to do the real download.
This pops up Wine's Mozilla ActiveX downloader dialog (great)
which then downloads the
On 12/02/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> I meant IWineD3DSurface <=> IWineD3DTexture and Parent(IWineD3DSurface) <=>
> Parent(IWineD3DTexture). The first case has no consequences for ddraw, if the
> secound one is forced by WineD3D this would cause a connection between
> IDirect3DS
Hi
> IDirect3DTexure9::Release
> {
> ULONG ref = This->ref--;
>
> if(ref == 0)
> {
> for(all surfaces in this container)
> {
> surfaceImpl->container = NULL;
> /* Or place this call in WineD3DTexture::Releaase*/
>
> IWineD3DTexture_Release(This->wineD3DTexture);
>
Hi,
> Are you talking about IDirect3DSurface9 <=> IDirect3DTexture9 or do
> you mean IDirect3DSurface9 <=> IWineD3DSurface?
I meant IWineD3DSurface <=> IWineD3DTexture and Parent(IWineD3DSurface) <=>
Parent(IWineD3DTexture). The first case has no consequences for ddraw, if the
secound one is forc
On 12/02/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Hi,
> I've thought over this: If you want to connect the IWineD3DTexture and
> IWineD3DSurface refcounts only, then there's no problem for me. If you want
> to connect the Texture's and Surface's Parents refcount,
Are you talking about IDire
Hi,
> 2 different viewports or just two different projection matrix settings?
> The way 2D overlays are handled in OpenGL from my (very limited)
> experience is that you setup your normal glPerspective, and then once
> you've drawn everything in the world, you switch to a glOrtho2D and do
> whateve
Hi,
I've thought over this: If you want to connect the IWineD3DTexture and
IWineD3DSurface refcounts only, then there's no problem for me. If you want
to connect the Texture's and Surface's Parents refcount, then you have do the
same for the rendertargets and the swapchain(I guess that Windows d
Stefan Dösinger wrote:
Err reading your e-mail again, pardon my directx ignorance, but aren't
all d3d z values supposed to be in the [0.0, 1.0] range? I thought that
was the range for the z buffer. I recall reading that one of the main
annoyance differences between OpenGL and D3D was OpenGL used
Tony, can you empower me to empower other people, since I have already
been empowered to fix bugs, and I got his request email last night?
Tom
Tony Lambregts wrote:
Michael Jung wrote:
Hi,
I would like to change the status of bug 4322 to FIXED, but I'm not
'empowered' to do it. Whom do I ha
Forwarded from Bugzilla bug 4551.
Nowadays on Linux you do not see your virtual wine hardware drives in KDE or
GNOME because they are not recognized. You have to open "invisible" folder
"$HOME/.wine". Many users will not be able to do this.
Maybe one could work out some standard with freedesktop
> With the solution mentioned in my previous post, d3d7/8/9 objects
> would essentially not be real COM objects on their own, they would
> just wrap the relevant wined3d AddRef/Release functions, and not have
> refcounts of their own. Wined3d would be responsible for it's own
> refcounting, and cle
Michael Jung wrote:
Hi,
I would like to change the status of bug 4322 to FIXED, but I'm not
'empowered' to do it. Whom do I have to talk to?
Bye,
One of them is me.
You are now empowered.
--
Tony Lambregts
On 12/02/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> Could it be that d3d9 surfaces and textures are the same objects on windows?
> What happens if you QueryInterface the surface for the texture GUID?
It returns 0x80004002 (E_NOINTERFACE). Same thing for the reverse.
> When the app releases t
> One way to solve this would be to have wined3d handle the reference
> counting for d3d7/8/9 as well, so that their AddRef/Release calls just
> call AddRef/Release on the wined3d object they wrap. That would also
> mean we need to pass a pointer to the d3d7/8/9 object's cleanup
> function. (Releas
I've run into a somewhat annoying problem with d3d9/wined3d recently.
It appears that on d3d9 on Windows a surface either forwards its
AddRef / Release calls to its container if it has one, or just shares
the refcount directly. Either way, it comes down to the same thing.
Calling AddRef on the sur
one more update. 0.12 is the current version and is mainly a
minor-fixes-release which also fixes a really stupid bug (or so).
Functionality is the same, have fun. hmmm, time to release this thing
with a readme...
getwinegit.sh
Description: Bourne shell script
Hi,
I would like to change the status of bug 4322 to FIXED, but I'm not
'empowered' to do it. Whom do I have to talk to?
Bye,
--
Michael Jung
[EMAIL PROTECTED]
On 10/02/06, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> > The output of glGetString(GL_PROGRAM_ERROR_STRING_ARB) can get too
> > large for a normal FIXME. Use fprintf to stderr instead.
>
> You should use debugstr_a. fprintf will mess up the output.
The output of glGetString(GL_PROGRAM_ERROR_
> Err reading your e-mail again, pardon my directx ignorance, but aren't
> all d3d z values supposed to be in the [0.0, 1.0] range? I thought that
> was the range for the z buffer. I recall reading that one of the main
> annoyance differences between OpenGL and D3D was OpenGL used [-1.0, 1.0]
> fo
Hi,
> Err reading your e-mail again, pardon my directx ignorance, but aren't
> all d3d z values supposed to be in the [0.0, 1.0] range? I thought that
> was the range for the z buffer. I recall reading that one of the main
> annoyance differences between OpenGL and D3D was OpenGL used [-1.0, 1.0]
21 matches
Mail list logo