https://bugs.winehq.org/show_bug.cgi?id=39057
Bug ID: 39057 Summary: Support for Indexed Vertex Blending Product: Wine Version: 1.7.47 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: swswine@gmail.com Distribution: ---
Created attachment 52025 --> https://bugs.winehq.org/attachment.cgi?id=52025 Patch to implement indexed vertex blending support
Vertex blending support has been added recently (https://bugs.winehq.org/show_bug.cgi?id=6955 was closed). But indexed vertex blending is not supported yet.
I've implemented rather straightforward patch to do it which works for me, it is attached. Though I am far not familiar with wined3d development and not quite sure that my patch is complete and does not have any caveats.
A potential caveat with this patch is the following. Besides using indexes in vertex shaders, a big enough number of supported vertex blend matrices is required to really support this Direct3D feature. It was 4 in 1.7.47, I changed to 128 using the same framework developed in 1.7.47. It may potentially fail on some graphic cards due to large number of uniforms in vertex shader generated. Besides the transfer of those uniforms may probably be optimized not to call glUniformMatrix for every matrix when only one or few has changed.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends on| |6955
https://bugs.winehq.org/show_bug.cgi?id=39057
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #1 from super_man@post.com --- Do you have a test application for this?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #2 from Sebastian Lackner sebastian@fds-team.de --- Patch submissions are not accepted on bugzilla, to discuss your implementation I would suggest to ask for comments on the wine-devel mailing list: https://www.winehq.org/mailman/listinfo/wine-devel
When you think the implementation is good enough, you can also send it to the wine-patches mailing list, take a look here for additional guidelines regarding patch submission: http://wiki.winehq.org/SubmittingPatches
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #3 from swswine@gmail.com --- (In reply to super_man from comment #1)
Do you have a test application for this?
AFAIK it affects most of Illusion games (example WineHQ forum discussion: https://forum.winehq.org/viewtopic.php?f=8&t=24954)
I've tested it on one of those (AG3: https://appdb.winehq.org/objectManager.php?sClass=application&iId=7352).
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #4 from swswine@gmail.com --- (In reply to Sebastian Lackner from comment #2)
Patch submissions are not accepted on bugzilla, to discuss your implementation I would suggest to ask for comments on the wine-devel mailing list: https://www.winehq.org/mailman/listinfo/wine-devel
When you think the implementation is good enough, you can also send it to the wine-patches mailing list, take a look here for additional guidelines regarding patch submission: http://wiki.winehq.org/SubmittingPatches
Thank you for your comment. I realize that the patch won't be accepted from here. I actually just wanted to file a bug (as 6955 is already closed). I also wanted to put patch here for now if it is possible (like numerous patches for bug 6955 were attached for different wine versions previously). Maybe someone will test it first, or include into PlayOnLinux as a separate build.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=6955
https://bugs.winehq.org/show_bug.cgi?id=39057
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=39057
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=39057
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=39057
gamiljydcome@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gamiljydcome@gmail.com
--- Comment #5 from gamiljydcome@gmail.com --- Created attachment 52718 --> https://bugs.winehq.org/attachment.cgi?id=52718 strange shadow
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #6 from gamiljydcome@gmail.com --- Thanks for this patch i can test BattleRaper2, it almost working but still have problem, it shows some strange shadow when edit first role in the game. wine 1.5.28 with software vertex blending patch works fine without this problem. Maybe need to continue upgrade this patch.
My test environment: wine 1.7.54 OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset OpenGL version string: 2.1 Mesa 10.3.2 OpenGL shading language version string: 1.20
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52025|0 |1 is obsolete| | CC| |swswine@gmail.com
--- Comment #7 from swswine@gmail.com --- Created attachment 52722 --> https://bugs.winehq.org/attachment.cgi?id=52722 Patch to implement indexed vertex blending support (wine 1.7.54)
I've updated the patch for wine 1.7.54 and further increased the number of world matrices. Hope that helps.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.7.47 |1.7.54
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #8 from gamiljydcome@gmail.com --- It's working after apply new patch for wine 1.7.54. nice work!
https://bugs.winehq.org/show_bug.cgi?id=39057
Sergey Isakov isakov-sl@bk.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isakov-sl@bk.ru
--- Comment #9 from Sergey Isakov isakov-sl@bk.ru --- Bug 38326 resolved with this patch. Thank you!
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #10 from Sergey Isakov isakov-sl@bk.ru --- *** Bug 38326 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #11 from swswine@gmail.com --- Bug 38326 looks unrelated to this patch, seems like nothing in this patch that could help with shader compile warnings listed there. Perhaps something else has also changed between your 3DMark tests. I've run 3DMark03 with stock wine 1.7.53 without any custom patches (with -nosysteminfo option, without which it does not work due to some COM related issues). It worked for me without any problems or warnings like yours.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #12 from Matteo Bruni matteo.mystral@gmail.com --- I thought I had already commented here but apparently that's not the case :/
Not going into the details of the patch, the main issue here is that, on Windows, indexed vertex blending is only supported with software vertex processing - MaxVertexBlendMatrixIndex is 0 for hardware devices and 255 for software devices on all the boxes I tested. So this feature should be only exposed for software vertex processing but at the moment wined3d ignores that flag entirely. That should be fixed, in some measure, before implementing indexed vertex blending.
It's probably okay to think about implementing software VP and indexed vertex blending with GLSL. There's the issue you encountered with the large amount of uniforms needed. I think requiring and using uniform buffer objects for that is the way forward.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #13 from swswine@gmail.com --- Thank you very much for clarification.
I will get back to this and try implementing this patch through uniform buffer objects within a couple of weeks when I have more time.
Regarding software & H/W vertex processing, the games I've seen using indexed vertex blending (IVB) had configuration option to choose between software and hardware vertex processing, but IVB was used in both modes. I had MaxVertexBlendMatrixIndex constantly set to 0 initially in my patched wined3d (updated this field setting in the patch later), this was ignored by these games, they used as much VB matrices they wanted without any error. So is it possible that at least some (or many) Windows drivers advertise 0 matrices in H/W mode but actually support up to 256 if requested? If yes, should not wine d3dx9 just do the same: just support IVB with 256 matrices in H/W mode (and in software mode when it is in place) but advertise 0 in H/W mode (or let this value to be configured)?
BTW I came across similar issue with number of supported uniforms in HLSL shader. DX9 advertises max of 256 uniforms. I came through some games failing to compile HLSL vertex shader under wine due to excessive number of uniforms they were trying to use. I worked that around by simply increasing the constant for max number of uniforms in wine d3d9, it worked. Apparently these games work on Windows which means that Windows drivers do support bigger number of uniforms per HLSL shader while advertising 256. Should not wine do the same: advertise 256 but allow up to the limit actually supported by underlying GL driver?
https://bugs.winehq.org/show_bug.cgi?id=39057
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #14 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to swswine from comment #13)
Thank you very much for clarification.
I will get back to this and try implementing this patch through uniform buffer objects within a couple of weeks when I have more time.
Regarding software & H/W vertex processing, the games I've seen using indexed vertex blending (IVB) had configuration option to choose between software and hardware vertex processing, but IVB was used in both modes. I had MaxVertexBlendMatrixIndex constantly set to 0 initially in my patched wined3d (updated this field setting in the patch later), this was ignored by these games, they used as much VB matrices they wanted without any error. So is it possible that at least some (or many) Windows drivers advertise 0 matrices in H/W mode but actually support up to 256 if requested? If yes, should not wine d3dx9 just do the same: just support IVB with 256 matrices in H/W mode (and in software mode when it is in place) but advertise 0 in H/W mode (or let this value to be configured)?
If that's the case, yes. Notice that the game might create the device with D3DCREATE_MIXED_VERTEXPROCESSING when the "hardware" mode is selected (you can check that from a +d3d9 trace). Ultimately this needs tests to figure out what exactly is supported in every vertex processing mode.
BTW I came across similar issue with number of supported uniforms in HLSL shader. DX9 advertises max of 256 uniforms. I came through some games failing to compile HLSL vertex shader under wine due to excessive number of uniforms they were trying to use. I worked that around by simply increasing the constant for max number of uniforms in wine d3d9, it worked. Apparently these games work on Windows which means that Windows drivers do support bigger number of uniforms per HLSL shader while advertising 256. Should not wine do the same: advertise 256 but allow up to the limit actually supported by underlying GL driver?
That should only happen with the so-called "software vertex shaders" i.e. https://msdn.microsoft.com/en-us/library/windows/desktop/bb147365%28v=vs.85%... , which AFAIK are also only supported with SOFTWARE or MIXED vertex processing. I think those should also be implemented via GLSL + UBOs but that's probably quite a bit harder than the related fixed function stuff (i.e. indexed vertex blending) in current wined3d.
Notice that I don't want to discourage you (far from it ;) and your work on this is very much appreciated.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #15 from swswine@gmail.com --- Created attachment 52746 --> https://bugs.winehq.org/attachment.cgi?id=52746 Patch to implement index version support (using UBO, wine 1.7.55)
I updated the patch to use UBOs to transfer blend matrices, and now all 256 possible matrices are supported. The patch is for wine release 1.7.55.
Vertex blending without indices also use UBO with this patch. The patch is still not optimal in a sense that there are much of extra updates of the buffer with all the 256 matrices on any transform matrix change or view matrix change (and even for every shader which is redundant as UBO is common for all shaders). But this is in place only if vertex blending is actually requested by application. If not, UBO is not created (and '#extension GL_ARB_uniform_buffer_object' is not added), and glsl shader is even simplified a bit compared to current release version. So I hope this patch should not introduce any regression for the applications not using vertex blending.
Neater solution on matrix update is of course possible but requires getting deeper into glsl pipeline update logic.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.7.54 |1.7.55
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52746|0 |1 is obsolete| |
--- Comment #16 from swswine@gmail.com --- Created attachment 52747 --> https://bugs.winehq.org/attachment.cgi?id=52747 Patch to implement indexed vertex blending support (using UBO, wine 1.7.55)
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #17 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to swswine from comment #15)
Created attachment 52746 [details] Patch to implement index version support (using UBO, wine 1.7.55)
In principle it seems okay, although the first thing to do is to test the various things I mentioned in my previous post. You could write a d3d9 test checking for the value of MaxVertexBlendMatrixIndex for devices created with the different D3DCREATE_*_VERTEXPROCESSING values. This also needs a test for the actual indexing vertex blending functionality. It should be easy to create one by copying and modifying test_vertex_blending() in d3d9/tests/visual.c.
Vertex blending without indices also use UBO with this patch.
That's probably not okay, it would mean losing non-indexed vertex blending support if the driver / GPU doesn't support UBOs. It's not the most critical issue here though.
The patch is still not optimal
Yeah, it will have to be made somewhat smarter with not uploading all the data every time.
A few more things from a quick look. You shouldn't report indexed vertex blending when the ARB_uniform_buffer_object extension isn't around (or for hardware vertex processing, unless the tests disagree). You shouldn't change MAX_VERTEX_BLENDS but create a separate define: MaxVertexBlendMatrices is 4 even for software devices. And please, try to fix formatting and indentation.
BTW, I strongly suggest you to setup a Wine git repository clone and base your work on it. You'll find it much easier to maintain your patches as Wine changes, generate diffs etc.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #18 from swswine@gmail.com --- (In reply to Matteo Bruni from comment #17) Thank you for the review. I will follow your recommendations and hopefully will come up with production level patch eventually. Everything is clear and doable by me except for the following:
In principle it seems okay, although the first thing to do is to test the various things I mentioned in my previous post. You could write a d3d9 test checking for the value of MaxVertexBlendMatrixIndex for devices created with the different D3DCREATE_*_VERTEXPROCESSING values.
I do not have Windows in place and much of various GPU hardware. Do you know some realistic way to check native DirectX responses without Windows? Is it some place to post d3d9 test so that someone will run it and send responses?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #19 from gamiljydcome@gmail.com --- (In reply to swswine from comment #16)
Created attachment 52747 [details] Patch to implement indexed vertex blending support (using UBO, wine 1.7.55)
Hi swswine.
I applied this patch for wine 1.7.55. then test the game battleraper2 crash when it start. Could you review the error log? It seem calling shader_glsl_select cause crash.
---------------------------------- err:dmloader:IDirectMusicLoaderImpl_SetObject : could not attach stream to file fixme:dmime:IDirectMusicPerformance8Impl_InitAudio (0x1d5a4b8, (nil), 0x6efebc, 0x1004a, 1, 64, 3f, (nil)): to check fixme:dmime:IDirectMusicPerformance8Impl_Init (iface = 0x1d5a4b8, dmusic = (nil), dsound = 0x1d5a8b4, hwnd = 0x1004a) fixme:dmime:IDirectMusicPerformance8Impl_CreateStandardAudioPath (0x1d5a4b8)->(1, 64, 0, 0x1d5a684): semi-stub fixme:dmime:IDirectMusicAudioPathImpl_Activate (0x1d7c9b8, 0): stub fixme:dmime:IDirectMusicPerformance8Impl_GetDefaultAudioPath (0x1d5a4b8, 0x6efed0): semi-stub (0x1d7c9b8) err:quartz:GetClassMediaFile Media class not found fixme:d3d:wined3d_device_set_software_vertex_processing device 0x1c5ef0, software 0 stub! wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00000000 ESP:0032f4cc EBP:0032f548 EFLAGS:00210246( R- -- I Z- -P- ) EAX:01da4c80 EBX:7ebd8b30 ECX:00000000 EDX:7eb99a6f ESI:01da4c80 EDI:001bf5d0 Stack dump: 0x0032f4cc: 7eb058b2 00000006 0015c5e0 0000000f 0x0032f4dc: 7eb16f5c 001bf5d0 00000006 00000001 0x0032f4ec: 00127ec4 00000002 7d0a11b4 7d6958a4 0x0032f4fc: 7d45e16f 7cf942d4 7d0a11b4 0032f514 0x0032f50c: 7d359d7d 7ebdc659 00127eb0 7d45e04b 0x0032f51c: 00000000 01d9bdec 7eb99a48 001bf5d0 Backtrace: =>0 0x00000000 (0x0032f548) 1 0x7eb18f22 shader_glsl_select+0x1ba1() in wined3d (0x0032f668) 2 0x7eadfc45 context_apply_draw_state+0xf84() in wined3d (0x0032f6d8) 3 0x7eb0066c draw_primitive+0x1eb() in wined3d (0x0032f928) 4 0x7eae12d3 wined3d_cs_exec_draw+0x22() in wined3d (0x0032f958) 5 0x7eae0596 wined3d_cs_st_submit+0x25() in wined3d (0x0032f978) 6 0x7eae14dd wined3d_cs_emit_draw+0x3c() in wined3d (0x0032f998) 7 0x7eaf1615 wined3d_device_draw_indexed_primitive+0x74() in wined3d (0x0032f9e8) 8 0x7ebf7804 d3d9_device_DrawIndexedPrimitive+0xb3() in d3d9 (0x0032fa38) 9 0x004da2a2 in battleraper2 (+0xda2a1) (0x0032fb20) 10 0x004db4f3 in battleraper2 (+0xdb4f2) (0x0032fc9c) 11 0x004daca6 in battleraper2 (+0xdaca5) (0x0032fcb0) 12 0x004017cd in battleraper2 (+0x17cc) (0x0032fcdc) 13 0x004063fd in battleraper2 (+0x63fc) (0x0032fd38) 14 0x0059b913 in battleraper2 (+0x19b912) (0x0032fe60) 15 0x7b85bfec call_process_entry+0xb() in kernel32 (0x0032fe78) 16 0x7b85cf7a start_process+0x59() in kernel32 (0x0032fea8) 17 0x7bc7a7c0 call_thread_func_wrapper+0xb() in ntdll (0x0032fec8) 18 0x7bc7d581 call_thread_func+0xb0() in ntdll (0x0032ffa8) 19 0x7bc7a79e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 20 0x7bc50cc7 start_process+0x16() in ntdll (0x0032ffe8) 21 0xf76211bd wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 22 0xf7621320 wine_switch_to_stack+0x1f() in libwine.so.1 (0xffdaa748) 23 0x7bc567e5 LdrInitializeThunk+0x1f4() in ntdll (0xffdaa788) 24 0x7b862d43 __wine_kernel_init+0x9b2() in kernel32 (0xffdab678) 25 0x7bc575a3 __wine_process_init+0x152() in ntdll (0xffdab6e8) 26 0xf761ee33 wine_init+0x292() in libwine.so.1 (0xffdab738) 27 0x7bf00d6a main+0x79() in <wine-loader> (0xffdabb78) 28 0xf7455a63 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x00000000: -- no code accessible -- Modules: Module Address Debug info Name (119 modules) PE 400000- 845000 Export battleraper2 ELF 7a800000-7a92d000 Deferred opengl32<elf> -PE 7a820000-7a92d000 \ opengl32 ELF 7b800000-7ba61000 Dwarf kernel32<elf> -PE 7b810000-7ba61000 \ kernel32 ELF 7bc00000-7bce9000 Dwarf ntdll<elf>
(In reply to swswine from comment #15)
Created attachment 52746 [details] Patch to implement index version support (using UBO, wine 1.7.55)
I updated the patch to use UBOs to transfer blend matrices, and now all 256 possible matrices are supported. The patch is for wine release 1.7.55.
Vertex blending without indices also use UBO with this patch. The patch is still not optimal in a sense that there are much of extra updates of the buffer with all the 256 matrices on any transform matrix change or view matrix change (and even for every shader which is redundant as UBO is common for all shaders). But this is in place only if vertex blending is actually requested by application. If not, UBO is not created (and '#extension GL_ARB_uniform_buffer_object' is not added), and glsl shader is even simplified a bit compared to current release version. So I hope this patch should not introduce any regression for the applications not using vertex blending.
Neater solution on matrix update is of course possible but requires getting deeper into glsl pipeline update logic.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #20 from swswine@gmail.com --- (In reply to gamiljydcome from comment #19)
(In reply to swswine from comment #16)
Created attachment 52747 [details] Patch to implement indexed vertex blending support (using UBO, wine 1.7.55)
Hi swswine.
I applied this patch for wine 1.7.55. then test the game battleraper2 crash when it start. Could you review the error log? It seem calling shader_glsl_select cause crash.
Did you check that the game starts without the crash if using wine 1.7.55 (released) without this patch built and installed the same way? If yes, could you please run the game crashing with patch with WINEDEBUG=+d3d,+d3d_shader,+winedebug and attach gzipped output (it should produce a lot of output)?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #21 from gamiljydcome@gmail.com --- Created attachment 52753 --> https://bugs.winehq.org/attachment.cgi?id=52753 WINEDEBUG=+d3d,+d3d_shader,+winedebug error log
This is winedebug log, Please review it.
Original wine 1.7.55 can run this game without any crash, broken 3d model of course.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #22 from swswine@gmail.com --- (In reply to gamiljydcome from comment #21)
Created attachment 52753 [details] WINEDEBUG=+d3d,+d3d_shader,+winedebug error log
This is winedebug log, Please review it.
Original wine 1.7.55 can run this game without any crash, broken 3d model of course.
I see... Your Mesa driver 10.3.2 supports GL 2.1, while GL 3.1 is required to support UBOs. The crash in this situation is a bug in the patch (a function from GL 3.1 specification is called unconditionally which apparently results in NULL pointer call if not supported). I will fix it later to do something more reasonable in such a case along with the other improvements. But this won't help you in your current configuration: it will still not work.
So you can do one of the following: 1. Upgrade Mesa drivers to some later version which supports at least OpenGL 3.1 2. Stay with wine 1.7.54 with my previous patch for running this game
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #23 from gamiljydcome@gmail.com ---
So you can do one of the following:
- Upgrade Mesa drivers to some later version which supports at least OpenGL
3.1 2. Stay with wine 1.7.54 with my previous patch for running this game
My video card (mobile intel gm45) HW just support GL2.1, so i keep using the patch for wine 1.7.54, and expect you will continue working on new patch.
Thanks.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #24 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to swswine from comment #18)
I do not have Windows in place and much of various GPU hardware. Do you know some realistic way to check native DirectX responses without Windows? Is it some place to post d3d9 test so that someone will run it and send responses?
There is testbot.winehq.org but that's unfortunately not too helpful with d3d stuff since it only has the software-emulated WARP device (that's in the Win8 and Win10 VMs) which is in general not a good reference for Windows behavior.
I guess you can post your test here, on the wine-devel mailing list or on #winehackers and someone will hopefully run the test for you...
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #25 from Sergey Isakov isakov-sl@bk.ru --- (In reply to swswine from comment #22)
- Stay with wine 1.7.54 with my previous patch for running this game
No problem to rebase this patch for 1.7.55
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #26 from Sergey Isakov isakov-sl@bk.ru --- Created attachment 52787 --> https://bugs.winehq.org/attachment.cgi?id=52787 Same patch rebased to wine-1.7.55-38
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #27 from swswine@gmail.com --- (In reply to Matteo Bruni from comment #24)
There is testbot.winehq.org but that's unfortunately not too helpful with d3d stuff since it only has the software-emulated WARP device (that's in the Win8 and Win10 VMs) which is in general not a good reference for Windows behavior.
I guess you can post your test here, on the wine-devel mailing list or on #winehackers and someone will hopefully run the test for you...
I have updated dlls/d3d9/tests/visual.c to support indexed vertex blending testing and to print MaxVertexBlendMatrices and MaxVertexBlendMatrixIndex caps. The test is performed for each relevant device creation flag: D3DCREATE_HARDWARE_VERTEXPROCESSING, D3DCREATE_SOFTWARE_VERTEXPROCESSING and D3DCREATE_MIXED_VERTEXPROCESSING. The test is run regardless the MaxVertexBlendMatrixIndex caps to see if indexed vertex blending is actually working or not even if caps suggests it should not. I am adding attachments with patch and with Windows .exe (compiled with 'make crosstest'). The patch also comments out all the other visual tests so it is quicker to run for its purpose. I hope someone can run it on some real Windows machines (not under virtual machines) and send me the full output.
Apart from this I studied MSDN docs for indexed vertex blending. It suggests that 256 matrices can always be used in case of software vertex processing, and implicitly suggests that it is up to hardware (driver) otherwise, and MaxVertexBlendMatrixIndex should be checked (see here, for instance: https://msdn.microsoft.com/en-us/library/windows/desktop/bb206316(v=vs.85).a... ; Determining Indexed Vertex Blending Support paragraph). Maybe I can just set MaxVertexBlendMatrixIndex to 255 regardless of vertex processing mode?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #28 from swswine@gmail.com --- Created attachment 52803 --> https://bugs.winehq.org/attachment.cgi?id=52803 Test to run on Windows machine to verify indexed vertex blending native behaviour
To be run as 'd3d9_crosstest.exe visual'
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #29 from swswine@gmail.com --- Created attachment 52804 --> https://bugs.winehq.org/attachment.cgi?id=52804 IVB test added to d3d9/tests/visual.
This patch was used to build https://bugs.winehq.org/attachment.cgi?id=52803&action=edit Other tests are commented out.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #30 from Sergey Isakov isakov-sl@bk.ru --- Created attachment 52807 --> https://bugs.winehq.org/attachment.cgi?id=52807 Output test visual in Windows 7 X64, Nvidia 9600GT
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #31 from gamiljydcome@gmail.com --- Created attachment 52810 --> https://bugs.winehq.org/attachment.cgi?id=52810 visual.exe test win7 32bit, mobile Intel GM45
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #32 from Sergey Isakov isakov-sl@bk.ru --- Created attachment 52812 --> https://bugs.winehq.org/attachment.cgi?id=52812 There is broken image if no index blending support
Just making the patch for 1.7.54 I have good image.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52722|0 |1 is obsolete| | Attachment #52747|0 |1 is obsolete| |
--- Comment #33 from swswine@gmail.com --- Created attachment 52816 --> https://bugs.winehq.org/attachment.cgi?id=52816 Patch to implement indexed vertex blending (updated), wine 1.8-rc1
I updated the patch. The changes are:
1. Reporting capabilities MaxVertexBlendMatrices is always 4. MaxVertexBlendMatrixIndex is 255 if ARB_UNIFORM_BUFFER is supported, 0 otherwise.
2. Actual IVB support If ARB_UNIFORM_BUFFER is supported (opengl 3.1+), UBOs are used to store matrices for IVB. UBO is declared in shader and created only if IVB is requested by application. If ARB_UNIFORM_BUFFER is not supported, it still tries to support IVB if actually requested by application. In this case (and only in this) it works the same way as my initial patch by transferring matrices through plain uniforms. It does not affect vertex blending without indexes (only 4 matrices is declared if IVB is not requested by SetRenderState(... D3DRS_INDEXEDVERTEXBLENDENABLE). The existing functionality should not be affected so far.
3. Finer uniforms update granularity Patch adds mask to context which gets bits indicating which world matrices were updated. Besides, the "update version" number is stored for these updates. When processing uniforms updates for shader the mask is checked: only changed matrices are updated. This also relates to vertex blending without indexes.
UBO is updated only if the update version in context was not processed yet (this eliminates redundant updates of UBO when processing uniform updates for multiple shaders). Maybe it would be more straightforward to link UBO update to some other place rather than glsl shader backend, but till now I did not find a better place with relevant update infrastructure.
While this reduces some of redundant updates, there is still quite a lot of them as shader gets view*model matrices. So when view matrix is updated all the matrices have to be updated also. This cannot be reduced any further if not to move raw model matrices into the shader instead of view*model. But I think it is not a good idea for general case as there will be extra mat4*vec4 multiplication in shader for every vertex in IVB.
If IVB is not requested by application then no UBO or extra matrices are defined or transferred.
4. Conformance test for IVB was added. It tests IVB support in 3 modes (software, hardware and mixed vertex processing). If MaxVertexBlendMatrixIndex < 7 or MaxVertexBlendMatrices < 4 then the test for the mode is skipped.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.7.55 |1.8-rc1
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #34 from gamiljydcome@gmail.com --- Created attachment 52819 --> https://bugs.winehq.org/attachment.cgi?id=52819 error rendering 3d model not broken with patch for wine 1.8rc1
I've test new patch for wine 1.8rc1. With card support GL3 (mobile firegl v5700) it works fine. With card only support GL2.1 (mobile intel gm45) it looks strange as screenshot posted.
So this new patch has some bug for non-ubo maybe.
besides, I tried modify patch for wine 1.55, replace ubo to vao/vbo(that's supported by GL2.1/glsl1.2), but got totally wrong renderring so i give it up. Could you have a try if you interested?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #35 from swswine@gmail.com --- (In reply to gamiljydcome from comment #34)
Created attachment 52819 [details] With card only support GL2.1 (mobile intel gm45) it looks strange as screenshot posted.
Could you please reproduce this with WINEDEBUG=+d3d,+d3d_shader,+d3d9 and attach a gripped output?
Which game is it?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #36 from gamiljydcome@gmail.com --- Created attachment 52829 --> https://bugs.winehq.org/attachment.cgi?id=52829 WINEDEBUG=+d3d,+d3d_shader,+d3d9 trace log, ~400M uncompressed
The game SexyBeach3(plus) runs ok by patch for wine 1.7.54 too. So new patch has some bugs with non-ubo.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52816|0 |1 is obsolete| |
--- Comment #37 from swswine@gmail.com --- Created attachment 52830 --> https://bugs.winehq.org/attachment.cgi?id=52830 Patch to implement indexed vertex blending (updated), wine 1.8-rc1
(In reply to gamiljydcome from comment #36)
The game SexyBeach3(plus) runs ok by patch for wine 1.7.54 too. So new patch has some bugs with non-ubo.
I found bug for the case when ARB_UNIFORM_BUFFER_OBJECT is not supported. Could you please try with the updated patch?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #38 from gamiljydcome@gmail.com --- Created attachment 52835 --> https://bugs.winehq.org/attachment.cgi?id=52835 wrong renderring screenshot but not sure because of vertex blend
I found bug for the case when ARB_UNIFORM_BUFFER_OBJECT is not supported. Could you please try with the updated patch?
The bug fixed, nice work!
At least for now, i tested new patch for wine 1.8rc1: Radeon firegl v5700(GL3.3) Intel GM45(GL2.1)
BattleRaper2: works fine (ubo, non-ubo) SexyBeach3: works fine (ubo, non-ubo) schoolmate2: not working (ubo, non-ubo both)
I'm not sure schoolmate2's problem really caused by vertex blending although the game enabled it. Could you review the trace log?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #39 from gamiljydcome@gmail.com --- Created attachment 52836 --> https://bugs.winehq.org/attachment.cgi?id=52836 WINEDEBUG=+d3d,+d3d_shader,+d3d9 wrong renderring trace log, ~410M
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #40 from swswine@gmail.com --- (In reply to gamiljydcome from comment #39)
Created attachment 52836 [details] WINEDEBUG=+d3d,+d3d_shader,+d3d9 wrong renderring trace log, ~410M
I think this is likely not related to IVB. This game uses excessive number of HLSL shader constants (there was a discussion of this also in this bug comments above):
warn:d3d_shader:shader_record_register_usage Shader using float constant 771 which is not supported.
I suggest you open a separate bug for this (I would call it something like "Support bigger number of shader constants") and put log and maybe screenshot there.
If you send me the link to this bug I will upload quite a different (and small) patch tomorrow that fixes similar problems for me in a quick and dirty way. Then maybe I will be enhancing it somehow. A quick and dirty way that works is just increase constant limits (it is 256, while your card supports at least 1024).
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #41 from gamiljydcome@gmail.com ---
I think this is likely not related to IVB. This game uses excessive number of HLSL shader constants (there was a discussion of this also in this bug comments above):
warn:d3d_shader:shader_record_register_usage Shader using float constant 771 which is not supported.
I've reported this bug? (sort of not be i think). Please see https://bugs.winehq.org/show_bug.cgi?id=39578
The big float constants warning shows in BattleRaper2 trace log too such as c771,c890 etc, but it's tested ok as you know.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #42 from swswine@gmail.com --- Created attachment 52845 --> https://bugs.winehq.org/attachment.cgi?id=52845 Temp fix: constants number increase for testing purposes
(In reply to gamiljydcome from comment #41)
I've reported this bug? (sort of not be i think). Please see https://bugs.winehq.org/show_bug.cgi?id=39578
The big float constants warning shows in BattleRaper2 trace log too such as c771,c890 etc, but it's tested ok as you know.
Still I think the reason I suggest is possible. Look at this comment here: https://bugs.winehq.org/show_bug.cgi?id=8051#c118
I am attaching temporary patch here (just for testing purposes) which does the same (but actually there is yet another place in the code to increase the constants to make it work), and adds some debug warnings which are not related actually to the case. Can you test with this patch applied on top of my latest IVB patch? I did not see this game but I know this fixes some other Illusion games, AA2 for instance. If this won't help, I will dig further.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #43 from gamiljydcome@gmail.com ---
I am attaching temporary patch here (just for testing purposes) which does the same (but actually there is yet another place in the code to increase the constants to make it work), and adds some debug warnings which are not related actually to the case. Can you test with this patch applied on top of my latest IVB patch? I did not see this game but I know this fixes some other Illusion games, AA2 for instance. If this won't help, I will dig further.
Nice, new patch is work!
swswine. to keep this bug post focus on IVB patch, could you please view https://bugs.winehq.org/show_bug.cgi?id=39578? I have a little questions. Thank.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #44 from Sergey Isakov isakov-sl@bk.ru --- My test is also successful. Image is no more broken.
Just for info there are many repeated messages --- fixme:d3d:resource_check_usage Unhandled usage flags 0x10. fixme:d3d:resource_check_usage Unhandled usage flags 0x10. fixme:d3d:resource_check_usage Unhandled usage flags 0x10. --- It means #define WINED3DUSAGE_SOFTWAREPROCESSING 0x00000010
May be with this patch we should mark that SOFTWAREPROCESSING is handled?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #45 from swswine@gmail.com --- (In reply to Sergey Isakov from comment #44)
#define WINED3DUSAGE_SOFTWAREPROCESSING 0x00000010
May be with this patch we should mark that SOFTWAREPROCESSING is handled?
No. I think it is really difficult discussing software/hardware processing without going deeper into DirectX architecture and its implementation in Wine (I am in fact not an DirectX or wined3d expert either). And software processing flags affect really nothing in Wine currently (maybe except for some debug messages).
Actually software or hardware processing is just a sort of hint which application sets to DirectX. This hint affects some feature availability and their limits in DirectX though (e. g., number of matrix indices supported for IVB). Applications are not directly affected by supporting or not supporting actual processing of vertexes and shaders on CPU (software) rather than on GPU in wine. They are affected by the limits explicitly set or imposed by implementation, e. g. number of supported constants in shaders.
Please see Comment #12 here by Matteo. Software vertex processing in an exact meaning of this is not in Wine and is not going to appear there soon. What I am trying to do here is to implement (some of) software vertex processing features with GLSL (which is analogous of native directx "hardware" processing). Though as we know now IVB is supported in hardware processing also in native Wine with less number of indexes allowed (thank you and gamiljydcome@gmail.com for running my test).
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #46 from Sergey Isakov isakov-sl@bk.ru --- a question Why matrix-template differs from 150+? --- + {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(148)), {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(148)), glsl_vertex_pipe_vertexblend }, WINED3D_GL_EXT_NONE }, + {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(149)), {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(149)), glsl_vertex_pipe_vertexblend }, WINED3D_GL_EXT_NONE }, + {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(150)), {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(150)), glsl_vertex_pipe_vertexblend }, ARB_UNIFORM_BUFFER_OBJECT}, + {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(151)), {STATE_TRANSFORM(WINED3D_TS_WORLD_MATRIX(151)), glsl_vertex_pipe_vertexblend }, ARB_UNIFORM_BUFFER_OBJECT}, ---- WINED3D_GL_EXT_NONE <-> ARB_UNIFORM_BUFFER_OBJECT What is the count=150?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #47 from swswine@gmail.com --- (In reply to Sergey Isakov from comment #46)
WINED3D_GL_EXT_NONE <-> ARB_UNIFORM_BUFFER_OBJECT What is the count=150?
matrices 151-255 are available only if ARB_UNIFORM_BUFFER_OBJECT GL extension is supported (see constants in wined3d_private.h). Structure initialization is messy, but I followed the style that was already in there.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #48 from Sergey Isakov isakov-sl@bk.ru --- It weird. The matrix should be created dynamically.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #49 from gamiljydcome@gmail.com --- Hi swswine .
I'm retrying to add vao/vbo support to your IVB patch that ext feature GL2.1/glsl1.2 supported. The problem is howto make glsl var "uniform mat4 ffp_modelview_matrix[256]" communicate with vao/vbo. i was tried to redefine "attribute mat4 ffp_modelview_matrix[256]" but glsl1.2 don't support attribute array, must above glsl1.5.
So is there anyway change glsl code to make "uniform ffp_modelview_matrix[256]" could communicate with vao/vbo or it's not possible?
Thanks.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #50 from swswine@gmail.com --- (In reply to gamiljydcome from comment #49)
So is there anyway change glsl code to make "uniform ffp_modelview_matrix[256]" could communicate with vao/vbo or it's not possible?
It is clearly not possible. "V" in VAO/VBO stands for Vertex. OpenGL < 3.1 can use buffers for per vertex data and not for uniforms (which stand for the values used by shaders which are common for all vertexes). The meaning of ARB_UNIFORM_BUFFER_OBJECT extension is to allow buffers to be used for uniforms. No such extension, no buffers for uniforms: just plain uniforms with accompanying limits. Those limits are not as bad as 256 though, even for your rather old card it is 4096 as we found out.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #51 from gamiljydcome@gmail.com ---
It is clearly not possible.
Fine, i give up.
Thanks.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #52 from Sergey Isakov isakov-sl@bk.ru --- I also want to say that d3dx9_36_test visual affected by this bug. It is too fast to see something but if set pauses the we can catch broken geometry.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #53 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Sergey Isakov from comment #52)
I also want to say that d3dx9_36_test visual affected by this bug. It is too fast to see something but if set pauses the we can catch broken geometry.
Sorry, d3d9_test visual As well there are log messages as noticed in bug 38326. It seems to be MacOSX specific bug.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #54 from Matteo Bruni matteo.mystral@gmail.com --- Created attachment 52920 --> https://bugs.winehq.org/attachment.cgi?id=52920 Test output on a Radeon HD 2600
I'm attaching the output of your test on my Windows XP + Radeon HD 2600. I also ran the test on Windows 7 + Nvidia GTX 970 and that matches the previous test results you got here (i.e. MaxVertexBlendMatrixIndex=8 for hardware / mixed vertex processing).
About the patch: cool stuff. Not going into the details, again, but here are some more high-level comments. Ah, BTW, these are my opinions, Henri (aka the wined3d maintainer) might disagree...
I would probably drop indexed vertex blending with plain uniforms altogether, it looks too messy and e.g. allocating extra ~1KB for modelview_matrix_location[] for each GLSL shader doesn't seem justifiable. You should probably add a separate field in d3d_info.limits for the indexed limit (and avoid touching ffp_vertex_blend_matrices) and use it where necessary. You should also report 0 (or 8, but since there is real hardware on Windows returning 0 that is okay) indexed vertex blending matrices for devices not created with the D3DCREATE_SOFTWARE_VERTEXPROCESSING flag (I think you can look that up from device->create_parms.flags). I don't think you need a static variable (or a variable at all) to store the next update_id value, unless I'm missing something.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52830|0 |1 is obsolete| |
--- Comment #55 from swswine@gmail.com --- Created attachment 52947 --> https://bugs.winehq.org/attachment.cgi?id=52947 Patch to implement indexed vertex blending (updated), wine 1.8-rc2
(In reply to Matteo Bruni from comment #54)
I would probably drop indexed vertex blending with plain uniforms altogether, it looks too messy and e.g. allocating extra ~1KB for modelview_matrix_location[] for each GLSL shader doesn't seem justifiable.
I am not comfortable dropping it because the only person who actively tests my patch here is keen of running it under GL 2.1 :)). IVB might be used by old games working fine on old hardware, should not we attempt to support it? Actually I set only 150 matrices if no UBO, so it just 600 bytes. It can be further reduced by making it dynamic, so the space will be allocated only for the shaders which actually use IVB (if it is not too messy for these 600 bytes). It seemed to me that the most messy part is selective matrix update logic which is currently more tricky for the UBO part. But if you are sure that it is better to drop non-UBO support than I will of course drop it.
You should probably add a separate field in d3d_info.limits for the indexed limit (and avoid touching ffp_vertex_blend_matrices) and use it where necessary. You should also report 0 (or 8, but since there is real hardware on Windows returning 0 that is okay) indexed vertex blending matrices for devices not created with the D3DCREATE_SOFTWARE_VERTEXPROCESSING flag (I think you can look that up from device->create_parms.flags).
done. Considering D3DCREATE_SOFTWARE_VERTEXPROCESSING flag looks a bit messy as done outside the function where all the caps are filled in, but this function (wined3d_get_device_caps in directx.c) does not have access to device structure and thus can't get that flag. Changing its parameters is tricky as it is exported function and changing it will require fixing it's call across the tree. I've verified that the wined3d_device_get_device_caps in wined3d/device.c actually used in d3d9 GetDeviceCaps implementation, and tested that reported capabilities are those we expect.
I don't think you need a static variable (or a variable at all) to store the next update_id value, unless I'm missing something.
I've changed this part now: I figured out now how to get a link to a shader priv structure from the context update handler and replaced transform context update versioning with just a plain flag in shader_priv structure.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.8-rc1 |1.8-rc2
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52947|0 |1 is obsolete| |
--- Comment #56 from swswine@gmail.com --- Created attachment 52951 --> https://bugs.winehq.org/attachment.cgi?id=52951 Patch to implement indexed vertex blending (updated), wine 1.8-rc2
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #57 from gamiljydcome@gmail.com --- New patch works fine with my intel/radeon card.
So after more testing and bug checking sould make this patch merge into mainline?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #58 from Sergey Isakov isakov-sl@bk.ru --- I am very sorry for the bad news but there is something i didn't understand. See bug 39674. It is resolved by reverting some commit. OK, 3DMark03 works. Then I decided to check how your patch will work with this application. It failed. 3DMark03 is not started again with log ~~~ err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nulldrv_CreateWindow The explorer process failed to start. ~~~
To check I reverted this patch and the application is working again. How it is possible? Why this patch may influence?
Anybody can check the application with this patch?
PS. About including into mainstream take into account that 1.8 will not accept new codes. "Code freeze". Will wait for 1.9.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #59 from swswine@gmail.com --- (In reply to Sergey Isakov from comment #58)
See bug 39674. It is resolved by reverting some commit. OK, 3DMark03 works.
This is all very strange. See this: https://appdb.winehq.org/objectManager.php?sClass=version&iId=7133 WineHQ suggests that 3DMark03 does not work without -systeminfo at least since 1.7.46. Anyway, I do not think it can have any relation to this IVB patch.
Then I decided to check how your patch will work with this application. It failed. 3DMark03 is not started again with log
err:winediag:nulldrv_CreateWindow Application tried to create a window, but no driver could be loaded. err:winediag:nulldrv_CreateWindow The explorer process failed to start.To check I reverted this patch and the application is working again. How it is possible? Why this patch may influence?
Anybody can check the application with this patch?
I've tested 3DMark03 with -nosysteminfo, it works without any problem for me with this patch (without it as well). Are you testing with 3DMark -nosysteminfo? Are you testing the latest 1.8-rc2 version and presence of this patch is the only difference between it works and don't work? Without -nosysteminfo 3DMark03 does not work in 1.8-rc2 without this patch either.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #60 from Sergey Isakov isakov-sl@bk.ru --- Thank you for your attention and test.
WineHQ suggests that 3DMark03 does not work without -systeminfo at least since 1.7.46
In the bug 39674 I made an attempt to start 3DMark03 WITHOUT -no-systeminfo. And I have a success in bug 38411 fixed in 1.7.46 and in bug 39674 fixed by reverting commit b6710c2a006234ac1a729881e7ca75d34cffb474
Are you testing the latest 1.8-rc2
Yes!
and presence of this patch is the only difference between it works and don't work?
Yes!
Without -nosysteminfo 3DMark03 does not work in 1.8-rc2 without this patch either.
Repeat: fixed by reverting commit b6710c2a006234ac1a729881e7ca75d34cffb474
But now I got new result: wine-1.8-rc2 + patch-1.8-rc2-ivb + patch from bug 34166 comment 23. Works! Without patch 34166 I have very dirty screen at start and it seems this influents on uninitialised variables/cash/stack/buffers. Very strange and this I can't explain. OK, I resolved my problem. As well your patch is tested in some applications and it works, images are good and not broken. Thanks! Hope your patch will be in next wine version.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52951|0 |1 is obsolete| |
--- Comment #61 from swswine@gmail.com --- Created attachment 53162 --> https://bugs.winehq.org/attachment.cgi?id=53162 Patch to implement indexed vertex blending, wine 1.8
Rebased to 1.8 and fixed some formatting.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #62 from Sergey Isakov isakov-sl@bk.ru --- Tested game Tony Hawk's Pro Scater HD 2012 and see ~~~ fixme:d3d_shader:print_glsl_info_log ERROR: 0:28: Index 244 beyond bounds (size 241) fixme:d3d_shader:print_glsl_info_log ERROR: 0:29: Index 243 beyond bounds (size 241) fixme:d3d_shader:print_glsl_info_log ERROR: 0:69: Index 242 beyond bounds (size 241) fixme:d3d_shader:print_glsl_info_log ERROR: 0:70: Index 242 beyond bounds (size 241) fixme:d3d_shader:print_glsl_info_log ERROR: 0:84: Index 241 beyond bounds (size 241) fixme:d3d_shader:print_glsl_info_log ERROR: 0:88: Index 251 beyond bounds (size 241) fixme:d3d_shader:print_glsl_info_log ERROR: 0:91: Index 241 beyond bounds (size 241) fixme:d3d_shader:print_glsl_info_log ERROR: 0:95: Index 241 beyond bounds (size 241) fixme:d3d_shader:print_glsl_info_log ERROR: 0:96: Index 241 beyond bounds (size 241) ~~~ Is it related to this bug?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #63 from swswine@gmail.com --- (In reply to Sergey Isakov from comment #62)
Is it related to this bug?
Does the same problem happen without this patch also? Could you please reproduce the problem with WINEDEBUG=+d3d,+d3d_shader,+d3d9 and attach gzipped output?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #64 from swswine@gmail.com --- Created attachment 53402 --> https://bugs.winehq.org/attachment.cgi?id=53402 Patch to implement indexed vertex blending, wine 1.9.1
rebased the patch for 1.9.1
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #53402|0 |1 is obsolete| |
--- Comment #65 from swswine@gmail.com --- Created attachment 53581 --> https://bugs.winehq.org/attachment.cgi?id=53581 Patch to implement indexed vertex blending, Wine 1.9.3
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #53581|0 |1 is obsolete| |
--- Comment #66 from swswine@gmail.com --- Created attachment 54151 --> https://bugs.winehq.org/attachment.cgi?id=54151 Patch to implement indexed vertex blending, Wine 1.9.7
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52845|0 |1 is obsolete| |
--- Comment #67 from swswine@gmail.com --- Created attachment 54152 --> https://bugs.winehq.org/attachment.cgi?id=54152 Constants number increase for testing purposes, Wine 1.9.7
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #54151|0 |1 is obsolete| |
--- Comment #68 from swswine@gmail.com --- Created attachment 54568 --> https://bugs.winehq.org/attachment.cgi?id=54568 Patch to implement indexed vertex blending, Wine 1.9.11
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #54152|0 |1 is obsolete| |
--- Comment #69 from swswine@gmail.com --- Created attachment 54569 --> https://bugs.winehq.org/attachment.cgi?id=54569 Constants number increase for testing purposes, Wine 1.9.11
https://bugs.winehq.org/show_bug.cgi?id=39057
Zion Nimchuk zionnimchuk@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zionnimchuk@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39057
Hans Petter Jansson hpj@copyleft.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hpj@copyleft.no
--- Comment #70 from Hans Petter Jansson hpj@copyleft.no --- I'm not sure how much bearing it has on this bug, but I tested the latest version of your patch with Wine master (1.9.12+) and Dark Age of Camelot, which uses vertex blending. It was crashing before, and the patch didn't appear to have any impact one way or the other.
However, an old patch from bug 6955 fixed the issue once I rebased it (see bug 40801). Maybe it's worth integrating with your changes.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #71 from swswine@gmail.com --- (In reply to Hans Petter Jansson from comment #70)
I'm not sure how much bearing it has on this bug, but I tested the latest version of your patch with Wine master (1.9.12+) and Dark Age of Camelot, which uses vertex blending. It was crashing before, and the patch didn't appear to have any impact one way or the other.
However, an old patch from bug 6955 fixed the issue once I rebased it (see bug 40801). Maybe it's worth integrating with your changes.
Description on WineHQ suggests disabling GLSL. This patch (unlike patch in 6955) implements indexed vertex blending in GLSL backend and has no effect if GLSL is disabled. Were you testing with GLSL enabled? If yes, could you please attach gzipped output with WINEDEBUG=+d3d9,+d3d,+d3d_shader? Or is the game or its demo available for download so I could look?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #72 from Hans Petter Jansson hpj@copyleft.no --- Good news: With GLSL enabled, your patch fixes the crash. The other patch fixes the GLSL disabled case.
I generated a log with GLSL enabled and your patch applied anyway. However, it's almost 4GB with a couple of minutes of gameplay. XZ compressed it's 19MB, which is still too big for Bugzilla, so I uploaded it here:
http://s000.tinyupload.com/index.php?file_id=80369659748657653148
https://bugs.winehq.org/show_bug.cgi?id=39057
fjfrackiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fjfrackiewicz@gmail.com
--- Comment #73 from fjfrackiewicz@gmail.com --- Will the patches mentioned here be added to the development version of Wine? I have two games that need "glsl=disabled" to be set in order to run properly.
If need be, I can provide logs for how things look with "glsl=disabled" versus when glsl=enabled.
https://bugs.winehq.org/show_bug.cgi?id=39057
René Kjellerup rk.katana.steel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rk.katana.steel@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #74 from René Kjellerup rk.katana.steel@gmail.com --- Created attachment 55919 --> https://bugs.winehq.org/attachment.cgi?id=55919 Patch to implement indexed vertex blending, Wine 1.9.20
added minor changes for the patch to apply cleanly to 1.9.20
this is all work done by swswine@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #75 from René Kjellerup rk.katana.steel@gmail.com --- I tested the 1.9.20 patch against 1.9.23 and it applied fine.
will try with 2.0 as soon as I can
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #76 from René Kjellerup rk.katana.steel@gmail.com --- Created attachment 57046 --> https://bugs.winehq.org/attachment.cgi?id=57046 diff to the wine-1.9.20 and wine-2.0 patch
tiny update to the 1.9.20 patch that will make it apply against 2.0 source tree
https://bugs.winehq.org/show_bug.cgi?id=39057
René Kjellerup rk.katana.steel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57046|0 |1 is patch| |
https://bugs.winehq.org/show_bug.cgi?id=39057
René Kjellerup rk.katana.steel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57046|file_39057.txt |wine1.9-2.0.diff filename| |
https://bugs.winehq.org/show_bug.cgi?id=39057
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #77 from winetest@luukku.com --- The author of this patch could you start trying to upstream the patch? Even some parts of it? Even on wine-staging? The patch sitting here helps only people who can compile wine themselves.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #78 from swswine@gmail.com --- (In reply to winetest from comment #77)
The author of this patch could you start trying to upstream the patch? Even some parts of it? Even on wine-staging? The patch sitting here helps only people who can compile wine themselves.
I am currently away but I will think of it. As I understand there were some plans to introduce UBOs in wined3d in a systematic way, I am not sure how well this patch would fit in in its current state. Meanwhile if anyone wants to do anything with upstreaming this issue please feel free to use this patch in any way.
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #53162|0 |1 is obsolete| | Attachment #54568|0 |1 is obsolete| |
--- Comment #79 from swswine@gmail.com --- Created attachment 57070 --> https://bugs.winehq.org/attachment.cgi?id=57070 Patch to implement indexed vertex blending (rebased, git 28.01.2017)
https://bugs.winehq.org/show_bug.cgi?id=39057
René Kjellerup rk.katana.steel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57046|0 |1 is obsolete| |
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57070|0 |1 is obsolete| |
--- Comment #80 from swswine@gmail.com --- Created attachment 57145 --> https://bugs.winehq.org/attachment.cgi?id=57145 Patch to implement indexed vertex blending (rebased for Wine 2.1)
https://bugs.winehq.org/show_bug.cgi?id=39057
swswine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57145|0 |1 is obsolete| |
--- Comment #81 from swswine@gmail.com --- Created attachment 57893 --> https://bugs.winehq.org/attachment.cgi?id=57893 Patch to implement indexed vertex blending (rebased for Wine 2.6)
https://bugs.winehq.org/show_bug.cgi?id=39057
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #82 from gamiljydcome@gmail.com --- still outside 2.x? it's useful after all.
https://bugs.winehq.org/show_bug.cgi?id=39057
Jan Havran havran.jan@email.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |havran.jan@email.cz
--- Comment #83 from Jan Havran havran.jan@email.cz --- (In reply to swswine from comment #81)
Created attachment 57893 [details] Patch to implement indexed vertex blending (rebased for Wine 2.6)
This patch fixes also bug #9337
https://bugs.winehq.org/show_bug.cgi?id=39057
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
https://bugs.winehq.org/show_bug.cgi?id=39057
David Gámiz Jiménez david.gamiz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david.gamiz@gmail.com
--- Comment #84 from David Gámiz Jiménez david.gamiz@gmail.com --- Hi community,
And thanks for the efforts to implement vertex skinning animations. Various LithTech engine games had this feature and issues in wine.
I has checked in Die Hard Nakatomi Plaza, LithTech engine 2.x. With wine-staging 2.16, that include improve patch for this feature. But this it not show the character models correctly. I has added 3 screen-shots, from the intro cut-scene(full game last official patch).
You can check with a demo version: https://www.fileplanet.com/84666/80000/fileinfo/Die-Hard:-Nakatomi-Plaza-Dem...
Thanks in advance,
David Gámiz Jiménez
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #85 from David Gámiz Jiménez david.gamiz@gmail.com --- Created attachment 59189 --> https://bugs.winehq.org/attachment.cgi?id=59189 Die Hard Nakatomi Plaza - Wine-staging-2.16_2
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #86 from David Gámiz Jiménez david.gamiz@gmail.com --- Created attachment 59190 --> https://bugs.winehq.org/attachment.cgi?id=59190 Die Hard Nakatomi Plaza - Wine-staging-2.16_1
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #87 from David Gámiz Jiménez david.gamiz@gmail.com --- Created attachment 59191 --> https://bugs.winehq.org/attachment.cgi?id=59191 Die Hard Nakatomi Plaza - Wine-staging-2.16_3
https://bugs.winehq.org/show_bug.cgi?id=39057
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #88 from Paul Gofman gofmanp@gmail.com --- (In reply to David Gámiz Jiménez from comment #84)
Hi community,
And thanks for the efforts to implement vertex skinning animations. Various LithTech engine games had this feature and issues in wine.
I has checked in Die Hard Nakatomi Plaza, LithTech engine 2.x. With wine-staging 2.16, that include improve patch for this feature. But this it not show the character models correctly. I has added 3 screen-shots, from the intro cut-scene(full game last official patch).
You can check with a demo version: https://www.fileplanet.com/84666/80000/fileinfo/Die-Hard:-Nakatomi-Plaza-Dem...
Thanks in advance,
David Gámiz Jiménez
I've tested the demo and was able to reproduce the glitch, it can be seen right on the first cut scene after starting new game.
The glitch is not there with the original patch attached to this bug. The relevant difference is that original patch always uses maximum supported indexes regardless of software or hardware vertex processing mode selected (which does not look like correct behaviour either), while Staging version supports max index of 7 in HWVP and 255 in SWVP mode only. If to make it use SWVP mode path only, the glitch goes away (* see note below).
The game uses d3d8 interface and creates mixed vertex processing (MVP) device. The way of setting SWVP in MVP for d3d8 is done through D3DRS_SOFTWAREVERTEXPROCESSING render state, unlike d3d9 SetSoftwareVertexProcessing call (which is not there for d3d8). This render state is not taken into account, but this is not the reason for this glitch actually: the demo never sets this state. I did not test how many indexes are de facto supported in MVP mode on Windows, but can guess that it might be different from what is reported through capabilities.
* The core GL profiles must not be used for indexed vertex blending in Staging to work, that is, HKEY_CURRENT_USER\Software\Wine\Direct3D\MaxVersionGL registry entry must not be set or set to something below 3.2. This is due to glVertex... and similar functions which are used in 'software emulation' codepath are not supported on opengl 3.2+ core profiles.
https://bugs.winehq.org/show_bug.cgi?id=39057
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/wined3d-Indexe | |d_Vertex_Blending CC| |dmitry@baikal.ru, | |erich.e.hoover@wine-staging | |.com, michael@fds-team.de Status|NEW |STAGED
https://bugs.winehq.org/show_bug.cgi?id=39057
andy andy86@fastwebnet.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andy86@fastwebnet.it
https://bugs.winehq.org/show_bug.cgi?id=39057
TOM l12436@yahoo.com.tw changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l12436@yahoo.com.tw
--- Comment #89 from TOM l12436@yahoo.com.tw --- Indexed Blender patchset seems has problem in wine-staging 3.4. I have similar glitch in my game.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #90 from TOM l12436@yahoo.com.tw --- OK I found it, wine has enable CSMT by default, CSMT will cause Indexed Vertex patch glitch. I need to disable CSMT to let it work.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #91 from TOM l12436@yahoo.com.tw --- I found the issue, one of the settings in my game cause glitch. now the only issue is Indexed Vertex Patch performance seems slow.
https://bugs.winehq.org/show_bug.cgi?id=39057
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=39057
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/wined3d-Indexe |er/patches/wined3d-Indexed_ |d_Vertex_Blending |Vertex_Blending
https://bugs.winehq.org/show_bug.cgi?id=39057
Alexandr Oleynikov sashok.olen@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sashok.olen@gmail.com
--- Comment #92 from Alexandr Oleynikov sashok.olen@gmail.com --- Seems like newer drivers for both NVidia (396 and higher) and AMD (AMDGPU) don't like registers that are this high: https://devtalk.nvidia.com/default/topic/1036629/linux/-quot-nvidia-396-gl_i...
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #93 from Paul Gofman gofmanp@gmail.com --- Created attachment 62605 --> https://bugs.winehq.org/attachment.cgi?id=62605 Patchset for supporting SW shaders and indexed vertex blending (through glsl)
(In reply to Alexandr Oleynikov from comment #92)
Seems like newer drivers for both NVidia (396 and higher) and AMD (AMDGPU) don't like registers that are this high: https://devtalk.nvidia.com/default/topic/1036629/linux/-quot-nvidia-396- gl_invalid_operation-error-generated-quot-when-compiling-1024-vertex-shaders/
I am attaching a rebased draft patch set from what I was testing a while ago, which includes the following: - Support for UBO instead of uniforms for shader constants; - Support for software vertex shaders (through glsl backend); - Support for indexed vertex blending (through glsl backend).
It should probably work with newer NVIDIA drivers (as it minds GL capabilties for uniform arrays' sizes). I didn't test with the newest drivers though, some bugs are possible. If it is still does not work as is for some reason, setting HKEY_CURRENT_USER/Software/Wine/Direct3D/consts_ubo (DWORD value) to 1 in registry might help.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #94 from Alexandr Oleynikov sashok.olen@gmail.com --- Oh great! Do you mind looking at the patch for Sims 2 from https://bugs.winehq.org/show_bug.cgi?id=8051 ? It seems to be the same thing but slightly different, I think. Would really appreciate it!
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #95 from Paul Gofman gofmanp@gmail.com --- (In reply to Alexandr Oleynikov from comment #94)
Oh great! Do you mind looking at the patch for Sims 2 from https://bugs.winehq.org/show_bug.cgi?id=8051 ? It seems to be the same thing but slightly different, I think. Would really appreciate it!
That bug covers a bunch of different issues, including the software vertex shaders which are (in draft) addressed by the patchset I put here in the previous message. If you are referring your patch there (https://bugs.winehq.org/attachment.cgi?id=61321) and that was the one you needed for Sims 2 to work, I think you can leave just the part adding a stub for undocumented shader validator interface (changes in d3d9_main.c), drop everything else from it and use it together with the latest pacthset from here.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #96 from Alexandr Oleynikov sashok.olen@gmail.com --- Thanks! Still a few artifacts just like in Die Hard Nakatomi Plaza, but at least it's working :D
https://bugs.winehq.org/show_bug.cgi?id=39057
Lukáš Krejčí lskrejci@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lskrejci@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39057
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #62605|0 |1 is obsolete| |
--- Comment #97 from Paul Gofman gofmanp@gmail.com --- Created attachment 63583 --> https://bugs.winehq.org/attachment.cgi?id=63583 Patchset for supporting SW shaders and indexed vertex blending
Rebased for Wine 4.2.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #98 from Sergey Isakov isakov-sl@bk.ru --- This is a great patch and I always include it into my compilation because of game https://bugs.winehq.org/attachment.cgi?id=52812 Why it is still not in mainstream?
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #99 from Jan Havran havran.jan@email.cz --- (In reply to Paul Gofman from comment #97)
Created attachment 63583 [details] Patchset for supporting SW shaders and indexed vertex blending
Rebased for Wine 4.2.
Good job. This patch is working for both Vietcong demo and full version (fixes bug #9337). Would be nice to replace current wined3d-Indexed_Vertex_Blending patchset from staging, since it has rendering issues since 3.9 (bug #45278)
https://bugs.winehq.org/show_bug.cgi?id=39057
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #100 from Zebediah Figura z.figura12@gmail.com --- (In reply to Sergey Isakov from comment #98)
This is a great patch and I always include it into my compilation because of game https://bugs.winehq.org/attachment.cgi?id=52812 Why it is still not in mainstream?
Probably because nobody has submitted it.
https://bugs.winehq.org/show_bug.cgi?id=39057
Anthony Jagers noonetinone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noonetinone@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39057
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |docmccoy80@freenet.de
--- Comment #101 from Anastasius Focht focht@gmx.net --- *** Bug 9337 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=39057
andy andy86@fastwebnet.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|andy86@fastwebnet.it |
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #102 from Andrey Gusev andrey.goosev@gmail.com --- Fixes a broken player geometry in Max Payne when acceleration set to D3D Software T&L.
https://bugs.winehq.org/show_bug.cgi?id=39057
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #103 from joaopa jeremielapuree@yahoo.fr --- No plan to submit the patchset? Because bug still occurs with vanilla wine-6.19.
https://bugs.winehq.org/show_bug.cgi?id=39057
Matheus matheus.venturini@acad.ufsm.br changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matheus.venturini@acad.ufsm | |.br
--- Comment #104 from Matheus matheus.venturini@acad.ufsm.br --- I was testing Max Payne with 8.0-rc3 and I encountered the bug described in comment 102, I will try the latest patch to see if it still works
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #105 from Matheus matheus.venturini@acad.ufsm.br --- I tried to apply the patch in comment 97 but it causes various conflicts with the current Wine version. The glitches can be seen in the demo for the game (https://archive.org/details/MaxPayneDemo), I tried to record a video but it didn't work for some reason.
https://bugs.winehq.org/show_bug.cgi?id=39057
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #106 from Sergey Isakov isakov-sl@bk.ru --- Created attachment 74556 --> https://bugs.winehq.org/attachment.cgi?id=74556 Broken image in Crossover
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #107 from Matheus matheus.venturini@acad.ufsm.br --- Created attachment 74616 --> https://bugs.winehq.org/attachment.cgi?id=74616 Max Payne with Software T&L on Wine 8.10
This is a video of what Max Payne looks like with the Software renderer on Wine 8.10.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #108 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Zeb Figura from comment #100)
(In reply to Sergey Isakov from comment #98)
This is a great patch and I always include it into my compilation because of game https://bugs.winehq.org/attachment.cgi?id=52812 Why it is still not in mainstream?
Probably because nobody has submitted it.
As I shown just now the bug is still present in Crossover 22.1.1. Can't check it in WineHQ because the game is 32bit which is not supported by wineHQ. But I applied Staging patchset for Index Vertex Blending to crossover sources and got only 10 chunks rejected. All of them I successfully applied and got fully working wine without the bug. I think Codewears employees should do this for their Crossover. I can help, I can provide revised patchset exactly for Crossover 22.1.1. Not sure if there is any sense for WineHQ.
https://bugs.winehq.org/show_bug.cgi?id=39057
--- Comment #109 from Sergey Isakov isakov-sl@bk.ru --- WineHQ-10 and Crossover-24.07 The bug is still present. Wine-staging patchset is not working because functions changed their definitions, changed names, changed arguments, changed a sense, changed locations.
Until you include this patch into mainstream this bug will be forever with all wine flavour (except mine).
-
wine-bugs＠winehq.org -
WineHQ Bugzilla