Generated by StatCvs v0.2-dev
Pages: << Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 Next >>
Summary Period: 2000-11-12 to 2000-10-23 (Commits 3645-3694 of 12744)
Enabled automatic DSP generation for 3ds2lev.
2 lines of code changed in:
sounddriver wasnt decrefed at destruction
2 lines of code changed in:
changed the DirectSound renderer to use the new interface
9 lines of code changed in:
Fixed solaris.mak because it suddenly appears needed to
compile oglempty for OpenGL.
15 lines of code changed in:
Made a small correction to canvas.mak in response to a bug report from
Jorrit regarding glx2d.mak's failure to correctly build files from the
canvas/openglcommon directory following my major makefile changes on
6-Nov-2000. I can not actually test this fix, but I think that it should
correct the problem. It was a vpath issue. The Glide canvases were
probably also broken in the same fashion.
10 lines of code changed in:
Fixes for bit rot in proc textures and preparation for dumping dtsimple
76 lines of code changed in:
restructured the sound modules
19 lines of code changed in:
restructured the sound modules
2 lines of code changed in:
restructured the sound modules
161 lines of code changed in:
restructured the sound modules
451 lines of code changed in:
GLuint->GLenum for glBlendMode.
63 lines of code changed in:
Eric accidently added cspythonswigclean to the 'clean' target
of cspython.mak. This means that the files generated by swig
are cleaned up. However most people cannot regenerate them (lacking
the swig utility) so it is not a good idea to clean them up with
'make clean'.
1 lines of code changed in:
-*- Fixed the SIGSEGV at program exit when OpenGL driver is used due to font
cache callback being called after the font cache object was destroyed in
iG2D::Close().
-*- Fixed halo drawing in OpenGL. It seems like halos in OpenGL never worked
because backface culling was enabled in hardware, and the halo polygon was
defined anti-clockwise (in OpenGL coordinates).
-*- Fixed a very old bug in software halo drawing. The color components
sometimes were incorrectly clamped; this was noticeable when one of the
components was > 1.0 and others were < 1.0 (e.g. 2,0,0). Alas, this slows
down halo drawing a little.
-*- Made halo brightening/fading speed independent of frame rate. Currently
halo fades in steps of 0.05 every 20msecs, this means a complete transition
from intensity 0 to intensity 1 (or vice versa) occupies about 400 msec,
e.g. 4/10 seconds.
-*- Added limited support for 2*SRC halos (e.g. halos with R,G,B > 1.0) in
OpenGL renderer. However I wasn't able to add 100% correct support for it;
software renderer still does it better. However results looks
approximatively similar, although software halos are brighter.
Maybe someone with better knowledge of OpenGL can fix it;
I don't have OpenGL docs handy right now. The basic formula for computing
a pixel with halos in theory (and in software renderer) is:
output_color = src_color * alpha + dst_color * (1 - alpha).
This results in normal glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA).
However, for case when src_color > 1.0 OpenGL will clamp the color to 1.0
thus producing incorrect results. To circumvent this, if renderer detects
that at least one component is greater than 1.0, it divides every color
component by two, and uses the following blending function:
glBlendFunc (GL_SRC_ALPHA, GL_ONE);
This is not mathematically correct, however it gives similar visual results
except that "bright" halos are still darker than those from software
renderer.
-*- Separated most halo-related code into a new file called
libs/csengine/light/halo.cpp.
-*- Finished hint objects in CSWS.
-*- Added hints to most buttons in MazeD. Move the mouse above some button on a
toolbar and wait three seconds to see a short description of this button.
-*- Fixed iSystem::UnloadPlugin() so that plugin is correctly unloaded if it
implements the iConfig interface (plugin's options are removed as well).
-*- Added support for keypad '+', '-', '/', '*' and center keys to all X11
canvas drivers.
-*- Fixed a bug in event cords which caused hotkeys to not work in MazeD (and
keyboard accelerators in general).
-*- Fixed an accuracy problem with line drawing (actually two).
-*- Fixed the problem with $" and $| introduced after Eric's last changes.
The problem was that on some systems with non-Unix-like shells
(e.g. OS/2) " is defined to empty, thus `ifdef "' branch was taken.
Now " and | are defined prior to including config.mak from cs.mak,
exactly same way as it works from root makefile.
674 lines of code changed in:
Fixed a bug to csSprite3D::HitBeamObject(). It was taking the
wrong frame from the sprite to do the collision detection with.
5 lines of code changed in:
Update.
29 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.
252 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.
172 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.
1956 lines of code changed in:
added comments to layout classes
511 lines of code changed in:
-*- Fixed font drawing in OpenGL canvas (this was not my bug, it is a
very old bug - glBindTexture() cannot be invoked between glBegin()
and glEnd() -- it just happened my changes to trigger that bug,
previously it was triggered by fonts occupying more than one texture).
-*- Tried to fix OpenGL halos but failed: I'm not sure, maybe the software
OpenGL I have here does not support alpha textures properly. Will
continue at home with TNT2.
119 lines of code changed in:
Renamed docproc.pl to jobber.pl in anticipation of the Big Bang!
698 lines of code changed in:
-*- Replaced the csInsets object with the standard CSWS rectangle csRect.
-*- Replaced the csVector2 with a new small class csPoint. There is no need
to use csVector2: first it uses floats for x,y and second it pulls
a lot of unneeded code from csgeom.
-*- Made csLayout a fully transparent class (CSS_TRANSPARENT). Now the real
window background is seen through the layouts, e.g. try
"cswstest -skin=Colorful".
-*- Re-indented code to match better CS coding standards.
438 lines of code changed in:
After recent changes, ReadFntFile had disappeared. Put it back, modified to
work with current iFont architecture. Tested. Works.
214 lines of code changed in:
Eliminated several compilation warnings.
4 lines of code changed in:
- Added csSprite3D::GetWorldBoundingBox() to get an inaccurate
bounding box of the sprite in world space.
- Added csSprite::HitBeam() and HitBeamObject() which hit a beam
with a sprite. It will return true if the sprite is hit and it
will also return the intersection point. HitBeamObject() works
in object space while HitBeam() works in world space.
- Added csSector::HitBeam() which is similar to the already existing
HitBeam but this version returns the first object that is hit.
So it also looks at sprites. The original HitBeam() only looks
at things and sectors. For particle systems and 2D sprites this
function will currently always return false. This is something
to be implemented. Note that this function will first test the
bounding box of the sprite for an easy reject. So that's fast. But
if this test succeeds then it will test every triangle of the
current frame. This is not very fast but it is accurate. In
the future this function might change to do this with a lower
LOD version of the sprite instead.
- Extended csIntersect3::BoxSegment() with an optional 'r' parameter
so that you can get a number between 0 and 1 indicating where
in the segment the intersection happened. Also fixed this function
so that it will return a correct value for 'isect' if the start
of the segment is in the box. This return was undefined before.
- Added csIntersect3::IntersectTriangle() to intersect a segment
with a triangle.
307 lines of code changed in:
Update.
4 lines of code changed in:
Signature of main() now matches csMain() so program now links
correctly with Visual C++.
2 lines of code changed in:
Failed to request SYSDEF_ALLOCA.
1 lines of code changed in:
Update.
8 lines of code changed in:
Now compiles with VC5.
3 lines of code changed in:
Fixed compilation problem: const vs. non-const.
2 lines of code changed in:
removed Font variable
0 lines of code changed in:
Two fixes to csws. Andrew: you forgot SYSDEF_ALLOCA and
also default parameters cannot be repeated in the cpp file.
4 lines of code changed in:
A few fixes
3 lines of code changed in:
Update. Some fixes to app makefiles after Andrew's changes.
121 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.
4841 lines of code changed in:
Changed iCollideSystem::Collide to accept 'const' transform
pointers.
5 lines of code changed in:
Made the following changes to efed.pl:
-*- Fixed bug: Was ignoring files mentioned on the command-line and only
processing directories.
-*- Addressed shortcoming: Was not applying --rename patterns to directory
names.
-*- Added filename suffix convenience to --rename. Now automatically
translates 'old=new' or 'old:new' to the expression 's/\.old$/\.new/'
to change the filename's suffix from '.old' to '.new'.
-*- Added --quiet option.
-*- Worked around differences between Perl versions in
File::Basename::fileparse(). Some versions return the directory
portion of a path as '.', whereas others return './' for a path
containing only a filename.
129 lines of code changed in:
Added GetSector(idx) to the swig interface file (cs.i) so that
Python scripts can use it.
45 lines of code changed in:
made layouts selectable
1 lines of code changed in:
- added suggestsize for inputline and listbox
- some fixes for the gridbaglayout (resizing and componenets that never showed up)
47 lines of code changed in:
- added suggestsize to inputline and listbox
- in gridbaglayout fixed the disappearing of elements in some cases
- also on resizing the original size of the componenet is now used and not the one after last resize
8 lines of code changed in:
turned off console printing
2 lines of code changed in:
Update.
25 lines of code changed in:
Made the csArchive::Write() method a lot faster in the case you did not
specified the max file size when you opened the file for writing by the
following means:
- The buffer size is increased in 1K blocks rather than adding just the
size of appended block. This means the memory will be allocated just
once per many calls (in the case you're writing in small chunks) rather
than doing one memory allocation per call (which is VERY slow).
- Using realloc() instead of new[] and memcpy() which also should increase
the speed a lot on platforms with properly implemented realloc().
Now writing files into archives in small chunks (e.g. PVS) should work
a lot faster (same speed as csMemFile).
21 lines of code changed in:
Eliminated compiler warning in:
void csFlowLayout::SuggestSize (int &sugw, int& sugh)
Initialized at decleration previously un-initialized variable i.
1 lines of code changed in:
CR/LF -> LF
1864 lines of code changed in:
added example for layoutmanager
87 lines of code changed in:
various layout managers for csws, see cswstest for an example
1442 lines of code changed in:
various layout managers for csws
581 lines of code changed in:
Pages: << Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 Next >>
Generated by StatCvs v0.2-dev