[v2] SlimDX 2 roadmap

[Alexandre Mutel]

Hi all!

 

I have just checked-in a primary support for D3D10 and D3D10.1 for SlimDX 2. There are lots of small API that are not yet fully usable with extensions (like Font or Sprite) but Effects are working, meaning that I was able to compile a SimpleTriangle sample using the D3D10 Effect framework, so that’s pretty cool!

 

The current API coverage for SlimDX2 is:

- D3DCompiler

- Direct3D 11

- Direct3D 10

- Direct3D 10.1

- DXGI

- DXGI 1.1

 

This coverage is not yet fully compliant with SlimDX in terms of names and API extensions. I won’t probably be able to fill in the whole gap on my own, so If you could help me on this, that would be cool.

 

Also, I’m going to integrate the following API:

- DirectWrite

- Direct2D

- XAudio2

 

Looking more at DWrite/D2D API, It seems that I will need a bit more work on those API. Some new API usage like the dual usage of some interfaces (all the *.Sink interfaces) that could be used as callback or default implem provided by D2D. I have seen that there are also some structs using bitfields, but It should be easy to support them.

 

After XAudio2, I will probably work more on a XNA API like project leveraging on API Direct3D11, DWrite, Direct2D and XAudio2. It will be an opportunity for me to check the consistency of the generated API, but I will not probably go on every corners of the SlimDX 2 API...

 

So, I have a couple of question :

- What do you think about the current generated API?

- How/When do you thing we should proceed for a SlimDX 2 alpha public release?

- What about the API coverage for v2? (For example, Direct3D9....etc. => It’s possible to generate them, but will require some mapping work...)

 

 

 

[Josh Petrie]

I have not looked at the actual generated code in detail, so I can't
really comment on that yet. But part of the benefit of this generation
technology is that we can change the nature of the API and rebuild
everything much easier than we could by hand, so that should not be a
concern. At this point in the project I'm more concerned with
re-implementing the existing build and project structure conventions
we have from v1, and/or fixing ones from v1 that were deficient in
some way. That said, however, our policy is to avoid (via svn:ignore
properties) checking in any code that is generated -- part of moving
stuff down to the root will involve setting up appropriate pre-build
steps to ensure generation tools are run as part of a build. That's
the only thing I've noticed so far.

I've been using the hand-written v2 in anger on my own projects and
since you've completed the Effect stuff, I'll be able to switch that
over to use your generated versions this weekend and give it a shot. I
like your idea about writing an XNA-like framework on top of v2 as
another means of doing real-world evaluation (that's how we developed
most of the original SlimDX after all) -- although to be clear that
kind of project isn't something that should be a part of SlimDX
itself.

Our releases are tied to the official SDK releases, and will remain
that way until we deprecate v1. One thing we are going to be focusing
on in v2 is a better release process that does require Promit to
perform mystical voodoo, since he's quite busy with his new startup
these days. To that end we won't be ready to include v2 into any of
our releases for some time - including something in a release, even as
an alpha or a CTP, legitimizes it in some way and I think we're ways
off from being ready to commit to that. We don't want a repeat of the
sample framework disasters.

Users who want access to bleeding edge tech can freely check out and
build the branch on their own, and within the next few weeks we should
have that process down to something that is clean and usable. We will
probably be able to mention that interested parties should check out
the v2 branch in the next SDK release, or the subsequent one,
depending on exactly when the next official SDK drops.

I'm also not worried about D3D9 right now. I wouldn't spend time
mapping it unless you really want to -- we've actually had some
offhand discussion in #gamedev about whether or not we want to drop 9
support at all in v2. So we should look into that decision, as it
would be a big one.

-- jmp

> --
> You received this message because you are subscribed to the Google Groups
> "slimdx-devel" group.
> To post to this group, send email to slimdx...@googlegroups.com.
> To unsubscribe from this group, send email to
> slimdx-devel...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/slimdx-devel?hl=en.
>

[@lx]

Thanks for your response!

On 3 nov, 21:31, Josh Petrie <josh.pet...@gmail.com> wrote:
> I have not looked at the actual generated code in detail, so I can't
> really comment on that yet. But part of the benefit of this generation
> technology is that we can change the nature of the API and rebuild
> everything much easier than we could by hand, so that should not be a
> concern. At this point in the project I'm more concerned with
> re-implementing the existing build and project structure conventions
> we have from v1, and/or fixing ones from v1 that were deficient in
> some way. That said, however, our policy is to avoid (via svn:ignore
> properties) checking in any code that is generated -- part of moving
> stuff down to the root will involve setting up appropriate pre-build
> steps to ensure generation tools are run as part of a build. That's
> the only thing I've noticed so far.

Oh, Great, thanks, I understand a little bit more what are the current
issues with the build process.
Non integrating generated files is fine for me, as far as the building
process is still able to be done from a VS2010 solution (at least for
the dev part. I'm not talking about generating the documentation,
packages for releasing...etc.)
Probably, the generating process should be done outside the VS2010
solution/projects, as part of the more global building process... (For
example, keep in mind that in a C# project, you don't have any way to
express dependencies on generated files from a custom build event...
as it is possible to do in VC++...)

