Wine Traffic #282 For 8 Jul 2005

This patch agains winecvs 2005-05-13 adds support for Stateblocks, sampler states and swapchains to wined3d There are a few spelling fixes and tidyups, and a fix for some errors with cubtexture introduced in the interface seperation patch.

With this patch the following demos now run correctly:

from http://www.codesampler.com/dx9src.htm

• dx9_primitive_types
• dx9_texture
• dx9_vertex_data
• dx9_multitexture
• dx9_texture_mipmapping
• dx9_indexed_geometry
• dx9_texture_filtering
• dx9_initilization
• dx9_texture_subloading
• dx9_offscreen_rendering
• dx9_1pass_emboss_bump_mapping
• dx9_2pass_emboss_bump_mapping
• dx9_tokamak_chailIGHTSn
• dx9_effect_simple
• dx9_texture_dot3_blending
• dx9_point_light
• dx9_spot_light
• dx9_alpha_blending_texture

from http://triplebuffer.devmaster.net/tutorials.php

• tb_dx9_04
• tb_dx9_06
• tb_dx9_07
• tb_dx9_08
• tb_dx9_10
• BumpMapping

from http://www.clootie.ru/delphi/download_dx90.html#Direct3D

• CreateDevice
• Verticies
• Matricies
• Textures
• Lights

This patch adds support for Vertex declarations.

The parsing of vertex declarations has been tidied up, d3d8 declarations are converted into d3d9 declarations so that only one type of declaration need to be managed in the code. Vertex declarations are no longer parsed into FVF's since the fvf doesn't support everything vertex declarations support.

There is a minor issue in that vertex shader constants provided by d3d8 declarations aren't parsed properly yet, but this will be impmeted with vertx shaders.

this patch renames

_D3DCAPS9.MaxPixelShaderValue;

to the correct

_D3DCAPS9.PixelShader1xMaxValue;

To my knowlage this doesn't fix anything but does enable code with the correct name to compile properly.

This patch adds relay tracing to texture, WINEDEBUG=d3d9 will now display the message 'relay' whenever any member of IDirect3DTexture9 is called.

This patch disables the creation of invalid vertex declarations in d3d9 preventing some applications from crashing.

the patch will be superseded as soon as additions to wined3d make it into cvs.

This patch causses d3d9 to call wined3d for GetDirect3D instead of using the ->direct3D instance, which is no longer valid.

This patch mostly implements swapchains in wined3d.

additionally a couple of minor issues that prevented anything from running have been fixes.

the non-power2 texture check in wined3d/device.c has been changed to ignore rendertargets

direct3d is no longer deleted in d3d9/device.c, because d3d9/device.c no longer holds a reference to a direct3d instance.

This patch tidies up a few texture bugs

• Makes all newly created surfces dirty, so that they are loaded properly the first time around.
• Replaces some calls to cubetexture in basetexture to calls to basetexture.
• Checks that the level isn't out of bounds in calls to texture.

This patch adds support for samplers to wined3d, and switches from using d3d9 constants to wined3d constants so that there's no recursive dependencies (and so that d3d8 doesn't need to know about the d3d9 constants)

Also fixed appended a \n onto the end of a trace call in BaseTexture and Resource cleanup.

Note: The code for managing sampler and texture states has been re-written in the current wined3d patch, the new changes don't appear in this patch as other architecture changes are required that are not yet stable.

This patch changes the way caps are sent between d3d9/d3d8 and wined3d to make it easier for wined3d to support additional versions of Direct3D.

This patch implements rendertargets using either textures, swapchains or standalone surfaces.

This patch is only dependand on winecvs but.....

When applying this patch along with the stateblock patch the following lines in wined3d/stateblock.c :

This patch removes the old render target code from d3d9 and replaces the render target calls with relays to wined3d.

This patch against wine-cvs adds support adds support for vertex decalrations to wined3d and d3d9.

This patch makes sure that the OpenGL visual created for a window has a stencil buffer. This is a requirement for stencil buffer support in d3d.

