Module CS/plugins/video/canvas/

back to main page

Summary Period: 1999-05-06 to 2003-06-14

Modules

[root]/CS/plugins/video/canvas
     asciiart (6 files, 573 lines)
     common (8 files, 1990 lines)
     ddraw (5 files, 1139 lines)
     ddraw8 (6 files, 1105 lines)
     directxcommon (4 files, 730 lines)
     macosx (1 files, 6 lines)
         cocoa (16 files, 1735 lines)
         common (9 files, 1406 lines)
         coregraphics (7 files, 533 lines)
         opengl (7 files, 633 lines)
     memory (5 files, 366 lines)
     null2d (5 files, 287 lines)
     openglcommon (11 files, 19167 lines)
     openglwin (6 files, 1200 lines)
     openglx (6 files, 650 lines)
         glide (5 files, 205 lines)
     sdl (5 files, 822 lines)
         img (12 files, 0 lines)
         util (3 files, 3608 lines)
     softx (5 files, 1212 lines)
     svgalib (5 files, 620 lines)
     xextf86vm (5 files, 548 lines)
     xextshm (5 files, 366 lines)
     xwindow (5 files, 1023 lines)

Lines Of Code


Total Lines Of Code: 38 (2003-07-11 20:29)

Authors

Author Changes Lines of code Lines per change
Totals 21 (100.0%) 86 (100.0%) 4.0
sunshine 7 (33.3%) 34 (39.5%) 4.8
matzebraun 1 (4.8%) 19 (22.1%) 19.0
andy 2 (9.5%) 17 (19.8%) 8.5
norman 4 (19.0%) 7 (8.1%) 1.7
res2002 2 (9.5%) 2 (2.3%) 1.0
jorrit 2 (9.5%) 2 (2.3%) 1.0
bdavis 1 (4.8%) 2 (2.3%) 2.0
andyz 1 (4.8%) 2 (2.3%) 2.0
samuel 1 (4.8%) 1 (1.2%) 1.0

Most Recent Commits

res2002 2003-06-14 20:38

Changed the way how SCF plugin scanning works:
- Moved scanning invokation to scfInitialize().
- A platform-dependent function, csScanPluginsDir(), returns
plugin filenames and metadata.
- Such a function is provided for Win32. For unix and macosx,
the "old" function that scans for .csplugin files is used.
Made the following changes:
- The DirectDraw configure time test now also tests for
DirectSound, and thus changed the makefile var nomenclature to
"DirectX".
- Slight changed the way DLLs are loaded on Win32: now
LoadLibraryEx() is used with a flag which causes Windows to
first look for the actual file in the specified directory.
- On Win32, plugin metadata is now contained inside the DLL.
Worked around problems with static linking. Specifically, it was
assumed that a factory function is always only used for a single
class. This is not always the case (e.g. the bezier loader.)

1 lines of code changed in:

jorrit 2003-05-19 13:08

Jorrit removed the infinite and line 3D renderers. They were pretty
obsolete. Also removed the associated linex canvas.

0 lines of code changed in:

sunshine 2003-04-27 11:33

Eric Sunshine made the following changes:

-*- Modified configure.ac so that it emits a SRCDIR property to
config.mak. This value represents the --srcdir argument given to the
configure script (or "." if --srcdir is omitted). This points at the
directory containing the CS source code (which may differ from the
build directory, which is typically the current working directory).

-*- Modified makefiles and build scripts throughout the project so that
they respect $(SRCDIR). This allows the project to be built in a
directory other than the source directory, thus it is possible to
place the source directory on a readonly filesystem (such as a
CD-ROM), or to share a single NFS-mounted source directory among
different builds, where each build inhabits its own directory. For
example, if CS resides at /home/CS and you wish to build the project
in /home/build:

% cd /home/build
% ../CS/configure
% make -k all
% make install

(Note that the Jam-base build system already supports this build
paradigm.)

