That pretty much what I meant, you just explained it in a clearer way... I only had a minute or so to type it in heh. The irony here is I was writing it while playing WoW via wine through opengl... The factor of irony is overwhelming =P. I basically agree. I figured (without actually looking at it) that d3d was a shared code-base of some kind with the individual dx dlls basically pointing here and there for the nuggety center. Now just throwing up a (pretty much) mock up of d3d10 or dx10 in general would be great, it would atleats give a little structure, and as you said ease the code to a new structure if need be.
<br><br><div><span class="gmail_quote">On 3/10/07, <b class="gmail_sendername">Stefan D�singer</b> <<a href="mailto:stefandoesinger@gmx.at">stefandoesinger@gmx.at</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am Sonntag 11 M�rz 2007 00:06 schrieb Bryan Haskins:<br>> I'm no actual dev here by any means, but I think anything more than setting<br>> up the extreme basics would take away from the work done on 8, and 9. As
<br>> not much uses 10 yet it would be a bit premature to do a ton of work on it.<br>> Porting the current code if only to the point of 10 working as well as 9 or<br>> 8 without the fancy new calls would suffice for now, and yes, I also think
<br>> we should have a Vista version if only for the sake of consistency, it<br>> wouldn't really be any different than XP for us at the core just throwing<br>> the tag up there.<br>The idea is that our main Direct3D engine, wined3d, is shared between all
<br>Direct3D versions, from Direct3D 1 to Direct3D10. Admitadely, the core<br>functionality that is equal between d3d1 and d3d10 is comparably small, and<br>the part that exists should work pretty well by now. But work on d3d10 games
<br>can definitly fix bugs in d3d9 apps accidentally, in the same way the d3d7<br>merge fixed bugs in wined3d that affected d3d9 apps.<br><br>Also consider that d3d10 may need some architectural changes to wined3d. I<br>think it is better to make them now and when further optimizing it have
<br>things in the d3d10 style than to drive everything to d3d9 and see in a year<br>that we have to turn a few core parts upside down.<br><br>Of course having one SoC project on d3d10 does not exclude someone else who<br>
wants to do something do a SoC project on d3d9 :-) . Ideas would be Overlay<br>support for movie players or the d3dx9_xy helper DLLs(Although those are<br>maybe out of scope for wine). Or even a completely different area of DirectX.
<br>DirectSound, DirectPlay, ...<br><br>> I say focus SoC on 8 and 9, imagine having a more complete 8 and 9 then 10<br>> would be cake, as I understand it all it does it add new calls right? And<br>> possibly dig up the theming zombie, so we might have that finally lol.
<br>One problem is nowadays that wined3d is pretty advanced already, and the<br>learning curve is rather hard already. D3D10 is in my eyes an oportunity of<br>an exciting project which allows a new developer to grow into wined3d. I
<br>personally won't start hacking on d3d10 immediately, I'll continue to work on<br>d3d9 and below apps. The state of d3d9 does not justify that yet.<br><br>And I think that *Direct3D* isn't in a bad shape nowadays. We recently had a
<br>nice success when that new Command and Conquer game came out, and ran on the<br>day it hit the shelves. Wine is getting the public opinion that it does<br>better on games than Cedega. What we should not shout our loudly is the shape
<br>of other DirectX stuff. DirectSound is an issue, although I must say that<br>Maarten Lankhorst is doing nice work on winealsa :-)<br><br></blockquote></div><br><br clear="all"><br>-- <br>Cheers,<br>Bryan