new to wine, Guild Wars don't display correctly

[Stefan Dösinger]

Am Freitag, 31. März 2006 09:12 schrieb BONNEL Christophe:
> Hi everyone,
>
> Sorry in advance not to know where to post, but I'm new to wine.

It would be better to post requests like this to [email protected]
> First of all, I'm under debian stable and i'm using the debian package
> wine_0.9.10~winehq1-2_i386.deb. My kernel is 2.6.8 and my graphic card is
> an ati radeon 9000pro (I know ...ouch...)

The fglrx driver you mentioned doesn't work any more on those cards. PPracer 
has problems too: Start the "Doing" course. Head to the yellow arrows on the 
left. They will disapper when you come really close.
> So i first try with the dri driver and , although my 3D was ok(openGL1.2
> it seems), it was too slow to be playable and my mouse didn't appear.

So it basically worked with the open source driver?
> So i use now the official ati last driver(openGL 1.3 it seems). Now, most
> of the images doesn't appear. If you know guild wars, in the login screen,
> i have only rocks, the background image behind rocks and the "window" for
> login in front of rocks don't appear.

You hit the bug ati introduced with 8.19.10. I think it's related to opengl 
display lists, and I've reported it to ati months ago. Didn't get a reply so 
far
> I can send you the lasts many "fixmes" that appears but for some seconds,
> i have approximatively 1Mo file. However, i have no "err". The lasts line
> are : fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(190,15)
> not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(191,15) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(192,15) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(193,-1) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(194,0) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(198,0) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(199,0) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(200,0) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(201,0) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(202,0) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(203,0) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(204,0) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(205,0) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(206,0) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(207,2) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(208,1) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(209,1) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(162,-1) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(163,0) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(164,1065353216) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(165,1) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(172,3) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(173,1) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(178,1065353216) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(179,1065353216)
> not handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(180,0) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(181,0) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(182,1065353216) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x4d290020)->(183,0) not
> handled yet fixme:d3d:IWineD3DDeviceImpl_SetRenderState
> (0x4d290020)->(184,0) not handled yet
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from
> glStencilOp(...) @ device.c / 3809
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from
> glStencilOp(...) @ device.c / 3809
> fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from
> glStencilOp(...) @ device.c / 3809

These are harmless, they are fixmes from the direct3d initialization. Some 
render states aren't supported by wines d3d implementation, but when wined3d 
initializes, it sets them to the default value, which causes such messages. 
The last three fixmes are fixed in the current cvs version, and they are 
harmless too.
> There are also in the upper-middle of the log file many :
>  fixme:d3d:IWineD3DDeviceImpl_EvictManagedResources (0x4d290020) : stub

EvictManagedTextures is a windows-related video memory management thing, and 
it won't have much impact too. If it has, then it will only show slightly 
reduced performance for a few secounds after loading. It should remove the 
managed textures from the video card, to make the memory free for new 
textures.
> Hope this can help a bit....
>  My command line to launch the games is :
>  wine "E:/toph/games/GUILD WARS/Gw.exe" 2>gw.wine
>  I use win98 version per default because sometimes with win2k i have some
> ntdll errors when connecting to internet(areanet). I don't use anything
> else. I try display by hardware or emulation, with simple or double buffer,
> in a window or in directly, with pixel shader or not, but nothing works.
> Per default, my screen is 1024*768*24bits

Should be fine
> Note that tuxracer (or ppracer) works so i don't think it comes from the
> driver, but i can make mistakes...

See above

WineD3D has serious performance problems, somehow related to textures. I hope 
that I can debug them during the weekend, but I can't give garantees. These 
problems seem to be related to textures. My tests with 3dmark2000 show that 
texture rendering should be 10 times faster than it is.

I hope I could help you,
Stefan

[H. Verbeet]

On 31/03/06, Stefan Dösinger [email protected] wrote:
> > fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from
> > glStencilOp(...) @ device.c / 3809
> > fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from
> > glStencilOp(...) @ device.c / 3809
> > fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from
> > glStencilOp(...) @ device.c / 3809
>
> These are harmless, they are fixmes from the direct3d initialization. Some
> render states aren't supported by wines d3d implementation, but when wined3d
> initializes, it sets them to the default value, which causes such messages.
> The last three fixmes are fixed in the current cvs version, and they are
> harmless too.

