search

iXit / wine-nine-standalone

Build Gallium Nine support on top of an existing WINE installation
GNU Lesser General Public License v2.1
272 stars 23 forks source link

Videos in Serious Sam 2 aren't rendered correctly #39

Closed aufkrawall closed 3 years ago

aufkrawall commented 5 years ago

There is this corruption (doubled and wrong colors): Screenshot_20190527_133941 They look correct with wined3d.

axeldavy commented 5 years ago

Would it be possible to get a short trace of the issue with https://github.com/iXit/wine-nine-standalone/wiki/apitrace ? Thanks

aufkrawall commented 5 years ago

Here it is: Sam2.trace.zip I ran the game with Gallium Nine and not wined3d, hope that's not an issue.

axeldavy commented 5 years ago

Thanks, I'll investigate

axeldavy commented 3 years ago

Given the same issue happens with wined3d in the trace, I guess it is something with texture pitch or similar. Having the same trace with wine would be helpful.

dungeon007 commented 3 years ago

There is a demo of this: https://www.moddb.com/downloads/serious-sam-2-demo Seems about format conversion, from YUY2 to RGB888:: d3d:wined3d_check_device_format_conversion wined3d 0x1306a8, adapter_idx 0, device_type WINED3D_DEVICE_TYPE_HAL, src_format WINED3DFMT_YUY2, dst_format WINED3DFMT_B8G8R8X8_UNORM stub! https://en.wikipedia.org/wiki/YUV AFAIR YUY2 format was removed from hardware since ATi/AMD HD cards, so conversion is needed there on more recent ones.

dungeon007 commented 3 years ago

I guess this just works if somebody tries to play this on pre HD AMD card... i mean on r300 gallium driver, as there such conversion is not needed... well, i am not sure if nine even works on r300 in the first place. 🤣 But that is what i think this bug is about, it must be converted... otherwise wont play correctly on a HW without such format support.

dungeon007 commented 3 years ago

DXVK also play this correctly, likely do conversion there too... 🤣 https://github.com/doitsujin/dxvk/tree/master/src/d3d9/shaders

dungeon007 commented 3 years ago

"Given the same issue happens with wined3d in the trace, I guess it is something with texture pitch or similar. Having the same trace with wine would be helpful." Well, wined3d trace when replaying on nine just exits with 🤣 44 @0 IDirect3D9::CreateDevice(this = 0x135170, Adapter = D3DADAPTER_DEFAULT, DeviceType = D3DDEVTYPE_HAL, hFocusWindow = 0x1005a, BehaviorFlags = D3DCREATE_HARDWARE_VERTEXPROCESSING, pPresentationParameters = &{BackBufferWidth = 1024, BackBufferHeight = 768, BackBufferFormat = D3DFMT_X8R8G8B8, BackBufferCount = 1, MultiSampleType = D3DMULTISAMPLE_NONE, MultiSampleQuality = 0, SwapEffect = D3DSWAPEFFECT_DISCARD, hDeviceWindow = 0x1005a, Windowed = FALSE, EnableAutoDepthStencil = TRUE, AutoDepthStencilFormat = D3DFMT_D32, Flags = 0x0, FullScreen_RefreshRateInHz = 0, PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE}, ppReturnedDeviceInterface = &0x134e90) = D3D_OK 44: warning: failed with 0x8876086c (D3DERR_INVALIDCALL): Invalid call I guess you want some from Windows? 🤣

dungeon007 commented 3 years ago

He, he, seems Windows trace no one could replay as it picks D3DFMT_YUY2. 🤣 WINED3D and DXVK, when replaying just exits with: X Error of failed request: BadWindow (invalid Window parameter) NINE seems do something else, but still crashy... anyway, if interested to see crashes for yourself, both wined3d and windows traces here:

https://drive.google.com/file/d/1jcoTlhZDzAcBS0hWjZCXYRSXbIgdS3vY/view?usp=sharing

axeldavy commented 3 years ago

The formats can be emulated so I should be able to replay both traces.

axeldavy commented 3 years ago

If I emulate YUV2 I can run both traces fine.

Unfortunately it is a bit more complicated than that. On both windows and wined3d they advertise suppose for the format as surface but not texture. Probably for a good reason. Nine makes no difference between the two in terms of advertised format. I'll have to take a look.

dungeon007 commented 3 years ago

He, he, i hexed GfxD3D.dll and replaced all occurrences of YUY2 with RGBG or GRGB. 🤣 WINED3D looks the same as NINE if on RGBG or GRGB, doubled and wrong colors. Meanwhile, NINE is not doubled on these, just on YUY2. DXVK is never doubled. Colors are off with these on any WINED3D, NINE, DXVK of course, but at least could be a proof that scaling seems actually different on all these. Dont know why i mention this, but who knows it might help. 🤣

dungeon007 commented 3 years ago

I mean that was an brute force attack, just to show a difference 🤣 NINE seems opposite of WIND3D there, just a guess.... should formats ever turn into doubles, probably no?

dungeon007 commented 3 years ago

"Meanwhile, NINE is not doubled on these, just on YUY2." Not just, it is on YUY2 but also on UYVY, meanwhile on WINED3D these YUVs are scaled, but else arent - quite the opposite of NINE. 🤣 On DXVK, none is doubled UYVY, RGBG, YUY2, GRGB, DXT1, DXT2, DXT3, DXT4 and DXT5... anything that game supports is scaled correctly. On WINED3D, correct are only UYVY and YUY2, else doubled. On NINE, everything else scale correctly, besides UYVY and YUY2. 🤣

dungeon007 commented 3 years ago

On Windows, it scales and renders correctly there no matter what i hexed there on formats, unlike on Linux where seems NONE do that. So maybe, just return the same emulated thing for UYVY, RGBG, YUY2 and GRGB. 🤣