Important Notes
VortexGE library built with different configuration options and/or different
GCC versions will be most likely not ABI compatible, but should be API
compatible (unless I have made bugs in the source code).
Two VortexGE libraries with different versions built with exactly the same
options and GCC will be most likely not ABI compatible (tough may still API
compatible). In this case recompiling the application with the newest VortexGE
library is a must.
In future releases, when VortexGE has become stable (let say version 1.x.x),
the ABI and API between versions will be made compatible as far as possible
(assuming the user uses the same configuration options and GCC).
By default, VortexGE will build only the shared
libraries. See the topic "Configuring, Building and
Cleaning" for more details.
Below are some other important notes that need to be remembered when using
VortexGE :
- VortexGE is designed to use the left-handed coordinate system. In this
case all panels' vertices must be arranged in clockwise formation in order to
be displayed correctly.
- VortexGE uses perspective corrected texture mapping but only uses simple
linear lighting calculation for smooth (gouraud) shading. This algorithm may
cause noticeable light intensity warp. In order to reduce the warping effect,
try to :
- Minimize the use of gouraud shaded panels, try to use the flat shaded
or even the unshaded panels whenever possible. The panels count can be
increased to obtain smoother looks even with flat shading.
- Place the scene omni light in a spot that is not too close with the any
of the panels.
- The recommended texture sizes to be used are 64, 128 and 256 pixels
(although textures with sizes of 16, 32 and 512 pixels are also supported).
- When an application using VortexGE crashes (even VortexGE always installs
fatal signal handler), resource lack might still can be occurred. In this case,
the user can remove the "unwanted" shared resources (shared memory segments
and/or message queues) using the provided utility
"util/ipcrem" (or manually using the
Linux's utilities "ipcs" and
" ipcrm").
- For libTiMidity (which is included as 3rd party source code) to work well,
one must make sure that :
- Patch files (sampled musical instruments waveforms) are installed in
one's system. They are usually in "/usr/share/timidity/instruments"
(or in "/usr/share/timidity/eawpats" if
eawpatches package is installed).
- A usable TiMidity configuration file (usually "/etc/timidity.cfg"
or "/usr/share/timidity/timidity.cfg") is
exist and valid.
The easiest way to meet this requirements is to install all the TiMidity
(or TiMidity++) packages that come with your Linux distribution. The classic
TiMidity (which is the foundation of libTiMidity) can be relicensed under the
GNU LGPL (see
http://sca.uwaterloo.ca/www.cgs.fi/tt/timidity). Even the newer TiMidity++
is only available in GPL, it is ok to install it and use its patch files with
VortexGE because patch files
are not linked with the VortexGE library, patch files are just sampled
musical instruments waveforms (PCM samples with additional information such
as which part of the samples are belong to the intro/looping/ending section).
- Most of VortexGE APIs are not thread safe (for some classes, as long
as the same instances are not used from more than one thread, they may be
thread safe). It is a good idea to use the CMutex class from the start for
multi-threading application and then remove the mutex locking one by one after
the application has become stable (to see which actually need locking and
which are not). I plan to make a list of classes that can be used safely from
more than one thread (as long as not the same instances) in the future.