Tom Miller's Blog

The Ramblings of Miller. These postings are provided "AS IS" with no warranties, and confer no rights.

Known issues with Whidbey Managed DirectX

Known issues with Whidbey Managed DirectX

  • Comments 18

So, how is it that I can get scooped by my own information?  (Just kidding ZMan, I appreciate it!)

Anyway, two main known issues with the Whidbey MDX Beta.  First, it requires VS2005 Beta2.  Nothing later.  Those of you using RC0 will get "FileNotFound" exceptions when trying to load the assemblies.

Two, there is a large 'chunk' of D3DX that is 'missing' from the assembly due to a mistake on my part.  It is most certainly unintentional.  (Oh, and MatrixStack is a D3DX component too, despite it being in the Microsoft.DirectX namespace).

We are working on getting these issues addressed as quickly as possible.  One of the benefits of releasing every other month though is no matter what, you don't have *that* long to wait for updates.  Please keep the feedback coming, particularly on design issues, but on anything you feel the need to tell me about.

  • *More Feedback*

    I have a problem: My application allows any plug-in to add "assignable axes" to my Input-class during runtime.
    All these axes, which have been added during runtime, can be assigned to any enumerated device-object-instance of a joystick during runtime. Thus, I cannot use static structures for device-state-retrieval.

    This was no problem with earlier MDX-releases. I could use buffered-data, and identified arbitrary device-object-instances by looking at BufferedData::Offset.

    With MDX-October, all buffered-device-data-retrieval seems to have disappeared!!!

    The closest equivalent would probably be the Generic Device::GetCurrentDeviceState<T>, which (I guess) accepts a type which resembles the one I set with Device::SetDataFormat.

    Now the deal is, that I know my axes during runtime only, so I have no ready-to-use device-state-structure to pass as generic argument!

    As a thought-experiment, I could create one using reflection, but it would most likely be too slow to enumerate the reflected members on a per-frame base.

    In native C++, could have probably passed some chunk of typeless memory, and then cast myself into heaven.

    But in managed world, I cannot even pass an array of bytes, because only Value-types are accapted as generic-argument for Device::GetCurrentDeviceState.

    So, basically, assuming that I program a flight-simulator, the "mission-critical" *fully assignable* input-system is currently screwed up due to the removal of buffered-device-data-retrieval.
    No chances to go a non-buffered way due to the runtime-flavour of my input-system.

    I would really love to see buffered device-data-retrieval in the next release again ... PLEASE. Don't forget, that it's a basic functionality of native DX.

    Another good way to retrieve abitrary buffered input-data would be like it's done in D3D with the GraphicsBuffer<T> class. That would be really cool, example:

    GenericInputStream^ stream = m_Device->GetCurrentDeviceData();
    int axis1 = stream->Read<int>();
    int axis2 = stream->Read<int>();
    bool button1 = stream->Read<bool>();

    However, re-introducing the BufferData/BufferedDataCollection would be even more cool, since my system already utilizes them.

    I hope I don't sound like a diva, but a fully assignable dynamic input-system shouldn't be too special, right?
  • Please put the wrapper classes for the native DirectInput "action mapping" capabilities back in as well (including the old Manager.ConfigureDevices). While we would like to see replacements for this at some point, we just don't have time to reinvent all of this right now.
  • I've probably found two potential issues with D3D.

    1)Device.set_VertexShader
    It calls the function with the offset 0xc4 in the vtable of IDirect3DDevice9, but the offset for SetVertexShader is 0x170. (at least in the old d3d for win32)

    2)Device.get_VertexDeclaration
    This function returns always null. Comparing to the old MDX it seems that the following is missing at the end:

    if (declarationPtr1 != null)
    {
    return new VertexDeclaration(declarationPtr1, this);
    }
  • Dear Santa Claus,

    just one more little suggestion for the december-event:
    I would love to see a ScissorBox-property in Direct3D::Font.
    (This would really help to realize labels in scrollable containers when thinking of a D3D-vector-GUI.)

    It shouldn't be too difficult, as the the Scissor-rectangle-renderstate just has to be included in the corresponding state-block* of the font-class. It wouldn't even break existing applications, as this property could be set to the entire screen by default.

    ---
    *) the state-block, which overrides previous scissor-settings
  • what about "LightType" enums.
    I can't find any enum constants in LightType.
    Currently...

    ~Lights[0].LightType = (LightType)2;

    Is this a mistake, or intentional?
  • Daniel, I mentioned this bug in Tom's previous post. It's definitely a bug. Note that Tom has said 40% of D3DX is accidentally missing, I'd bet a paycheck that the LightType enum is restored in the November SDK.
  • I hope we don't have to wait until November for the MDX fix if this was just a compile/build error. I would like to do a real compile with the Visual Studio 2005 Beta 2 before needing to install another Visual Studio update/release.
  • I'd still set my personal worst-case scenario to December.

    The good thing about this would be, that the longer they develop, the more bugs will be removed -> would make the December-February-period more pleasant to work with MMDX (mature managed DX).

    However, my project is currently still not in a representative state, and I hope this ends ASAP (mainly due to DI).
  • In a discussion on GameDev some concerns & comments were posted about the 'non-Whidbey' October release of MDX. Quite some valid points are made I think, so it might be worthwhile to check it out:

    http://www.gamedev.net/community/forums/topic.asp?topic_id=349441
  • Any chance of a working version of AudioVideoPlayback to render a video on a texture? I bought your books.
  • Can you please help

    old code

    OcclusionQuery = new Query(device, QueryType.Occlusion);
    OcclusionQuery.Issue(IssueFlags.Begin);

    device.RenderState.ZBufferEnable = true;
    device.RenderState.ZBufferWriteEnable = false;

    RenderMesh(device);

    OcclusionQuery.Issue(IssueFlags.End);

    device.RenderState.ZBufferWriteEnable = true;

    bool l_bData = false;
    int TotalDrawOfPixelInScene = 0;

    while (!l_bData)
    {
    TotalDrawOfPixelInScene = (int)COcclusionQuery.GetData(typeof(int), true, out l_bData);
    }


    new code
    bool Data = false;
    int pixelsVisible;

    OcclusionQuery = new Query(device, QueryType.Occlusion);
    OcclusionQuery.Begin();
    device.RenderState.ZBufferEnable = true;
    device.RenderState.ZBufferWriteEnable = false;
    RenderMesh(device);

    OcclusionQuery.End();
    device.RenderState.ZBufferWriteEnable = true;

    while (!l_bData)
    {
    pixelsVisible = OcclusionQuery.GetData<help here>(true, <help here>);
    }
    Mh@3devolution.net
  • Hi,

    I am relatively new to DirectX and trying to hack with Mananged DirectX to make some prototype done ASAP. Is there a way to use vertex texture fetch in Managed Direct3D? It seems that SamplerState[] or SetSamplerState() don't take index values corresponding to D3DVERTEXTEXTURESAMPLER0 or above.
  • Any info on when we can expect an update to the SDK that works with the Visual Studio 2005 release?
  • I understand that some D3DX-related classes were missing in October. If possible, please ensure that DirectInput/ActionMapping and DirectX Diagnostics classes are also fixed in the December release. Thanks.
  • How about an official bootstrapper for Managed DirectX. Deployment is somewhat of a nightmare.
Page 1 of 2 (18 items) 12