 I really cleaned up the code of CI today. The transform DLL and its accompanying lowlevel LIB are building well. I removed many old C style functions into classes and such, to remove global variables and such. I had been pretty sloppy trying to get it up to this level (and it is not near finished). I had actually got a few memory handling stacks working and optimised, and they were the ones needed for this DLL >> other wise I am including the Mem handling stuff in another file. The OCTREE traversal is working quite nicely, I have built some fake OC-trees with it and it traverses and returns points fine. My key system for my DLL plugs is working well, and I am just getting my pseudo command line stuff ready for initing them. I noticed my good friend Jaap had been talking about the pluggable DLL system he is going to use. I too have been planning to use one for a long time... I am avoiding COM though. I do have a special system, that uses the .H file specially though, to register all the functions totally dynamically. The things I also have designed for script like input will also be relatively simple. I will have a console, for calling scripts, DLLs and such. I will have two scripting languages. One will be more like a macro system, except with a little control, based on user input and the ability to call internal gotos. The other is much more interesting, and can be called from the console, the macro system and DLLs (which includes levels). This secondary scripting environment, notably is not a hi-level language... It is more assembler like, with opcodes and multistacking. It has variable address space (defined at compilation time), stack spaces, and multiple useful things. One odd thing about this asm style system is how I do alterations, calls and date from engine internals; I use a stack based method. The coder can set an internal variable, by pushing to the internal request stack, and then using a opcode, to tell the internals to return such a variable. Functions can occur in a similar way. Data and function returns are recieved from the internal data stack for that specific assembler object. If any request opcode fails, for any reason, I can set an error flag. Many of these objects can be initialised at once on a system, using dynamic memory object allocation. So in this system can be used in a sort of "Threaded" way to do many world + character objects. The best thing about this system is that many game objects can be treated as registers. So, by including a link to compiled byte code (A compiler for this is very easy to write) a level, or character model can operate in a very specific way. Anyway, I am still doing a reasonable amount of work, as time allows, so don't discount CI as having its first demo release, in the future. Maybe a month, maybe as many as 3 months, but it will be there. Also, as a side note, I have corrected some of pset.txt on my page (there were some grammar and word errors) and I will be writing a full Doc sometime soon on CI's vis system, and the cool optimisations I have for it. I have quite a bit of work I have done on the system, so don't expect it to be the same. Also, if you use a generic OCTREE (or KD-tree) for any reason, it may be worth a read, because I have some very simplistic things, like the 7 point system (which in fact uses 6 points) virtual nodings, node LODing and other interesting things. I hope to have some more graphics stuff on here very soon. I just have to prove a bit of calc, and then get some time. 
|
