ContentTools:DeveloperDesign:General - Revision history

Nikai: sp

2010-07-12T21:01:54Z

klauss: Add back link

2008-05-15T16:13:09Z

Add back link

klauss: Added some implementation generalities

2008-05-15T16:08:59Z

Added some implementation generalities

New page

== 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 [http://wiki.python.org/moin/TkInter 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. [http://python-ogre.org/ 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.

← Older revision		Revision as of 16:13, 15 May 2008
Line 1:		Line 1:
		+	Back to [[ContentTools:DeveloperDesign\|Developer Design Documents]]
		+
	== Development Language ==		== Development Language ==

@@ Line 5: / Line 5: @@
 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.
+When specific tasks of an application do require an implementation in C++, be for performance or because it's 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 ==
@@ Line 11: / Line 11: @@
 Some libraries will be mandatory for various reasons.
-* '''User interface''': Support applications will use [http://wiki.python.org/moin/TkInter 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).
+* '''User interface''': Support applications will use [http://wiki.python.org/moin/TkInter 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 maintainer 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. [http://python-ogre.org/ 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.