Getting panda running in c++

I’m struggling to get a c++ panda app going (generally getting exceptions and things at start up), and can’t find the help page (it’s missing) or tutorials. Does anybody have an example c++ app for vc2008 I can pinch.



The C++ pages have been integrated. Click the “C++” side of the “Python / C++” text at the top of the manual to switch your view to C++ mode, and then you can read the tutorial in the manual.


The problem is, the section:

Panda3D Manual: How to compile a CXX Panda3D program

has a broken link to setting it up in visual studio.

I’ve used the c++ tutorial for hello world, but i think my issue is something to do with project setup, so I want to get that right first. A sample project would do if you have one.



It’s not hard to set up a project - just set the include paths, linker paths, and linker dependencies.
This forum section is full of people who tried to setup VC2008 - browse it and you’ll find a lot of stuff.

But you’re right, I’ll make a manual page about it soon.

Sure - I’m generally pretty good at this stuff (I’m a a games developer) but the issue I’m getting is not a compiler/linker problem, which is what most people refer to on this forum. I succesfully build/run and get this error in set_window_title:

First-chance exception at 0x773f42eb in mmo.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0013f9a4…

If I don’t call set_window_title, I get further errors when the window tries to open. A very simple sample app - even just a working version of the hello world progam written in VC2008 would instantly tell me if it’s a project config issue or some typo in some code somewhere.

To try and catch the exception lower down I’ve been trying to build panda so I get symbols. However when I run makepanda, I get a few errors which I’m working on, such as:

mt.exe : general error c101008d: Failed to write the updated manifest to the res
ource of file “built/bin/libpandaode.dll”. Access is denied.

My gut says this might be something to do with my virus checker.

This thread discusses the same problem:
This a similar one:

OK - got a step further for now - the release build runs up to the next line and dies with the exception that it can’t find cgiGetParameterValues. Looking through the source, all I can see is an nvidia function called

CG_API const double * CGENTRY cgGetParameterValues(CGparameter param,
CGenum value_type,
int *nvalues);

(note there it’s just cg, not cgi). Could this be a bug?

I’m also struggling to get panda compiling so I can create a debug build. Is there any reason you guys don’t just provide debug versions as well as release versions?

That function is not used by Panda. Could it be that you have multiple versions of Cg around that are conflicting?

That sounds like a good idea, we could make a Panda build that is compiled with debug symbols (like we have for the RPM builds) with a debug version of Python. I don’t feel like recompiling the thirdparty packages in debug mode, though.

Good call, and maybe something to mention in the docs - cg.dll comes with maya2009 and their version is incompatible. In addition, (although no issue arose) libguide40.dll also came from Maya accidently.

To ensure everything uses what it should, I’ve put the versions of those dlls that come with panda in the same folder as my vcproj for now. Interestingly, if I just do a bulk copy and paste of all the dlls shipped with panda the app hangs, which indicates you have some dodgy 3rd party dlls somewhere (they’re just working as they are found in the windows folder first).

For the record, these are the panda dlls that end up getting used
‘mmo.exe’: Loaded ‘C:\MiniCoders\mmo\Release\mmo.exe’, Symbols loaded.
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\libp3framework.dll’
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\libpanda.dll’
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\libpandaexpress.dll’
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\libp3dtool.dll’
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\libp3dtoolconfig.dll’
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\libpandaeay.dll’, Binary was not built with debug information.
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\zlib1.dll’, Binary was not built with debug information.
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\libpandassl.dll’, Binary was not built with debug information.
‘mmo.exe’: Loaded ‘C:\MiniCoders\mmo\mmo\cg.dll’
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\avcodec-51-panda.dll’, Binary was not built with debug information.
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\avutil-49-panda.dll’, Binary was not built with debug information.
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\avformat-50-panda.dll’, Binary was not built with debug information.
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\highgui100.dll’
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\cxcore100.dll’
‘mmo.exe’: Loaded ‘C:\MiniCoders\mmo\mmo\libguide40.dll’, Binary was not built with debug information.
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\libpandadx9.dll’
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\libp3windisplay.dll’
‘mmo.exe’: Loaded ‘C:\Panda3D-1.6.2\bin\cgD3D9.dll’

All others come from system directories of some form.

On the debug stuff, the ultimate requirement is a version of panda that can be linked against by a vc2008 debug config. I reckon you might not have to redo all the 3rd party libraries - the only reason the versions are incompatible right now is that panda passes classes around the dll interface that differ in debug/release builds - hence the warning:

c:\Program Files\Microsoft Visual Studio 9.0\VC\include\vector(439) : warning C4
275: non dll-interface class ‘std::_Container_base_aux’ used as base for dll-int
erface class ‘std::_Container_base_aux_alloc_real<_Alloc>’

This might be something to consider fixing in a future version.

Most 3rd party packages should avoid this so you shouldn’t need to rebuild all of them. I’m not looking to debug 3rd party stuff anyway - it’d just be nice to be able to debug panda when something goes wrong.

It’d be really helpful if you could include some working vc2008 samples along with the python samples in the package - even if it’s just a hello world app. No matter how long you’ve worked with vc++, there’s still no easier way to setup a project than to copy an existing one :slight_smile:

Incidently, I’m still getting this error when I try to compile panda with makepanda --everything

mt.exe : general error c101008d: Failed to write the updated manifest to the res
ource of file “built/bin/libpandaeggstripped.dll”. Access is denied.
Storing dependency cache.
Elapsed Time: 59 min 24 sec

About the permission problems, I don’t know. Are you running Vista? Try running the cmd as administrator.

I have no clue about those warning messages and debug<>release incompatibility, drwr might be able to answer to that.

To compile Panda in debug mode, you need to compile it with “–optimize 1” in the command line.

Right, that makes sense. We’d need someone to translate the sample programs into C++, then (though I believe someone from CMU might be working on that).

No, actually, it’s a much deeper problem than that. It is true that there are some code differences between debug and release builds, and we can protect those fairly easily (and, in fact, we have already done so in the cvs trunk). But the real problem is that Microsoft provides two different versions of the C++ runtime for debug and release builds, and each version has different heap allocation functions. This is not generally a problem for C code, because in C programming all of the alloc/dealloc operations end up compiled within the module, and every alloc call is paired with the dealloc call from the matching library.

But in C++, where you have inline functions and (even worse) templates, a lot of the referenced code gets instantiated into the caller’s module. If the caller isn’t using the same alloc library that the callee is using, you get a big crash. It’s not just Panda; it’s all of the standard C++ libraries, especially STL and basic_string, which rely heavily on templates and inline methods.

So, it may not be necessary to rebuild all of the thirdparty libraries, just any of them that present a C++ API. Most of them probably don’t.

Incidentally, the quoted error message refers to a minor objection with STL vector and the way we export the template class from the DLL. We used to have to explicitly export template classes back in VC6, and the code to do that is still present; reportedly, it’s no longer necessary in VC7 and above, but we’ve never tested this by removing the code in question. It’s not related to the problem of mixing debug and release builds, however.