Rudy Velthuis wrote:
> 
> But then you'd have to have a "compiler" (to parse the files and turn them
> into binary or whatever) and a "linker" (to connect the parsed files into
> one scene). This is of course a totally different approach from the current
> one.
Yes, it would be far different. Perhaps better, perhaps worse.
The main thing I have a problem with the current model, is that there is
no syntax checking performed before a parse is done. This irritates me a
bit, since I have a bad habit of foretting a ; or doing a pigment{WHite}
style approach when I type.

Tehn, all of sudden, POV parses, all is ok, allocates lots of memory for
my five recursive cakks that make 50000 objects each, and hangs on the
plane afterwards, with a wrong pigment and then I have to wait for my
windows to stop swaping as hell so I can get back to work..

Solution to this? Add more RAM:-)
But, a pre-check of syntax might improve, this could also choose a
parser after the version or something.. (please don't flame me because I
haven't read the source and don't have any idea of what I am talking
about, please don't. )

> But it would be great. The .par files would be something like the
> precompiled headers many C/C++ compilers provide for, or the symbol files
> many compilers can produce to speed up compiling.
Yes. It would probably increase the file-size a bit, but it is a
trade-off to do...
 
> But as the POV-team already mentioned somewhere, most time is not wasted in
> parsing, but in allocating objects during this process. If this is true (I
> can't verify it), the pre-compile wouldn't do a lot of good.
It depends on the scene, as far as I know. in some cases, I've spent a
lot of time waiting for a parse to finish. (take a look at the recursive
tree creation algorithms. Those are very long parsing, but not long if
declared as a .inc. (try the WinTrees if you like:-) it is from this
experience that I came with the idea.

//Spider

Post a reply to this message