standard
(1 files, 4 lines)
object
(5 files, 1024 lines)
persist
(1 files, 3 lines)
standard
(5 files, 550 lines)Summary Period: 2000-10-08 to 2003-04-08
[root]/CS/plugins/motion
standard
(1 files, 4 lines)
object
(5 files, 1024 lines)
persist
(1 files, 3 lines)
standard
(5 files, 550 lines)
Total Lines Of Code:
3 (2003-07-11 20:29)
| Author | Changes | Lines of code | Lines per change |
|---|---|---|---|
| Totals | 28 (100.0%) | 891 (100.0%) | 31.8 |
| azverkan | 10 (35.7%) | 515 (57.8%) | 51.5 |
| jorrit | 2 (7.1%) | 204 (22.9%) | 102.0 |
| sunshine | 11 (39.3%) | 163 (18.3%) | 14.8 |
| mgeisse | 1 (3.6%) | 6 (0.7%) | 6.0 |
| matzebraun | 1 (3.6%) | 3 (0.3%) | 3.0 |
| miklby | 3 (10.7%) | 0 (0.0%) | 0.0 |
added the Jamfiles
3 lines of code changed in:
- Shift motion loader out to a plugin.
- Fix malloc/realloc bug in motion.cpp.
0 lines of code changed in:
rewrote the DECLARE_TYPED_VECTOR macro to be really type-safe
6 lines of code changed in:
Eric Sunshine renamed all of the pure SCF interface header files.
Considering that that these files were recently organized into well-named
subdirectories, it is possible to use more descriptive names for the files
themselves. Also dropped the `i' prefix.
Here are just a few examples of the new more meaningful and descriptive
names:
iengine/idlight.h --> iengine/dynlight.h
iengine/imeshobj.h --> iengine/mesh.h
imesh/imeshobj.h --> imesh/object.h
imesh/mfire.h --> imesh/fire.h
imap/ildrplug.h --> imap/reader.h
imap/isvrplg.h --> imap/writer.h
isound/isnddrv.h --> isound/driver.h
isound/isndlstn.h --> isound/listener.h
ivideo/imater.h --> ivideo/material.h
2 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Moved all of the pure SCF interface header files (the filenames
beginning with `i') into subdirectories of CS/include. They no longer
reside directly in CS/include. The new subdirectories within
CS/include are iengine, igame, igeom, igraphic, imap, imesh, inetwork,
iobject, isound, isys, iterrain, iutil, ivaria, and ivideo. Also,
several files were decomposed into multiple new files, so you may need
to include one or more of the new files in place of the old ones. The
files which were specially split are:
itexture.h -> iengine/itexture.h & ivideo/itexture.h
imater.h -> iengine/imater.h & ivideo/imater.h
imeshobj.h -> iengine/imeshobj.h & imesh/imeshobj.h
iterrobj.h -> iengine/iterrobj.h & iterrain/iterrobj.h
Also updated all source & header files, documentation files, and
makefiles to reflect this change.
-*- Eliminated several compilation warnings throughout the project.
2 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Resolved a circular reference problem between the system driver and
the VFS plugin. The actual problem was that the VFS plugin was
utilizing the new configuration manager module even though it should
not have been doing so. There are a couple of reasons why utilization
of the configuration manager by VFS was problematic. First, this
introduced an unwanted circularity since the configuration manager and
the VFS plugin each relied upon the services of the other. Second, it
does not make sense for the VFS plugin to utilize the configuration
manager at initialization time since the VFS plugin is loaded very
early in the application start-up sequence. In fact, it is loaded
before any other configuration files have been loaded (indeed, all
other configuration files are typically loaded from a VFS volume; thus
this was a chicken-and-egg issue). Now the VFS plugin manually loads
its own configuration file (vfs.cfg) rather than relying on the
configuration manager mechanism. In the future, we should introduce
some new API into the VFS plugin which allows an application to
override or augment the initial configuration from vfs.cfg. This will
allow a client application to provide its own VFS.Mount settings if
desired. Also note that when this API is finally added it should be
in the form of a method in the VFS plugin which is invoked by the
client application (or system driver) and that method should accept an
iConfigFile* as its argument. The VFS plugin can then query this
configuration object for the desired information. There is no need to
re-introduce any circularity with iConfigManager.
-*- Converted several modules to use the new configuration manager which
were missed by Martin when he made his conversion sweep through the
project.
-*- Modified all makefiles project-wide so that the individual `clean'
targets (such as `softclean', `x2dclean', etc.) no longer remove the
dependency information (.dep files). In theory, having a module's
`clean' target remove the .dep file was a sensible idea, however in
actual practice, it turned out to be quite obnoxious to lose
dependency information each time an individual module's `clean' target
was invoked. You can still remove dependency files by invoking one of
the standard and existing targets `cleandep' or `distclean'.
1 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Repaired the MacOS/X Server, OpenStep, and NextStep ports of Crystal
Space after they had sat idle for several months. Many core-level
changes to the project during the idle time broke these ports rather
severely. The ports are probably about 97% functional now compared to
how functional they were once. Some problems still exist which will
be addressed in subsequent repair and upgrade sessions. For instance,
the NextStep port is not yet fully compatible with Andrew's new
National Keyboard Support. Full compatiblity requires reverse
engineering internal NextStep structures. The MacOS/X Server and
OpenStep ports, on the other hand, are now compatible with the
National Keyboard Support. Further, certain portions of the software
renderer (which Andrew updated since the last time I repaired all such
problems) are broken for the Apple/NeXT ports running at 32-bit mode
on big-endian hardware. Future plans also include a port to the
upcoming MacOS/X, as well as further decoupling of the 2D driver from
the system driver.
-*- The default NeXT 2D canvas is now responsible for the querying and
interpreting its own `simulated depth' option. This is no longer the
responsibility of the system driver.
-*- Eliminated iNeXTSystemDriver (NeXTSystemInterface.h) which published a
method to report the simulated-depth value to the 2D canvas. The
canvas is now entirely responsible for this feature, so the system
driver need not publish this any longer.
-*- NeXTSystemDriver now manages an iEventOutlet which the 2D canvas can
use for default handling of mouse and keyboard events.
-*- NeXTSystemDriver now implements SystemExtension() to provide default
mouse and keyboard event handling on behalf of canvases, as well as
other functionality.
-*- Promoted the ability to suspend the engine's virtual-time clock into
csSystemDriver from NeXTSystemDriver where this feature was originally
implemented. This is useful for ports which allow the user to suspend
the entire engine (for instance, to be friendly on multi-tasking
systems). Suspending the virtual-time clock prevents temporal
anomalies from occurring within the engine even though the real-time
clock continues to elapse. An example of a temporal anomaly would be
the firing of a missile just prior to suspension of the engine. Upon
engine resumption, if the virtual-time clock was not also suspended,
the missile would suddenly jump forward as though much engine time had
elapsed.
-*- Updated Apple/NeXT plug-in loading (NeXTLoadLibrary.cpp) to work
correctly with new plug-in search-path capabilites. Also now
implements a meaningful csPrintLibraryError()
-*- Enhanced keyboard handling in the MacOS/X Server and OpenStep ports to
be compatible with Andrew's National Language Support functionality.
(This feature is not yet fully implemented in the NextStep port.
Doing so requires reverse engineering internal NextStep data
structures.)
-*- Implemented F1 - F12 function key translation in MacOS/X Server and
OpenStep ports. (These keys are not yet implemented in the NextStep
port.)
-*- csEngineConfig is no longer an inner-class of csEngine. This change
was made in order to work around a bug in the NextStep compiler which
was triggered after csObject (from which csEngine inherits) was
changed so that it inherits from iObject. Somehow, the compiler was
getting confused by the QueryInterface(), IncRef(), and DecRef()
methods declared in csEngineConfig as well as in iEngine and csObject
(both of which csEngine inherits from). Making csEngineConfig
stand-alone works around the problem.
-*- In order to work around a multiple-inheritance bug in NextStep
compiler, changed the following classes so that they embed an SCF
interface rather than inherit from it:
iCameraPosition -> csCameraPosition
iMaterialWrapper -> csMaterialWrapper
iRegion -> csRegion
iSpriteTemplate -> csSpriteTemplate
iTextureWrapper -> csTextureWrapper
The compiler's symptom was that it did not think that IncRef(),
DecRef(), and QueryInterface() were implemented in classes which
inherited from iBase multiple times (through different paths).
*BEWARE* There were many places where the engine was dangerously and
blindly casting pointers between the interface and the implementing
class. For instance, a pointer might be cast from a csMaterialWrapper
to an iMaterialWrapper or vice-versa. Although this worked when the
implementing class inherited from the SCF interface, it does _not_
work when the interface is embedded. The danger here is that the
compiler does not warn about this problem since it assumes that the
programmer knew what he or she was doing when using the cast operation
in the first place. I tried to repair all such broken and dangerous
blind casts in which the above classes were involved, but it is
possible that I missed one here or there.
-*- Added an assignment operator to ddgTriangle3 in order to appease the
NextStep compiler.
-*- Added a missing `inline' keyword to csCovMaskTriage::GetState(). The
lack of this keyword resulted in this function being implemented and
exported from every single source file which included the header.
-*- Unified the case of the `full-screen' extension as understood by
iGraphics2D::PerformExtension(). Some canvases expected "fullscreen",
whereas others expected "FullScreen".
-*- Added a preprocessor flag to Blocks which allows all of the broken
networking code to be disabled in one fell-swoop.
-*- Eliminated compilation warning in pttex.cpp.
-*- Minor modification to csphyzik/entity.h to appease broken OpenStep
compiler which wasn't instantiating template methods early enough.
Worked around problem via simple textual reordering of header so that
templatized variables are declared before they are actually referenced
by inline methods.
-*- Augmented TrueType to CS font converter makfile (csfgen.mak) so that
its target only shows up on platforms which also build the TrueType
font server plug-in.
-*- Eliminated several compilation warnings in ddgchull.cpp regarding use
of enumeral and non-enumeral types in conditional expression.
-*- Added missing SYSDEF_ALLOC define to halogen2.cpp.
-*- Worked around minor compiler bug on NextStep which affected csapp.cpp
and txtmgr.cpp.
-*- Eliminated several compilation warnings about "unused computed value"
in CSWS and several applications which utilize CSWS, such as cswstest
and levtool.
-*- Worked around NextStep compiler limitation in null_pix.cpp and
drawpmap.cpp.
-*- 3dsout.cpp now includes cssysdefs.h in order to fake up a `bool' type
for compilers which do not support `bool' natively.
-*- Fixed error in me_app.cpp. Was assinging an mzModificationOriginDepth
constant to a csVector3 instance.
-*- imotion.h no longer imports matrix3.h and quaterni.h. iskeleton.h no
longer imports transfrm.h. Not only was this unnecessary, but it also
caused csSystemDriver to depend upon these classes on NextStep, which
was a less-than-desirable consequence. This resulted in linkage
errors when linking the csSystem library into applications which do
not otherwise link with the csGeometry library (such as scfreg).
(This problem is specific to the NextStep compiler which generates
references to every mentioned class even if the class isn't actually
used.)
-*- All source files in apps/t3d2cs and apps/t3d2cs/libt3d now import
cssysdef.h as the very first included file. This ensures that the
`bool' type is faked up, if necessary, before it is used by any other
imported headers.
-*- Eliminated an "unused variable" warning in tBrush.cpp.
-*- Worked around a bizarre NextStep compiler bug which manifests as an
apparent corruption of the virtual table for csSprite2D. Calls to
QueryInterface() from a csSprite2D pointer would never actually invoke
the real, inherited csSprite::QueryInterface(), and would instead
always return NULL. It is not even clear which, if any, method was
being called in lieu of the real csSprite::QueryInterface(). Calls to
QueryInterface() from a local instance of csSprite2D would succeed as
expected (since the virtual table is not consulted in this case). The
work around for this problem (for magical reasons) is to declare
QueryInterface() in csSprite2D which overrides the inherited
csSprite::QueryInterface(). It is sufficient for this method to
simply exist in csSprite2D. Its actual implementation merely invokes
its superclass' QueryInterface().
1 lines of code changed in:
Made the following changes to the project:
-*- Finally eliminated the evil monolithic apps/support/static.cpp file
which caused repeated maintenance headaches. The problem with this
file was that every time a plug-in module was added or removed from
the project, a developer also had to remember to edit static.cpp to
reflect the change. Thus, the perceived modularity of plug-ins was
offset by the very real monolithic disposition of this file.
-*- As a replacement for static.cpp, the new makefile CS/mk/static.mak
automatically and dynamically synthesizes C++ code which forces hard
symbolic references to each plug-in module being linked into the
application (assuming that the application is being linked
statically---that is, with USE_PLUGINS=no).
-*- Information used by the synthesis process is gleaned from the GNU
makefiles, project-wide. The old CFLAGS.STATIC_SCF makefile variable
has been removed. A new variable, SCF.STATIC, contains a list of
plug-in module basenames (such as `soft3d', `vfs', etc.), and this
information is used to synthesize the hard references needed when
linking applications statically.
-*- The static.mak makefile is smart enough to regenerate the synthesized
symbolic references when certain events occur; such as when the user
edits the list of plug-in modules in user.mak or reconfigures the
project's makefiles.
-*- Note that the new synthesis process is geared toward platforms which
utilize the GNU makefile system to build the project. It does not
apply to ports which use `project files'. However, historically, none
of the ports which rely on project files has ever supported static
linking, so this is no loss. If, in the future, a port does wish to
support static linking via project files, it would be a simple matter
to set up an automated synthesis task, and commit the result to the
CVS repository on a regular basis, much as is already done with MSVC
project files.
-*- Added $(DEP.EXE) to the dependency lists of the following GUI
applications. This should allow them to successfully link statically
(that is, when USE_PLUGINS is `no'):
cctest
g2dtest
-*- Removed $(DEP.EXE) from the dependency list of the following console
applications, since they need not link against the various plug-in
modules:
csfgen
makedep
scfreg
scftutor
textconv
uninst
1 lines of code changed in:
Corrected the long standing misnomer where USE_PLUGINS was incorrectly
specified as USE_SHARED_PLUGINS. Updated all makefiles, scripts, and
documentation to reflect this change.
1 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Visual-C++ DSW and DSP project files are now automatically generated
and updated. Information gleaned from GNU makefiles, project-wide, is
used to synthesize DSW and DSP files on-the-fly. The project file
synthesis procedure attempts to enforce the invariant that if a module
builds correctly via the GNU makefile, then the same module should
build correctly via the Visual-C++ project file which was built from
information gleaned from the makefile. Thus, the headache associated
with manual maintenance of the Visual-C++ project files should be a
thing of the past.
-*- Added a new directory, CS/mk/msvcgen, in which all resources related
to automatic generation of Visual-C++ project files reside.
-*- Added msvcgen.pl, which is a Perl script capable of generating
Visual-C++ DSW and DSP files based upon input arguments and a set of
template files. The script accepts a useful array of options for
controlling several aspects of the synthesis process, and is also
independent of Crystal Space, thus it may be useful in other arenas as
well. A copious amount of documentation related to the generation of
DSW and DSP files, including a description of the special variables
which may appear in template files, may be viewed by invoking
msvcgen.pl with the --help option.
-*- Added the directory CS/mk/msvcgen/template, which contains template
files used by msvcgen.pl during the synthesis of Visual-C++ DSW and
DSP project files. The master level templates are appgui.tpl,
appcon.tpl, group.tpl, library.tpl, and plugin.tpl, which represent
the five different types of DSP files which can be generated. These
templates are supplemented by the template-include files dspgroup.tpi
and dspfile.tpi, which combine to form resource groups within each
DSP. The master level template dsw.tpl is used for synthesizing DSW
files and is supplemented by dswgroup.tpi and dswdep.tpi, which
combine to form dependency groups within the DSW. Refer to the --help
output of msvcgen.pl for a description of the special variables which
may appear in each of the template files.
-*- Added msvcgen.mak, which is the Crystal Space-specific makefile
responsible for generating, and optionally installing, Visual-C++ DSW
and DSP project files. It performs this task by gleaning information
from GNU makefiles throughout the project and then invoking msvcgen.pl
with the appropriate arguments to synthesize each DSP file represented
by a makefile, as well as the master DSW file, csall.dsw. Also added
the supplemental makefiles win32.mak and required.mak. The first,
win32.mak, contains additional Windows-specific DSP targets (such as
grpall, grpplugins, libcswin32dll, etc.) which are not otherwise
represented by makefiles. The second, required.mak, supplements the
normal PLUGINS makefile variable with a list of modules for which DSP
files must be generated regardless of the platform which is performing
the project file generation procedure. This allows any platform (such
as Unix) to generate the complete set of Visual-C++ project files.
-*- Added two makefile targets which are specific to Visual-C++ project
file generation and installation.
o 'msvcgen' builds the entire set of DSW and DSP files represented by
the GNU makefiles, project-wide. The generated files are placed in
CS/out/mk/visualc.
o 'msvcinst' copies the DSW and DSP files from CS/out/mk/visualc to
their official location at CS/mk/visualc. Furthermore, this target
instructs the user as to exactly which CVS commands must be invoked
in order to properly commit the newly generated files to the CVS
repository. For instance, if a new plugin named "foo" is added and
an old library named "bar" is dropped, the 'msvcinst' target will
instruct the user to invoke the commands "cvs add -kb plgfoo.dsp",
"cvs remove libbar.dsp", and "cvs commit" in order to make the
changes permanent. The 'msvcinst' target automatically invokes the
'msvcgen' target, so the synthesis and installation procedures can
be performed as one operation.
-*- Added support for automated Visual-C++ DSW and DSP project file
generation to all of the GNU makefiles, project-wide. Project file
synthesis is performed by gleaning the values from some existing
makefile variables as well as some newly added ones. In the following
discussion, assume that "PROJECT" is the core name of the module
represented by a particular makefile.
In addition to the existing makefile variable SRC.PROJECT, the
following new general-purpose variables were added to support
Visual-C++ project file creation:
o INC.PROJECT -- Complements SRC.PROJECT, but lists header files
related to this project.
o DEP.PROJECT -- Although this variable already existed in some
makefiles, its meaning has been altered slightly. The value of this
variable is the list of projects (typically library projects) upon
which this module depends. Each item in this list is the core name
of some other module, such as "CSGEOM", "CSUTIL", or "CSSYS".
o LIB.PROJECT -- This variable now assumes the roll which DEP.PROJECT
used to play in some makefiles. It lists the libraries upon which
this module depends. The value of this variable is normally derived
automatically from DEP.PROJECT, but may be specified manually in
very special cases if necessary (though doing so is frowned upon).
If specified manually, each entry should be of the form
"$(PROJECT.LIB)".
o CFG.PROJECT -- List of configuration files related to this module.
Furthermore, the following new variables specifically control DSW and
DSP project file creation. These variables should only appear in
makefiles for which a corresponding DSP file should be generated.
o MSVC.DSP -- This is the master list of modules for which project
files should be generated. Entries must be *appended* to this list
with the "+=" operator. Each entry is the core name of a module as
used within its makefile. For example, soft3d.mak, ensures that a
project file is created for the 3D software renderer by invoking
"MSVC.DSP += SOFT3D".
o DSP.PROJECT.NAME -- Base name (such as "soft3d") for the generated
project and target. This name is used to compose the DSP file name,
the end target (such as "soft3d.dll"), and the displayed project
name in the Visual-C++ IDE. In general, it should be identical to
the base name of the target which is generated for non-Windows
platforms.
o DSP.PROJECT.TYPE -- The module's type. It should be one of
"appgui", "appcon", "library", "plugin", or "group", which stand for
GUI application, console application, static library, plug-in
module, and pseudo-dependency group, respectively.
o DSP.PROJECT.RESOURCES -- Lists any extra human-readable resources
related to this module which are not covered by CFG.PROJECT. These
resources may be browsed in the Visual-C++ IDE as a convenience to
the user. Some good candidates, among others, for this variable are
files having the suffixes .inc, .y (yacc), .l (lex), and .txt.
o DSP.PROJECT.DEPEND -- Lists extra dependencies for this module.
Entries in this list have the same format as those in the
DEP.PROJECT list. This variable is generally only used for
pseudo-dependency group projects (see win32.mak).
-*- Renamed docproc.pl to jobber.pl and modified it to also rebuild and
commit Visual-C++ DSW and DSP project files in addition to its normal
duties of rebuilding and publishing project documentation. The script
is automatically invoked twice daily. As always, the script is smart
enough to add new project files, and remove obsolete project files
from the CVS repository in addition to committing those which were
only modified. It also takes special are to use the "-kb" option when
adding Visual-C++ project files to the repository in order to preserve
the CRLF line terminators (which Microsoft requires). Also, when
scanning directories to determine which files to add and remove from
the repository, ".cvsignore" files are now ignored (along with all
other CVS administrative files which have always been ignored).
-*- Performed significant unification and clean-up of makefiles throughout
the project. Simplified several makefiles which had unnecessarily
complicated innards. Also added missing makefiles: snda3d.mak,
sndds3d.mak.
-*- Changed suffix of OpenGL extension-detection files from .cpp to .inc
since they are use as include-files rather than stand-alone sources.
Also performed much clean-up of these files.
-*- The standard system-dependent makefiles now define the additional
utility command definitions CD, PWD, and PERL (in addition to other
existing definitions such as RM, MV, CC, etc.). The default
definitions are specified in unix.mak and dos.mak.
-*- The makefile fragment common.mak now specially defines $" and $| if
they are not already defined. This allows recursive 'make'
invocations to use these variables with "echo" commands within targets
in exactly the same way as top-level makefile targets can do so.
-*- Fixed the makefile 'clean' targets of all library modules so that they
also remove the generated dependency (.dep) file. (Other makefiles
around the project had already been repaired in this manner.)
-*- Removed obsolete memory-debugger support from cssys.mak. Andrew had
removed the remainder of this cruft from the rest of the project on
2000/10/30 but missed cssys.mak.
-*- Added better documentation and more correct protection to ddg.h's
inclusion of cssysdef.h.
-*- Removed references to obsolete "null" sound driver from makefiles and
documentation.
18 lines of code changed in:
Cleaned up formatting for the code from Brandon.
204 lines of code changed in:
There are some issues with frames where no interpolation occurs,
but Quaternion based skeletal animation is in and amazingly fast
even before attempting to optimize. Matrix mode animation is
supported, but no interpolation code exists yet. Tons of changes
to the csQuaternion class as it appears that nobody has used it yet
and one function added to csMatrix3 to support Quaternion
initialization. Also revamped the iMotion interfaces a bit, and
added a hacky SCF implementation for the csSkeleton classes until
someone with better knowledge can fix them so they are correct.
256 lines of code changed in:
-*- Added csHashCompute(char const*) to hashmap.{h|cpp} which quickly and
effectively computes a hash key from a string.
-*- Eliminated the bogus and broken GetReducedHash() which Brandon added
to csMD5. Brandon was using this as a bizarre form of very expensive
string hashing. To say that this was overkill is an understatement.
It was like using a sledge-hammer to kill an ant. Furthermore,
GetReducedHash() was buggy and failed to be endian-correct.
-*- Modified Brandon's motion.cpp to use the inexpensive csHashCompute()
rather than the overkill and bogus GetReducedHash(). Also reformatted
motion.cpp to follow CS formatting guidelines. (Brandon, please use
tab size 8!)
-*- Fixed a memory corruption bug in motion.cpp. Was writing past the end
of an allocated buffer when copying a string.
-*- Removed garbage which brandon left in motion.mak.
-*- Added Motion plugin to user.mak and static.cpp since Brandon forgot to
do so.
-*- Removed one of the CS_ASSERT() calls which Brandon inserted into
csBasicVector since it fundamentally changed the behaviour of the
class, even though he neglected to modify the rest of CS to take this
fundamental behavioral change into account. (Brandon, if you make
fundamental behavioral changes like this, then you must also fix every
place in the project which is affected by such changes. Do not expect
other people to keep cleaning up after you.)
137 lines of code changed in:
Frame index bug that caused a crash
8 lines of code changed in:
Fixed compile errors
6 lines of code changed in:
Had a revelation and restructured the motion API
123 lines of code changed in:
Adding the motion interface to the CVS tree. The SCF interfaces & the
loader are 90% done, but the plugin and rendering loop still need to be
implemented.
122 lines of code changed in:
Generated by StatCvs v0.2-dev