# Migration to Visual C++ 2010, availability of x64 builds

#1

Based on popular demand, we’ve finally switched to Visual C++ 2010. I’ve recompiled almost all of the thirdparty libraries for both 32-bit and 64-bit; my plan is also to start offering experimental 64-bit builds at this point.

VC2010 finally ditched WinSxS for the Visual C/C++ Runtime, yay! This means that we can finally ditch all the stupid manifest stuff, which is no longer necessary since we can just use local deployment for the msvcr; the old-fashioned, headache-free way.

Here are the thirdparty directories. Put their contents in a directory named “thirdparty” in the Panda3D source.
(links removed, the 1.9.0 thirdparty tools are more up-to-date)
The Python builds are from the Python site and therefore compiled against the VC90 runtime - I may build them myself if that turns out to be a problem.

I’ve also compiled debug builds of Python for those interested. These are compiled with VC 2010 and include .pdb files.

rdb.name/win-python-dbg.7z
rdb.name/win-python-dbg-x64.7z
They are needed to compile Panda3D with optimize levels lower than 3.

You only need the Windows SDK 7.1 to compile Panda - it comes with 32-bits and 64-bits compilers. (In fact, Visual C++ 2010 Express doesn’t ship with a 64-bit compiler). Due to an error in the WinSDK 7.1 installer, you first need to remove any versions of the Visual C++ 2010 redistributable before running the installer.
You might also need to install the “Microsoft Visual C++ Service Pack 1 Compiler Update for the Windows SDK 7.1”.

All of the builds are currently available from the buildbot.

Panda_3D with Visual Studio 2010
Compiled Panda on VS2013 but have runtime assertion
Compiled Panda on VS2013 but have runtime assertion
Compiling for VS2010
Win64, Maya 2014, current builds?
Looking for some information
Migration to Python 3
Compiling CVS, thirdparty packages aren't being found
[HOWTO] Compile from source on windows
#2

Yee-haw!

#3

The 64-bit build will be a while until I fix some issues with cross-compiling in makepanda (as our Windows buildbot is 32-bits).

I also removed the dependency on ATL, so now you don’t need to use --no-directcam any more in order to build the SDK with the free version of MSVC.

#4

Sorry, it’ll be a while before there are x64 buildbot builds because in my stupidity I didn’t realise that the buildbot is 32-bits and that we need to run the built version of interrogate in the makepanda process, so we can’t cross-compile.

#5

Surely it’s possible to fix makepanda so that it will run a previously-built interrogate instead of the built interrogate. For instance, via an option like --interrogate c:/stbin/interrogate_x86.exe or something like that.

It does mean that someone would have to build a new interrogate by hand after any updates to interrogate itself, which might become a bit of a nuisance; but updates to interrogate are infrequent enough it may not be that bad.

David

#6

Yes, that’s what makepanda actually does when cross-compiling: it expects an existing copy to be in the PATH.

That does make building a lot less automatic, though; and sometimes, there’s a particular change to interrogate that follows a change to the source base. If we wanted to do this, then we should probably implement makepanda to build a second version of Panda just for interrogate, which would be rather complicated. Failing that, the buildbot should just build two trees of Panda automatically, one with just interrogate built for the host platform.

Anyway, I may get around to that if Steve doesn’t get around to setting up a 64-bits buildbot before then.

#7

Hey ! I’ve been using these builds and I seem to have an issue while opening windows. Whenever I try to open it, it says that no displays are available and that I should specify some in my Config.prc file.
I already have some in there: pandadx9, pandadx8, tinydisplay and pandagl. This prc file used to work with 1.8.1, the dlls bear the same names and are in the executable’s folder. Everything seems in order to me. Is there something else that could be wrong ?

#8

I’ll look into it. Do you mean you’re using the buildbot build or did you make your own build?

#9

Oh man. Sorry about that, actually it seems there was a mix between dll in the path and the ones I put in the running directory. I realized that as QtCreator managed to build something that actually launched. With some investigation, I managed to get Panda3D to almost work. I think it’s alright now !

There are just two issues I noticed while using both the last automated build and my own build.

There’s a crash happening every time I call CollisionNode::add_solid. It just displays something starting with “TypeHandle” and asking if memory is corrupt.

I also can’t load any model or texture, and apparently it’s not an unsupported format issue, this is the output I get when loading such things:
Models

