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. Always check on the developers mailing list first.

• General todo: fix all bugs in bugs.txt :-)
• Continue with more support for sprite lighting. This is almost finished but there are still a few missing things (like the ability to see which dynamic lights affected a sprite).
• Optimizing lighting. Using the convex outline of objects we can still do some opts.
• Maybe implement shadows for sprites and things using a simpler outline version? (for sprites we can use LOD).
• We also need to update the lighting on the polygons of a thing when the thing moves. It is easy to find all dynamic lights that hit a thing at the current location but then you also have to find all dynamic lights that hit a thing at the new location. One way to optimize this is to keep a list of all lights that affect a sector. See docs/notes.txt for a more detailed explanation of this.
• Like explained in the previous paragraph we should maintain a list of static and dynamic lights in every sector. This not only contains all the lights of that sector but also lights of nearby sectors which are visible from the sector.
• Make MazeD the best Crystal Space editor in the world :-)
• Better LOD function for sprites. The current one doesn't preserve the shape well enough.
• Generalize the engine so that it can use general gouraud shaded polygons instead of only triangles. The 3D rasterizers can already do this.
• Implement halo visilibity checking in the engine instead of using the Z buffer.
• For correct portal on thing handling we need to Z fill the portal polygon after drawing (and use Z sort or STATBSP for the portals).
• Continue with support for multi-sector sprites. We need a way to quickly update the list of sectors that every sprite is in. Also we need to clip the sprite (rough clip) to the portal.
• Consider support for multi-sector things as well.
• Convert the few remaining classes to csXxxx name convention.
• Create more user documentation. Update FAQ. More tutorials.
• Rewrite bots and missile using the real collision detection system.
• Optimize the collision detection system.
• Fully implement or approximate 2*SRC*DST in hardware (with gamma or something else).
• Integrate landscape engine (ROAM) with CS. Also integrate dynamic sky support which is also in the ROAM engine from Alex Pfaffe.
• Physics module? Is this still needed? What do we need here?
• Scripting: Make COM interfaces (IDL) for the engine.
• Scripting: Ad hoc scripting language?
• Scripting: interface with existing language (Python, Scheme, ...)
• Option to make dynamic library (DLL/so) for all CS libraries.
• VFS (virtual file system) to make things easier for the game developer.
• Curved surfaces on sector walls.
• Curved surfaces in sprites. There are two ways: we could merge them statically and just use the curves as a triangle generator or we could have real LOD curves. I think the first approach is best because sprites have LOD on their own.
• More types of curves. Nurbs are one example. Wavelets are another. But also simple curves should be considered because they will be more efficient and also very useful. One good example is simple circle shaped curves. Those are great for archways.
• Dynamic curve lighting. This requires some thought because lightmapping a curve is expensive. More precalculation may help here.
• REMPES visibility system or at least a subset.
• Improve the current c-buffer system. For example, add the ability to insert dynamic objects (i.e. sprites) into the c-buffer and use them for testing as well.
• Implement a 'make install' in the makefile system.
• Try to use the NASM assembler code in the Windows/VC port as well.
• Better world loader with support for plug-ins (to allow apps to insert game specific data in a world file).
• Import entities from MDL, 3DS, ...
• Implement vertex fog for Direct3D and Glide. Further improve vertex fog support in OpenGL and maybe support limited version of vertex fog for software (testing purposes).
• Resolve TXTMODE mess (private, global, and 24bit). Some mode/display combinations are obsolete or not well supported.
• Special effects (bumpmapping, explosions, particles, smoke, ...)
• 2D sprites (flat sprites).
• Particle system. Maybe using pixels or 2D sprites.
• Fix BMP loading so that it is endian correct.
• Fix WAV loading so that it is endian correct.
• More configuration parameters for objects (like lightmap size for detail of shadows).
• Allow flags and config values for objects to be set from within the world file.
• Gravity configuration value for WalkTest.
• Do mipmapping based on texel density instead of fixed distances.
• Automatic portal generation (used in MazeD or Crystal Space itself).
• Fix cleanup problems in engine.
• Better error handling and checking for invalid data in the engine. Maybe make a level validator.
• Hierarchical objects.
• LOD on things. Maybe user specified.
• Artificial Intelligence?
• Spotlight support.
• Ability to load textures later after the world has already loaded. It's almost there but not yet :-)
• Correct textures for special hardware (like square limitation on RIVA 128 and 256x256 limitation on Voodoo).
• Two adjacent polygons may not have correctly connected lightmaps. In other words: there may be a dark border when there should not be any. This probably needs to be solved by a second pass through all the lightmaps.
• Calculate lightmaps in a higher resolution and then down-sample them for better quality.
• Full radiosity on lightmaps.
• Need to continue cleanup of code (we are constantly busy with this :-)
• Continue cleaning up the language, the API, and the interface to create the world.
• We need to improve the quality of the 8-bit palette generator.
• 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), ...
• 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 :-)
• Portals can now affect the light color that passes through it. it would be nice if this could also be done based on individual texel values on the portal polygon. That way a light shining through an alpha-mapped portal would shine on the wall with the colors of the texture on the portal.
• 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.
• Support for 24-bit display-mode (32-bit is already supported).
• Delay real transformation of sprites until they are visible (with a dirty bit or something).
• Consider rewriting parts of the texture cache in assembler. They still take a lot of time.
• Transform the planes of polygons only once if they are shared.
• Make a special optimized algorithm for the texture cache private memory pool.
• 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.
• 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.
• Joystick/mouse support.
• Make a map in 3D a bit like in Descent.