Difference between revisions of "ContentTools:DeveloperDesign:General"

From VsWiki
Jump to: navigation, search
(Added some implementation generalities)
 
m (Add back link)
Line 1: Line 1:
 +
Back to [[ContentTools:DeveloperDesign|Developer Design Documents]]
 +
 
== Development Language ==
 
== Development Language ==
  

Revision as of 17:13, 15 May 2008

Back to Developer Design Documents

Development Language

All content tools (in fact all support applications for VS) will be done in Python, when the performance or convenience for low-level manipulations of C++ is not required. To this date, the only such tool that requires C++ is the mesh importer (mesher).

When specific tasks of an application do require an implementation in C++, be for performance or because its implemented within the VS engine, python bindings through an extension module will be used so that the bulk of the application remains implemented in the Python. The objective of this is to guarantee trouble-free portability across all supported platforms.

Libraries

Some libraries will be mandatory for various reasons.

  • User interface: Support applications will use TkInter. The reason behind this forceful adoption of the library is to make support for all official tools uniform and easy, and to avoid what would happen if each tool mantainer chose its own preferred toolkit (dependency mayhem).
  • 3D visualization: This is a complicated point. Eventually, when and if the Ogre rendering backend of VS materializes, applications should use it since it would provide an easy-to-use and well abstracted view of VS resources, besides rendering things exactly the way they would be rendered ingame (quite important for previews). Right now, however, this may be a problem, since that backend has not been implemented. Ideally, 3D visualization would wait for such backend which, ideally, would be finished by 0.6. When 3D visualization is a must, though, an ad-hoc solution will be required. Python-Ogre is a possibility, however loading current-generation VS resources into Python-Ogre may be nontrivial.
  • XML parsing: Since the engine already uses classes specifically designed for XML parsing and editing, and since we want perfect correlation between how the various tools process a file and how the engine does (ie: the same set of XML namespace extensions), we'll be relying on said XML parsing implementation exposed to python as an external module.