Some questions about the npapi/activex layer thing.
I know it’s work in progress but is it in svn anywhere for preview?
I know that it will support python and c++. But will it support mixed languages? i.e: python as base and some parts in c++? I guess it does, just want to be sure.
What dependencies will the plugin be shipped with? For example, fmod is the preferred audio platform currently but it would be preferable (for me at least) to have openal in there. (I doubt you can legally distribute fmod like that anyway). So, what dependencies are planned?
It’s in CVS, you can compile it easily with makepanda. It’s a bit tricky to set up without explanation though, e-mail me and I’m willing to give you one. I believe David has a test build uploaded somewhere, email him/me for a link if you really want to test it.
As far as I’m aware, C++ support is not planned (yet).
Anything. Basically, when running an app in a browser, the plugin pulls in a very light optimized Panda build. The application can specify what dependencies it needs and the plugin will automatically download it and plug it into this runtime Panda3D build.
This basically allows for a very small download but any dependency we choose to host (physx, ode, fmod, or external deps like wx or pygame, you name it).
Ouch, there goes my best reason to use panda. I was convinced I had read that. But now that I checked the blog entry again I was probably assuming that because I had just read about google native client (http://code.google.com/p/nativeclient/) that day.
But now that I think about it… if I want to have c++ with panda in a plugin I could just use the integration work already done and build my own plugin that way. The disadvantage would be that users would need to install a plugin just to play my game but QuakeLive already does that and it works fine for them. Do you know if this is feasible or if there’re plans to support it, even if minimally? If not, may I suggest you guys keep this in mind while doing it?
The ideal scenario (provided native code execution a la google client is not planned) would be to be able to #include “pandaFrameworkNPAPI.h” or #include “pandaFrameworkActiveX.h” and have makepanda build a plug-in. That would be perfect, but I don’t even ask for that much. Just not making the assumption that the plugin is always gonna run python would be enough, so that we can put together a “pandaActiveX.h”, etc.
Actually, the current design of the plugin does fully support this idea:
The plugin does embed Python internally to get the ball rolling, to be the “base” as you put it. Beyond that, your embedded application can contain any code of your choosing, either more Python code, or a compiled C++ library (with a suitable Python-callable entry point), or a mixture of both.
You are also, of course, free to compile and distribute your own version of the plugin, and I’ve gone through some effort to make this relatively easy; but I wouldn’t recommend going this route unless there really is some compelling reason to do so.
Oh, that sounds good, then. And yeah, you are right, in that case it’s a good idea to stick to Panda3D official plugin. I’m also hoping that if Disney is gonna use this they will use the same binary distribution of the plug-in, right? Which means that people that has played a Disney game will already have the plug-in, not a lot of market share but it helps. Also it’s a guarantee that it will be well supported, for timely security fixes, etc.
Got another one: does the plug-in support switching to full-screen? Is this planned? If so, how is it gonna work? Browser plug-ins usually switch to full-screen without changing the screen resolution. If the panda plug-in does the same we may end up with brutal native resolutions that our games can’t handle like 1920x1080. Some form of stretching would be preferred… so that panda would be rendering to 800x600 or whatever the original size was but stretched to full screen. I don’t know anything about NPAPI or ActiveX so I don’t know if this is something that is handled automatically or what.
Of course you could always change the real desktop resolution but that takes a little of time, not to mention you could lock the monitor in a non-supported frequency. But I’m guessing Panda handles this already so if that is the idea that’s ok too.
The window configuration is really up to the app, not the plugin per se.
When you launch an app via the plugin, the plugin provides the requested window size and placement within the browser window. It is then up to the app whether to respect that information and create an embedded window (which is the default behavior if your app uses the normal Panda startup sequence), or to create some other window instead, such as a fullscreen window.
An app may also launch initially with an embedded window, and then switch to a fullscreen window later, at the time of its choosing, using existing window-management code in Panda.
When an app requests a fullscreen window in Panda, it changes the desktop size as requested. There aren’t any built-in safeguards against unsupported monitor frequencies, but this hasn’t been an issue historically, since most games are designed for well-standardized desktop sizes. A robust app would have a user-assisted fallback when switching configurations like this. An app could also simply request a fullscreen window that matches the current desktop size (at least on Windows, where this information is already available, and on other platforms in the future); then it would have to be prepared to accept whatever size that is.