-*- Modified configure.ac so that it emits EXTENSIVE_MEMDEBUG to
config.mak since this variable is used by Makefile.in for the
`showconfig' target.

-*- Modified configure.ac so that it emits MONITOR_MAKEFILE_CACHE when the
value is either "yes" or "no", instead of emitting it only when the
value is "yes". This was necessary because CS/mk/cache.mak prints the
value of this variable as part of $(SYSMODIFIER).

1 lines of code changed in:

res2002 2003-04-15 11:12

- added a check for DirectDraw to the configure process.
- added missing Jamfile for directxcommon.

1 lines of code changed in:

matzebraun 2003-04-08 20:21

added the Jamfiles

19 lines of code changed in:

jorrit 2002-10-16 12:27

- csProcTexture is now able to use the new SetRenderTarget() system.
And it seems to work fine. Converted all current proc textures
that inherit from csProcTexture to the new system.
- Added 'persistent' flag to SetRenderTarget(). If that flag is given
then the original texture will be copied in BeginDraw() so that
the previous contents is preserved. If that flag is not given
then the previous contents is ignored and it is assumed you fully
update the texture yourselves.
- simplept works nicer than ever with the new SetRenderTarget() system.
- Completely removed the old procedural texture implementation from
both the software and OpenGL renderers.
- Here is a summary on the status of the new procedural texture system.
- Software renderer procedural textures are TOTALLY broken. This
needs to be redone again.
- Simplept works VERY well in OpenGL (very fast and very nice
looking).
- The pixel drawing procedural textures (flame, plasma, dots,
water, ...) are slower in OpenGL then they were before.
The reason is that drawing a pixel in OpenGL is a LOT
slower than in software renderer. To solve this problem
I will add new API functions to either draw series of
pixels or else to blit memory areas to the screen (or
texture).
- For some reason I cannot render at vertical line 0.
i.e. a g2d->DrawPixel (i,0,color) will do nothing. That
means that one line of the procedural texture will remain
whatever contents the screen has at that moment.
I have no clue on how to solve this yet.

2 lines of code changed in:

sunshine 2001-07-05 11:04

Eric Sunshine removed a bunch of Glide references from documentation,
sources, headers, and makefiles.

0 lines of code changed in:

sunshine 2000-11-10 02:55

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.

1 lines of code changed in:

sunshine 2000-11-06 22:44

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.

13 lines of code changed in:

samuel 2000-06-13 12:07

Changed names from dynamic textures to the more correct term procedural
textures.
- The iGraphics3D method CreateOffScreenRenderer is now gone. All drivers are
updated.
- The software drivers procedural textures are now more memory efficient.
- By default the software procedural textures use the main renderers texture
manager, which makes it more consistent with the glide and back buffer
opengl implementations. Within this mode the engine can render to the
texture.
- The CS_TEXTURE_DYNAMIC_SHARE_HINT is now gone. In its place is a new hint
CS_TEXTURE_PROC_ALONE. When this flag is selected the software procedural
textures run internally at 8bit, they share and utilise their own 8bit
texture manager. (Before each procedural texture had its own texture
manager and cache..this is no longer the case :). The engine cannot render
to the texture in this mode.
- The iTextureHandle->TextureDynamicSyncPalette is now gone. This is no
longer needed, and makes the interface more consistent across
implementations. In its place is ProcTextureSync (), which currently is
an empty method, but is in preparation for fine grained control of
mip-mapping. The software texture manager now keeps a single linked list
of all 8bit canvases it services.
- Rewritten the opengl software procedural texture implementation. So that it
can be rendered to by the engine.
- Added a force32bitsoftware additional flag to opengl.cfg, which performs
better with mesa and 16bit displays with a voodoo2. However, the problem
with the transposition of red and blue returns, this is probably a bug
in Mesa3.3beta.
- This is how it now works: csOpenGLProcSoftware now wraps an instance of
csSoftProcTexture3D. This instance is created via a new interface
iSoftProcTexture. csSoftProcTexture3D creates its own texture manager and
canvas. Subsequent software procedural textures share this texture
manager. Each procedural texture registers itself with the software
texture manager, and passes its handle back to the csOpenglProcSoftware
class which stores it in a vector along with its opengl texture handle.
The app writer registers and prepares all textures with the opengl
texture manager, and then starts rendering. Each texture handle not
already present within the vector is registered and prepared with the
software texture manager and its handle stored with its opengl counterpart
in a vector. Each iGraphics3D call which utilises a texture is intercepted
and the opengl texture handle swapped for its software counterpart. On
Print (csRect) the opengl texture is updated with the new procedural
texture state, and also its software counterpart.
- This change has required modifying the software drivers so that the
texture handle is not referred to within the iPolygonTexture structure.
- The CS_TEXTURE_PROC_ALONE_HINT has the effect of disabling the updating of
the software texture managers versions of the procedural textures, which
improves performance but disallows the engine from rendering to any
procedural textures. For this mode to operate all textures need to possess
this flag otherwise it'll revert to the slower mode.
- Fixed the colours on the opengl back buffer implementation. Voodoo2 owners now
need Mesa beta3.3 from cvs for this to work. Unfortunately glCopySubTexImage2D
is now broken in cvs so I cant implement this optimisation. The texture
probably still renders inverted, it does on the voodoo2. I dont think there
is an opengl trick to reinvert the texture, but I could be wrong. Possible
solutions are to intercept every draw call and invert these or to copy over
from the framebuffer to the texture line by line. The latter way is going to
be *slow*, the former would involve modifying transformation matrices (i.e.
rotating by 180 degrees the world to camera matrix about the lookat vector)
within the driver and inverting all vertices which are in screen co-ordinates.
I wait for a better suggestion :).
- Lastly Ive destroyed the performance of the opengl procedural textures, oops,
need to investigate this :( Used to get about 70fps with the astext texture
alone, this is now down to 10ish with software textures. This might be
Mesa3.3beta.
- dtsimple is updated to demonstrate how to do things with the cleaner, more
consistent interface.
- Added new constructor for csImageMemory
- Fixed typo in memdbg.sh

1 lines of code changed in:

sunshine 2000-05-10 09:33

Added dynamic-texture support to NeXT. Removed unused junk from dyntex2d.

2 lines of code changed in:

norman 2000-05-09 03:10

here comes the new font rendering

0 lines of code changed in:

sunshine 2000-05-07 15:21

Another batch of patches to account for the move of drivers from CS/libs
to CS/plugins.

17 lines of code changed in:

norman 2000-05-06 22:24

changed all (hopefully) refrences to the old directories cs2d and cs3d

5 lines of code changed in:

norman 2000-04-27 22:17

unified unix glide 2d driver. now bot can be build at same time. see linux.mak file

1 lines of code changed in:

norman 2000-02-26 03:15

removed some global glide dependencies and changed unxglide makefile so no glide include path is added to the global CFLAGS variable

1 lines of code changed in:

andyz 2000-02-23 16:05

Rewritten texture manager and texture cache. Vastly improved software renderer.
Lots of changes, too many to list them here. Will post a detailed message on
the mailing list.

2 lines of code changed in:

andy 1999-11-10 16:59

Small changes

1 lines of code changed in:

andy 1999-11-05 15:21

The Big SCF patch. Completely replaced COM with SCF. Most drivers broken.
The only that works are: csdive, glos2, dosraw, soft3d. Some others *may* work.

16 lines of code changed in:

bdavis 1999-05-06 19:18

Initial revision

2 lines of code changed in:


Generated by StatCvs v0.2-dev