- Apr 12, 2008
- Reaction score
So, if I want to contribute to OVP by working on a d3d11 based engine, what do you think is the best way to do that ? Should I work on some advanced features that D3D9Client don't have now(heightmaps for example) or should I work on conversion of some pieces of d3d9client to d3d11 (the same thing you're going to do now) ? And what should I do after I complete something. Merge it with your code from bitbucket and release updated code somewhere ?That sounds promising. You are more than welcome to contribute to OVP, of course. I'm not in the position to allow contribution (or disallow it, for that matter), so you don't have to ask me at all.
I will keep the sources in Mercurial on BitBucket, since I have Martin's SVN repository mirrored there, as well as Jarmo's ZIP releases converted to commits. Therefore, nothing stops you or other interested developers from cloning that repository and hacking away. My repo there is by no means "blessed".
BTW, have you already decided how to implement surfaces/textures and blit/fill/create/getdc functions ? In my version of d3d11client I decided to make 2 kinds of textures: First are in the same format as a source image (dxt1,3,5 etc), can have mipmaps and created as resources with immutable usage, and with no miscflags. Second are in B8G8R8A8 format (the only texture format that allows sucessful usage of getdc() ) have no mipmaps, created with default usage and with gdi compatibility miscflag. First type of textures can be used only for rendering. Second can be used for rendering, gdi drawings and blit/fill functions. Any of blit/fill/etc functions checks texture type, and converts any first type texture to second by creating new second type texture with the same dimensions and rendering a textured quad over it. FillColor() functions can be implemented effectively by setting some texture as rendertarget and filling it with ClearRenderTargetView() function (4-5 mcrsec. ). Blit can be implemented by CopySubresourceRegion() (7-8 mcrsec. ) or by rendering a quad in case of a colorkey flag or src == NULL (30-80 mcrsec.). Also, I found that GetDC() and CreateTexture2D()/CreateBuffer() functions are pretty slow (200-600 mcrsec. and 200-500 mcrsec.), so may be it is a good idea to not use them more than it's required.I'm pretty sure some parts need a rewrite, but I also think that many things can be directly inherited from the D3D9Client.
This approach worked with default, DG3, DG4, XR2 panels without bugs.