Right so I was searching the forums, possibly not thoroughly enough, and couldn’t see any clear ways as to how to build/configure panda3d with the new makepanda system.
I downloaded the latest source from the download page. And loaded up the solution in makepanda/ which seems to have NMake set up any everything. However when I Build I get:
C:\panda3D-1.6.2_Source>makepanda\makepanda --everything --optimize 1 --outputdir debug
Traceback (most recent call last):
File "makepanda\makepanda.py", line 53, in <module>
LoadDependencyCache()
File "C:\panda3D-1.6.2_Source\makepanda\makepandacore.py", line 332, in LoadDependencyCache
CXXINCLUDECACHE = cPickle.load(icache)
EOFError
I really have no idea whats going on… The tutorials say its as easy as running makepanda --everything, however when I do this it looks like there are a bunch of compile errors.
Also, I want to build all of panda3d in debug mode, which it seems like is the default setting…
I don’t think 1.6.2 version of makepanda supports building in debug mode (there was a thread a couple of weeks ago about fixing this; the fix is on the cvs trunk, but it isn’t part of the 1.6.x series).
That said, I’m not sure whether this is the problem you are running into or not. What happens if you just run “makepanda --everything” from the command line, instead of via the project file?
Edit: looking at the makepanda source, it appears to be failing to read the dependency cache file that it writes during the build; perhaps there is some leftover garbage from an aborted previous build. Try emptying out the build directory completely, and trying again from the beginning.
Thanks, I did a tmr on the ‘built’ folder, then the build went through fine. Although, as I’m looking at the output there seems to be some warnings and maybe errors being thrown.
Are you saying I can’t build in debug mode? Sounds kind of silly… whats an engine if you can’t debug it.
Edit:
Getting lots of warnings like:
>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\vector(439) : warning C4275: non dll-interface class 'std::_Container_base_aux' used as base for dll-interface class 'std::_Container_base_aux_alloc_real<_Alloc>'
1> with
1> [
1> _Alloc=pallocator_array<TypedWritable *>
1> ]
1> C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xutility(377) : see declaration of 'std::_Container_base_aux'
1> c:\panda3d-1.6.2_source\debug\include\vector_src.h(64) : see reference to class template instantiation 'std::vector<_Ty,_Ax>' being compiled
1> with
1> [
1> _Ty=TypedWritable *,
1> _Ax=pallocator_array<TypedWritable *>
1> ]
1>cl /wd4996 /Fodebug/tmp/lerp_composite.obj /nologo /c /Ipanda/src/lerp /I"thirdparty/win-python/include" /I"debug/tmp" /I"debug/include" /MD /Zi /RTCs /GS /Fddebug/tmp/lerp_composite.pdb /DBUILDING_PANDA /EHsc /Zm300 /DWIN32_VC /DWIN32 /W3 panda/src/lerp/lerp_composite.cxx
1>lerp_composite.cxx
There’s no way to build Panda directly from inside of MSVC, period. Your choices are to use makepanda, which invokes the MSVC compiler externally.
The MSVC solution/project that comes with makepanda is only a convenience wrapper around the makepanda.bat file and the Panda3d source. When you invoke ‘Build’ from the menu, all it does is run the makepanda.bat, same as you would do by hand.
Makepanda.bat invokes a Python script that acts like a Python makefile. (Which is just a Python script, itself.) The versions currently on this website (1.6.2) do not support a debug build using MSVC. This has been resolved in the latest trunk that is available via CVS, if you want to go that route.
The other choice is PPremake, which as far as I can tell is an autoconf-like C++ program which generates makefiles for Panda. From there, you’ll need to use UNIX-style make. If you aren’t comfortable with a mixed environment like this (say, Cygwin-compiled make working with MSVC’s command-line compiler and linker), then you should stick to makepanda. It’s simpler and easier to use.
And I’m not saying there is something wrong with Windows, just pointing out my suspicion that most of the active devs do not use it as their primary development system. (Either that, or makepanda is pretty new and still isn’t being used all that much. No idea, I just started using this engine about a month ago!)
I’ve been down this route already, and you should check my thread. I was initially as confused as you are, because the docs said that an --optimize 1 option should make a debug build. But it wasn’t, and changes were made to the current makepanda source to fix this.
I’m not a novice with MSVC, I realize all its doing is calling the makepanda.py file.
I read your thread, where do I find the CVS repository? Once I update, I should be able to just run makepanda --everything --optimize 1 --outdir debug?
Edit:
Okay, so I got everything from the head cvs revision. Tried to compile and it said I’m missing the thirdparty files, I assume I have to transfer them over. Which I am doing now…
Edit:
I copied them over, but aparently they are not the debug libs or versions? I got the error:
1>Could not find thirdparty/win-python-dbg/python_d.exe!
Do I have to recompile python in debug mode…? What if I only want to step through panda3d code and my c++ modules and not python itself?
I’m getting many macro conflicts like the one in that bit above as well, if someone could point out the reason, or if they need more info, help would be appreciated.
That build failure is my fault, sorry about that. A couple of days ago I committed a change that required a corresponding change to both build systems, and I completely forgot to make the appropriate change to makepanda. My apologies; I’ve just committed that fix to makepanda.
I understand the macro conflict warnings have been around for a while, and cause no harm. (I hadn’t seen them myself; I don’t get them with the ppremake build.)
As FenrirWolf observes, the developers within Disney don’t use makepanda; we use ppremake instead. ppremake is the original build system; makepanda is not new, but it was designed to be easier to use for a casual developer, and it is not sufficiently powerful to meet our needs. Unfortunately, that means we have to maintain two independent build systems, leading to the occasional mistake such as the one above.
We’re not opposed to supporting native MSVC builds, but no one has yet suggested a good way to do this without adding a third independent build system to the mix. (In fact, ppremake was originally designed to be able to produce an MSVC project file as output if desired, but no one finished the work needed to make this a reality; and it’s not clear that it would be useful even if it did this.)
Ah thanks, if its better to use ppremake then I have no problem with using it, it’d just be nice to have its usage explained to me rather than me spending hours to days trying to figure it out.
However, if for some reason ppremake can’t generate debug output that the MSVC debugger can use then I’d have to ask how you debug your projects.
I wouldn’t say it’s better to use ppremake necessarily; it’s just more powerful and allows a greater range of configuration options. makepanda is probably better for most people’s needs because it’s sufficiently powerful to build Panda with all of the default options, and it requires less hand-tweaking to get it to do the right thing. The cvs version of makepanda that you’ve just installed should build a debug version correctly (once you pick up the latest changes I committed last night).
ppremake has always supported building a debug version. But in fact, we rarely use that option. It is perfectly possible to debug Panda, or any C++ code, with a Release build, and that’s what we do most often.
Interesting, it seems though, that you and the Disney team you work with don’t do a lot of work in the C++ area when developing your games, which is somewhat surprising.
However, it seems the Disney team doesn’t focus on anything ground breaking in terms of gameplay, or anything too innovative, and I mean no offense, I realize the main reason you keep things simple is to allow for a larger audience of players. This may be, and what I think is the main reason you don’t often delve into the C++ realm.
It just seems that, if you are to have a successful indie game, you must have an effective game design the puts people in a position they’ve never been before, and keep gameplay fresh. As you know, such ‘innovation’ usually requires you to make stuff from scratch, which means heavy calculations, networking code optimizations, and God knows what depending on what your ‘innovative’ aspects are.
Python is defiantly a great tool for high level code that doesn’t need to run particularly fast and makes things more readable and easily understood.
True, if you use --optimize 3, you can get debug symbols without linking to the debug heap/runtimes. However, I find that I can learn a lot about how a very complicated piece of code is structured by stepping through it as it runs and tinkering with the internals. It exposes me to the code and the logic flow at the same time. I find it more engaging and fun than just pouring over the raw code itself.
I disagree. You seem to be equating gameplay with the game engine. Panda3d is just a game engine, nothing more.
Also, I must disagree. While I agree that gameplay is the key to success for most games, I don’t always think you need to re-invent the wheel every time. If you are making a game that uses the latest cutting edge realtime rendering technology, then you could argue that a by-hand approach might make sense than refactoring existing work. But unless your game is absolutely so radical that it can’t take advantage of the reams of code that already exist, such as robust networking and physics code, then I would argue that an indie game developer has the opposite choice.
I see lots of successful indie game studios using pre-existing tools, such as SDL, Box2D, or ODE.
I think you’re both underestimating Python, and overestimating the amount of computation that innovative game design requires.
It is true that certain innovative techniques may require heavy computation; particularly when these techniques involve novel rendering or A.I. algorithms. (But you shouldn’t confuse rendering techniques with game design–some of the most unique, compelling games out there have relied on standard rendering techniques; and conversely, some of the most unique-looking games out there have fairly unremarkable game designs.)
Every once in a while, someone, Disney or otherwise, requires some computation-intensive routine that is not already provided by Panda, and then they can choose to write that routine in C++. Perfectly reasonable; like I said, we’ve done this some five or six times over the years.
But these moments are relatively rare; and even when they do occur, it usually makes sense to write the prototype algorithm in Python first. For instance, one of our engineers was recently working on an improved design to the basic collision algorithm implemented by Panda, and he developed the proposed design in Python first. When we were convinced that it was working well in Python, we ported it to C++. It still saved a lot of development time that way over developing it in C++ in the first place.
The moral is, you can accomplish quite a lot without ever stepping outside of Python.
That said, I do develop in C++ every day; most of Panda is written in C++, after all, and I’m primarily a Panda developer. I do prefer to do this on Linux or Mac, though, where I consider the C++ developer tools to be superior (but then, I’m pretty old-school, and actually feel most at home on the command line). When I do use Windows for development, I find that using the debugger in Release mode is perfectly adequate. Every once in a great while, I might fire off a quick build in Debug mode to help me unravel a particularly knotty stack trace.
Those are not options to makepanda, they’re options to ffmpeg’s configure script. Those instructions are for building a version of ffpmeg that is compatible with the cvs head version of Panda. (The version of ffmpeg in the 1.6.2 thirdparty tools may not be current enough.)
In your case, the easiest thing to do is to ask makepanda not to attempt to build support for ffmpeg: use --without-ffmpeg (or whatever the option is).
Or, another possibility: maybe you should use the cvs version of makepanda to build the 1.6.2 version of Panda, instead of attempting to build the cvs version of Panda.
For now I just won’t compile ffmpeg, however, where are those config scripts? I’d like to compile it if at all possible.
If all else fails, I’ll do what you said, and only use the updated makepanda to build the on-site source.
I’m not talking about panda3d, anyone can see panda3d is a game engine, I’m talking about Disney’s PotC MMO, Pinball, ToonTown, ect. I also happen to know some people on successful indie teams and their tales about the code they wrote. It just doesn’t seem like all the things can be done with python and be scalable (meaning more objects, same performance, ect)
When I say ‘innovations’ I mean gameplay and nothing else. Rendering was not something I was implying. Maybe I should have worded it differently, by ‘making from scratch’ in my head I meant adding support for a feature that doesn’t exist in the panda engine already by yourself. I’m not saying that what is already there I will not use, I am saying complex game logic (destructible terrain, destructible models, realtime face editing, AI, pathfinding, procedural animations, procedural anything really…) are all things that need to be made for high speed and scalability, and shouldn’t be provided by an engine, since engines provide common functionality not specific functionality like I mentioned.
Also, using libraries other people have made is completely doable (other than possible licensing restraints/conflicts) I don’t remember saying anything against that.
The “configure” script is a fairly standard script distributed with packages for building on Unix-like systems. There should be one distributed with the ffmpeg package. However, for building on Windows, it might use a different mechanism–I do seem to recall that ffmpeg is a bit troublesome to build on Windows (even more so than Panda ). You would have to do some research on the ffmpeg site for the full details; I don’t know much about it myself.
However, I do believe pro-rsoft has already built it, and he may be able to point you at a binary. Or you might be able to find one on the net that someone else has provided.
Good news, the build passed (release build). Took friggen 3 hours… and the MSVC files in tmp/ take up almost 2 GB of HD space -.0
I’ll try a debug build, although I’m not really sure the build I made even works at runtime, is there a test framework at all that I can run to make sure everything is working?
I just get paranoid when I look down and see:
1>makepanda - 0 error(s), 944 warning(s)
:S, although most of them are macro conflicts.
Do you think I should just use the source provided on the site instead of the CVS head to be safe? Is the CVS head even that different?
944 warnings for about a million lines of code isn’t too bad a ratio. We do make an effort to keep the compiler warnings down, but a few warnings is not unusual for a multi-platform project like this.
If you can run pview and see a blue triangle, that’s a good sign. If you can run any of the sample programs, that’s an even better sign.
The CVS head and the 1.6.2 version do have several important differences, and now that I look at it, one of them might cause more trouble when attempting to mix-and-match makepanda and Panda versions. So maybe you’re better off sticking with the CVS version across the board, especially since you appear to have gotten that to work now.
Couldn’t run any samples, I didn’t try anything else, if I can’t even run the samples, I consider it a catostrophic failure. I noticed there was something that looked like a python error in makepanda (I think it relates to building ode with makepanda, I didn’t copy the error sorry).
I added --no-ode to the build and rebuilt (hopfully this won’t do a full build, just build dependancies).
Although, ode is something I will be using so I hope this gets resolved soon…
). You would have to do some research on the ffmpeg site for the full details; I don’t know much about it myself.