WorldFoundry To Do list

KevinSeghetti -- What I want to do for the upcoming release

I am working toward a release, both a designer/artist release and an end user release (binary so that someone can preview WF without having to build it) for both windows and linux.

The biggest chunk of work left to do is in the I3D exporters:

• The geometry exporter is about half done, needs textures and animation

(these were mostly waiting on I3D's implementation of these things to get more mature, if they are still not good enough it might be time to contribute some more time to I3D).

• The level exporter needs path support (again was waiting on I3D)

Then the release itself

• for windows, resurect the installshield code (or pick something more modern)
• for linux, learn a bit about package managment and make rpms as well as tarballs.
  • Also don't forget the Debian users: "deb" packages should be provided as well. Debian is well-known for its superior package management; superior because package dependencies are minimal and well-thought-out; a team of people makes sure that packages are only accepted into the distribution if, among other criteria, their dependencies are correct and up-to-date. World Foundry could become an official Debian package (official Debian packages require someone a maintainer; if the maintainer disappears, the package becomes orphaned and migrates out of the distribution.) --MrLin

• for linux, figure out an easy way to make builds for various distributions (maybe just punt and statically link the libraries).

---

General

In the Engine

• • • Matte (scrolling tiled background) renderer. Was implemented in the Playstation version, need to add both Windows and Linux versions
    • Sound (platform independent!)
    • Investigate using The Nebula Device as a renderer (Crystal Space would also be an option but the prevailing opinion seems to be that Nebula's design is better and that using Nebula is less complicated). See InterfacingNebulaDeviceAndWorldFoundry
    • Improve look of renderer (modern eye candy like volumetric fogging, voxels, better lighting, particle systems for special effects, etc.) - e.g. by using Nebula
      • • KevinSeghetti -- WF has 2 particle systems already in it: one which generates real game objects (via the generator object), and one which just generates geometry (for expolsions and the like). The geometry generator was one of the last things added, so it might need some testing and tweeking, but it is in there.
    • Add rotation to physics/collision system; see AnalysisOfCurrentPhysicsSystem, PlanToUpdatePhysicsSystem
    • Figure out how to prevent boxes from being shoved through walls - see PlanToUpdatePhysicsSystem
    • Look at other collision resolution systems and compare to what we have now - see PlanToUpdatePhysicsSystem, AnalysisOfCurrentPhysicsSystem, TechnicalDetailsOfCollisionDetection
    • Break out the lower libraries (pigsys, hal, cpplib, math, memory, etc.) into a seperate base project which could be used outside of WorldFoundry (this would also solve the problem were wftools and wfsource are inter-dependent, would make a new dependency: wfbase <- wftools <- wfsource)
    • Continue to move funtionalty out of the game directory into more generic libraries.
    • Work on better integration of the TCL scripting language into the engine.
    • Make it possible to have more than one scripting language used in the same game (since WillNorris is partial to perl instead of TCL).
    • Implement a floating point version of the math library
    • Command-line switch to show collision boxes in wireframe on top of geometry in debug build
    • Try to get fogging working using GL blending instead of GL fogging (because ATI Mach64 chipset can do blending or fogging but not both at the same time) Toolchain
    • Make textile able to load more graphics types (use an existing graphics loader).

Other

• • • Make some test levels which demonstrate the engine's abilities
    • Continue to work on the programmer documentation
    • Continue to work on the user (designer & artist) documentation
      • Make work flow diagrams for designers & artists (showing all steps required to create and convert a level)
    • Make a release (both source and precompiled binaries)
    • Work on the web site

Windows specific

Build

• • • Investigate building WF and toolset (including attribedit, which uses GTK) with totally free-software tools - cygwin, gnu make, gcc. Should theoretically work without too much trouble. Main hurdle will probably be OpenGL, but I know cygnus gcc can be made to work with OpenGL on Windows.
    • * KevinSeghetti - We actually tried to use GNU Make under DOS years ago, but it totaly chokes on the '\' (backslash) character (thinks it is an escape character) and on the ':' (colon) charater (thinks it is a rule target - sources separator). Therefore DOS/windows paths like "C:\source" don't really work. In most places '/' works as well as '\' (but not everywhere), so we were able to get around the '\' issue with some work, but ':' was a show stopper, we had to re-compile gnu make with a hack that interally re-mapped another character (I think we used '@') to ':' in filename, which wouldn't be a good solution here. Of course maybe GNU make has been improved since then (this was circa 1995). Another issue is the windows command shell is practically unusable, we used 4DOS (also sold as Norton DOS) which is a pretty nice replacement, but also not free. I suppose cygwin solves this, but only for developers familiar with unix.

Engine

• • • Implement keyboard driver (currently requires joystick) (Actually keyboard does seem to work, but a joystick must also be plugged in).
    • Make run in window (currently only runs in full screen mode)
    • Debug superhero level in release mode (doesn't run, just quits)
    • Debug access violation when quiting game in release mode

Linux specific

Engine

• • • Implement Joystick interface (currently only works with keyboard)
    • Investigate full screen mode
    • Write a software textured rasterizer (so can run without OpenGL (since Mesa is quite slow on non-accelerated hardare)
      • See TinyGL, an OpenGL-compatible (!) fast software rasterizer! http://fabrice.bellard.free.fr/TinyGL/ Though fast, it does rely heavily on floating point math.

Toolchain

• • • Add path exporting from Innovation3D
    • Add texture map export to Innovation3D geometry exporter
    • Add deformation animation export to Innovation3D geometry exporter
    • Write an Innovation3D plugin which can select objects based on WorldFoundry attributes
    • Figure out how to do multi-paste (paste WorldFoundry attribute data into multiple objects)
    • The level exporter and the Attribute Editor need support for shortcut/soft-link/alias/derived objects (can we think of even more names for an object which just points to another?

Other

• • • Need to use autoconf/configure script

---

Bugs

• RENDERER & RENDERER_PIPELINE set to directx no longer builds (obviously Windows only)
• RENDEREER=gl, RENDERER_PIPELINE=software, superhero level doesn't appear (at least on the windows version, need to test the Linux version)
• Superhero can fall outside of the walls in test level
• * seems to be level bug (gaps in walls), not engine bug
• Eliminate need for -rate switch
• * MrLin - Strangely it seems to work lately for me without -rate in release mode
• * But, from an old mail:
• ** kts said: PS: I have to set -rate100 to get it to go slow enough to be controlable. If I leave the -rate command off it fails entering the superhero level, I am probably failing to reset the time (so it calculates how long it has been since the last frame of the cubemenu, which is about a second, and physics just goes nuts)
• ** nlin said: If I leave the -rate command off, it fails immediately on the cubemenu for me. Probably the same symptom.
• ** kts said: If the frame rate is too low physics tends to thrown things out of rooms, which makes everything unhappy (I think I need to add a special case for level initialization so that the level load time doesn't count as a frame).
• * The "special case" is what needs to be done - or has it already been done? Search for "tap dancing" in c files, this code section appears relevant, maybe it is already done.
• * KevinSeghetti -- I believe I have fixed this, the problem was I completely mis-understood the time reading calls in Linux when I first did the port. Assuming your framerate is above 10Hz or so (and under some maximum top limit where we reach the resoution of our fixed point system) everything should work fine (other than other physics bugs :-).
• lvldump -l doesn't work on linux with new .iff or .iff.txt files in oad/ directory, instead looking for older-style .oad files, so OAD data cannot be analyzed with lvldump
• Physics problem pushing boxes against boxes against wall: see PlanToUpdatePhysicsSystem, look for part describing "chain of execution issues"
• Physics problem with interpenetration. Interpenetration occurs. Debug version asserts. Release version runs mostly but sometimes segfaults or goes into infinite loop. Avoid penetration and/or recover gracefully from it. See PlanToUpdatePhysicsSystem.
• Level build system: should recreate animatedmesh.iff files from animatedmesh.ali files (see AnimationHandlingInWorldFoundryEngine), rather than reusing the existing animatedmesh.iff files.
• Camera sometimes gets stuck in wall in superhero level - probably a collision problem
• attribedit barfs on FILE token. Try this test: for each object in superhero.lev, extract its IFF block, strip the non-attribute parts (NAME, VEC3 for position, EULR for orientation, PATH), save the rest, and attempt to edit it in attribedit.
• *KevinSeghetti -- FILE is the old chunk name, it should be STR, try changing it and see if that works (I have a note somewhere to change that in the .lev exporter in Max).

---

Redesign issues

• OAD data is separate from object NAME, position, orientation, and path. Merge this into OAD data. Then each object has only OAD data attached to it. (Currently an object has name, position, orientation, path, and OAD data, but the first four could be subsumed into OAD data.)
• * KevinSeghetti -- The reason these are separate is becaue they are typically things edited in/provided by the 3D editor. (this data IS all merged in the .lev file at the same level in the heirarchy as the OAD data).