This patch relays all the pixel shader calls from d3d9 to wined3d

This patch check for a NULL vertex declaration being sent to IWineDeviceD3D_SetVertexDeclaration

This patch, combined with the other wined3d and d3d9 patches already sent in is enough to get Pirates working OOTB. Pixelshaders need to be turned on in the registry or you'll have problems with missing textures. Turn on 'disable shaders' in pirates settings, and turn down the detail. (don't worry vertex buffer objects bring the frame rate up to something more desirable).

The release notes state config file control has been moved to the registry and that winecfg is active. winecfg does not seem to recognize dll overrides. Has anyone else seen this? If so were you able to work around it?

What may not be obvious is the "Applications" tab in winecfg is tied to the other tabs. We should probably add a sentence in the description of that tab to briefly explain it links to other ones (inc. "Graphics"). In fact, I'm procrastinating, so maybe I'll just try to submit a patch for that.

So if you want to change systemwide overrides:

1. Select "Default Settings" in the Applications tab.
2. Then move to the "Libraries" tab and enter the name of the DLL in "New override" box, such as "msi.dll" and click on "Add".
3. "Edit" the load order as necessary in the box below.

If you want to change the override for one application, "Add" the new application in the "Applications" tab, select it on that tab, and then move to "Libraries" to create an override. If you update to the latest CVS you'll see a different Libraries tab than what was in wine-20050628 and it follows what I described above. The layout is different in wine-20050628, but it's essentially the same concept.

The current design is totally braindead from a usability standpoint:

• As you pointed out it's not very intuitive that selecting an item in the first tab affects the semantics of the other tabs (even if it would be documented).
• It's not clear which settings are global-only - we could disable the controls but it would still be confusing IMHO. Also the drives tab will probably never contain any per-app settings so we would have to disable the whole tab. Silly.
• All per-app settings really need exactly one more option - "don't override" (inherit from global). This is not doable with the current design.

I'll submit a preliminary patch (introducing the not yet configurable DSound settings) showing how I think this should be done later today.

Felix and I talked this stuff over on IRC, I think we came to some understanding on where winecfg is going and why it's designed the way it is.

For everybody: generally, we should resist the temptation to do yet more UI overhauls. Yes, the linked tabs thing is not ideal. It's more an artifact of the Property Sheet control than anything else. However, a few things which are less ideal are:

1. Treeviews: tried, didn't work very well. Treeviews have generally poor usability anyway
2. Tri-state checkboxes: not really clear what the third state means, but for now it may be a quick fix
3. Opening up new windows for each app: hard to implement in the code.

A much better way forward is simply to fix the damn bugs that winecfg settings invariably exist to work around :)

Eg, even "Windows Version" will hopefully be fixed sometime later this year (?) by switching us to 2K/XP mode by default and by nailing the last DCOM problems. Desktop mode will eventually (I hope) become the "winedesktop" program that was done years ago, I'm not sure what AJ plans are here though.

Eventually nobody should have to use winecfg for anything. Let's spend our time fixing the bugs and increasing automation rather than arguing about the best way to represent a list of hacks in the UI :)

I think Alexandre didn't want every special folder to have its own implementation. Mike also has a network neighbourhood folder that has the same problems. Basically, a lot of the shell folder code needs to be tidied up with all of these special folder integrated into it.

I See, but I don't see any comment from Alexandre. We need even more Window-handling in shell32.dll See my stub for Printers_RegisterWindowW. (Printer Properties)

Together with the other special Folders we have a big Part of explorer.exe ready.

I'd like to use an LGPL licensed LZX compressor for the compression part of cabinet.dll. What's the best way to accomplish this?

1. copy and pasting the code as required.
2. dynamically loading an elf library at runtime
3. do configure checks at ./configure and link statically
4. do the same and link dynamically
5. checkin a windows-version of this LZX compressor to wine cvs and use that at runtime.

Web site:

http://www.speakeasy.org/~russotto/chm/