I am investigating Panda3D for web runtime (ActiveX on windows XP).
Currently I can build all the modules and can run the the ActiveX with VS2008 debugger.
I can build and debug the p3dpythonw.exe, however p3dpythonw failed to import Virtual File System at line:
_vfsimporter.pyd is the first DLL loaded by the runtime (after p3d_plugin.dll). It contains the Python code in direct/src/showbase/VFSImporter.py, which is needed to support loading the remaining Python code from the multifiles in the various packages, particularly the panda3d package and/or the p3d file itself.
If it’s not loading, something isn’t built right. Perhaps you have inadvertently compiled in a dependency on a runtime DLL that isn’t available, or some other dependency? Or perhaps there was a missing symbol?
It’s difficult for me to diagnose the problem from here, but a return value of NULL simply means that the import failed, presumably because the DLL could not be loaded by the operating system. You’ll have to figure out why from there.
You may be right that I missed some thing for the building process, so I will explain more about what I’ve don so far.
I checked out the latest panda3d-runtime patch from the CVS server, here is these steps I did build (in debug mode, using VS2008) and debug the ActiveX:
build Panda3D engine from panda3d-runtime\makepanda\makepanda.sln
build P3DActiveX from panda3d-runtime\debug\direct\plugin_activex\P3DActiveX.sln
build p3d_plugin.dll from panda3d-runtime\debug\direct\plugin. I manually make the .sln file myself to build this DLL
build p3dpythonw.exe from panda3d-runtime\debug\direct\plugin. Again I manually make the .sln file myself to build this exe
I tried to debug these modules by modifying file p3d_plugin_config.h as: #define P3D_PLUGIN_P3DPYTHON “panda3d-runtime\direct\src\plugin\p3dpython\Debug\p3dpython” #define P3D_PLUGIN_P3D_PLUGIN “panda3d-runtime\direct\src\plugin\p3d_plugin\Debug\p3d_plugin.dll”
I also put all DLL dependencies in a right location (all debug DLLs have postfix “_d”)
I know that the DLL _vfsimporter.pyd is built in release mode, and its dependency is python24.dll. So I need _vfsimporter.pyd in debug mode which should have a dependency with python26_d.dll - Am I right?
If I use your p3dpythonw.exe (i.e I set P3D_PLUGIN_P3DPYTHON = “”) then the ActiveX works correctly (work with my built P3DActiveX.ocx & p3d_plugin.dll)
You will need to host your own panda3d package, that includes your own vfsimporter_d.pyd, and allow Panda to download and run that package. This requires several additional steps beyond the ones you are doing.
I’m not sure that the makepanda scripts are set up to build all this successfully in debug mode. It might work; but I personally have little experience with this. I used the ppremake system to develop the runtime initially. The makepanda scripts were added later, for the primary purpose of building the runtime for distribution, so their support for building a debug runtime is largely untested.
Anyway, let’s assume for now that makepanda can be used successfully. In order to host your own panda3d package, you will need to define PANDA_PACKAGE_HOST_URL to an appropriate URL from which your package will be downloaded. This can be a file:// URL for development purposes, e.g. “file:///c:/my/panda3d/dir” .
After you have built all of the required libraries, you can construct the panda3d package with the command sequence:
cd direct/src/p3d
ppackage.py -i /c/my/panda3d/dir coreapi.pdef
ppackage.py -i /c/my/panda3d/dir panda3d.pdef
These commands will install the panda3d package (as well as the coreapi and other require packages) into the named directory, which is the same directory you referenced with your file:// URL, above. Now, when you run the panda3d.exe or p3dactivex.ocx that you have compiled, both should attempt to download from your file:// URL, and they will thus “download” and run your newly-built vfsimporter and other needed components.
It shouldn’t be necessary to redefine P3D_PLUGIN_P3DPYTHON or P3D_PLUGIN_P3D_PLUGIN. When you have followed all of these steps, it should “download” these parts of the system from your file:// URL as well.
I found that the p3dpython.exe compiled in debug mode doesn’t work with _vfsimporter.pyd.
I managed to get _vfsimporter.c and compiled it into _vfsimporter.pyd:
Both _vfsimporter.pyd in debug or release mode don’t work with p3dpython.exe (debug mode) BUT they work with p3dpython in release mode.
I am using python 2.6. Is there any python version (debug?) that works with exe compiled in debug mode?
It should be called _vfsimporter_d.pyd in debug mode. This is a Windows (and Python, and Panda) convention to make a filename difference between dll’s compiled in debug mode and dll’s compiled in release mode (if there weren’t such a filename difference, you might accidentally load a release dll into a debug executable, or vice-versa, which would result in a terrible crash).
So, if you’ve got a file called _vfsimporter.pyd, then either it was incorrectly compiled in release mode (and therefore can’t be used with a debug-mode p3dpython.exe), or it was compiled in debug mode but named incorrectly.
Well, as I said I got _vfsimporter.c and I manually compiled this into .pyd file either debug or release mode.
I found that it did not work even if I renamed the dll into _vfsimporter_d.pyd.
I did a try with a simple “helloworld” python script and made an test.exe file to import this “helloworld”. As result, test.exe (release) works with “helloworld” while test.exe (debug)doesn’t.
Can you explain this?
No, I don’t know about that; but the debug/release rule only applies to .pyd files, which are dll’s, not (generally) Python scripts. .py/.pyc/.pyo files can be loaded from either debug or release programs.