iPhone support?


your avatar makes my computer feel 2x as slow.

Can we get more updates from David regarding this? I heard that its stopped do to browser plug in. Can we get update on the plugin as well?


I’ve just changed my avatar. 8)

I can see he’s checking in loads of new stuff to the web plugin every day- most of it even compiles fine on my Linux box.
Too bad there’s no npapi plugin support for Linux yet, I’d love to try it already. :slight_smile:

PS. p3dPythonRun.cxx references a “runp3d_frozen.pyd”, how do I make that?


The plugin effort is indeed going well. I’ve got a webpage running Airblade and Roaming Ralph in a little embedded applet window. Right now I’m working on adding scriptability, so that Panda can control the web document; or JavaScript on the web page can control Panda. Still to come are automatic Panda version selection and patching, and security features. And, of course, support for Mac (partially complete so far) and Linux (not yet started).

The iPhone support is on hold for now, but it will eventually take advantage of the same .p3d packaged application we’ll be using for web distribution, so it does make sense to wait a little bit for that to be finished. Still, as it is right now, Panda does run just fine on the iPhone, with Python and everything. It does take a bit of an effort to compile for the iPhone, and this is one reason why it will be advantageous to have a p3d-runner already precompiled for the device. (Of course, installing this p3d-runner program on your iPhone will require a jailbroken phone, because Apple doesn’t want you to have apps that run other apps. For those who’d rather not go there, we can still provide the straight-and-narrow path to iPhone development, which will just be a little clumsier.)

I have the following script on my Mac box:

python $DIRECT/src/showutil/pfreeze.py -i direct.directbase.DirectStart -i direct.actor.Actor -i direct.fsm.FSM -i direct.directutil.Mopath -o runp3d_frozen.so direct.showutil.runp3d

.pyd is just the extension on Windows, other platforms will use .so.

Having the runp3d_frozen file isn’t enough, though; you’ll next need the Python/Panda package that it will want to download. I also have this script:

#! /bin/sh

