Not long back from seeing CombiChrist in london myself; awesome times all around [grin]

Apprently there were some people there who were at the Edinburgh gig as well :o

Quote: Original post by Evil Steve
I'm on Vista if that makes any difference?

I did that test at home and I'm also on Vista. Vista Home Premium SP1, MSVC 2005 Standard SP1, 175.90 Acer video drivers (they're old but it's a notebook and HDMI port doesn't seem to like modded desktop nvidia drivers). I'm compiling against Windows SDK Feb 2007 and DirectX SDK Aug 2008.

Where do you call SetD3DDevice?

Quote: The GPU is single-threaded, so you have to do some marshalling to combine input from multiple threads / processes / devices into one path for the GPU.

Yes, that's my point.

I've got a couple of heavy scenes to render and yesterday decided to try something different. I've spent some time on MSDN and I'm still confused.

The documentation clearly states VMR9 is the way to go for integrating videos in games. Furthermore the suggested video renderes are VMR9 for XP and EVR for Vista. What I missed last time I read the documentation is the fact VMR7 is still the default video render, even on Vista!

Old renders (i.e. legacy video render) are never selected by default.

Asking DirectShow to play a video without specifying any video render should enable VMR7, which is named after DirectDraw7. As for DD7 I guess nowadays it's hw-accelerated on *everything*. It could probably put less pressure than VMR9 but it's another thread accessing the GPU. I didn't tried building a VMR7 graph, neither looked at how VMR7 works, as it doesn't seem the way to go.

I'm taking another approach: trying to grab a frame with ISampleGrabber and updating my texture from an intermediate buffer I fill via a custom callback class derived from ISampleGrabberCB.

It looks promising.

I still have a couple of problems which I hope to fix today:
- there's a tremendous speed improvement, but my video is completely desynched from audio. It runs at approx 10x the original speed! From a programmer's POV it's cool to see a video running at 250fps, I guess the same doesn't apply to a customer! :D Oh and it works without creating a multithreaded device.
- There's a severe design issue about which class is responsibile of updating the texture map.

As for the first issue, it should be about the way the graph builder creates the graph. I've run into weird behaviours, expecially if I try to build what looks like a malformed graph (by manually connecting some pins) I am able to disconnect those pins later and get a working one. If I let the graph builder do everything for me, the ISampleGrabber isn't connected to anything meaningful.

My guess is when I connect 2 pins the corresponding filters enter into a new state, then after the graph builder fails, I disconnect the pins but the filters keep the modified state, allowing the second RenderEx call to build a "proper" graph. Calling RenderEx without connecting pins results in a graph which doesn't seem to include my ISampleGrabber filter (breakpoints in my callback class are never reached), despite returning S_OK.

The design issue is more complicated. The media file class updates a texture which I can set everywhere, from materials to lightmaps. The idea is the material/light/whatever doesn't know its texture comes from a video, so it can't ask the video to update it.

The texture can't be directly added to my scene graph/scene list/scene descriptor, as it's not renderable without geometry, so while updating the scene there's no way I can update the video.

ATM it's the application responsibility to ask the video to update the texture, this allows me to safely lock the surface but I'd like this process to be completely transparent to the programmer. In VMR9 I updated my surface from the allocator/presenter, so with a multithread device and critical sections the operation was transparent.

Sorry for the long and boring post, if you like I can post an update if this evil thing works... :)