This file describes the bugs and missing features that are still in
Crystal Space. The ultimate goal is to make this file empty :-)
Note that some of the wanted features in this list are currently
being worked on by some people. Check the Who Is
Doing What list first.
Bugs
- The u/v overflow tests in the draw_scanline routines should
be either removed or minimized.
- There is still a known bug when the viewer is positioned very close
to a portal polygon. When this happens the portal polygon may be
clipped to the Z-plane, thus causing only half of the screen to be
drawn. One solution would be to make a special case of Z-plane
clipping for portal polygons and to make sure that this situation
never happens.
- Shadows are not always very accurate at the boundaries of
different polygons. This is because the lightmap grids
of the bordering polygons are not always aligned. I need to
force the alignment so that shadows are always nicely shaded.
- Need to do a major cleanup of code (we are constantly busy with this :-)
- Clean up the language and the interface to create the world.
- Unlighted textures are sometimes displaced.
- The precalculating lightmapper has some bugs. It often says parts of
a polygon are not lighted while they should be lighted.
Desired New Features and Enhancements
Lighting:
- Consider the possibility to make lighting somewhat more dynamic
if it is known in advance when and how a sprite is going to move?
- Perform fast uniform lighting on sprite polygons. This is useful for
sprites that will move a lot.
Note! Use the texture cache for this feature. Will this be fast
enough?
- Dynamic lighting: spherical lighting. Use the precomputed plane
normals of all polygons to quickly calculate the squared distance
from the light to the polygon. Use this to calculate a circular
area on the polygon where the light will shine. Add a new special
polygon with a pointer to some fixed spherical texture and use
that for lighting (or do this in Polygon::draw_textured_2d after
the normal texture mapping has occured!).
- Implement 'shadow polygons' which are simply polygons that cast
a shadow over what they have been drawn. These shadow polygons
can be used to accompany moving things so that the appearance
of dynamic lighting is preserved.
- To solve the problem that we need to recompute the light tables
file whenever we go to a new system we should store the final
256 RGB values of the colormap as well. Then we can make a
translation table at startup to translate the indices into the
256-table that are used in lights.tables to new indices that
are system dependent. This will allow us to better include a
lights.tables file with a ZIP file and so make the light tables
file system independent.
- A non-accurate dynamic lighting has been implemented in late
beta 0.07 releases. It is not accurate because it assumes that
a projection of a 3D sphere to the viewplane will be a circle
which is not correct but it is a good approximization.
Some things still need to be done (for example, moving very close
to a dynamic light will make it dissapear :-)
- Radiosity.
Scripting And Triggers
- Enhance script language. The current script language is too
limited to do anything useful. The scripting language we are
now working on will be based on ReAct from Chronicles.
(As a consequence of the current primitive scripting language,
the opening door script only works correctly
the first time. It doesn't know how to close the door again.)
- Extend the LanguageLayer so that it can be a useful layer for
the support of the scripting languages.
- Better and more support for triggers. This is closely related
to the script language.
Engine And Mathematical Features
- Physics (gravity, friction, ...) (a preliminary system is
now available). An alternative approach will be to implement
this through the LanguageLayer.
- More texture features like bumpmapping, displacement mapping, ...
The problem is to do all those things fast enough.
- We have to look into the possibility of using particle systems
for fogs, clouds, explosions, ...
A possible optimization here would be to use many small 2D
animated sprites (possibly with a bit of alpha transparency) and
use these as particles. This way one could probably get away with
using less particles and reduce the computational overhead a bit.
- Make alpha mapping configurable. We currently have two tables.
Instead we could define a fixed number of tables (let's say three)
which can be used in a configurable way. For example, table 1 can
be used for 25% alpha mapping (and thus also 75% if the table is
used in reverse) while table 2 can be used for additive filtering.
- We should also implement animated textures. There is a problem
with lighting though. There are (at least) three options:
- Remove the texture from the texture cache and reapply the
lightmaps every time another animation frame of the texture is
choosen. This is time-expensive but it is an option if the
texture does not change that often (for example, a switch
that can be turned on/off) or is not very large.
- Just do no lighting (or only uniform lighting) on those
polygons. This is of course easy to do and it is an option
for those surfaces that don't really need lighting (like
lava surfaces).
- Let the texture cache perform lighting on a seperate
light-texture. This extra light-texture is then overlayed
at runtime with the animated texture. This option is
very good for rapidly animating textures but it slows
down the renderer a bit when the textures is currently
not being animated.
All three methods are useful and can be used on other occasions,
so maybe I should try to implement them all :-)
- Maybe we should select the mipmapping level more dynamically.
Currently the next mipmap level is selected based on distance.
But this would better be done based on the amount of texel-
squishing inside one pixel. For example, if four texels fit in
one pixel then one should consider going to the next mipmap
level.
- The different mipmap levels of every texture should probably
be computed starting from the original texture instead of the
next one in the chain. This will increase the quality.
Special Portal Features
- Portals can affect the color/intensity of light that passes
through the portal. This would not be difficult to implement and
I already have the needed fields in the Portal class.
- The code currently assumes (mostly in Graphics3D::DrawPolygon) that
whenever you go through a portal that warps space, the warping always
changes the order of the vertices from clockwise to anti-clockwise
(or the other way around). This is not always true. We need to include
a test for this some way.
- Create a polygonal terrain renderer that can be fully integrated
with the portal engine through the portals. Transition from one
sub-engine to another will be completely transparent to the
player. To make support for things and sprites in the polygonal
renderer easy it should also fill the Z buffer like the portal
engine does.
- To allow going back from the landscape renderer to the portal
engine we should allow portals on things.
- In principle the code takes care of the case when a light
shines through a warping portal. This also seems to work correctly
when the warping portal jumps to a different sector. However, if
you want to use a mirror and jump back to the same sector the
lighting is not calculated correctly. Therefore these kinds of
calculations are disabled. To enable them again just change the
test 's->beam_busy < 1' in Sector::shine to 's->beam_busy < 2'
or some higher value.
- Allow 'animated' space-warping portals. Using these one could
for example create a train where the inside of the train is
rendered as usual while the windows are portals to a large sector
or even the polygonal terrain renderer. Every portal (window)
would have a space warping matrix so that the moving of the train
(or other vehicule) can be simulated by changing that
transformation. This would be a really cool effect.
Renderer
- Support for 24-bit textures by the texture cache. This would
be useful even for 8-bit and 16-bit display modes. Currently there
is already support for private colormap textures (where every texture
has its own 256-color texture). There will not be a great quality
enhancement by going to true 24-bit textures but the texture cache
will get faster (one less lookup needed to get the R,G,B value
of a color).
- Complete the 16-bit alpha mapper (currently only 50% is supported).
- Complete 16-bit support and private colormap support.
Sprites And 3D Objects
- Allow transparent textures for Things. We can make use of
the transparent polygon queue that we are going to need
anyway to implement the previous feature.
- Implement 'occlusion objects' that can be used to eliminate
overdraw with large Things. Together with a large Thing one
could define a set of vertices which are transformed/moved
together with the Thing. The outer boundaries (as seen in 2D)
of these vertices form a 2D polygon that can be used for fast
clipping of the sector polygons.
- We now have 3D triangle mesh sprites. We still need to add
some kind of lighting though. A triangle should be uniformly
lit according to the environment lighting. The problem is how
to determine the environment lighting fast enough.
- The new 3D sprites should also be able to cast quick shadows.
Maybe only at the floor polygon just below the sprite?
- 3D model editor or convertor for those 3D sprites.
- Delay real transformation of sprites until they are visible (with a
dirty bit or something).
- 3D sprites should be decoupled from sectors. This is needed so
that they are rendered correctly through portals (this is not
the case currently) and can also move through a portal.
World File And Other External Files
- Config file.
Allow the choice between a fixed palette or a computed
palette. Control how the palette should be computed (adherence
to the colors in the bitmaps), ...
- Create an editor/convertor for Crystal Space world files.
Textures, Games, ...
- We will need libraries of 3D models that can be used for
various things. I'm thinking about torches, candles, space-ship
consoles, switches, ... Anything really.
- Crystal Space is currently still in an early stage but it would
be nice to have other projects starting to use Crystal Space.
I'm thinking about 3D games, MUDS, RPG's, ...
Optimizations
- Transform the planes of polygons only once if they are shared.
- Rewrite texture mapping loops in assembler (partly done).
- Rewrite texture cache filler in assembler.
- Rewrite memset in assembler?
- Make a special optimized algorithm for the texture cache private
memory pool.
- General optimization: try to get Crystal Space as fast as
possible.
- Optimization with cross product as suggested by Segher Boessenkool:
(a1 b2 - a2 b1) becomes (a1 - b1) (a2 + b2) - (a1 a2) + (b1 b2).
(a1 a2) and (b1 b2) can be precomputed. This mainly affects
which_side_2d and maybe some other optimizations.
- There is no need for backface culling inside the current Sector
(where the ::draw starts) provided that the sector doesn't use a BSP.
- We could consider doing backface culling in world space (before
transforming to camera space). So we don't need to transform a
polygon if it is not needed. But we have to consider that the
vertices of a whole sector are transformed first. In that case we
would need to postpone this transformation of vertices and maybe
use an array to indicate which vertices have already been
transformed.
- There is much room for improvement in Sector::shine and
Sector::follow_beam.
Ports
- Complete DOS ports to other compilers (Microsoft C++,
Borland C++, ...).
- NeXT, Commodore 64, HP calculators, Eniac :-) ...
Various Features
- More hardware accelerator support (OpenGL, Glide, ...)?
- Make all lightmaps a power of 2 by default. This is to make life
easier for the hardware accelerated versions.
- Allow multiple textures on a polygon (overlaying textures) which
are automatically merged by the Texture Cacher.
- Use a different lightmap size for a polygon. This is useful for
very large polygons for which shadow accuracy is not of utmost
importance and also for very small polygons where you would like
to have more accurate shadows. Default lightmap size is 16.
Currently this does not need to be a power of 2 but I would
not use anything else because future optimizations could depend on this.
- Enhance the typing speed/accuracy of the input console.
- Sound support.
- Joystick/mouse support.
- Networking support.
- Make a map in 3D a bit like in Descent.
This page hosted by 
Get your own Free Home Page