3d
(4 files, 136 lines)
iso
(23 files, 4825 lines)Summary Period: 2000-08-06 to 2003-04-08
[root]/CS/plugins/engine
3d
(4 files, 136 lines)
iso
(23 files, 4825 lines)
Total Lines Of Code:
4 (2003-07-11 20:29)
| Author | Changes | Lines of code | Lines per change |
|---|---|---|---|
| Totals | 31 (100.0%) | 171 (100.0%) | 5.5 |
| jorrit | 6 (19.4%) | 62 (36.3%) | 10.3 |
| sunshine | 14 (45.2%) | 56 (32.7%) | 4.0 |
| andyz | 4 (12.9%) | 42 (24.6%) | 10.5 |
| matzebraun | 1 (3.2%) | 4 (2.3%) | 4.0 |
| wouter | 2 (6.5%) | 2 (1.2%) | 1.0 |
| norman | 1 (3.2%) | 2 (1.2%) | 2.0 |
| mgeisse | 2 (6.5%) | 2 (1.2%) | 1.0 |
| philwyett | 1 (3.2%) | 1 (0.6%) | 1.0 |
added the Jamfiles
4 lines of code changed in:
Moved the contents of plugins/engine to plugins/engine/3d.
Moved plugins/iso to plugins/engine/iso.
0 lines of code changed in:
Moved all csObject stuff from csObject library to csUtil library.
This means that the csObject library is now gone.
1 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Updated out-of-date Mingw comment in enginep.mak.
-*- Fixed the makefiles for map2cs, mdl2spr, scfreg, scftutor, and gfxtest
so that these applications successfully link on NextStep in `debug'
mode.
-*- Fixed the makefile `clean' target so that it only strips the trailing
slash (/) from the $(OUTBASE) and $(OUTDLL) variables rather than
removing all slashes.
1 lines of code changed in:
Reverted Philip's change. Applied a more correct solution to the MSVC
build problem.
3 lines of code changed in:
Made "CSENGINE" a dependency of engine plugin.
Now compiles again under VC.
1 lines of code changed in:
Added a CSGFX dependency to enginep.mak so that the engine plugin can load
on NextStep. This probably shouldn't be required, but some file somewhere
in the engine is probably unnecessarily including csimage.h. The real
solution is to find this unnecessarily inclusion and eliminate it.
1 lines of code changed in:
Eric Sunshine provided a slightly more generalized solution in enginep.mak
to the problem of `dllwrap' failing to export engine_GetClassTable() when
Mingw is used. Also added a verbose explanation of the problem to
enginep.mak. Ultimately, however, someone who uses Mingw needs to figure
out how to force dllwrap to correctly emit symbols exported from
csengine.lib. Perhaps this person can contact people on the Mingw mailing
list. Finding a more correct solution to this problem is important, as
the current hack is really unacceptable in the long run.
12 lines of code changed in:
Added a (temporary?) bugfix to the mingw engineplugin compilation problem.
The engine was not being included. This fix, includes $(OUT)engine$(O) in
the linkage for all platforms. (this file is also present in libcsengine.a)
2 lines of code changed in:
removed some (hopefully) unneeded dependencies on csgfx
1 lines of code changed in:
split up the csgfxldr library into two parts. The first part contains the image
classes and now exists as the csgfx library. The second part contains the
image file loaders and now exists as a plugin.
1 lines of code changed in:
Removed all remaining `csterr' library references from the project.
1 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:
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:
-*- Renamed the following classes and SCF interfaces. Fixed all source
files, header files, and documentation to reflect these changes.
iWorld --> iEngine
csWorld --> csEngine
csWorldConfig --> csEngineConfig
csWorldState --> csEngineState
csWorldStateVector --> csEngineStateVector
-*- Renamed the following files. Fixed all source files, header files,
and documentation to reflect these changes.
iworld.h --> iengine.h
world.h --> engine.h
world.cpp --> engine.cpp
worldfmt.txi --> mapfmt.txi
-*- Eliminated the old iEngine SCF interface and the iengine.h header
file. This interface was just a very thin wrapper around the existing
iWorld (now iEngine) functionality. However, since the engine library
already contains sufficient SCF goop to pass as a plug-in module, the
old thin iEngine wrapper was not actually needed. The new iEngine is
now the one and only interface for accessing the engine regardless of
whether or not it is in a plug-in module or statically linked. There
is no longer any distinction.
-*- Renamed all `world' variables to 'engine' throughout the project and
documentation. Renamed all variations of `world' (such as `World',
etc.), as well. Also renamed `world file' references to `map file'
references. Code and documentation which specifically refers to
`world space' or `world coordinates' has not changed. In this case,
the `world' terminology is appropriate and has been retained.
-*- Added a bunch of missing `const' qualifiers to Dumper class.
-*- Renamed Dungeon plug-in's SCF name from
crystalspace.worldrnd.dungeon.std to crystalspace.dungeon.random.
-*- csProgressPulse now uses iSystem::Printf() rather than CsPrintf(),
thus it is no longer tied to the engine. Also added Doxygen comments.
-*- Enhanced the check for new C++ casting syntax in comptest.sh to be
more thorough. It now checks for all casting variations. This was
necessary, since someone at NeXT botched the OpenStep Objective-C++
compiler so that it fails to understand reinterpret_cast even though
it understands static_cast, const_cast, and dynamic_cast.
-*- Eliminated compilation warning in csbaglay.cpp regarding one variable
shadowing another.
-*- NeXT csosdefs.h now defines __NEED_GENERIC_ISDIR for SYSDEF_DIR so
that the generic isdir() gets defined. This is now required by CSWS.
-*- Added missing `const' qualifier to SetName() and GetName() methods of
csFrame and csSpriteAction.
-*- Eliminated several compilation warnings from the sound loader plug-in.
-*- Eliminated compilation warning about redefinition of RED_PREPROC macro
in haloscan.inc. This warning only showed up on platforms which have
TOP8BITS_R8G8B8_USED defined.
-*- Eliminated several compilation warnings in g2dtest regarding implicit
conversion of float to int.
-*- Added missing `const' qualifiers to several methods in mz3DSprite.
-*- Fixed quite a lot of multiple-include protection macros in
include/csengine so that they are now prefixed by `CS' (for instance
__CS_STATS_H__ rather than STATS_H). This should help to avoid naming
collisions with non-CS packages.
-*- Eliminated compilation warning in ptlab.cpp.
14 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.
21 lines of code changed in:
-*- Fixed a bug in default window theme that caused background texture to
not be drawn if the window is not semi-transparent.
-*- Fixed (I hope this is the last fix) clipping so that in very complex
window configurations CheckDirtyTD and CheckDirtyBU are called as
much times as required (until nothing changes).
-*- Added gradient backgrounds! In general background for all skins is now
one csBackground object which accepts one of the following modes:
textured, gradient, flat-color, none (default flat color from CSWS).
Gradients can be horizontal (two rgb values), vertical (two rgb values)
and four-corner (four rgb values).
-*- Fixed DrawPolygonFX in software renderer which works incorrectly for
more than three-vertex polygons (it did not take into account neither
z,u,v,r,g,b values for the fourth, fifth, ... vertices of the polygon).
It is a bit more costly now (one division per scanline) but that's
the price we have to pay for correct drawing...
-*- Modified cswstest to be able to change skins at runtime. You can either
set the [CSWS] Skin.Variant = ... option in main config file, or use the
"-skin=..." command line option. The skin variants themself are defined
in csws.zip file; for example use -skin=Colorful for a demonstration of
gradient background textures; -skin=Marble for a marble-texture-background
skin variant.
-*- Fixed back the awful behaviour introduced by someone: when a drop-down
submenu is visible, and the parent menu hides, the submenu stays visible.
-*- Re-formatted and commented (doc++ style) the csGrid class.
-*- Re-implemented font server interface from scratch. Added the iFont
interface. Any font is an iFont object now. You pass the iFont object
to iGraphics2D for drawing characters. The font server is not anymore
a class private to the canvas driver; it is a public plugin like most
others. You can avoid using a font server at all, if you aren't going
to type text through iGraphics2D::Write().
This implies some need for rewriting code outside CVS that deals with
fonts. The basic rules are:
(*) Instead of using csFontCourier, csFontTiny etc you should `load'
the font first. You can do it this way:
iFontServer *fs = G2D->GetFontServer ();
iFont *courier = fs->LoadFont (CSFONT_COURIER);
iFont *police = fs->LoadFont (CSFONT_LARGE);
iFont *italic = fs->LoadFont (CSFONT_ITALIC);
iFont *tiny = fs->LoadFont (CSFONT_SMALL);
Note the new names for the fonts (you can find them in ifontsrv.h).
(*) Then you use the iFont object to query text width, height etc:
int fw, fh;
font->GetDimensions ("Hello world", fw, fh);
font->GetMaxSize (fw, fh);
...
(*) The only method in G2D that accepts an iFont object is Write():
G2D->Write (font, x, y, fg, bg, "Hello world!");
All other font-related methods (e.g. SetFontID, GetFontID, GetTextWidth
and so on) are gone (mostly moved to iFont).
-*- Changes in CSWS due to above font server change:
(*) TextWidth() and TextHeight() are gone. Instead there is a new method
called int GetTextSize(char *, int *) which returns the width of given
text and possibly height (if second argument is not NULL).
(*) Added a new csComponent method - int GetTextChars(char *,int) which
will return how much characters if written with current font will
fit in given width.
-*- Added "floating hints" capability to CSWS. These hints can be attached to
absolutely any csComponent's; if the mouse stays unmoved over such an
component for more than three seconds (adjustable) a new csHint object
is created. As soon as you touch mouse or keyboard (or joystick :-) the
hint will vanish. These hints helped to find a lot of errors in clipping
algorithm related to clipping of foreign "clip childs"; this was not
tested very good because of limited use of "clip childs". csHint objects
are direct childs of the objects the hint is attached to, but they are
"clip childs" of the csApp to avoid being clipped by parent object.
Not complete yet (the size for hints is arbitrary right now :-)
-*- Added some debug capabilities to SCF. You can add #define SCF_DEBUG at the
top of certain SCF module and you will see (via printf()) all the IncRef's,
DecRef's, class initializations and so on. On GCC > 2.8.0 it also types
the address the methods were called from, use GDB's "l *address" command
to find out what file/line/function corresponds to given address.
-*- Added to VFS the ability to translate VFS paths into real filesystem paths.
This works only for non-archive files. This is means as a last-resort for
libraries that can't handle VFS directly (e.g. freetype can load fonts only
from real-world files). If the VFS path refers to multiple paths, all of
them will be searched for the existence of given path or filename. If
the file is non-existent, the first one will be returned.
-*- Ooops. Fixed a "bug", or rather an unimplemented yet feature. For some
reason I was under impression that VFS understands expressions like:
$(VAR:text), e.g. "get the value of VAR, if it is not defined, use the
"text". It did not, now it does. It even should understand very
complex things like: $(VAR1:VAR2:VAR3:sometext$(VAR4:plaintext)othertext)
-*- Removed the last traces of the old memory debugger from makefiles and
support/debug/memory,(h|cpp)
-*- Added correct window resize support to GLX canvas. Re-implemented font
support in GLX driver; now it will work even if you load fonts at runtime
(old "glfontserver" code was able to display only fonts that are available
at program startup, e.g. built-in fonts from font server). Now there is
a "font cache" object which loads and frees fonts on demand.
-*- Added runtime full-screen switching via Alt+Enter for the following X11
drivers: x2d, linex2d, glx.
-*- Fixed "double-backbuffer" support in OpenGL canvases. All OpenGL canvases
do NOT support double backbuffer mode. Note that "double backbuffer" is
NOT the same as "double buffer", these are completely different things.
All CS canvases should support double-buffering for smooth animation,
while they may or may not support double-backbuffer mode, mainly for
performance reasons.
1 lines of code changed in:
Reverted back my previous change to vfs.mak; instead I have fixed
win32gcc.mak. DO.SHARED.PLUGIN should contain a reference to $(LIBS),
however win32gcc's DO.SHARED.PLUGIN did not.
8 lines of code changed in:
Fixed engine plugin so that it is again enginep.so. This is needed
to get simplep to work.
2 lines of code changed in:
(6 more)
Generated by StatCvs v0.2-dev