Sv: Sv: Strangest thing happened; it seems I'm perfectly normal. That doctor must be a fraud! I want my money back!

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>>why not just make it part of the spec how this data *must* be stored?
>
>It's a matter of robustness - simply assuming the data PFile reads is
>correct is bad. PFile has to either detect corrupt data or limit the damage
>caused by it.
>
Do a parity check (that's counting the number of 1's and making sure it
matches what it should be, right?). I think it may be a bad idea to
compromise effeciency to give people the ability to make badly-implemented
pak writers. You could also add the possibility to write to the pak file
"this is sorted" or "this is not sorted".

>>This strikes me as a bit strange way to do things. If its going to be
sorted
>>anyway at some point, why not just sort them at write-time instead of
>>read-time? You just need to be ble to specify all the files that go in a
pak
>>format 1 when writing it at once for this to be effecient. You would still
>
>Yup, right. But as soon as you add files the sorting is destroyed (it would
>be of course possible to re-sort everything once a file is added, but
>that's rather slow).
>
When did adding one entry to a tree begin to require a complete resort?

>>Well, actually I haven't got anything to do right now, except for that
>>benchmark thing. I'd be happy to implement it. I've already figured out
how
>>to add and remove files while keeping the tree complete at all times (ok,
so
>>I probably could've found that info on the net, but didn't have anything
to
>>do...).
>
>Do you have some code for this or can you describe in detail how
>you're implementing a complete tree? I'm interested because you are right
>in that point:
>
Well... As it turned out, when I implemented it, the way I had figured out
to add or remove entries DID put the entry you added in the right place, and
DID remove the entry you wanted to get rid of, all the while keeping the
tree complete at all times. However, the two techniques also displace other
parts of the tree when the tree grows beyound a 7-8 entries.

And actually, I've found it impossible to find any content on this anywhere
on the web. The best thing I could find was a dictionary that would tell me
what "complete" "full" and "binary search tree" meant. Yeah. What a big
help... :)

However, I AM going to figure it out. I should have a correctly implemented
tree ready by tomorrow. Perhaps I'll even get around to add hashing and
benchmark it with a sample directory.

Strictly speaking, I actually do know how to do it, but that method is
EXTREMELY ineffecient - complete resort of the tree.

>>Usually, as you correctly have observed, data is stored in sub-directories
>>of the main game dir, sometimes data is stored 2-3-4 levels from the main
>>game dir. In other words, the directory data is going to get accessed ALOT
>>of times. Keeping directory data for itself therefore gives a performance
>
>If the game does hundreds of accesses to files in the same subdir in a row,
>each time with full path, then it deserves to get bad performance.
>A simple
>ppfChdir ("the/sub/dir/");
>ppfOpen ("thousands.of.files");
>makes all your performance fears here obsolete :)

>
Hmm... I thought ppfChdir just set a string that would be appended to all
paths passed in... I can see now how that would be quite stupid...