From: Filip V. <f.v...@ce...> - 2006-10-31 08:07:20
|
______________________________________________________________ > Od: tel...@fa... > Komu: opd...@li... > Datum: 31.10.2006 02:35 > P=F8edm=ECt: Re: [Opde-devel] Database service sketch > >Oh, great.. Now you're wasting time drawing silly diagrams. I thought >that was my job? What are you trying to make me actually write some co= de >or something? Not at all! I'm not trying to offend you. My thoughts ran over this, so= I thought sharing the quick sketch would be nice. If it is not helping= , just please dump/ignore it, that's all... Actually, I'm really looking forward to your design work. I'll better f= ocus on the DarkSceneManager for now to stop interfering. > >> The file handling classes are ment to be mainly a unifying classes f= or >> Ogre's / std access, but there is a MemoryFile for chunk load/save >> capabilities. That one will be inherited to provide chunk header access, >> and the DarkDB file handling class will supply a set of these >> (+iterator) for the services wishing to write/read data. >>=20 > >Why the need for both Ogre and std streams? Isn't Ogre alone enough fo= r >any file access? And I'd think that, for the benefit of the resource >manager, we'd want to discourage bypassing it. The reason for this is that ogre does not have any universal file writi= ng capabilities. For data loading, that is ok. The idea was that for file writing, one should use the same 'File' clas= s as for reading. Thus the File class to wrap the different underlying classes. =46or normal game mode, this is only useful for savegames, but, as the = engine classes could also be used to create an editor or such, this cou= ld be very useful. Just thinking ahead. The ogre's resource manager won't be skipped at al= l for normal data access (that means reading). If needed, the DataStrea= m one gets from ogre would be wrapped by a OgreFile class or such (Exce= ption when trying to write). > >In the databse class you've got a box labelled "Storage" for interfaci= ng >with the Data manager. A useful interface for this purpose would be >something like: > >class StructData: > This class binds a StructInfo descriptor to the data > that it describes. Class is initialized with a StructInfo > and some sort of reader/writer class for accessing the data. > method getName: Name of this structure. > method getFieldNames: Returns iterator. > method describeField(name): Returns the type information of a fiel= d. > method getField(name): Returns the data in a field as a DVariant. > method setField(name,value): Stores data in the field. > >You pass this to the database and it will be able to quickly stream da= ta >from arbitrary sources without regard for the underlying format. I like this. I got a small idea. I thought it would be helpful to implement union (S= tructUnion?) which would be a StructAlias with enum describing the poss= ible StructInfos. I do not yet know how to tell the system which of the= classes is now used. Should be doable. Otherwise the serialization wou= ld be a headache. Is this possible? Also, I thought it would be nice to do Vector3, Vector2 and some angle = class directly as a possible fields in the StructInfo. Hell, I really did not want to offend you. Sorry if I did =46ilip |