:loader(error): Couldn't load file C:/Users/plaristote/Work/foe/build/models/misc/sphere.egg.pz: not found on model path (currently: "/c/Users/plaristote/Work/foe/build-FoE-Editor-Desktop-Release/release;/c/Panda3D-1.9.0/etc/..;/c/Panda3D-1.9.0/etc/../models")
Unable to load C:/Users/plaristote/Work/foe/build/models/misc/sphere.egg.pz

Textures

:gobj(error): Texture::read() - couldn't read: C:/Users/plaristote/Work/foe/build/textures/random-desert-1.png
:gobj(error): Unable to find texture "C:/Users/plaristote/Work/foe/build/textures/random-desert-1.png" on model-path /c/Users/plaristote/Work/foe/build-FoE-Editor-Desktop-Release/release;/c/Panda3D-1.9.0/etc/..;/c/Panda3D-1.9.0/etc/../models

Both files do exist at these exact pathes.

Everything else I was able to try (considering I can’t load models) works nicely. Any idea what might be happening with add_solid or the loading issue ?

EDIT: There also are a couple of files that I’m pretty sure shouldn’t be compiled when using the option --no-python. I’ve had the same issue with the panda3d-cvs AUR pkgbuild: fairly certain one of those files is geomVertexArrayData_ext.cxx.

#10

Yeah i’ve encountered an issue where the buildbot builds crash if i attach rigid bodies to the bullet world this also happens if i compile panda myself but depending on what optimize level i use i get different errors.pstats doesn’t work at optimize 4 and bullet crashes with no optimizing im am rebuilding with something in between right now but i thought you should know of these.

Also note i don’t know what optimize does lol.

#11

Can you provide the buildbot number/version you use and a script which reproduces this crash?

#12

Panda3D-2013.10.06-54 has this problem for me.
Using bullet in python works fine here it is only c++ which crashes as soon as i attach bodies.

What does using --optimize 4 change that would cause it to start working because that is the only thing that makes it work?

#13

Not much mystery here, optimize triggers debugging builds. Bugs manifesting only on release/debug builds are a very common occurrence.

#14

Ok so there is something wrong with the optimize 3 build of c++ bullet.
Yeah i looked through makepanda.py and it looks like pstats only gets done if you build with 3 or less and that without the optimize tag it defaults to 3.

#15

When using C++, it is also very important that your build settings match that of Panda and Bullet, or otherwise you could get mysterious crashes like this. If you use an optimize 3 build, make sure that you compile in Release mode and that NDEBUG is not defined.

Also, make doubly sure that you’re not inadvertently mixing an opt3 build with an opt4 build; ie. that an opt4 bullet library is used in an opt3 build or so.

#16

Many thanks to Steve, we’ve got a 64-bit buildbot.

I was stuck for a while on getting it compiled with support for 3dsmax 2014, but I eventually gave up. Anyway, the 64-bit builds are now available, with support for Maya versions up to 2014.

#17

Alright, I found out what was wrong with the models not being loaded. They can be loaded, but apparently only if they are found in the model-path. Full paths don’t seem to work (I managed to load my files by removing the 3 first characters and adding ‘C:/’ to model-path). Can anyone concur or object that ?

And about the CollisionNode::add_solid issue I met, I opened a bug report with a few lines of code that reproduced the issue on three different builds of 1.9.0 ( bugs.launchpad.net/panda3d/+bug/1248551 ).

#18

You are using unix-style paths, right, such as “/c/path/to/something” as is the convention in Panda instead of “c:\path\to\something”?

#19

Announcement for people using the 64-bit buildbot builds: starting dev_sdk_win_amd64 build 124, Panda correctly installs itself to the 64-bit view of the registry instead of the 32-bit view. This fixes interoperability issues with other Python installations and libraries (ie. the wxPython installer will now correctly detect Panda’s Python installation).

However, to prevent stale registry entries, you should explicitly run the uninstaller before upgrading to build 124 or above.

#20

The links in the original post don’t seem to be working for me. I have tried all of them giving the same error, cannot find the server at www.rdb.name, so I tried rdb.name.com and it says “Oh snap! The page you are looking for fell off our servers!”. I could try to grab the files from the list in the manual but no versions are listed and from my lurking around the forums, that could be a bad thing. Is it just the subscription has run out or am I doing something wrong? Is there another place I can download these from?