cp -v $DTOOL/built/lib/*.dylib ~/p3drun/  || exit
cp -v $PANDA/built/lib/*.dylib ~/p3drun/  || exit
cp -v $DIRECT/built/lib/*.dylib ~/p3drun/  || exit
cp -v $DIRECT/built/bin/p3dpython ~/p3drun/  || exit

mkdir -p ~/p3dstage/coreapi/dev/osx.i386
cp -v $DIRECT/built/lib/p3d_plugin.dylib ~/p3dstage/coreapi/dev/osx.i386/ || exit

python $DIRECT/src/plugin/make_package.py -d ~/p3dstage -s ~/p3drun -p panda3d_dev_osx.i386  || exit
python $DIRECT/src/plugin/make_contents.py -d ~/p3dstage  || exit

And then I compile with:

#define P3D_PLUGIN_DOWNLOAD file:///Users/drose/p3dstage

As you can see, there’s a bit of setup work you’ll need to do to play with this locally. :slight_smile: Still, I don’t see any reason why you wouldn’t be able to get the panda3d standalone application to compile and run on a Linux box or anywhere else. It might not even be far to get the npapi part compiled on Linux, though I’ll get there eventually, I promise. :slight_smile:



Thanks - I was able to run p3dpython with your instructions. No idea how it works, though - does it communicate with the plugin via sockets? How is the XML stuff piped to p3dpython?

After a lot of hacking I was also able to get pfreeze, packp3d and runp3d working. Really neat stuff =)

I recently installed WinXP on VirtualBox (Panda works with 3D acceleration on it) so I’m sorely tempted to try building the plugin. :slight_smile:


p3dpython communicates with the browser via anonymous pipes, as created via the standard Posix pipe() call. This, of course, requires p3dpython to be launched as a subordinate process to the browser itself; it can’t be run from the command line. The XML data is streamed in both directions along these anonymous pipes; it’s just a quick-and-easy way to stream arbitrary data between separate processes.

Having Panda run in a separate process is quite a pain, but it really is necessary in order to support more than one instance of a Panda window running in the browser at once, especially unrelated instances. It’s also necessary to support different versions of Panda in different instances; and it has other nice advantages like keeping Panda’s frame rate independent of the browser, and helping to keep the browser from crashing in case the Panda app crashes.

I’m surprised it took hacking to get packp3d and runp3d running. Those should have worked out the box. pfreeze was a mess, though, and will definitely require some cleanup to make it more world-friendly. Are your changes safe enough to commit back in, to save me the work of re-doing your efforts when I visit Linux? :slight_smile:



Packp3d and runp3d worked well, but first I couldn’t get my models to load. I just found out I just had to omit the ‘.egg’ when loading models in my game, and runp3d would change the default model extension. Clever!
Maybe there should be a config var to force models to be loaded as .bam, even if .egg was explicitly requested, so any game given to packp3d would work. Then again, this would be a bit hacky.

Also, I think there should be a commandline option to specify custom extensions to be included (xml, etc) instead of just .egg and images.

First, I had to alter it to add the include and link directories of Python to the compile/link commands and “-lpython2.6”. (Is it a good idea to link to Python at link-time this way, or should we link to pystub or so.)
Also, it didn’t chew names with dashes (like Tut-Roaming-Ralph) because it would convert that into a C variable name. Maybe we should hash that or make pfreeze remove special symbols.


Hmm, this is not a bad idea. It is hacky, but probably not so bad.

Also a good suggestion. I think eventually we’ll need some kind of spec file for fully customized builds, something akin to Python’s disttools, since many games will have highly customized needs.

We actually do need to link to Python here, since we are building a Python runtime. Linking with pystub would break things horribly. Eventually, pfreeze will have to be a lot more like makepanda, and do a better job of automatically figuring out the appropriate compile and link lines.

Ah, a good point. Of course, these filenames are not legitimate Python module names anyway, for a similar reason (because they’re not valid as Python symbol names). They can only be loaded from the command line, where their name gets changed to “main” anyway. Unless Python has a trick here I’m not aware of.



Hi all,

Just curious, how hard would it be to build panda with EGL/X11/OpenGL ES 2.0 and GLSL shaders? I can’t seem to see their entries in the makepanda python script but would it just require adapting this file to point to those parts?



Although makepanda builds with GLSL support out of the box, it does not support building the EGL/GLES(2) part of Panda. You’ll need to use the ppremake build system for that, or add the proper instructions to makepanda.

Beware that I haven’t tested the OpenGL ES support in while, so you may encounter build issues. I’d be happy to help you through those, though.


Thanks for the reply rdb, my plan was to compile it for the nokia n900 platform seeing as I’ve got a scratchbox system set up and the actual device. I’ll compile the dependencies missing first and then tackle panda, like ODE & openal-soft which haven’t been ported to Maemo yet. maemo.org/ essentially it is nokia’s debian-based linux for internet tablets and smartphones.

The hardware is identical to the beagle board (OMAP3/PowerVR SGX) so I’m hoping it shouldn’t be too difficult to port. Thanks again rdb.


Ah, okay. If the hardware is similar indeed it shouldn’t be too much effort. I cross-compile Panda3D myself with the codesourcery toolchain. I started without much thirdparty packages, and when I got it working, added those other libraries. If you want, email me and I’ll send you my Config.pp file that I used for cross-compilation.


I’m considering using Panda3D for iPhone development, but I’m not clear on how difficult that will be. What is the general process required to create an iPhone app using Panda? I would prefer to take the straight-and-narrow (non-jailbroken) path.

If possible, I’m planning to load Collada files, use OpenGLES 2.0, and develop in C++.

Thanks for any help,


We haven’t actually made a lot of forward progress on the fully-productized iPhone app development process yet. That is to say, we’re in the same state today that we were when this was discussed in this thread: the code is there, and I do have a Panda app running on my (non-jailbroken) iPod touch, but it’s not easy to develop for yet.

We hope to get this finished within the next few months.



What needs to be done before you can officially release the iPhone version?


There’s been a delay due to Apple’s new iPhone Developer License, which explicitly forbids the use of any language other than C, C++, or Objective-C (which presumably includes Python).

Feel free to write a nasty letter to Steve Jobs.



Do you have confirmation on that? Because I thought Apple simply did not want other languages to be compiled into native iPhone code. Since the Panda3D engine is written in C++ and the Python is interpreted it should be fine.

I don’t know, I’m no expert on Apple’s user agreements.


There’s a lot of speculation on the net as to what Apple really and truly has in mind, but this phrase is hard to get around:

“Applications must be originally written in Objective-C, C, C++”

There are no clarifications forthcoming from Apple, so I guess any doubts will be resolved when the new license goes into effect and we can see what they actually do forbid and what they don’t.



I agree that the new Apple license is very strict. But the truth is that it’s so strict that they can’t possibly enforce it as written–or nearly half of the top games on iPhone would need to be kicked out of the store.

Also, since C++ is a permitted language, could you potentially release Panda3d as a C+±only engine? Or is it too tightly integrated with Python to be able to disable that integration?

Technically even that would be against the rules (“no compatibility layer”). But that part of the rules is simply insane, and frankly impossible to enforce entirely.

Yes you could pick a particular engine and exclude it (using “anti-virus”-like signature techniques, for example), but you’re not going to get every developer to completely rewrite every game for iPhone that exists on other platforms. So everyone will have a compatibility layer for their own games.

But if the Python integration is too tightly bound in with the rest, then I guess you’re right–in that I personally wouldn’t want the extra overhead of a Python interpreter in my iPhone game (or on Android).

Too bad Panda 3d doesn’t use Lua instead. Much lower overhead, and faster to boot.


There’s no marriage of Panda3D and Python. It should be possible to write a C++ iPhone app using Panda3D. It’s not entirely clear to me whether this falls under the definition of using a “compatibility layer” (since Panda is open source, you can copy the entire library into your application source code folder–and then it becomes part of your application itself, not a separate layer).

That said, I’ve used Python to develop experimental apps for the iPhone, and it works fine, from a technical standpoint. But this has been hashed to death: Apple’s license is not about technical restrictions, it’s about market share.

Whether it’s realistic for Apple to eliminate nearly half of the top games in the App store is also kind of beside the point. It appears that Apple thinks this is a worthwhile sacrifice for their own business needs, and they might well be right.

Whether this new agreement is enforceable in practice or not is irrelevant for the purposes of declaring Panda3D’s iPhone support. If developing for iPhone using Panda3D would violate Apple’s developer agreement, then Panda3D cannot provide (legitimate) iPhone support.

Of course, we can continue to provide illegitimate iPhone support. That’s less exciting to developers, of course.



That’s excellent.

Sorry, yes, I have to agree on all counts. No need to rehash.

As I mentioned, a C+±only game based on Panda 3d would be hard for them to detect, and as you mentioned, it may not even be in violation of their agreement.

Yes, but…a lot of this is beside the point for me, since I want to write Android games, and I don’t want to use Python, so I’m looking at potentially using your OpenGL ES support and parts of your 3d pipeline. The ability to rebuild my game(s) for iPhone would be a bonus, but not strictly necessary.

Is all of the OpenGL ES support you mentioned above available in the current source package, and/or CVS? And the iPhone support that does exist–is that already checked in as well, or is that only on your system?