[Balder-devel] Fwd: Anything happening ?
Status: Beta
Brought to you by:
holomorph
From: Bjorn H. <bh...@uv...> - 2002-05-28 20:59:11
|
I haven't had time to digest and understand this yet, but I'm back home now so I should have things (my life) under control in the next weeke here sometime : P I really should have passed this along earlier: >Hello all, > >(Can't send do balder developpement list) > >As nothing is happening, here are a reply to a mail I sent earlier >regarding a proposal to get something of a CEL look-a-like with possibly >some tweakings for network. > > The base concept is that a iMetaClass exists and actuall implementations >are accessed via a plugin technic. iMetaClass builds up iClass's. iClass's >are a collection >of slots and methods. iClasses creates instances. Nothing of an iInstance is >accessible without a call through the 'callMethod' or the 'get/set Property' >of the iClass method. > >To summerise: >iDb > has a way to access all instances through Id. > has a way to load up iMetaClass > has a way to access all available iClass > >iMetaClass > -> builds iClass > iClass > has Slots holding properties > has Methods > ->builds iInstances > iInstance > has an idea > has some storage for the slots/Methodf (if the method is > a script for instance) > > What do we get with that ? >- lets consider we have a network update frequency of 20/seconds (so, >we have a packet leaving every 1/20 th of a second), the iClass >'get/set/callMethod' >can log all relevent changes into a buffer, and when the train has to leave it >is sent out. All 'slaves' at the destination(s) gets the get/set/calls in >the same order >of creation. Method calls are like kind of events, set (we don't care >about get) are >like 'streaming' update. Instance creation is a callMethod, therefore it will >go through network also. For slots, we might consider first than only the last >'set' get sent away (interpolation technics are used to ensure that not to >high >jerkiness arrise because of this). > >- Instance creation is also a special call, therefore, on the client where the > call method is made, the instance is defined has being a 'master'. On > all the > other sites, 'slaves' instances are created. Master/slave means that > all slots > are read-only in the slave. But method calls are still possible on the > slave > instance. > > I am currently writing up a first implementation of the meta class > stuff. If anybody thincks >of reasonable improvements, I am all hears. The goal is to avoid having >the following kind >of code: > if ( isNetworkEvent ) { > .... > } else { > .... > } > Spread out al-over the code. Note also that 'slots" can be simulated. > Lets say I have >a normal C++ class with some attributes, then we can arrange for the >iClass created by the >iMetaClass to 'virtual slots' (that dont'really exists) to access the >native attribute. > > The network 'train' concept is 'hard'. That is we send data every 1/20 > th of a second >whatever. So, if the data gets to large that it would impair the ability >to send 1/20 of a second, >then we send right away and start filling up the packet for the next >train. This would raise >some flag if we can do something in the game to reduce network traffic. >Otherwise, we >are in trouble and can't do anything about it ! > > Best regards, > > Sebastien. > >PS: I have a build method for MSVC Win32, but has the source tree is still >probably going to change in the >futur (we have plugins in what I describes here), I am keeping it under >the hood for the moment. >By the way my idea on creating a meta data model is exactly >the ground basis for VOS (http://interreality.org/). But might be slightly >overkill in term of being too >generic. Also if licensing allows, we could start with this and eventually >tune it for our purpose. |