[Lindsayts]

Now, I was'nt going to put this up, but just in case it may help.............

File formats availible to the user should if at all possible be directly editable. Having to convert items with an an external program that needs to be controled by the user can be under some circumstances be a ___real___ pain. It also puts another step in a process that is alread6y a real challenge.

If the program is running slow _____________VERIFY______________ the file format is the issue __BEFORE__ doing any major changes. DO NOT DO ANY MAJOR WORK UNDER AN ASSUMPTION of whats wrong.

If the file format is shown to be a major issue consider doing a once only "on the fly" conversion using either an external program or an internal function. An example here is how MSTS handles the tiles.

For files the are accessed continously, Shape files for instance, consider using a simple in program cache to remove a lot of file requests from the file system. The most shape files in single route on my system is in the 9000 range, such a cache size would not be to difficult to accomadate on mst of systems these days.

While doing all this consider if they may be a better way one can tackle the problem than the current way. From my experience some algorithyms simple __CANNOT__ be spead up, this latter is a path a lot of open source programers seem very loath to take, in the end though it may be the only way.
I once spead up a bit blit function (bit block transferr function, it was used a lot in much older animated games, these days the GPU's do it) by a factor of 20, the exicutable code size for the function went from around 5 kilobytes to over 120k AND I made it more flexible in use.


Lindsay

[disc]

Any news, or ideas on new formats? :furious: It would be nice if we would able to replace the old lowpoly "msts" style models with better ones, and better textures, perhaps some extra materials would be useful too (normal mapped, lightmapped, environment mapped, controllable specularity, glass material, and the combinations of these).