> I've been using the hand-written v2 in anger on my own projects and
> since you've completed the Effect stuff, I'll be able to switch that
> over to use your generated versions this weekend and give it a shot. I
> like your idea about writing an XNA-like framework on top of v2 as
> another means of doing real-world evaluation (that's how we developed
> most of the original SlimDX after all) -- although to be clear that
> kind of project isn't something that should be a part of SlimDX
> itself.

Of course, I was not expecting to release this XNA like layer to
SlimDX2. This is currently more a project on my side to be able to
efficiently build some demos with it.

> Users who want access to bleeding edge tech can freely check out and
> build the branch on their own, and within the next few weeks we should
> have that process down to something that is clean and usable. We will
> probably be able to mention that interested parties should check out
> the v2 branch in the next SDK release, or the subsequent one,
> depending on exactly when the next official SDK drops.

Agree. I don't really want to be under the pressure of alpha-users
testing it yet! But as soon as there is a workable Direct3D10,
Direct3D11, Direct2D and DirectWrite, I will probably post this info
on my blog and tweet about it... - though my audience is tiny...
probably a post under gamedev as well?

>
> I'm also not worried about D3D9 right now. I wouldn't spend time
> mapping it unless you really want to -- we've actually had some
> offhand discussion in #gamedev about whether or not we want to drop 9
> support at all in v2. So we should look into that decision, as it
> would be a big one.

Ok great, that's fine, I'm not using anymore D3D9 so... There is
probably a slight concern with interoperability issues like with
WPF... but that could probably done with some custom handmade example
code...

[Michael Popoloski]

I really don't think it's a good idea to drop D3D9 support, especially if we're only doing it to avoid a little extra work. I think a lot of people view the all-encompassing nature of SlimDX as one of its most attractive features, and I don't see the benefit in dumping them. Sure, it's not the ideal choice these days, but we effectively cut off all current users of D3D9 in SlimDX from getting further updates or benefits we put into V2, as I certainly don't want to be supporting both versions of the library at the same time. Further, another one of our commonly touted features is interoperability with other DirectX libs. Anyone using SlimDX to supplement XNA development will be left out in the cold.

--

[Richard]

In article <AANLkTimfjxnxiEM_FeuA0uyT4qvxBh6htJQzpFLM7R=N...@mail.gmail.com>,
Michael Popoloski <mike.po...@gmail.com> writes:

> I really don't think it's a good idea to drop D3D9 support [...]

I would add that as long as a significant number of people are using
XP, D3D9 support should be kept. Yes, Win7 is better than Vista, but
I still see many people preferring XP and targetting that for
development.

I know that if it weren't for D3D10/11 being Vista/Win7 only, I would
still be on XP.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

[@lx]

I would have think about leaving DirectX9 in SlimDX 1... but agree
that users would not benefit from SilmDX 2 features (separate
lightweight anycpu assemblies)... as well as keeping a separate
support for SlimDX 1.

So I will probably generate an alpha interop for Direct3D9, but won't
take too much time to fix all stuffs (like adding custom code for
extensions...etc.)

The good news is that raw interop for Direct2D and DirectWrite is
almost done. I have now to handle the double usage of the Sink
interfaces (default implem by direct2D as well as user defined implem
callback). I will try to add as much as extensions I can, but probably
won't cover all aspects (especially DirectWrite which as a huge load
of methods, mostly useless for rendering usage...). I had to pack
Direct2D and DirectWrite all together in the same assembly, as they
have some circular references... I didn't want to introduce a separate
assembly for that, and perform myself the decoupling. I will wait
Microsoft to do that (They will probably have to do that If they are
going to release a Direct2D 2 version)

I had a bit of headache also to make some extensions to the interop
model, to support passing by value for struct that are define in the
assembly itself (like in Direct2D and DirectWrite). This particular
interop is not as fast as the regular one (around 20% slower) but the
number of methods using this interop is negligible (probably < 0.01%)
and are not critical methods used for rendering so...

At some point, I will definitely have to work on cleaning
XIDLToCSharp, as it is becoming harder and harder when I need to
handle a new parameter interop... too much mess in the code right now.

[Alexandre Mutel]

Good news! I have been able to generate a workable API for Direct3D9!

I did already lots of mapping, only in order to have a somewhat consistent naming with SlimDX (at least for Enums, Structures, and probably Interfaces).

 

The MiniTri sample is working... though, It’s more a proof of concept than a fully implemented API with all extensions.

There are a huge amount of work to make it fully working, tagging parameters with correct type, attribute.... create enums from macros, renaming structure fields....etc... and adding all the extension class (new Texture()...etc.)

 

You will find also 3 Direct2D1 API that demonstrates the usage of text rendering with DirectWrite and Tessellate method from Direct2D1.

 

After this, I’m not going to work on Direct3D9 anymore (at least not alone on this huge task). I’m just going to check how well DirectSound and XAudio2 are generated, and probably add one sample for each of these API.

 

The good thing about supporting Direct3D9 is that I was forced to have a better parsing of the C struct, typedefs and to implement new mapping cases...etc. Now, even DirectWrite has bitfields structures working!

The bad thing is that Direct3D9 has C headers that are badly written. Lots of information is missing and need to be added manually to the mapping process (to the ProgramDirect3D9.cs above).

 

[@lx]

The link didn't work: the mapping used for Direct3D9 is specified
here : http://code.google.com/p/slimdx/source/browse/branches/v2/SlimDX2/Tools/XIDLToCSharp/ProgramDirect3D9.cs