Hi
Has anyone thought about adding the directx options to the Graphics tab in WineCfg
Just now I've been testing all the work been done on the graphics layer on different games so I've been switching on and off GLSL and changing backbuffer to fbo etc using regedit
Would it not be better to change these things easily instead to allow for wider testing.
PS With GLSL and FBO Tomb Raider Legent Opening Level Sequence the cliffs are black
With all other options the watter effect is applied the the whole screen when any water is in the screen at all. Has anyone else noticed this.
Also none of the menu writing shows up in FarCry but the game works a treat
I'm now just waiting for mmstream to be implemented to I can see my video's on X3
Keep up all the good work your beating Transgaming hands down
Mike
PS the above reports were testing with 0.9.31, 0.9.32 and the latest git
Completely seconded, some nice UI love is the only thing we have under Transgaming right now, really. But a native Exec. UI is > a python buggy UI.
On 3/17/07, Michael Lothian mike@fireburn.co.uk wrote:
Hi
Has anyone thought about adding the directx options to the Graphics tab in WineCfg
Just now I've been testing all the work been done on the graphics layer on different games so I've been switching on and off GLSL and changing backbuffer to fbo etc using regedit
Would it not be better to change these things easily instead to allow for wider testing.
PS With GLSL and FBO Tomb Raider Legent Opening Level Sequence the cliffs are black
With all other options the watter effect is applied the the whole screen when any water is in the screen at all. Has anyone else noticed this.
Also none of the menu writing shows up in FarCry but the game works a treat
I'm now just waiting for mmstream to be implemented to I can see my video's on X3
Keep up all the good work your beating Transgaming hands down
Mike
PS the above reports were testing with 0.9.31, 0.9.32 and the latest git
Bryan Haskins <kingofallhearts999 <at> gmail.com> writes:
Completely seconded, some nice UI love is the only thing we have under
Transgaming right now, really. But a native Exec. UI is > a python buggy UI.
On 3/17/07, Michael Lothian <mike <at> fireburn.co.uk> wrote: HiHas anyone thought about adding the directx options to the Graphicstab in
WineCfgJust now I've been testing all the work been done on the graphicslayer on different games so I've been switching on and off GLSL and
changing backbuffer to fbo etc using regeditWould it not be better to change
these things easily instead to allowfor wider testing.
I completely agree with this.This fiddling around with regedit is really annoying, and moreover you cannot see what keys actually can be added or changed. Adding it to winecfg is quite simple, so i wonder what the reason is, why it's never been don
On 17/03/07, Louis Lenders xerox_xerox2000@yahoo.co.uk wrote:
I completely agree with this.This fiddling around with regedit is really annoying, and moreover you cannot see what keys actually can be added or changed. Adding it to winecfg is quite simple, so i wonder what the reason is, why it's never been don
Because it's not something you should have to configure. Eventually GLSL and FBOs should simply become the defaults, and if it doesn't work that's a bug. I think GLSL is basically at the point where in general it's at least as good as the ARB backend, FBOs will need a bit more work.
H. Verbeet <hverbeet <at> gmail.com> writes:
On 17/03/07, Louis Lenders <xerox_xerox2000 <at> yahoo.co.uk> wrote:
I completely agree with this.This fiddling around with regedit is really annoying, and moreover you cannot see what keys actually can be added or changed.
Because it's not something you should have to configure.
But "fiddling around" with native and built in DLLs is something that shouldn't have to be configured as well, but still, it has to be done and that's why it can be found in winecfg. For those who like to configure DirectX thingers, the better way (after a setting has become somewhat "useful" of course) would be winecfg. Even more, what if someone doesn't know about all the registry keys? Every user knows winecfg, and I'd say users are more likely tempted to "play" with some checkboxes than unknown registry settings, and users who "solved" a problem this way are more likely to report this than those who have not been successful.
On the other hand, why not implement switching these registry keys into winetricks because it's doing a great job already anyway? ;
On Mon, Mar 19, 2007 at 10:49:59AM +0000, Ray Jones wrote:
H. Verbeet <hverbeet <at> gmail.com> writes:
On 17/03/07, Louis Lenders <xerox_xerox2000 <at> yahoo.co.uk> wrote:
I completely agree with this.This fiddling around with regedit is really annoying, and moreover you cannot see what keys actually can be added or changed.
Because it's not something you should have to configure.
But "fiddling around" with native and built in DLLs is something that shouldn't have to be configured as well, but still, it has to be done and that's why it can be found in winecfg. For those who like to configure DirectX thingers, the better way (after a setting has become somewhat "useful" of course) would be winecfg. Even more, what if someone doesn't know about all the registry keys? Every user knows winecfg, and I'd say users are more likely tempted to "play" with some checkboxes than unknown registry settings, and users who "solved" a problem this way are more likely to report this than those who have not been successful.
On the other hand, why not implement switching these registry keys into winetricks because it's doing a great job already anyway? ;
Hi, implementing GLSL checkbox, OffScreenRenderingMode dropdown menu and VideoMemorySize textbox into winecfg would be easy.
winetricks is IMO going the same way as winetools - too much functions in one big shell file. This will be very hard to maintain as functionality grows.
I consider Wine-Doors project more promising as it splits these hacks into separate 'packages'. Recently it's become really usable :-)
There is also a lightweight command-line PERL based implementation of Wine-Doors called winebot at http://winebot.sandbox.cz . Both Wine-Doors and Winebot share same package sources.
Regards Vit Hrachovy
Hi, implementing GLSL checkbox, OffScreenRenderingMode dropdown menu and VideoMemorySize textbox into winecfg would be easy.
GLSL is OK IMO, because some drivers(*cough* macos *cough*) have serious problems with glsl. It could be included into the shader dropdown box. The issue that needs to be dealt with is that we can't combine arb vertex shaders and glsl pixel shaders or vice versa.
Video memory size maybe too. There are vendor dependent ways to read it, but implementing them is pretty nasty(requires some private to winex11.drv). Altough we had that discussion a number of times already and we only agreed on a registry key so far.
Offscreen rendering should have fbos fixed and made default, otherwise use backbuffer(not pbuffer because backbuffer with aux buffers is cheaper). I don't think it is a good idea to add it to winecfg
I don't think render target locking should be configureable as is. That rendering should be fixed to catch NOP locks some games do(which does the same as glFinish() on windows).
What I have considered is some performance vs correctness slider. With decreased correctness things like render target locking or drawStridedSlow are disabled. If the correctness is decreased even more some properly implemented, but known to be expensive settings could be deactivated, like smooth shading, per pixel fog(ok. not sure if that is expensive). Windows drivers have such a setting, so why shouldn't we :-) . This slider could also cover some software emulated features like vertex blending(if we ever get that). Of course we shouldn't pollute the wined3d code with if(someSetting) statements either.
On 19/03/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
GLSL is OK IMO, because some drivers(*cough* macos *cough*) have serious problems with glsl. It could be included into the shader dropdown box. The issue that needs to be dealt with is that we can't combine arb vertex shaders and glsl pixel shaders or vice versa.
The shader dropdown should go, actually.
Stefan Dösinger wrote:
Hi, implementing GLSL checkbox, OffScreenRenderingMode dropdown menu and VideoMemorySize textbox into winecfg would be easy.
GLSL is OK IMO, because some drivers(*cough* macos *cough*) have serious problems with glsl. It could be included into the shader dropdown box. The issue that needs to be dealt with is that we can't combine arb vertex shaders and glsl pixel shaders or vice versa.
Spec says otherwise... I've also seen a software vertex shader with a GLSL pixel shader.
What I have considered is some performance vs correctness slider.
We want incorrect graphics in wined3d?
With decreased correctness things like render target locking or drawStridedSlow are disabled. If the correctness is decreased even more some properly implemented, but known to be expensive settings could be deactivated, like smooth shading, per pixel fog(ok. not sure if that is expensive). Windows drivers have such a setting, so why shouldn't we :-) .
Are you sure it wasn't "performance vs quality" :)
On Mon, Mar 19, 2007 at 02:07:59PM +0100, Stefan D?singer wrote:
Hi, implementing GLSL checkbox, OffScreenRenderingMode dropdown menu and VideoMemorySize textbox into winecfg would be easy.
GLSL is OK IMO, because some drivers(*cough* macos *cough*) have serious problems with glsl. It could be included into the shader dropdown box. The issue that needs to be dealt with is that we can't combine arb vertex shaders and glsl pixel shaders or vice versa.
Video memory size maybe too. There are vendor dependent ways to read it, but implementing them is pretty nasty(requires some private to winex11.drv). Altough we had that discussion a number of times already and we only agreed on a registry key so far.
Hi Stephan, I've inspected winecfg code closely and the current state is that implementing GLSL into shader dropdown menu would make it non-elegant.
Shader dropdown box expects the registry value to be only on one place, in [Software\Wine\Direct3D] VertexShaderMode.
GLSL in my opinion uses two registry entries - VertexShaderMode and UseGLSL. IMO UseGLSL == enabled implicates VertexShaderMode == hardware.
To reflect the current state I could take one of the following two approaches:
1. Add a checkbox 'Allow GLSL (if supported by hardware)' after 'Allow Pixel Shader (if supported by hardware)'. This checkbox would control only state of UseGLSL registry entry, nothing else.
1.1 Checkbox 'Allow GLSL' would set Vertex Shader Mode to "hardware" when enabled.
2. Implement Implement GLSL entry into Vertex Shader Support dropdown menu and create nasty workarounds like: -------------- if (strcmp("GLSL" , D3D_VS_Modes[selected_mode].settingStr) == 0) { set_reg_key(config_key, keypath("Direct3D"), "VertexShaderMode", "hardware" ); set_reg_key(config_key, keypath("Direct3D"), "UseGLSL", "enabled"); } else { set_reg_key(config_key, keypath("Direct3D"), "VertexShaderMode", D3D_VS_Modes[selected_mode].settingStr); set_reg_key(config_key, keypath("Direct3D"), "UseGLSL", "disabled"); } --------------
where previous code was only:
-------------- set_reg_key(config_key, keypath("Direct3D"), "VertexShaderMode", D3D_VS_Modes[selected_mode].settingStr); --------------
I'd vote for 1. or 1.1 solution.
There is also another solution - to implement UseGLSL registry entry into VertexShaderMode entry and discard UseGLSL key completely. However, this is far reaching change.
Regards Vit Hrachovy
-
Bryan Haskins -
H. Verbeet -
Ivan Gyurdiev -
Louis Lenders -
Michael Lothian -
Ray Jones -
Stefan Dösinger -
Vit Hrachovy