From: Filip V. <f.v...@ce...> - 2007-02-25 19:27:55
|
Hello everybody! I've spent some time sketching the File class with some implementations (file from std::iostream, memory mapped file), and the data handling classes (DVariant is pretty complete, without the Vector3 type, which I'll add soon). I didn't do any deep tests of the File class and it's ancestors, but a small testing didn't reveal any errors. A missing piece to complete this file handling is to write a FileGroup class, which would handle .GAM/.MIS/whatever files in a nice way. I'm thinking about a few possible ways of implementing the class so that a small modifications to some chunks would not require the whole file to be read to memory (per request loading), and would allow a copy of the (un)modified tag-file to be saved to some other file without too much overhead. This would be useful for small utilities and specialized tag-file handling. There is some base code for structured data formats present, but it needs to be thinked about more, mainly because the fact that there are so many different approaches for data handling in the original engine. The DTypeDef should handle everything (once complete, there is no data format definition besides type for now), with a few exceptions: * Unioned structs (don't know yet how to do those, and if even those will be needed) - and overlapping fields in general * binary arrays (for example light maps from WORLDREP, those should result in char* buffer, but WRRGB should result in uint16_t or something, with automatic byte swapping. The code working with this kind of data should handle these specialties probably on it's own. All the code is to be found in: * proto/file * proto/dyntype in the CVS. There is a sketch of DEnum (dynamic enumeration), quite similar to the one found in the structreader. Bitfield will be implemented using this. Please note that these are not meant to be used yet. I've written them (and will continue probably), as a proof-of-concept of how to handle properties and links/link data. I still have some unanswered questions to be answered, mainly the transparency of the Property setting doing some things without noticing. What I mean is this: In the script, I set a Position property of a certain object. I do this by calling PropertyService's method (or something like this). The SceneNode of the object should be updated (in opde). If I understand it right, in original engine, there were Property listeners possible, and the Properties themselves were implemented customized (Each property having it's setter and getter(?) methods etc.). A possible way of implementing this is to create a interface which would contain getters and setters for stored variants, and implementing it differently for the special properties. The data serialization/deserialization should be quite easy with the proof-of-concept code, once finished (An iterator over fields itself would be sufficient to create the loader/saver). I'll try to study the existing materials (mainly the Telliamed's Public Scripts), to gain more knowledge of how this all works. I tried using Spy script, but the problem with it (logically) is that it only does reveal messages, not the script's reactions to them (E.g. what interfaces they use, which methods do they call, etc.). It would be interesting to write a program that could simulate the Dark Engines script usage. It could be inevitable to do so. This would allow us to see what a certain script is doing in a specific situation. This would be, of course, quite complex task, as great part of the DarkEngine's interfaces would have to be written. The gain would be that we would have a very accurate map of the script's function calls and reactions to specific situations. It could be even possible to use this harvested data to create a test environment for the rewritten scripts, thus ensuring that the new scripts work the same as the original (As I mentioned earier, script rewrite is probably inevitable, because of the complications that are present even on 64bit linux, not talking about other processor architectures). I'm realizing how complex the insides of the original engine are. I'll try to update the wiki if I'll find out something that needs to be stored permanently. Sorry for the long mail. Please write me if you have any comments or suggestions on this mess I've written. ;) Volca |