[1/4] D3D9: Implement IDirect3DDevice9::StretchRect
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 ...
WineD3D: ProcessVertices
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 rendered pixels' data written to the VBO then, right? To use this for ProcessVertices one would have to have a bijective relation between pixel's and processed vertices; p.e. pass the transformed vertex coordinates in varying variables and use'em as the color components and have the pixels stored in the order the vertices are so we can tell afterwards from what vertex they originate, in passing the vertex index as an attribute and so generate appropriate vertex coords ... theoretically. I don't think its easy or even possible to have exactly one pixel per vertex at sequential positions in the pixel buffer, or is it (using points and knowing the resolution etc.) ?
[15/20] WineD3D: Clean up drawprim a bit
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). If someone is extra-ambitious we can do something like Softwire/SwiftShader does. But I think ProcessVertices is a good oportunity to verify our vertex shader implementation. Sounds fun *g* ... I thought of generating Intel assembly code from the vertex shader bytecode on the fly, just like GLSL and ARB shaders are generated, using primarily SSE for doing the floating point computations (in situations where it brings an advantage), and directly referencing the memory at IWineD3DVertexShaderImpl->data,input,output (load constants, input data, store temporary values, store output data). Would something like that even be accepted in wine ? I'm already 'experimenting' a bit, but as I don't have much time these days don't count on it to be finished within the next 3 months, or ever, after all I might also get so desperate with it and stop working on it altogether ... I've never written anything similar before. The main reason for this mail is to know whether someone else is working on a solution for doing software vshaders already, and if so, rather invest the time in my other studies (I'm running behind there ...), before having two people work at the same thing.
Re: [2/8] WineD3D: Catch NOP vertex declaration changes
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 as well. If you set p.e. vertex declaration to 0, then you start recording, set vertex declaration to some object (ref still 1), then stop recording and get the stateblock, and then let this block Capture the device stateblock, the refcount of object would be decreased to 0 since the capturing stateblock's value of vertex declaration is &object, the device's is 0, and so stateblock would Release the object it holds.
[2/8] WineD3D: Catch NOP vertex declaration changes
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 at this.
Just look again at the SetPixelShader function, this is how it looks in
my current GIT (I didn't touch this one) :
3758 /* Handle recording of state blocks */
3759 if (This->isRecordingState) {
3760 TRACE("Recording... not performing anything\n");
3761 }
3762 3763 if (NULL != pShader) {
3764 IWineD3DPixelShader_AddRef(pShader);
3765 }
3766 if (NULL != oldShader) {
3767 IWineD3DPixelShader_Release(oldShader);
3768 }
3769 3770 if (This->isRecordingState) {
3771 TRACE("Recording... not performing anything\n");
3772 return WINED3D_OK;
3773 }
3774 3775 if(pShader == oldShader) {
3776 TRACE("App is setting the old pixel shader over, nothing
to do\n");
3777 return WINED3D_OK;
3778 }
[2/8] WineD3D: Catch NOP vertex declaration changes
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 that not adding a
reference here causes the declaration object to be deallocated to
early, when it is still used by the application ?
[4/4] wined3d: Create samplers for *all* 1.x instructions that sample
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.hex_version) == 1 &&
(WINED3DSIO_TEX == curOpcode->opcode ||
WINED3DSIO_TEXBEM == curOpcode->opcode ||
+ WINED3DSIO_TEXBEML == curOpcode->opcode ||
+ WINED3DSIO_TEXDP3TEX == curOpcode->opcode ||
WINED3DSIO_TEXM3x2TEX == curOpcode->opcode ||
- WINED3DSIO_TEXM3x3TEX == curOpcode->opcode)) {
+ WINED3DSIO_TEXM3x3SPEC == curOpcode->opcode ||
+ WINED3DSIO_TEXM3x3TEX == curOpcode->opcode ||
+ WINED3DSIO_TEXM3x3VSPEC == curOpcode->opcode ||
...
} else if
(WINED3DSHADER_VERSION_MAJOR(This->baseShader.hex_version) == 1 &&
(WINED3DSIO_TEXM3x3SPEC == curOpcode->opcode ||
WINED3DSIO_TEXM3x3VSPEC == curOpcode->opcode)) {
Re: Re: ntdll/signal_i386.c: __wine_enter_vm86 issue
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 those that did NOT crash just did nothing :-( ... I can't comment the vm86 stuff, but no input is because the unix process gets the signal and not the unix thread. Try this patch: http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html It's a while back, so you probably have to manually apply it. Yep .. it (the patch) works, at least for Blade of Destiny which is now actually playable (!) (without sound yet, though). Why hasn't it been merged?
ntdll/signal_i386.c: __wine_enter_vm86 issue
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 VM86TYPE(res) == VM86_UNKNOWN it calls the raise_segv_exception, which in turn calls NtSetContextThread. This one calls set_cpu_context which tries to reload the context of the VM86 thread an, of course, crashes since it can't load the segment registers with invalid (non GDT) values. Backtrace: =>1 0x7efe2a57 in ntdll (+0x52a57) (0x7d55e348) 2 0x7efd9a8d NtSetContextThread+0x77() in ntdll (0x7d55e478) 3 0x7efd412e in ntdll (+0x4412e) (0x7d55e498) 4 0x7efd5032 __wine_enter_vm86+0x1d6() in ntdll (0x7d55e608) 5 0x7eeb9b15 K32WOWCallback16Ex+0x417() in kernel32 (0x7d55e668) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported constant max_clusters in function fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported constant max_sectors_per_cluster in function fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported constant max_bytes_per_sector in function 6 0x7d6f50bb DOSVM_Enter+0xab(context=0x7d55e760) [/home/chr/WINE/CVS_BUILD/dlls/winedos/dosvm.c:586] in winedos (0x7d55e748) 7 0x7d71254b MZ_DOSVM+0xbb(lpExtra=0x0) [/home/chr/WINE/CVS_BUILD/dlls/winedos/module.c:638] in winedos (0x7d55ea48) 8 0x7eeacdf6 in kernel32 (+0x6cdf6) (0x7d55eb28) 9 0x7efd9939 in ntdll (+0x49939) (0x7d55f448) 10 0xb7de1512 start_thread+0x84() in libpthread.so.0 (0x7d55f4d8) 11 0xb7d7afde __clone+0x5e() in libc.so.6 (0x) 0x7efe2a57: pop %es My question, is this a bug, and, if so, what should be done to correct it? Is it sufficient to just make raise_segv_exception return if context->Eflags indicate VM86 instead of calling NtSetContextThread ? In my example (Realms of Arkania: Blade of Destiny) this lets the app continue and I get the initial text box to select difficulty level. But ... the process doesn't handle any input - events are queued but never handled p.e. by DOSVM_Wait or similar ... Unfortunately I don't know much about this stuff ... what procedure is responsible to handle these asynchronous events and when ?