Unfortunately, no, that's not fixed yet. I suspect the problem is the
three glGetIntegerv call slightly above that call, since they use
constants only defined in OpenGL 2.0.

[Stefan Dösinger]

Hello,
> Yes, without displaying the mouse and it's very slow (as if you were
> playing a game with direct rendering to No). But with dri, i have 1200fps
> and with ati 1900fps for common glxgears, there is a significative
> difference.

glxgears isn't a benchmark...
If you set 
Option      "AGPMode"         "4"
Option      "EnablePageFlip"  "1"
Option      "BackingStore"    "1"
in your device section of the dri driver, then the performance should be equal 
to fglrx(~2000 fps). If you install driconf and enable HyperZ, then you 
should get another boost. Alternatively, you can create a file /etc/drirc 
with the following content:
<driconf>
    <device screen="0" driver="r200">
        <application name="all">
            <option name="arb_vertex_program" value="true" />
            <option name="texture_level_hack" value="true" />
            <option name="hyperz" value="true" />
        </application>
    </device>
</driconf>

The first option enables software emulated vertex shaders, but I don't know if 
they work. The secound option enables a hack which increases the maximum 
texture size by a factor of 4 (1024x1024 -> 2048x2048) if you have the dxtn 
decompression libary installed. google for libtxc_dxtn050908.tar.gz, it 
should be the first entry. Installing this library enables compressed 
textures too, which can improve the performance drastically in some games 
which support it. The "hyperz" option enables hyperz, which also increases 
the performance, especially in glxgears. With all the options enabled, I get 
about 3670 fps in glxgears(Acer travelmate 803, 1.6 Ghz pentium M, radeon 
mobility 9000, Xorg 7.0 with the dri driver).
But again, glxgears isn't a benchmark. My experience is that the open source 
driver offers equal performance since Xorg 7.0, quite often it's faster, but 
only in unreal tournament 2004 it's significantly slower(general > 40fps, but 
sometimes only 15-20 fps, which makes ut unplayable. Surprisingly, this 
doesn't depend on the settings, so I think it's a driver bug)
> So, i have just reported them the problem and explain that it works with
> dri, so i hope they will make something to correct it....

Don't expect too much from at :( Just have a look at the linux driver forum at 
www.rage3d.com

Stefan

[BONNEL Christophe]

Stefan Dösinger a écrit :
> > So, i have just reported them the problem and explain that it works with
> > dri, so i hope they will make something to correct it....
>
> Don't expect too much from at :( Just have a look at the linux driver forum at 
> www.rage3d.com

I know that but if noone annoy them, they will never do anything ...

Thanks for the tips, I have tried with my debian sarge but all does not 
work because driconf is not available, but i have an unstable on an 
other partition, i will try later. With only the options in Xconfig 
file, i switch to 1700fps, thanks !!!

I use now wine.0.9.11 deb package and i have this repeating error (not a 
fixme) :
err:d3d:IWineD3DDeviceImpl_ActiveRender cannot get valides GLXFBConfig 
for (22,WINED3DFMT_X8R8G8B8)/(75,WINED3DFMT_D24S8)
It doesn't seem to modify anything with the game but is it important for 
you ? Does i do something as "winedebug=+ ***" for more information on 
this to help you ???

Note that the game is unplayable because it lags and lags and lags. I 
must wait 3 to 5 minutes before my character appears. And when i move, i 
see an image approximatively each second, it is jerky... I think it 
comes from the thing you said before : poor performance, but i prefer 
announce to others wine users what the results are now...

Christophe

[Stefan Dösinger]

Hi,
> Note that the game is unplayable because it lags and lags and lags. I
> must wait 3 to 5 minutes before my character appears. And when i move, i
> see an image approximatively each second, it is jerky... I think it
> comes from the thing you said before : poor performance, but i prefer
> announce to others wine users what the results are now...

I fixed the performance issue with radeon cards. The problem was that wined3d 
set the mipmap level count for textures every time they where used. This 
caused the driver to remove the textures from video memory, and they had to 
be re-transfered over the bus constantly.

The slowness in guild wars sounds unrelated too. Maybe guild wars locks the 
render target. This is more or less broken in WineD3D at the moment, and 
horribly slow on radeon cards.

Stefan