http://bugs.winehq.org/show_bug.cgi?id=22918
Summary: Ship Simulator 2008 demo crashes on startup (needs D3DXCreateSphere) Product: Wine Version: unspecified Platform: x86 URL: http://www.shipsim.com/downloads/trailers OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: madewokherd@gmail.com
Created an attachment (id=28358) --> (http://bugs.winehq.org/attachment.cgi?id=28358) console log, from wine-1.2-rc1-179-gdd09205
When installed with nothing else in a clean wine prefix, Ship Simulator 2008 crashes on startup.
wine: Call from 0x7b836a02 to unimplemented function d3dx9_36.dll.D3DXCreateSphere, aborting
Before that, it hits a number of d3dx stubs, so even when this is implemented, it will likely not work properly.
http://bugs.winehq.org/show_bug.cgi?id=22918
Roderick Colenbrander thunderbird2k@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thunderbird2k@gmail.com, | |wine-bugs@winehq.org Component|directx-d3d |directx-d3dx9
--- Comment #1 from Roderick Colenbrander thunderbird2k@gmail.com 2010-05-28 14:52:04 --- Marking as d3dx9.
http://bugs.winehq.org/show_bug.cgi?id=22918
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.2-rc1
http://bugs.winehq.org/show_bug.cgi?id=22918
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com AssignedTo|wine-bugs@winehq.org |misha680@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #2 from Misha Koshelev misha680@gmail.com 2010-06-25 20:32:42 --- Created an attachment (id=29139) --> (http://bugs.winehq.org/attachment.cgi?id=29139) Console log from (as yet uncommited) Wine version with D3DXCreateSphere
Needs D3DXCreateCylinder afterwards. I have a feeling I'll have to implement all D3DX shape functions to fix this bug. Lots of work to do!
http://bugs.winehq.org/show_bug.cgi?id=22918
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Ship Simulator 2008 demo |Ship Simulator 2008 demo |crashes on startup (needs |crashes on startup (needs |D3DXCreateSphere) |D3DXCreateSphere, | |D3DXCreateCylinder, and | |D3DXCreateTeapot)
--- Comment #3 from Dan Kegel dank@kegel.com 2010-06-26 04:19:55 --- I await D3DXCreateTeapot with bated breath :-)
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #4 from Dan Kegel dank@kegel.com 2010-06-26 05:51:29 --- Believe it or not, according to http://scene.foad.za.net/index.php/Raving_Tomatoes_-_BASTARD_Wine_Error Raving Tomatoes - BASTARD needs D3DXCreateTeapot (as well as D3DXCreateSprite and D3DXCreateSphere) and http://ubuntuforums.org/showthread.php?t=725338 says Rock Band Drums (http://andrewrudson.com/drummachine/main.php) needs 'em too. Just goes to show, if you write it, people will call it.
Back in the real world, according to http://appdb.winehq.org/objectManager.php?sClass=version&iId=20402 Aion Online also needs D3DXCreateSphere.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #5 from Misha Koshelev misha680@gmail.com 2010-06-26 07:13:55 --- Teapot is going to be a pain in a**. Sorry just being honest ;) Thanks for kudos.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #6 from Henri Verbeet hverbeet@gmail.com 2010-06-26 08:28:59 --- (In reply to comment #5)
Teapot is going to be a pain in a**. Sorry just being honest ;) Thanks for kudos.
Actually, if that's a standard Utah teapot it's probably the easiest of the shapes. I'd expect D3DXCreateText() to be the hardest.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #7 from Dan Kegel dank@kegel.com 2010-06-26 10:05:28 --- Yeah, see http://en.wikipedia.org/wiki/Utah_teapot The original data set is at http://www.sjbaker.org/teapot/teaset.tgz
And it's kind of low on the priority list :-)
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #8 from Misha Koshelev misha680@gmail.com 2010-07-09 12:04:40 --- Progress:
D3DXCreateBox is now a go (mostly).
http://github.com/misha680/wine/tree/
Feels like I'm finally getting somewhere after writing lots of tests and implementing ID3DXMesh COM object.
Eagerly awaiting 1.2 to start submitting patches back to Wine :)
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #9 from joaopa jeremielapuree@yahoo.fr 2010-07-09 12:27:13 --- First thing to do (that can be done during frezzing code) is to send patches for tests. Mesh functions needs tons of tests before being implemented. And shape create functions are based on mesh functions.
So, begin to send test patches.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #10 from Misha Koshelev misha680@gmail.com 2010-07-09 13:08:19 --- I would love to submit tests but as you can see per here: http://www.winehq.org/pipermail/wine-devel/2010-June/084637.html
on my previous attempts this did not succeed, and my patches were deferred.
Thus, I think at this point I am stuck with a private Git repo until 1.2 unless you have some other ideas that were not there.
Misha
p.s. I got a comment about my use of lpVtbl. I will please refer any interested parties to these two posts from Henri:
http://www.winehq.org/pipermail/wine-devel/2010-June/084592.html
http://www.winehq.org/pipermail/wine-devel/2010-June/084637.html
Thank you Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #11 from Misha Koshelev misha680@gmail.com 2010-07-13 19:33:47 --- _Almost_ have D3DXCreateCylinder implemented.
Thanks to Henri's wonderful help, I have a full test now for vertices and normals. http://github.com/misha680/wine/commit/9ec02c39a269c49d45bb8d9f4859777bf9881...
Still working on index buffers for D3DXCreateCylinder. Any hints appreciated.
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #12 from Misha Koshelev misha680@gmail.com 2010-07-15 20:14:37 --- D3DXCreateCylinder done: http://github.com/misha680/wine/commit/2900a9cb2aad27c96e4100c6e741466c362cd...
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #13 from Henri Verbeet hverbeet@gmail.com 2010-07-16 04:26:03 --- (In reply to comment #12)
D3DXCreateCylinder done: http://github.com/misha680/wine/commit/2900a9cb2aad27c96e4100c6e741466c362cd...
I quickly looked it over, and I've got a couple of points:
- In the expression "sqrt(normal.x * normal.x + normal.y * normal.y) * delta_radius / length;", "sqrt(normal.x * normal.x + normal.y * normal.y)" should be equal to "radius", and "delta_radius / length" is constant for a given cylinder. I.e., conceptually you have "radius * normal_slope". - The code would probably benefit from having a proper structure for the vertex data. E.g.:
struct vertex_data { D3DXVECTOR3 position; D3DXVECTOR3 normal; };
- The caps calculations look a bit forced into the main loop. The code will probably be clearer if you simply calculate those outside the main loop, like you do for indices. Also, note that you can easily define a helper function to generate a ring of vertices with a certain radius, z position and z normal. - "radius_step = (radius2 - radius1) / stacks;" can be simplified to "radius_step = -delta_radius / stacks;". Perhaps it's just as easy to just define it as "delta_radius / stacks" and change "radius += radius_step;" to "radius -= radius_step;" though.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #14 from Misha Koshelev misha680@gmail.com 2010-07-16 14:35:36 --- Thank you for your comments. I have updated per all comments: http://github.com/misha680/wine/commit/e90ead51ca630485eb95204fb9e605b47585f...
except I do not quite understand: Also, note that you can easily define a helper function to generate a ring of vertices with a certain radius, z position and z normal.
Or rather, in the new code, the inner loop looks like this:
/* side - iterate over stacks (z axis) and slices (x/y axes around circle) */ for (stack=0;stack<=stacks;stack++) { theta = M_PI / 2; for (slice=0;slice<slices;slice++) { vertex_data[vertex].position.x = radius*cos(theta); vertex_data[vertex].position.y = radius*sin(theta); vertex_data[vertex].position.z = z; vertex_data[vertex].normal.x = vertex_data[vertex].position.x; vertex_data[vertex].normal.y = vertex_data[vertex].position.y; vertex_data[vertex].normal.z = radius * delta_radius / length;
D3DXVec3Normalize(&vertex_data[vertex].normal,&vertex_data[vertex].normal); vertex++; theta += theta_step; } if (stack<stacks) { z += z_step; radius -= radius_step; } }
However, the cap calculations are dfferent wrt normals:
/* top cap */ theta = M_PI / 2; for (slice=0;slice<slices;slice++) { vertex_data[vertex].position.x = radius*cos(theta); vertex_data[vertex].position.y = radius*sin(theta); vertex_data[vertex].position.z = z; vertex_data[vertex].normal.x = 0.0f; vertex_data[vertex].normal.y = 0.0f; vertex_data[vertex].normal.z = -1.0f; vertex++; theta += theta_step; }
Thus, it seems that if I made a helper function, it would only be useful in the main loop and not the cap calculations... or am I missing something?
Thank you Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #15 from Henri Verbeet hverbeet@gmail.com 2010-07-16 15:29:49 --- (In reply to comment #14)
/* top cap */ theta = M_PI / 2; for (slice=0;slice<slices;slice++) { vertex_data[vertex].position.x = radius*cos(theta); vertex_data[vertex].position.y = radius*sin(theta); vertex_data[vertex].position.z = z; vertex_data[vertex].normal.x = 0.0f; vertex_data[vertex].normal.y = 0.0f; vertex_data[vertex].normal.z = -1.0f; vertex++; theta += theta_step; }Thus, it seems that if I made a helper function, it would only be useful in the main loop and not the cap calculations... or am I missing something?
No, you're right, the x and y components of the normal are 0.0f for the caps. You could still have separate helper functions for the main loop and caps, and perhaps you can share some code with spheres, but that's probably less interesting at this point.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #16 from Misha Koshelev misha680@gmail.com 2010-07-16 16:13:50 --- Thx. Btw, any objections to this kind of definition for vertex_data:
struct vertex_data { FLOAT x, y, z; D3DXVECTOR3 normal; };
Seems bit simpler to me and is used here: http://www.directxtutorial.com/tutorial9/b-direct3dbasics/dx9B4.aspx
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #17 from Misha Koshelev misha680@gmail.com 2010-07-16 16:16:30 --- Oh and if you have objections pls let me know quick as I'm making changes to the tests too.
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #18 from Misha Koshelev misha680@gmail.com 2010-07-17 17:38:23 --- Thanks to Henri for all his help!
D3DXCreateSphere: http://github.com/misha680/wine/commit/1bb0f94149f2a9bdc4617642b001d44a6a7c0...
D3DXCreateCylinder updated to properly handle 0.0f radius1, radius2, and/or length: http://github.com/misha680/wine/commit/182cf7d77d35cea36b77f495a1a402bed40c0...
Thank you!
Misha
p.s. that darn teapot!
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #19 from Misha Koshelev misha680@gmail.com 2010-07-18 14:18:12 --- Trying to make progress on D3DXCreateTeapot.
So far, unsure if I must: a) use original Newell dataset to reproduce Teapot or b) use D3DXCreateTeapot, output indices and vertices created, make an include file (or other file), and use this to reproduce the teapot
I am trying to compare Newell teapot to MS.
Unfortunately, I am not having much luck.
I will attach relevant code. However, at the moment, I am simply using these three coordinates from Newell: * 1.4,0.0,2.4 * 0.84,-1.5,2.4 * 3.1,-0.66,0.825
I am simply trying to find points in the vertices returned by D3DXCreateSphere with equivalent ratios of _some_ coordinate (x, y, or z, I am not assuming, and only looking at the x coordinates above).
I am using an epsilon of 0.0001f to compare the ratios. Unfortunately, I am not having much luck.
Again, I will add code to this bug (it is modified from functions on www.directxtutorial.com) as well as dataset I am using.
Any ideas/hints appreciated.
Also, any ideas whether I need to do this or can simply do option b) above - create include files via D3DXCreateTeapot - much appreciated.
Thank you Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #20 from Misha Koshelev misha680@gmail.com 2010-07-18 14:19:38 --- Created an attachment (id=29690) --> (http://bugs.winehq.org/attachment.cgi?id=29690) Simple test program to compare D3DXCreateTeapot to Newell teapot
Requires DXSDK I am using June 2010.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #21 from Misha Koshelev misha680@gmail.com 2010-07-18 14:19:56 --- Created an attachment (id=29691) --> (http://bugs.winehq.org/attachment.cgi?id=29691) Newell Teapot data - required for test_t.cpp
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #22 from Misha Koshelev misha680@gmail.com 2010-07-18 14:23:10 --- Fyi, here is relevant output data from running test_t.cpp on Windows XP 64 bit: Newell Test Set: {1.4,0,2.4} {0.84,-1.5,2.4} {3.1,-0.66,0.825} Windows Vertices:
As you can see, it finds the Newell Test Set, but not Windows ones.
Some more interesting comparisons.
Windows vertices = 2356. Newell vertices = 306. 2356/306 ~ 7.7
Windows indices = 13536 = 2256 faces. Newell "patches" (have to figure out what this means) = 32 2256/32 ~ 70.5
Hmm
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #23 from Misha Koshelev misha680@gmail.com 2010-07-18 14:29:38 --- Fyi, next function for this program is: wine: Call from 0x7b8369f2 to unimplemented function d3dx9_36.dll.D3DXSaveSurfaceToFileInMemory, aborting wine: Unimplemented function d3dx9_36.dll.D3DXSaveSurfaceToFileInMemory called at address 0x7b8369f2 (thread 001c), starting debugger...
I will attach console log. This is with stub for D3DXCreateTeapot.
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #24 from Misha Koshelev misha680@gmail.com 2010-07-18 14:30:35 --- Created an attachment (id=29692) --> (http://bugs.winehq.org/attachment.cgi?id=29692) Console log with patches from private GIT repo (see below).
From GIT repo:
http://github.com/misha680/wine/commits/master
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #25 from Misha Koshelev misha680@gmail.com 2010-07-18 14:31:35 --- Sorry last comment: this was _without_ Gecko installation. I had some install problems _with_ Gecko installation. Might be just a fluke.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #26 from Misha Koshelev misha680@gmail.com 2010-07-18 16:28:08 --- For reference, here is a link to the glut teapot sources: http://www.it.freebsd.org/pub/Unix/NetBSD/NetBSD-current/xsrc/external/mit/M...
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #27 from Misha Koshelev misha680@gmail.com 2010-07-18 17:01:52 --- Oh and patch for stub is here: http://github.com/misha680/wine/commit/965bc5f57e0632e67684cadb0189f178ce8c0...
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #28 from Misha Koshelev misha680@gmail.com 2010-07-18 17:15:50 --- I have created a new bug report here: http://bugs.winehq.org/show_bug.cgi?id=23706
Clearly the new direction is textures as both bugs require this: http://bugs.winehq.org/show_bug.cgi?id=23706 http://bugs.winehq.org/show_bug.cgi?id=22555
However, I am not yet sure which (if either) will be first, so please don't add me on the "Assigned To" list just yet.
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #29 from Misha Koshelev misha680@gmail.com 2010-07-22 19:26:50 --- Fyi very very useful Direct3D reference (free): http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #30 from Misha Koshelev misha680@gmail.com 2010-07-24 12:06:45 --- Created an attachment (id=29810) --> (http://bugs.winehq.org/attachment.cgi?id=29810) freeglut_geometry.c from freeglut 2.6.0. X Consortium License.
My apologies I could not find another way to send a link that was convenient. Please see my wine-devel email related to this bug.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #31 from Misha Koshelev misha680@gmail.com 2010-07-24 12:08:33 --- Relevant post is here: http://www.winehq.org/pipermail/wine-devel/2010-July/085482.html
http://bugs.winehq.org/show_bug.cgi?id=22918
Tony Wasserka tony.wasserka@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tony.wasserka@freenet.de
--- Comment #32 from Tony Wasserka tony.wasserka@freenet.de 2010-07-24 13:30:22 --- (In reply to comment #8)
Feels like I'm finally getting somewhere after writing lots of tests and implementing ID3DXMesh COM object.
This might come a bit late as an answer, but do you actually know that I've implemented most ID3DXMesh methods as part of my Summer of Code project?
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #33 from Misha Koshelev misha680@gmail.com 2010-07-24 14:36:02 --- Oh, I guess I redid work then :(
You can see most of my patches that implement ID3DXMesh here, with relevant tests as well: http://github.com/misha680/wine/commits/master?page=2
Do you have links to your code by any chance? I see the information from http://wiki.winehq.org/Tony_Wasserka
Dan had mentioned that you had done some work in this area:
BTW, somebody at Codeweavers is going through Tony Wasserka's old patches from summer of code and merging them. His project was in this area, but I don't think he got around to this function.
I believe "this function" refers to D3DXCreateSphere.
Since I have made some basic patches now for ID3DXMesh, do you mind if I try to get those into wine after D3DXCreateSphereTest in some form is accepted? I also have implementations of D3DXCreateSphere, D3DXCreateCylinder, and D3DXCreateBox with relevant tests.
Thanks Misha
p.s. I would of course be happy to look at your patches as well. Currently I am using a very small portion of ID3DXMesh interface for my functions, but it would be great to have even more!
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #34 from Tony Wasserka tony.wasserka@freenet.de 2010-07-24 15:04:29 --- (In reply to comment #33)
Alright, my code is located at http://repo.or.cz/w/wine/d3dx9TW.git The COM part of the interface isn't that clean anyway, but maybe there's still some useful information for you in there.. note that it prolly would be better to use vertex declarations instead of FVFs internally though. I don't know what functionality was still missing, but it was pretty complete apart from the Optimize function and... IIRC some CloneMesh misbehaviors. .x file loading is implemented as well :) Anyway, I don't work on getting those patches merged anymore (due to various reasons), so feel free to pick up stuff from the patches and just add my copyright to the headers.
And.. yeah, I didn't implement D3DXCreateSphere, yet. Just D3DXCreateBox (I think so) and D3DXCreateText (or whatever it was called)
fwiw, if you have questions just come to #winehackers on IRC, I'm quite often around, my nick is bigbrain or neobrain ;)
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #35 from Tony Wasserka tony.wasserka@freenet.de 2010-07-24 15:20:31 --- That said, I apparently didn't make the D3DXCreateText implementation public... It wasn't too nice anyway since it needs at least a partial tesselator implementation as well which would've been totally overkill... Anyway, you don't seem to have come as far as it sounded with implementing the ID3DXMesh interface, yet, so I guess my code should help you quite a bit then ;) I'd suggest talking to you on IRC about this first though, to explain a bit further what still needs to be changed in my code etc.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #36 from Misha Koshelev misha680@gmail.com 2010-07-24 16:44:59 --- Wow you're right that does look pretty completely... I'm impressed.
I know Henri wanted me to keep at least the D3DXCreate... functions in mesh.c http://osdir.com/ml/wine-devel/2010-06/msg00611.html
I noticed you had a separate basemesh.c file... not sure how he would feel about the ID3DXBaseMesh functions.
As far as implementing ID3DXBaseMesh, this is what he had told me at one point when I was still getting my feet wet. ---
Sorry for bugging. I am now about to start implementing the ID3DXMesh interface and noticed that it inherits from the ID3DXBaseMesh interface. I am not using the ID3DXBaseMesh interface per se - specifically I will not be implementing any functions that return objects of this actual type.
I also upon a quick skim of Wine code did not see similar inheritance patterns for COM objects in the source tree.
Thus I am thinking of implementing the ID3DXMesh interface directly, without first implementing ID3DXBaseMesh. If this is INCORRECT, please let me know. Further, if I do need to implement this inheritance, any pointers to similar features in Wine code much appreciated.
There are no functions that directly return an ID3DXBaseMesh interface, it's just a base interface for ID3DXMesh. There should be plenty of similar constructions inside Wine, for an example look at IDirect3DTexture9 / IDirect3DBaseTexture9 in dlls/d3d9/texture.c. You do need to add stubs for the ID3DXBaseMesh methods in ID3DXMesh of course. ---
In any case, I'm not on IRC very much (actually I don't use it but downloaded xchat-gnome after I saw your message. Usually find it distracting.
I did not see you on but my nick is misha680.
Feel free to email me too at misha680@gmail.com.
I hope you don't mind, just in case I emailed Owen Rudge with a link to your texture.c in your merge branch: http://repo.or.cz/w/wine/d3dx9TW.git/blob/e4dfdb7c2cc4264bbe89ef938c939a3965...
although I'm sure he's quite aware. I do not see either of the functions http://bugs.winehq.org/show_bug.cgi?id=23706 D3DXSaveSurfaceToFileInMemory
http://bugs.winehq.org/show_bug.cgi?id=22555 D3DXCreateCubeTexture
implemented but please correct me if I am incorrect.
Also just to double check: --- Anyway, I don't work on getting those patches merged anymore (due to various reasons), so feel free to pick up stuff from the patches and just add my copyright to the headers. --- do you mean that I can send patches that use your code using my email address (not yours), and add a copyright notice at the top, and send them to the main Wine list?
I just wanted to double check - as I don't want to step on any toes. It definitely looks useful.
For now, I'm still waiting to hear about my D3DXCreateSphereTest patch, and was going to add some more tests, but D3DXCreateMesh is definitely in the ballpark.
As for your comments re declarator use internally, that was my ultimate intent, but I wanted to start with FVFs as that seemed like it would fix this bug in a more speedy fashion.
I am not sure how Henri/AJ will feel about this (I believe Henri has given some scrutiny to my patches, but I know he is quite busy).
In any case thank you, and I appreciate our further interactions.
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #37 from Misha Koshelev misha680@gmail.com 2010-07-24 16:51:07 --- Created an attachment (id=29818) --> (http://bugs.winehq.org/attachment.cgi?id=29818) Tangentially related - has basic tesselation implementation for OpenGL (teapot)
Fyi, since you did mention a tesselation implementation (I know you mean an actual implementation of either D3DXTesselateTriPatch/TessellateRectPatch or ID3DXPatchMesh interface or both), I did borrow some code for tessellation that I was hoping to use to tessellate the teapot (I know I know but it gives me a good way to learn some new things).
I was hoping that perhaps I might be able to either: i) Get some teapot code into Wine using a helper tessellation function as, e.g., in the attached code or ii) Alternately generate raw vertex and index data in OpenGL and then include that way
In theory, if we had a helper tesselator function, this could be quite useful for an eventual implementation of: * D3DXCreateText * D3DXTessellateTriPatch/D3DXTesselateRectPatch/ID3DXPatchMesh
What do you think?
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #38 from Misha Koshelev misha680@gmail.com 2010-07-24 21:51:03 --- Fyi, I did a Google search and found this rather helpful post that describes http://www.mail-archive.com/wine-devel@winehq.org/msg60225.html Tony Wasserka's work, as well as this more detailed breakdown: http://www.mail-archive.com/wine-devel@winehq.org/msg60350.html
I look forward to working with this code as an addition to the code I have already made at my GIT repo.
Thank you so much Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #39 from Tony Wasserka tony.wasserka@freenet.de 2010-07-25 04:45:14 --- (In reply to comment #36)
I noticed you had a separate basemesh.c file... not sure how he would feel about the ID3DXBaseMesh functions.
As far as implementing ID3DXBaseMesh, this is what he had told me at one point when I was still getting my feet wet.
There are no functions that directly return an ID3DXBaseMesh interface, it's just a base interface for ID3DXMesh. There should be plenty of similar constructions inside Wine, for an example look at IDirect3DTexture9 / IDirect3DBaseTexture9 in dlls/d3d9/texture.c. You do need to add stubs for the ID3DXBaseMesh methods in ID3DXMesh of course.
Yeah, I didn't know where to look for this either at first... Anyway, there were two methods of doing this: the wined3d/texture.c way and the dsound/dsound.c way (not sure if the filenames match, but you get the idea). I (think I) went for the wined3d way, since the dsound one was quite a bit complicated and wined3d seemed to have been added more recently.
In any case, I'm not on IRC very much (actually I don't use it but downloaded xchat-gnome after I saw your message. Usually find it distracting.
I did not see you on but my nick is misha680.
FWIW, I'll probably be online for the next 10 hours...
Feel free to email me too at misha680@gmail.com.
I hope you don't mind, just in case I emailed Owen Rudge with a link to your texture.c in your merge branch: http://repo.or.cz/w/wine/d3dx9TW.git/blob/e4dfdb7c2cc4264bbe89ef938c939a3965...
That's okay with me,
although I'm sure he's quite aware. I do not see either of the functions http://bugs.winehq.org/show_bug.cgi?id=23706 D3DXSaveSurfaceToFileInMemory
While not being implemented, this might be trivial to add since we're using WIC internally in d3dx9.
http://bugs.winehq.org/show_bug.cgi?id=22555 D3DXCreateCubeTexture
implemented but please correct me if I am incorrect.
That one was out of scope of my project and might require some serious refactoring of my code...
Anyway, I don't work on getting those patches merged anymore (due to various reasons), so feel free to pick up stuff from the patches and just add my copyright to the headers.
do you mean that I can send patches that use your code using my email address (not yours), and add a copyright notice at the top, and send them to the main Wine list?
Not sure where you were referring to, but I meant a copyright notice at the the top of the files which use my code, not necessarily the commit message (you're free to mention that quite a bit of the code was done by me though :P).
For now, I'm still waiting to hear about my D3DXCreateSphereTest patch, and was going to add some more tests, but D3DXCreateMesh is definitely in the ballpark.
Good luck getting all this commited then ;) Anyway, we definitely _should_ talk about at least .x file loading, since that code needs some more changes before committing.
As for your comments re declarator use internally, that was my ultimate intent, but I wanted to start with FVFs as that seemed like it would fix this bug in a more speedy fashion.
I am not sure how Henri/AJ will feel about this (I believe Henri has given some scrutiny to my patches, but I know he is quite busy).
It's not that hard to use declarators instead... D3DXCreateMeshFVF will just call D3DXDeclaratorFromFVF to get a vertex declaration and pass it to D3DXCreateMesh, it's as simple as that ;)
(In reply to comment #37)
Fyi, since you did mention a tesselation implementation (I know you mean an actual implementation of either D3DXTesselateTriPatch/TessellateRectPatch or ID3DXPatchMesh interface or both)
Actually, I wasn't referring to these functions. IIRC, I was using GetGlyphOutline with the GGO_NATIVE flag to get the vertex data of the text, but I had quite a few problems about indexing.
I was hoping that perhaps I might be able to either: i) Get some teapot code into Wine using a helper tessellation function as, e.g., in the attached code or ii) Alternately generate raw vertex and index data in OpenGL and then include that way
ii) sounds way to hacky to ever be included in Wine, so I'd go for i).
In theory, if we had a helper tesselator function, this could be quite useful for an eventual implementation of:
- D3DXCreateText
- D3DXTessellateTriPatch/D3DXTesselateRectPatch/ID3DXPatchMesh
D3DXCreateText shouldn't need the same tesselator functionality functionality provided by the other functions you mentioned. Stuff like that is handled in GetGlyphOutline already.
(In reply to comment #38)
Fyi, I did a Google search and found this rather helpful post that describes http://www.mail-archive.com/wine-devel@winehq.org/msg60225.html Tony Wasserka's work, as well as this more detailed breakdown: http://www.mail-archive.com/wine-devel@winehq.org/msg60350.html
Yeah, the e-mails didn't get as much usuable attention as I had hoped for them to get :/
Anyway, I'm glad someone picks my patches up, thanks for doing this ;)
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #40 from Tony Wasserka tony.wasserka@freenet.de 2010-07-25 05:16:44 --- Alright, found my implementation of D3DXCreateText again, I can pass this one to you as well once you get to that point.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #41 from Misha Koshelev misha680@gmail.com 2010-07-25 22:15:46 --- Created an attachment (id=29835) --> (http://bugs.winehq.org/attachment.cgi?id=29835) Email on (private) email list describing question re ID3DXPatchMesh, tessellation, and teapot
My apologies this is on a private list - I am posting here as others may not have access and I will refer in my next post. Thank you.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #42 from Misha Koshelev misha680@gmail.com 2010-07-25 22:17:40 --- (In reply to comment #39) Thanks for all your comments.
Sent out new patch for D3DXCreateSphere test to wine-patches. Hope this one makes the cut ;)
http://www.winehq.org/pipermail/wine-patches/2010-July/091250.html
Thank you for all your very helpful suggestions.
A few quick questions - sorry if they are simple :(
although I'm sure he's quite aware. I do not see either of the functions http://bugs.winehq.org/show_bug.cgi?id=23706 D3DXSaveSurfaceToFileInMemory
While not being implemented, this might be trivial to add since we're using WIC internally in d3dx9.
What is WIC?
I think I am too tired for the rest. Will try to reply tomorrow.
In any case, I appreciate your patches and having your GIT repository as a great guide.
Also, I'll throw these two questions out there as I had asked on some other lists and did not get a response (they are teapot related).
I'll include links but basically: * ID3DXPatchMesh - with cubic bezier patches, is there any good info how the 16 indices map to the x/y/z plane? I did not find any on MSDN :( http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A2=DIRECTXDEV;2aba0210... * ID3DXPatchMesh - if I set fTessLevel = 1.0f for non-adaptive tesselation I result in fewer vertices than I started with (I mean unique vertices). I don't quite get how this is theoretically possible. http://lists.midnightryder.com/private.cgi/sweng-gamedev-midnightryder.com/2...
The latter link is unfortunately not working so I have attached to this bug (temporarily?) http://bugs2.winehq.org/attachment.cgi?id=29835
Thank you Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #43 from Misha Koshelev misha680@gmail.com 2010-07-26 21:41:44 --- In case anyone is interested, I have found a very nice resource for the rectangular and triangular patches: http://www.xmission.com/~legalize/book/download/05-Modeling.pdf
In fact, this book is quite excellent for anyone wishing to learn D3DX (or to implement it for Wine). http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/
Thank you Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #44 from Misha Koshelev misha680@gmail.com 2010-07-26 22:12:43 --- Created an attachment (id=29848) --> (http://bugs.winehq.org/attachment.cgi?id=29848) Temporary patches for D3DXCreateMeshFVF/ID3DXMesh for wine-devel
My apologies... either wine-devel scrubs my attachments and does not get my posts through or the web interface does not seem to pick up the emails in time... in any case I wanted to make sure to get this out.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #45 from Tony Wasserka tony.wasserka@freenet.de 2010-07-27 11:26:43 --- (In reply to comment #44)
Created an attachment (id=29848)
--> (http://bugs.winehq.org/attachment.cgi?id=29848) [details]
Temporary patches for D3DXCreateMeshFVF/ID3DXMesh for wine-devel
My apologies... either wine-devel scrubs my attachments and does not get my posts through or the web interface does not seem to pick up the emails in time... in any case I wanted to make sure to get this out.
If you mean the wine-patches archives with web interface, that one usually only gets refreshed every two hours or something. Anyway, from my personal experience, quick-but-not-quite-correct patches with the promise of "doing it properly lateron" tend to get rejected with the reason "no, do it properly from the beginning"... i.e. you should prolly implement D3DXCreateMesh first, it's not that much work anyway.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #46 from Misha Koshelev misha680@gmail.com 2010-07-27 13:12:18 --- (In reply to comment #45)
If you mean the wine-patches archives with web interface, that one usually only gets refreshed every two hours or something.
No I certainly meant wine-devel. I would as per your comments and my prior experience never send such an unready patch to wine-patches. Wanted to get feedback first.
Anyway, from my personal experience, quick-but-not-quite-correct patches with the promise of "doing it properly lateron" tend to get rejected with the reason "no, do it properly from the beginning"... i.e. you should prolly implement D3DXCreateMesh first, it's not that much work anyway.
Ah if I understand you correctly this would avoid me having to implement conversions between FVFs correct?
Any other comments esp about patches 2-4?
Thx Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #47 from Misha Koshelev misha680@gmail.com 2010-07-27 15:54:06 --- (In reply to comment #45)
(In reply to comment #44)
Created an attachment (id=29848)
--> (http://bugs.winehq.org/attachment.cgi?id=29848) [details] [details]
Temporary patches for D3DXCreateMeshFVF/ID3DXMesh for wine-devel
My apologies... either wine-devel scrubs my attachments and does not get my posts through or the web interface does not seem to pick up the emails in time... in any case I wanted to make sure to get this out.
If you mean the wine-patches archives with web interface, that one usually only gets refreshed every two hours or something. Anyway, from my personal experience, quick-but-not-quite-correct patches with the promise of "doing it properly lateron" tend to get rejected with the reason "no, do it properly from the beginning"... i.e. you should prolly implement D3DXCreateMesh first, it's not that much work anyway.
Ok, here is my argument why we _should_ use FVFs internally: 1) D3DXCreateMesh _only_ allows declarations that map to FVFs http://msdn.microsoft.com/en-us/library/bb172780%28v=VS.85%29.aspx
pDeclaration [in] LPD3DVERTEXELEMENT9
Array of D3DVERTEXELEMENT9 elements, describing the vertex format for the returned mesh. This parameter must map directly to a flexible vertex format (FVF).
2) If we implement D3DXCreateMesh first we still have to implement D3DXFVFFromDeclarator for index buffer creation
IDirect3DDevice9::CreateIndexBuffer http://msdn.microsoft.com/en-us/library/bb174357%28VS.85%29.aspx
3) The goal of wine, per Alexandre's private email to myself:
--- Our goal is not to implement the Win32 API just for the sake of it, it's to run actual Windows applications. So APIs that are not used in real life don't need to be implemented. --- (FYI this had to do with a teapot discussion and so is clearly taken out of the context. However, I believe the point I got from this is that our goal is to make things work on Wine. FVFs would work much better and make implementation quite a bit easier to make Ship Simulator 2008 demo work (better) under Wine.
Thanks Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #48 from Tony Wasserka tony.wasserka@freenet.de 2010-07-28 12:02:11 --- (In reply to comment #47)
Ok, here is my argument why we _should_ use FVFs internally:
- D3DXCreateMesh _only_ allows declarations that map to FVFs
http://msdn.microsoft.com/en-us/library/bb172780%28v=VS.85%29.aspx
pDeclaration [in] LPD3DVERTEXELEMENT9
Array of D3DVERTEXELEMENT9 elements, describing the vertex format for thereturned mesh. This parameter must map directly to a flexible vertex format (FVF).
Yeah, problem with that: You CAN actually create meshes with vertex decls which don't match any FVF. Not with D3DXCreateMesh, but with ID3DXBaseMesh::CloneMesh. It won't fail if the vdecl doesn't match an FVF and at least one of the DX SDK samples actually depend on this feature. So you'll at least need to use vdecl vertexbuffers internally to make this work.
- If we implement D3DXCreateMesh first we still have to implement
D3DXFVFFromDeclarator for index buffer creation
IDirect3DDevice9::CreateIndexBuffer http://msdn.microsoft.com/en-us/library/bb174357%28VS.85%29.aspx
huh, why do we need D3DXFVFFromDeclarator for CreateIndexBuffer? oO Anyway, yes, then we'll have to implement D3DXFVFFromDeclarator first... no, we don't need to actually. I already implemented it as well in my git repo (mesh.c), doesn't even look that hard to get into master ;)
- The goal of wine, per Alexandre's private email to myself:
Our goal is not to implement the Win32 API just for the sake of it, it's to run actual Windows applications. So APIs that are not used in real life don't need to be implemented.
(FYI this had to do with a teapot discussion and so is clearly taken out of the context. However, I believe the point I got from this is that our goal is to make things work on Wine. FVFs would work much better and make implementation quite a bit easier to make Ship Simulator 2008 demo work (better) under Wine.
uhm well, but there are more applications than just Ship Simulator 2008... I'm not saying just to give you more work, but it'd be kind of useless if one had to restructure the whole code to get ANOTHER app running just because the previous implementation only focused on that one game :/
Best regards Tony
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #49 from Misha Koshelev misha680@gmail.com 2010-07-28 12:14:33 --- (In reply to comment #48) Thank you for your comments.
Just wanted to note I talked to Henri today about this and he believes declarations are probably the way to go as this is used internally by wined3d.
He pointer me to: ConvertFvfToDeclaration() in wined3d
but he mentioned that even if this was submitted as a patch today, it would not get in.
Thus, he wants to see a _perfect_ implementation.
I have (very briefly) looked at the version in your repo, but I will most likely try to make one de novo as Henri seems to have very high standards regarding a D3DXFVFToDeclaration function (I don't mean to say your function isn't good enough - and I'm pretty sure mine won't be either if existing functions in wine git are not good enough - but if I am going to have to revise it 8-9 times it is easier for me to start from scratch and perhaps input parts from yours later).
Anyway I appreciate all your feedback and all your hard work.
Thank you Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #50 from Tony Wasserka tony.wasserka@freenet.de 2010-07-28 13:13:53 --- (In reply to comment #49)
Thank you for your comments.
Just wanted to note I talked to Henri today about this and he believes declarations are probably the way to go as this is used internally by wined3d.
He pointer me to: ConvertFvfToDeclaration() in wined3d
but he mentioned that even if this was submitted as a patch today, it would not get in.
Thus, he wants to see a _perfect_ implementation.
I have (very briefly) looked at the version in your repo, but I will most likely try to make one de novo as Henri seems to have very high standards regarding a D3DXFVFToDeclaration function (I don't mean to say your function isn't good enough - and I'm pretty sure mine won't be either if existing functions in wine git are not good enough - but if I am going to have to revise it 8-9 times it is easier for me to start from scratch and perhaps input parts from yours later).
Anyway I appreciate all your feedback and all your hard work.
Thank you Misha
My implementation of D3DXFVFToDeclaration is mostly just a copy-paste of ConvertFvfToDeclaration anyway (although the latter one has been modified a bit meanwhile), so it doesn't really matter which one you chose as a guide or if you chose none at all :P I guess it'd be better to implement that function stepwise though.. like "first patch supports position and color elements" "second supports texture coordinates" "third supports ..."; especially since you'll have to write tests for all of this stuff :/ (I have written some already, but one could test more specifically instead of in a all-in-one fashion like I did)
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #51 from Henri Verbeet hverbeet@gmail.com 2010-07-28 16:19:29 --- There are some tests in d3d9/tests/vertexdeclaration.c.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #52 from Misha Koshelev misha680@gmail.com 2010-07-28 16:52:14 --- Created an attachment (id=29893) --> (http://bugs.winehq.org/attachment.cgi?id=29893) Brute force tester for declaration -> FVF conversions
Thank you Henri.
I found some useful tables on MSDN: http://msdn.microsoft.com/en-us/library/bb147173%28v=VS.85%29.aspx http://msdn.microsoft.com/en-us/library/bb147172%28v=VS.85%29.aspx
I wanted to double check Windows behavior and so made a brute force tester (attached).
Onwards and upwards.
http://bugs.winehq.org/show_bug.cgi?id=22918
Misha Koshelev misha680@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #29893|0 |1 is obsolete| |
--- Comment #53 from Misha Koshelev misha680@gmail.com 2010-07-28 18:01:47 --- Created an attachment (id=29894) --> (http://bugs.winehq.org/attachment.cgi?id=29894) Brute force tester for declaration -> FVF conversions
I realize you guys probably think I am reinventing the wheel here (I am), but this does allow some nice testing and I prefer to approach Windows as a black box, as I have found, in my prior work with Wine, MSDN is often wrong.
For example, unless I messed something up, I have updated the tester to show that if we split up a declaration, we do indeed get the same FVF codes as if we had converted each sub-declaration individually and ORed the resulting FVF codes together.
Obviously, if the sub-part does not have a member with a usage of D3DDECLUSAGE_POSITION, the second FVF conversion fails.
In any case, I don't think this is the best example, but you get the picture.
Thank you Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
Misha Koshelev misha680@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #29894|0 |1 is obsolete| |
--- Comment #54 from Misha Koshelev misha680@gmail.com 2010-07-28 22:00:39 --- Created an attachment (id=29898) --> (http://bugs.winehq.org/attachment.cgi?id=29898) Brute force tester for declaration -> FVF conversions, current version (texture coordinates currently broken)
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #55 from Misha Koshelev misha680@gmail.com 2010-07-31 10:29:08 --- Created an attachment (id=29947) --> (http://bugs.winehq.org/attachment.cgi?id=29947) Test for D3DXCreateSphere.
Same as http://www.winehq.org/pipermail/wine-patches/2010-July/091578.html
Posting so can post other two patches for wine-devel discussion. Thank you
Misha
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #56 from Misha Koshelev misha680@gmail.com 2010-07-31 10:29:34 --- Created an attachment (id=29948) --> (http://bugs.winehq.org/attachment.cgi?id=29948) patch 2 - _D3DXMESH enumeration for D3DXCreateMeshFVF
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #57 from Misha Koshelev misha680@gmail.com 2010-07-31 10:30:01 --- Created an attachment (id=29949) --> (http://bugs.winehq.org/attachment.cgi?id=29949) Stub and test for D3DXCreateMesh.
http://bugs.winehq.org/show_bug.cgi?id=22918
Pavel Ondracka drakkk@centrum.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |drakkk@centrum.cz
--- Comment #58 from Pavel Ondracka drakkk@centrum.cz 2010-09-01 10:46:10 CDT --- Fritz 11 needs D3DXCreateMeshFVF too.
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #59 from Austin English austinenglish@gmail.com 2010-09-22 21:09:13 CDT --- Quest 3D demo wants D3DXCreateCylinder: http://download.quest3d.com/Demos/Quest3D_Demo_Qumulus.exe
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #60 from Austin English austinenglish@gmail.com 2010-09-23 12:45:59 CDT --- (In reply to comment #58)
Fritz 11 needs D3DXCreateMeshFVF too.
It's now committed: http://source.winehq.org/git/wine.git/?a=commit;h=e4182ead47ff4094dd397afccf...
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #61 from Austin English austinenglish@gmail.com 2010-09-24 12:29:43 CDT --- And, now we've got a teapot stub: http://source.winehq.org/git/wine.git/?a=commitdiff;h=10af823fd59ed0e49068d4...
Still needs: wine: Call from 0x7b8367e3 to unimplemented function d3dx9_36.dll.D3DXCreateCylinder, aborting
http://bugs.winehq.org/show_bug.cgi?id=22918
--- Comment #62 from Austin English austinenglish@gmail.com 2010-09-27 12:45:05 CDT --- D3DXCreateCylinder stub is now in: http://source.winehq.org/git/wine.git/?a=commitdiff;h=fe9db6faf7fdf5a969d69c...
now Ship Simulator crashes on wine: Unimplemented function d3dx9_36.dll.D3DXSaveSurfaceToFileInMemory called at address 0x7b836823 (thread 001b), starting debugger...
stubbing that gets to d3dx9_36.dll.D3DXCreateCubeTexture.
Didn't try beyond that.
http://bugs.winehq.org/show_bug.cgi?id=22918
the.ideals@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |the.ideals@gmail.com
--- Comment #63 from the.ideals@gmail.com 2010-09-28 06:37:12 CDT --- Can this bug be closed as fixed? The next bugs encountered already have entries.
http://bugs.winehq.org/show_bug.cgi?id=22555 http://bugs.winehq.org/show_bug.cgi?id=23706
http://bugs.winehq.org/show_bug.cgi?id=22918
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #64 from Austin English austinenglish@gmail.com 2010-09-28 12:17:10 CDT --- (In reply to comment #63)
Can this bug be closed as fixed? The next bugs encountered already have entries.
http://bugs.winehq.org/show_bug.cgi?id=22555 http://bugs.winehq.org/show_bug.cgi?id=23706
Yes, I think so. This bug has gotten pretty long and become a d3dx9 stub bandwagon.
Please file a new bug for any other issues. One function per bug, please.
http://bugs.winehq.org/show_bug.cgi?id=22918
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #65 from Alexandre Julliard julliard@winehq.org 2010-10-01 13:57:28 CDT --- Closing bugs fixed in 1.3.4.
https://bugs.winehq.org/show_bug.cgi?id=22918
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |fe9db6faf7fdf5a969d69c0a9da | |7f1ca22553829 CC| |focht@gmx.net
-
wine-bugs＠winehq.org