You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

139 lines
4.6 KiB

+============+
| TO BE DONE |
+============+
A tasks and bugs are now being tracked by sourceforge. Please
goto: http://sourceforge.net/projects/plib/
* Have a look into known_bugs and fix them.
* Lines in ASCII files are terminated...
With '\n' under UNIX/Linux
With '\r' under MacOS
With BOTH under Windoze.
Hence, UNIX/Linux does no conversions of either '\r' or '\n'.
and MAC swaps '\r' and '\n' on input.
and Windoze dumps '\r' if it follows a '\n'.
This is a mess - so I'm changing all the ASCII I/O code
to allow either or both '\n' or '\r' and I'm reading the
ASCII files in BINARY mode.
* Array deletion requires '[]' after 'delete' on Mac.
* Some of the MSVC-project files for plib_examples seem to be
broken, for example some miss a "winmm.lib".
* Check whether the new ssgStripify works with TuxKart
See Steves post from 11.12.2000 15:12 for a problem description
The abbreviation NIV14 means not in Version 1.4.
Bugs:
=====
- When creating fgfsTux, sometimes .ac, .dxf,
.ase and .obj saved zero objects, although
there were objects. For example, PLIB
created this .ac file:
----------- snip ------------
AC3Db
OBJECT world
kids 0
OBJECT group
kids 0
----------- snip ------------
This seems to happen after ssgFlatten.
- WK: Create a sphere in ppe. Save it as .ASE. See that values like
diffuse colour are cr*p. Try to load it. It crashes. This could be
one or - probably - two bugs. I don't think this is a ppe problem.
The loader complains that number of faces is -2.
The problem seems to be the writer.
*new remark*: About the diffuse values: I think it has to do with
colour material, a loader (.ASE?) loading colours into a colour
list and writing colours from the ssgSimpleState where they are
undefined. I think the same bug is in .AC
- WK: I have a crash in ssgFlatten if I load .ac files with
unused materials (not reproducable?)
- Loading and saving lines in .OBJ doesn't work. Maybe NIV14.
- Sam wrote:
Has anyone here debugged with plib under Windoze 2000 and MSVC++?
I get a whole bunch of
"Free Heap block modifed after it was free"
warnings with the ssgFlatten and ssgStripify.
I'll try and hunt this one down.
...
I think it may be because I'm using MFC which (if I remember
correctly) enables a bunch more memory checks. Also I'm doing
#ifdef _WIN32
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
#endif
- Not all loaders use ssgLoaderOptions::begin. Don't all have to?
- Search for todo, fix, fixme, kludge.
Misc:
=====
- Look whether scaling works. [see current discussion]
If not and if we can't/don't want to make it work, for example
because of performance issues we need a warning in the docs and
IMHO PLIB should "write out" a warning if an unallowed matrix is
sent to it.
Update: Scaling does not work (intentionally). Uniform scaling may be
enabled by uncommenting "radius *= sgLengthVec3(m[0])" in
sgSphere::orthoXform. It is currently disabled because that extra
calculation would degrade performance on non-scaled matrices.
- Reduce lint warnings. Lint is an error checking tool that gives warnings
where things *could be* wrong as opposed to the compiler that tells
you where they are wrong.
- It would be great if we had one or even two working native .ssg
file formats. Currently (16.12.2001) the format work most of the time, but not all
entities are implemented.
- We should write the GetWrapU/GetWrapV function, since
loading /writing .ssg files can't work 100% without it.
- When saving, there is often a warning that "ref count doesn't
tally with parent count"
- Go through the mailing list for unfinished business.
- Someone, preferably a native english speaker with ssg-knowledge,
should go through the new ssg-doc and fix any mistakes. It should be
fairly complete by now.
- Add Per's new Formats to the doc?
- For the other parts of plib, people should bring the doc up to
date.
- There is a bug in the 3Dfx driver for Linux (tdfx_dri-4.0.1-1) that
causes the "complex" example program to crash in "fxSetupBlend".
This is fixed in more recent DRI snapshots (requires kernel 2.4.x).
Probably after 1.4.0:
=====================
- In fgfsTux, not a large object, you get a DList overflow
with the standard values for its size. Can we make its
size dynamic?
- Look at handling of normals. For example, loaders,
stripify etc should only recalculate missing normals.
Have *one* function that recalculates normals.
It would be nice if people would volunteer for tasks.