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-06-18 to 2000-06-13 (Commits 2745-2794 of 12744)
Eric Sunshine made the following changes to the Crystal Space
documentation:
-*- Repaired all of the errors and warnings reported by 'makeinfo'
after recent changes to the Texinfo source documents.
-*- Repaired all of the TeX formatting problems which cropped up
with recent changes to the documentation source files. Mostly
these problems involved overfull and underfull hboxes.
-*- Overhauled portals.txi. Performed a much more thorough Texino
conversion on it. Replaced the ASCII-art with real images.
This looks much nicer in the printed and HTML output.
-*- Cleaned up the win32.txi build documentation following some
recent changes to it. Fixed several mark-up problems and also
re-wrapped source file to 80-column width. Added a slew of
missing cross references.
-*- Performed a more thorough Texinfo conversion on memdgb.txi and
also renamed it to memdebug.txi. Fixed several Texinfo mark-up
problems as well.
-*- Created a new section (portable.txi) which discusses portability
issues when writing code and creating resources for Crytal
Space. Most of the content of this section actually comes from
the older coding.txi file which now contains only Coding Style
guidelines instead of a mixture of both. Also expanded the
portability guidelines and added a lot of missing discussion.
Corrected some mis-information which was recently added to these
discussions.
-*- Overhauled lighting.txi. Cleaned up much of the Texinfo mark-up
and also rewrote sections of the document. Replaced the
ASCII-art with real images.
-*- Removed the mipmap.txi and texcache.txi files which Martin
recently converted since they were excessively out of date,
meaningless, and confusing to the reader (since they didn't
reflect reality).
-*- Added missing Texinfo mark-up to viscull.txi.
-*- Syncrhonized the contributor lists on the Crystal Space web page
and the one in the Crystal Space manual (intro/contrib.txi).
This involved adding contributors to each document which
appeared in only one or the other document, and in some cases
neither.
551 lines of code changed in:
- Fundamental change in how the particle systems work.
A particle system now also inherits from csSprite and
is controlled like other sprites. So for the engine as
such a particle system behaves just like any other sprite.
In addition a particle system will now control its own
children. So sprites inside a particle system will not be
added to the entire world anymore but will be local to
the particle system. This will make optimizations (i.e.
DrawTriangleMesh) and visibility for the entire particle
system easier to manage. A particle system of 1000
particles would cause 1000 visibility checks in the engine.
Now the entire particle system can be handled with one check.
- csSprite now expects a new 'parent' csObject which can currently
be either csWorld or csParticleSystem. This is an important
change which will require changes in potentially all applications
using CS. csSpriteTemplate::NewSprite() also has the new
parent parameter.
229 lines of code changed in:
added new sample to show csGrid dialog
91 lines of code changed in:
new grid and slider class + new WindowToClient method. csWindow now ask its associated client window for its minimum size, so client has a chance for optimal appearance
789 lines of code changed in:
new grid and slider ( splitter handle ) class and a WindowToClient method for csWindow
328 lines of code changed in:
Changed color of rain particles.
1 lines of code changed in:
improved rain, now mixmode ADD, and a setcolor 0.25,0.25,0.25 to darken the texture a bit. Looks good.
2 lines of code changed in:
Fixed another bug with 'rain' command in sectors that have
no polygons.
47 lines of code changed in:
Fixed a pretty severe memory leak in the c-buffer. This leak
could trigger in any use of the c-buffer but it was most
obvious when doing lighting or radiosity.
3 lines of code changed in:
removed cleanup() call from win32 system driver
0 lines of code changed in:
Fixed error.
2 lines of code changed in:
Now has nice, pretty, and should compiler nicely member functions.
I hope the port maintainers will like it too...
13 lines of code changed in:
Now has a functional TestRectangle function, which is rediculously fast.
(at least in design :-) ). It compares bytes, not bits.
Also propagate_down and sift_up functions.
21 lines of code changed in:
Improved the 'rain' console command in WalkTest so that it
adds rain to the entire current sector. There are now three
parameters: 'rain raindrop.png,100,2'. 100 is the number of
particles. Use more particles for bigger sectors. 2 is the
speed in meters per second.
43 lines of code changed in:
added shift so rain will look nicer.
5 lines of code changed in:
fixed buggy.
3 lines of code changed in:
Update.
5 lines of code changed in:
Added 'rain' console command to create a new rain particle
system. Experimental right now. Doesn't work perfectly yet.
49 lines of code changed in:
Added raindrop.png to library file too now.
0 lines of code changed in:
typo.
1 lines of code changed in:
rain starts at ceiling now.
1 lines of code changed in:
improved now rain will fall down (the y axis...)
2 lines of code changed in:
Added raindrop.png.
0 lines of code changed in:
Untested, but csRainParticleSystem has been added.
106 lines of code changed in:
Cleaned up debug_dump() and cleanup() junk from all apps.
WalkTest now does this on its own with code inside
#ifdef OS_UNIX. This isn't pretty but it is debugging stuff
anyway and at least it doesn't contaminate other apps that
don't need this.
67 lines of code changed in:
- Cleaned up some debugging stuff for c-buffer from WalkTest.
- Moved csOjbectStuffFactory::Initialize to csObjectStub.
- Moved csPolyTreeObject::RemoveData to csObjectStub.
- Added new classes csSphereStub, csSphereStubFactory, and
csSphereTreeObject. These will be used for adding bounding
spheres to a polygon tree. The implementation of these classes
is not finished though.
140 lines of code changed in:
Moved glViewport() from OpenGL 3D renderer to the 2D canvas
drivers for OpenGL. The reason for this is that some specific
canvas (used for embedding for example) may want another
viewport.
22 lines of code changed in:
converted more docs to texinfo
64 lines of code changed in:
Removed some warnings
1 lines of code changed in:
Made compileable on MSVC
2 lines of code changed in:
- Changed csFrustum constructor to accept a 'const' parameter.
- Did the same fix to csCBuffer::TestPolygon() as was done with
csCBuffer::InsertPolygon() a few days ago.
- Fixed a small bug in CheckFrustum which could cause different
results in different runs. i.e. it made the result of CheckFrustum
a bit unpredictable in some cases.
- FINALLY fixed a very severe bug in the c-buffer which really
triggered only in VERY rare cases indeed. This bug caused errors
in lighting, PVS, rendering (in some cases), radiosity, ... (you
name it :-)
144 lines of code changed in:
Fixed after Travis' changes.
1 lines of code changed in:
Added a new CS_ZBUF_FILLONLY mode for DrawPolygon() to be able to draw
non-textured polygons with Z-Fill mode. The hardware guys still need to
implement it.
27 lines of code changed in:
Got the first patch from Travis McIntosh
<Travis.McIntosh@student.oc.edu>. He changed the dynamic lighting
system to work on lightmaps instead of polygons. This is the
first step towards getting dynamic lights working with curves
too.
57 lines of code changed in:
Fixed DrawFogPolygon() so that it can be used to draw z-fill polygons
(non-textured) with CS_FOG_BACK and without opening a fog object.
36 lines of code changed in:
Remove the cases that resulted in the use of the GL_UNSIGNED_SHORT_5_6_5. This is undefined on win32 GL.
-frank(frank@oconnors.org)
9 lines of code changed in:
fixed a bunch of redefinition errors caused by defaults in both the header and implementation.
-frank(frank@oconnors.org)
2 lines of code changed in:
Automated Texinfo @node and @menu repair.
1 lines of code changed in:
Updated
-frank(frank@oconnors.org)
203 lines of code changed in:
Update.
92 lines of code changed in:
Fixed body dimensions to 1.8m height, 0.8m legs and so on.
Added a large comment about the meaning of body parameters in .cfg file.
42 lines of code changed in:
typo corrected
1 lines of code changed in:
Speed increase, it will now get stuck in long refractive sequences for a
shorter time only.
4 lines of code changed in:
oops, missed an include
0 lines of code changed in:
-*- Fixed my fix regarding Eric's fix regarding halos yet again :)
2*SRC lighting did not work for halos.
-*- Fixed csFrustum::Classify(). Now it seems to work okay.
-*- Removed delaying of draw operations in CSWS. From now on graphics pipeline
always draws at the time the draw routine is called. This both reduces
memory usage by CSWS programs (by ~500K) and removes the limit on the
number of graphics primitives that can be painted in one frame (this
was seen as uncomplete redraws when loading complex 3D models in MazeD).
Also it should be a little faster now.
-*- Fixed an old-standing bug that caused wrong window resizes when switching
MazeD screen resolution.
391 lines of code changed in:
added recent changes
75 lines of code changed in:
remove them again
0 lines of code changed in:
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
84 lines of code changed in:
- 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
59 lines of code changed in:
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
35 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