Total Lines Of Code: 12293 (2003-07-11 20:29)
Summary Period: 2001-12-04 to 2003-07-09
[root]/CS/plugins/mesh/thing/object
Total Lines Of Code:
12293 (2003-07-11 20:29)
| Author | Changes | Lines of code | Lines per change |
|---|---|---|---|
| Totals | 330 (100.0%) | 20744 (100.0%) | 62.8 |
| jorrit | 273 (82.7%) | 19924 (96.0%) | 72.9 |
| res2002 | 12 (3.6%) | 382 (1.8%) | 31.8 |
| tulebast | 5 (1.5%) | 265 (1.3%) | 53.0 |
| sunshine | 12 (3.6%) | 41 (0.2%) | 3.4 |
| tetron | 4 (1.2%) | 31 (0.1%) | 7.7 |
| philwyett | 10 (3.0%) | 26 (0.1%) | 2.6 |
| gblock | 1 (0.3%) | 23 (0.1%) | 23.0 |
| dentoid | 4 (1.2%) | 23 (0.1%) | 5.7 |
| matzebraun | 4 (1.2%) | 19 (0.1%) | 4.7 |
| thebolt00 | 1 (0.3%) | 4 (0.0%) | 4.0 |
| alquarra | 1 (0.3%) | 3 (0.0%) | 3.0 |
| ab031ns | 2 (0.6%) | 2 (0.0%) | 1.0 |
| vengeance2001 | 1 (0.3%) | 1 (0.0%) | 1.0 |
- Jorrit fixed PlaceMesh() so that it now uses
engine->GetNearbyObjects(). That makes it a lot more efficient
then the old implementation which simply traversed all objects
in the current sector.
- Jorrit added iMeshWrapperIterator to iterate over meshes.
- Jorrit added three new functions to iEngine: GetNearbyMeshes()
and two versions of GetVisibleMeshes(). These functions complement
the already existing GetNearbyObjects() and GetVisibleObjects().
Instead of returning an iObjectIterator they return an
iMeshWrapperIterator. This avoids the need to do SCF_QUERY_INTERFACE
to get the iMeshWrapper in the code using the iterator so this
can be a significant optimization.
The Get...Objects() functions will not be removed because in the
future they will also return lights.
Side note: GetVisibleObjects() and GetVisibleMeshes() are not
implemented yet.
- Jorrit changed PlaceMesh() so it uses GetNearbyMeshes() now.
- Jorrit changed Walktest collision detection code so it uses
GetNearbyMeshes().
1 lines of code changed in:
Fix so that the object plane (polygon normal) is updated if necessary
when csPolygon::GetObjectPlane() is called.
14 lines of code changed in:
Eric Sunshine removed the unused, obsolete, and deprecated top-level <name>
node from the .csplugin files.
0 lines of code changed in:
Made the following changes to thing:
- Polys are now triangulized as single triangles instead of tri
fans. That makes it possible to store multiple poylgons in a
single rendermesh. Now one rendermesh per material is created.
- Index buffer now uses UNSIGNED_INT instead of INT. The latter
one doesn't seem to be liked by ATI's Cat3.4.
Added a Jamfile for the stencil shadow renderstep.
77 lines of code changed in:
Made the following changes to the new renderer system:
- Index buffers aren't treated in a special way any more now.
Just your average vertex buffer.
- Changed the internal implementation of render buffers a bit.
- Renamed stencil shadow binary to 'rlsstencil' to fit in with the
other renderstep plugins.
2 lines of code changed in:
- Jorrit fixed a compile error in thing with relation to the new
renderer.
2 lines of code changed in:
Started working on converting thing for NR. You already can see
something, but it's still rather crude and naive, tho.
248 lines of code changed in:
- Jorrit made the <moveable/> option no longer required (it is
now deprecated). The thing mesh object plugin will not automatically
detect if it is needed to switch to moveable or not. So setting
this is no longer required.
12 lines of code changed in:
- Jorrit fixed the bezier mesh so that ForceRelight() with a new
light also works.
- Jorrit fixed the bezier mesh so that removing a pseudo-dynamic
light also works.
1 lines of code changed in:
- Jorrit fixed thing so that removing a pseudo-dynamic light actually
works.
26 lines of code changed in:
- Jorrit added iLightingInfo->StaticLightDisconnect() so that a light
can be removed.
- Jorrit implemented iEngine->RemoveLight(). However since none
of the mesh objects correctly implement StaticLightDisconnect()
the function will not actually work even though it is fully
bugfree :-)
24 lines of code changed in:
- Jorrit added iEngine->RemoveLight() to remove a pseudo-dynamic
static lights and also automatically update all lightmaps. In case
of a static light this will not update the lightmaps unless
ForceRelight() is called later.
NOTE! Currently not implemented yet!
- Jorrit Extended iLightingInfo->InitializeDefault() with a new flag
telling the lighting sub-system if the lighting information should
be cleared or not. This allows correct handling when a single light
is added in case of genmesh and bezier curves.
7 lines of code changed in:
- Jorrit added two versions iEngine->ForceRelight(). The first version
relights all lightmaps in the engine. The second version updates
the lightmaps for a given light (i.e. useful after adding
a static or pseudo-dynamic light).
- Jorrit fixed a problem with the engine would always attempt
to read precalc_info even if reading from the cache was disabled.
- Jorrit added a new 'addstlight' command to Walktest. This command
adds a static light and uses the new ForceRelight() function to
recalculate lighting. alt-l is assigned to this command by default.
- Jorrit fixed thing so that initializing lighting again will actually
cause the lightmaps to be updated correctly.
82 lines of code changed in:
- Jorrit fixed a small bug in the thing plugin in case a polygon mesh
was requested before the thing was prepared and in case the
thing contained a portal.
6 lines of code changed in:
Eric Sunshine performed Phase Three of the elimination of the monolithic
scf.cfg:
-*- Eliminated the SCF information which was hardcoded in the .cpp files
of plugin modules, and which duplicated information in the external
.csplugin files.
-*- Plugin modules no longer maintain and export a monolithic class list.
Now, each factory implemented by the code is exported automatically.
-*- Added a new <implementation> child node to the <class> node in
.csplugin files. The value of this node is the name of the C++ class
which implements the SCF class. For instance, C++ class csVFS
implements crystalspace.kernel.vfs.
-*- Eliminated the following SCF macros which were related to exporting
SCF information from .cpp code and/or registering classes manually:
SCF_EXPORT_CLASS_TABLE
SCF_EXPORT_CLASS
SCF_EXPORT_CLASS_DEP
SCF_EXPORT_CLASS_TABLE_END
SCF_REGISTER_STATIC_CLASS_DEP
-*- Eliminated the following methods from iSCF:
RegisterStaticClass
RegisterClassList
-*- Plugin modules are now initialized/shutdown lazily as classes are
requested from them. The first time a class is requested, the plugin
is initialized. The plugin is shutdown after the last class instance
has been destroyed.
-*- Fixed bug in scf.h where SCF_PRINT_CALL_ADDRESS was not being enabled
for gcc 3.x.
-*- Fixed bug in win32.jam where GenerateExportDefs rule failed to ensure
that directory containing output file existed before creating file.
Also fixed bug where it failed to set up a dependency between the
input and output files.
-*- Still To-Do:
- Remove references to scf.cfg and scfreg from documentation. Also
document new .csplugin resources.
- Add platform-specific function to scan and locate plugins
automatically rather than using the ad-hoc approach inherited from
scanning for .scf files.
- Add platform-specific function to query a plugin's meta-information.
This should be used by SCF to do the raw extraction. Provide and
finalize API for higher-level clients to access meta-information.
- Augment static linking to work with the new facility. (Removal of
the hardcoded SCF information, has now broken static linking. It
worked until this time, even with all of the preceding changes.)
1 lines of code changed in:
Replaced NULL with 0.
169 lines of code changed in:
adds an Unprepare() method
17 lines of code changed in:
Eric Sunshine performed Phase One of the elimination of the monolithic
scf.cfg:
-*- Plugin modules are now self-describing. This information can be
queried at run-time without having to actually load the module.
-*- The plugin maintainer now manages the plugin's meta-information in an
external .csplugin file, rather than hard-coding the information into
the plugin's source code. The mechanism by which the meta-information
is bound to the plugin is platform-dependent. Presently, all
platforms simply lay down the meta-information in a plain text file
alongside the plugin itself; with the same basename and extension
.csplugin. This may change in the future. For example, on MacOS/X,
the meta-information will probably be encapsulated within the plugin's
bundle wrapper.
-*- Plugin meta-information is now maintained in XML format. Here is an
example:
<?xml version="1.0"?>
<!-- gl3d.csplugin -->
<plugin>
<name>gl3d</name>
<scf>
<classes>
<class>
<name>crystalspace.graphics3d.opengl</name>
<description>OpenGL 3D graphics driver</description>
<requires>
<class>crystalspace.font.server.</class>
</requires>
</class>
</classes>
</scf>
</plugin>
-*- Since meta-information is now extensible, maintainers can choose to
publish supplementary information about plugins (in addition to the
SCF information already published). For example, image loading
plugins could publish "image indendification" information which would
allow the image loading multiplexor to selectively request image
loading plugins on-demand, rather than requesting all plugins
unconditionally, even if they are not needed. Here is an example of a
possible meta-information table for the PNG loader:
<?xml version="1.0"?>
<!-- cspngimg.csplugin -->
<plugin>
<name>cspngimg</name>
<scf>...</scf>
<imageloader>
<imagetype>
<class>crystalspace.graphic.image.io.png</class>
<identify>
<mimetype>image/png</mimetype>
<extension>png</extension>
<extension>PNG</extension>
<scan length="4" bytes="\0x89PNG"/>
</identify>
</imagetype>
</imageloader>
</plugin>
In this example, the PNG loader meta-information tells the multiplexor
several different ways to identify a PNG image: by checking file
extension, if available; by checking MIME type, if available; by
checking for the magic-string "\0x89PNG" in the raw image data. If
the multiplexor identifies the image as PNG, only then will it
actually request the PNG loader.
-*- Added the --meta-file directive to msvcgen.pl to allow specification
of the meta-information file for a module. The value of this option
is interpolated into template files via the new %metafile% variable.
msvcgen.mak now utilizes this flag with the value of the new
INC.PROJECT makefile variable. Augmented the MSVC6 and MSVC7 plugin
template files (plugin.tpl) to make use of %metafile%.
-*- Changed the file extension for plugins on MacOS/X from .csplugin to
.csbundle to avoid conflict with new meta-information resource which
uses the extension .csplugin.
-*- Still To-Do:
- Augment SCF to utilize the new meta-information resources, and to
understand the new XML format. Presently, these resources are
ignored at run-time.
- Add platform-specific function to scan and locate plugins
automatically, rather than relying upon a monolithic registry such
as scf.cfg.
- Add platform-specific function to query a plugin's meta-information.
- Eliminate the monolithic scf.cfg.
- Augment static linking to work with the new facility.
- Eliminate the hard-coded SCF registration information in each
plugin's source code.
15 lines of code changed in:
- further worked on storing rendermeshes in the sector. Z sorting
as specified by the renderpriorities works now.
- fixed a bug in the new renderer where not binding of a render
buffer caused visual distortions.
5 lines of code changed in:
Jorrit did various changes related to portal management:
- Moved iPortal definition from imesh/thing/portal.h to
iengine/portal.h. The reason is that portals are now an engine
concept and not only for things. The only portal implementation
is currently still in thing though.
- Added the ability to get the portal vertices from iPortal.
- Added iMeshObject->GetPortalCount() and iMeshObject->GetPortal().
- Also added default implementations of those to csMeshObject
(supporting no portals).
- At two places in the engine (GetNearbyObjects() and PlaceMesh())
this new function is used instead of first querying for
iThingState. This makes those functions a bit faster and is (in
theory) also more general (in the sense of being able to add
portals to any mesh object). However later on most functions
still query for iThingState so this promise of more generality
is not fulfilled yet.
59 lines of code changed in:
(110 more)
Generated by StatCvs v0.2-dev