This also (partially) fixes the issue with NFS:MW where nothing except
the menus appears to be draw when setting the Visual Treatment option
to high.
The scene is now visible, but its scaled down in the y direction and
only covers about the top 2/3 of the screen ...
Henri Verbeet wrote:
Well, you can't set a VBO as rendertarget directly, but you can copy
the FBO data into a PBO, which you can bind as a VBO. That's pretty
legitimate in OpenGL. But I was wondering how hard it would be to use
something like that for ProcessVertices.
Well, you would get the re
Stefan Dösinger wrote:
We will need software shaders for a correct implementation of
IWineD3DDevice::ProcessVertices. It supports Vertex shaders, but I
don't really think OpenGL feedback mode is what we want here.
Maybe we should remove it for now, but keep the code somewhere(in the
wiki maybe).
Zitat von "H. Verbeet" <[EMAIL PROTECTED]>:
Nah, it's correct that the refcounts are broken at the moment. What
Stefan probbly meant was that we might as well remove refcounting
completely from that fucntion.
Then so should the AddRef/Release be removed from the StateBlock's
Capture function
Yet the application (NFS:MW) page faults right at startup at the
address of pDecl + 4 so something's amiss ... maybe this will get fixed
automatically in one of the next patches or is due to some other weird
thing that affects my sources (eh?) ... as long as no one else
complains, lets leave it
Not performing the following:
if (NULL != pDecl) {
IWineD3DVertexDeclaration_AddRef(pDecl);
}
in IWineD3DDeviceImpl_SetVertexDeclaration(...) when state is being
recorded (note the return that was added), seems to cause a page fault,
at least in NFS: Most Wanted. Is it possible th
Note that WINED3DSIO_TEXDP3TEX, WINED3DSIO_TEXM3x3VSPEC,
WINED3DSIO_TEXM3x3SPEC are already handled in the 2 else if branches
below, they should probably be
removed somewhere.
@@ -295,8 +295,15 @@ HRESULT shader_get_registers_used(
if
(WINED3DSHADER_VERSION_MAJOR(This->baseShader.h
Zitat von Markus Amsler <[EMAIL PROTECTED]>:
Christoph Bumiller wrote:
I tried to run some DOS games with wine recently and since most of them
crashed
I would call this a success, since not ALL of them crashed :-).
Winedos is far from a complete DOS emulation.
Well, unfortunately
I tried to run some DOS games with wine recently and since most of them
crashed with a page fault I tried to find out why and so, examining the
last function calls before faulting revealed that when
__wine_enter_vm86 in signal_i386.c returns from
res = vm86_enter(...)
and encounters a VM
