Table of Contents
The BigWorld Technology engine now includes the open source Mozilla project allowing for displaying and interacting with web pages as part of the client.
The BigWorld Technology Client includes the following components as part of the web browser integration:
-
The bigworld/src/lib/web_render directory contains the BigWorld web integration code. The WebPageProvider class is the main interface for the web integration. The MozillaWebPageInterface class contains the main interface implementation for the Mozilla integration.
-
The Mozilla project, see http://www.mozilla.org/ is the web layout engine used by the BigWorld Technology Client. This project is shipped as compiled dlls as part of the BigWorld engine. These dlls are available in the fantasydemo/game/mozilla directory. Different dlls are compiled for Visual Studio 2005 and Visual Studio 2008. These dlls are based on the Mozilla 1.8 release. If required, customers can also replace these dlls by recompiling Mozilla using the instructions available at http://ubrowser.com/. When recompiling Mozilla, additional fixes to the Mozilla source code might be required (see the content of bigworld/bin/client/mozilla/patch/mozilla_diff.txt for more details. Any modification to the Mozilla source code will require redistribution of the modification (as required by the Mozilla license).
-
The LLMozlib library, see http://ubrowser.com/ is an open source wrapper for the Mozilla project and is shipped as part of the BigWorld source code. The LLMozlib source code is available in bigworld/src/lib/third_party/llmozlib2 and is compiled as part of the BigWorld client solution file. Any modification to the LLMozlib source code will require redistribution of the modification (as required by the LLMozlib license).
How the code works:
-
A secondary thread is used to deal with all web related requests. This prevents performance spikes when responding to long web related requests.
-
The MozillaWebPageManager manages calls to Mozilla and callbacks by using a separate command thread with two FIFO buffers.
-
Users (i.e. Python/C++ classes) use MozillaWebPageInterface to interact with the MozillaWebPageManager, and they send commands to the manager which are sent over via the FIFO buffer to be dealt with by the secondary thread. This thread dispatches the commands to the MozillaWebPage instance which correlates with the MozillaWebPageInterface.
-
Callbacks are dispatched using a second FIFO buffer which is flushed by the main thread during the tick method.
-
Please note that all interaction with Mozilla must be done in the second thread (as Mozilla itself is not thread safe).
-
Please note that global plugins have been disabled as of BigWorld 2.1 as the LLMozlib library is incompatible with the Adobe Flash Player 11 plugin. In order to distribute an earlier version of the Adobe Flash Player with your application, you will need to obtain a license from Adobe. This can be obtained from http://www.adobe.com/products/players/flash-player-distribution.html
Plugins must now be installed manually.
To re-enable global plugin support, change
CHECK_LLMOZLIB_CALL_RET(llmozlibInstance->enablePlugins(false));toCHECK_LLMOZLIB_CALL_RET(llmozlibInstance->enablePlugins(true));in mozilla_web_page.cpp in the web_render project.
The BigWorld web integration can be used in multiple scenarios. Multiple usage examples are available as part of FantasyDemo and will be explained below.
An in game web GUI component is a GUI component capable of displaying 2D web content and sending mouse and keyboard events to that web content. There is some experimental (not supported) code also allows building a game integrated with ActionScript and JavaScript components (see below).
Displaying an interactive 2D web GUI Component which can be used to browse the web can be done by creating a GUI component containing a child SimpleGuiComponent using the fantasydemo/res/scripts/client/Helpers/PyGUI/InternalBrowser.py script. For an example of a 2D web GUI component please review the fantasydemo/res/gui/web.gui. Following are the main considerations for creating an interactive 2D web GUI component.
-
The web.gui contains multiple child GUI components. The main GUI component used to display the web content is the InternalBrowser component. Other child components are mainly used to display navigation buttons, a window label and the window texture.
-
The InternalBrowser.py sets the SimpleGuiComponent texture to use the TextureProvider returned by the WebPageProvider in order to display the web page as part of the SimpleGuiComponent.
-
The InternalBrowser.py implementation currently supports two types of keyboard input methods. Keyboard input is automatically captured by Mozilla when mozillaHandlesKeyboard is set to True, otherwise key events are sent to Mozilla by the InternalBrowser script, allowing for in game IME implementation.
A game integrated 2D web GUI component is a web GUI component which can interact with the game logic. This allows building game GUI using fast development tools like HTML or Flash, and having them call Python methods using a JavaScript to Python or ActionScript to Python bridges. Please note that this BigWorld feature is not supported and we recommend using the ScaleForm solution for customers interested in such a solution. Implementing a Game Integrated 2D Web GUI Component is done similarly to the above Interactive Component but with several additional steps. The fantasydemo/res/gui/html_chat_window.gui contains an example html GUI component using the JavaScript to Python bridge.
An in game web screen is a 3D in game entity with similar capabilities and use cases as the previously explained Web GUI Component. The main difference between the Web GUI component and the in game web screen is that the Web Screen is part of the 3D game scene and not a 2D GUI component. This Web Screen is located in a specific world location and isn't available for gamers as part of their HUD.
The WebScreen entity available as an example in fantasydemo/res/scripts/client/WebScreen.py implements an in game web screen. Following are the main considerations for creating an In Game Web Screen:
-
The WebScreen entity uses a model with multiple tints, the current tint is fed by a TextureFeed created by the WebScreen entity. The parameters usedTint and textureFeedName control the entity model used tint and the TextureFeed name used by this entity. These should usually contain the same string based on the tints available for that model. These options are exposed as part of World Editor.
-
The model used by the WebScreen entity should also have three hard points called HP_top_left, HP_top_right, HP_bottom_left. These hard points are used by the _intersectMouseCoordinates method to find an intersection between a world ray and the entity model. This allows sending mouse events with a 2D position to the actual web page.
-
The webPage member of this entity contains a WebPageProvider and is used to render a web page and to send mouse and keyboard events to the web page.
The TextureProvider returned by the WebPageProvider can be used to build a TextureFeed (similar to the one used for the WebScreen entity above). A VideoScreen Entity allows simple usage of the TextureFeed to map the texture into 3D world objects with the correct material settings (same as the tints used above). The exhibition room in the Urban space contains a teapot example of mapping a web texture into a world object using a VideoScreen entity.