RE: Full-screen, exclusive-mode video and D3D debugging

Hi,

I uploaded my source code to my blog at
http://www.ostrogothia.com/?page_id=405 if you want to check it out. You can
find the code for resetting devices etc in the SyncVMR9 project in the
Allocator.cpp file, method CAllocator::ResetDevice. I now remember that you
have to release the *pins* of the VMR9 before reset and then reconnect them
again. I think you will recognize a lot in the source as it was started as a
tweak to the AllocatorPresenter demo project. I think it is possible under
some circumstances to recreate the device w/o releasing the pins but sooner
or later you run into trouble and you also end up leaking memory.

Are you sure that you need to run in exclusive mode? Fullscreen in
non-exclusive mode is much easier to handle because you don't need to
re-create the device. I did get much more fluid video in exclusive mode
though through better timing of the Present method.

Read more about the GothPlayer project on the blog pages.

Pls also note that I'm really an amateur programmer. I haven't written a
commercial line of code since 1989 :-) So there might be a few
"unconventional" solutions in the code. I don't think it leaks any memory
though.

Please let me know if you find anything useful in the source.

Cheers!

Arto

"Doctor Bonzo" wrote:

Hi Arto,

Thanks very much for your reply.

I've been proceeding to develop with the presenter only in fullscreen,
exclusive mode and have had some success without switching between non- and
windowed modes. I find the terminology really confusing since there seems to
be at least 2 other uses of "exclusive mode" in the DirectX canon - one for
input devices and one for DirectDraw surfaces. For my own disambiguation,
I've been thinking in terms of windowed and non-windowed Direct3D devices.

I've discovered that if my WndProc claims to handle WM_NCACTIVATE messages,
then my app doesn't get minimized "behind my back" and I can effectively
debug in a 2 monitor system. Apparently someone hooks my app window and does
stuff when it loses focus through this message. I'm guessing that this
happens inside IDirect3D9::CreateDevice. This 'cheat' seems to keep me from
getting a device-lost return from IDirect3DDevice9::Present, too. I'm pretty
nervous about leaving this in a release build, though, since I don't know
what else might be going on. I'd love to know the whole story, but I haven't
been able to dig it out of any dox.

I still have funny stuff going on with ::ShowWindow(..). Seems like I can
show and hide OK, but if my app is still 'presenting' when the window isn't
visible it shows on the monitor anyway. I suspect this may be result of my
WM_NCACTIVATE preemption and that I'll be able to hack around it by checking
the window visibility before I do any rendering.

But it might be something else, too - I'd be curious to know what COM
interfaces you needed to muck with, Arto, in switching between windowed mode
and non-, just to see if anything sounds suspicious.

A little off-topic, but here's a nugget that might save someone an hour or
two of hair-pulling: the order of monitors you get from EnumDisplayMonitors
and IDirect3D::GetAdapterMonitor is not necessarily the same. The former
seems to return monitors in left-to-right desktop order while the latter
always returns the primary display as adapter 0. Easy to miss the
distinction if your primary is always on the left.
.

Loading