02-22-2009, 12:02 AM
I looked everything over, and I'm still stumped. >_<
I did research on D3D (not usually one of my knowledge bases), and found that D3D init/create functions will assert and fail if run outside a proper multithreaded context. Furthermore, that context is constructed entirely by Gsdx/ZeroGS after window creation (meaning that the order in which I call plugin load/init/open functions is irrelevant, since only Open actually does anything, and happens to do everything). Now in your case the window is being created and D3D is initialized fine. The freeze happens when the window is shown, and then the second freeze immediately after the window is shown. So apparently I was wrong, and the hard lock occurs during the Windows Message Loop for the Gsdx window, which means it has little or nothing to do with D3D itself.
Sum up: I'll revisit my Windows Message Loop changes in pg r488, and see if anything jumps out at me. Pcsx2's own message loop shouldn't affect Gsdx's but.. well.. who knows. :/
I did research on D3D (not usually one of my knowledge bases), and found that D3D init/create functions will assert and fail if run outside a proper multithreaded context. Furthermore, that context is constructed entirely by Gsdx/ZeroGS after window creation (meaning that the order in which I call plugin load/init/open functions is irrelevant, since only Open actually does anything, and happens to do everything). Now in your case the window is being created and D3D is initialized fine. The freeze happens when the window is shown, and then the second freeze immediately after the window is shown. So apparently I was wrong, and the hard lock occurs during the Windows Message Loop for the Gsdx window, which means it has little or nothing to do with D3D itself.
Sum up: I'll revisit my Windows Message Loop changes in pg r488, and see if anything jumps out at me. Pcsx2's own message loop shouldn't affect Gsdx's but.. well.. who knows. :/
Jake Stine (Air) - Programmer - PCSX2 Dev Team