MyMikeD

Members
  • Content count

    3
  • Joined

  • Last visited

Community Reputation

102 Neutral

About MyMikeD

  • Rank
    Newbie
  1. #superbowl only 2 more hours of pregame #sigh
  2. Anderson C-Train station has been made up as one big U of L advertisement #ourtaxmoneyatwork
  3. Gotta love chinooks. Got the BBQ fired up tonight! #flamein
  4. Victory in Taber. Makes the long bus ride a bit better. #peeweehockey
  5. On the bus to Taber for our last regular season road game
  6. Our peewee hockey provincial playdowns begin today. First opponent Lethbridge. Hopefully the boys are awake!
  7. Had some Chinese BBQ. But not so good for me. Ate too much! @jiffyporne
  8. New twitter photo! I'm sure it was a love song... wink!
  9. Yes we are using d3dImage to render the Direct3D 10 scene via a shared texture... there is also some Direct2D stuff mixed in there as well. So it's a bit of a complicated scenario with making use of shared surfaces. Turns out that yes indeed it was a synchronization issue. The different results I had on different cards was a result of how fast the card could render my scene. If it could render it fast enough before extracting it to the d3dImage then I was fine, if not then stuff was dropped. This article describes the issues and the solutions http://archive.msdn.microsoft.com/D3D9ExDXGISharedSurf All I had to do was the "mapping staging texture" trick (my case I'm not worried about multiple threads) and voila things seem to be synchronized now fine on all cards. Below is the piece of slimDX code I used (I'm using D3D10) to synchronize after rendering my D3D10 scene : [CODE] const int subResourceNumber = 0; ResourceRegion resourceRegion = new ResourceRegion { Back = 1, Bottom = _stagingTexture.Description.Height, Front = 0, Left = 0, Right = _stagingTexture.Description.Width, Top = 0 }; _device.CopySubresourceRegion(_renderTexture, subResourceNumber, resourceRegion, _stagingTexture, subResourceNumber, 0, 0, 0); _stagingTexture.Map(subResourceNumber, MapMode.Read, MapFlags.None); _stagingTexture.Unmap(subResourceNumber); [/CODE]
  10. Found this thread after I had posted [url="http://www.gamedev.net/topic/606138-slimdx-issues-with-keyedmutex-and-wpf/"]http://www.gamedev.net/topic/606138-slimdx-issues-with-keyedmutex-and-wpf/[/url] I'm going to try the "staging resource" technique for synchronizing and see if that fixes the problem. Will post the results!
  11. Hi, Our application is using Shared Surfaces to interop between Direct3D10 and WPF (using d3dimage). Basically the concept is to created a shared Direct3D9 surface that is attached to the d3dimage and then have Direct3D10 render to that shared Direct3D9 surface. There is an SlimDX example that does this as well. We use the code from the example in our application. We have been finding some strange drawing anomalies using this technique on some cards. Basically it looks like the image is only partially rendered. My current theory is that this is because of synchronization issues between the shared surfaces. I stumbled upon this article and info about synchronization [url="http://archive.msdn.microsoft.com/D3D9ExDXGISharedSurf"]http://archive.msdn.microsoft.com/D3D9ExDXGISharedSurf[/url] From what I can tell the SlimDX code for doing this shared surface stuff to WPF doesn't have any of this type of stuff in it. Should it? Also is any of the queue functionality described in this D3D9ExDGIISharedSurf API (ie ISurfaceQueue, ISurfaceProducer, ISurfaceConsumer) exposed via SlimDX? Thanks, Mike
  12. Ham part of show? RT @JiffyPorne I took back the empties and with the $ bought drumsticks and Ham #recyclingrocks http://t.co/mpovsX0I