Re: [Alephmodular-devel] Serializing the world

[Jeremy P. <jer...@ve...>]

I really need to think these things through all the way.

This would also be a good time for defining how and when  
load_raw_data fails. Does it return something. Does it throw a  
CLoader::LoadFailed exception? (This is fine by me. And considering  
that one of the ways of failing is to go out of bounds with an  
AIStream, it might make sense to try and catch things like this and  
translate them to CLoader exceptions).

Nicer still, translating them to a CLoader exception could be handed  
by the primary base code, and the sub classes all override and define  
the private implementations for their given area of expertise.

On Jun 13, 2005, at 9:09 PM, Br'fin wrote:

> Ok, I've been working on adding more AI/OStreams friends and the  
> like to more objects. As well as tweaking the code that iterates  
> over the various save game tags and throws the various data out  
> into a file.
>
> Specifically, this array:
>
>> struct save_game_data save_data[]=
>> {
>>     { ENDPOINT_DATA_TAG, FILE_SIZEOF_endpoint_data, TRUE },
>>     { LINE_TAG, FILE_SIZEOF_line_data, TRUE },
>>     { SIDE_TAG, FILE_SIZEOF_side_data, TRUE },
>>     { POLYGON_TAG, FILE_SIZEOF_polygon_data, TRUE },
>>     { LIGHTSOURCE_TAG, FILE_SIZEOF_light_data, FALSE },
>>
>
> Now, in the past, this thing basically helped develop count of data  
> per tag, size of data per tag, and array location for data. So,  
> especially for those elements not handled by the level loader, it  
> could just say, data, size, source/dest, memcpy. With packing,  
> things progress with a big switch for determining size, a big  
> switch for source, and then packs the data for copying into a wad.
>
> And that doesn't even cover the additional code to unpack it from a  
> saved game.
>
> It feels reasonable to me to have some loader classes that  
> encapsulate the elements needed to load/save data.
>
> Something along the lines of
>
> MyFoo.h
> -------
> #include "CLoader.h" // CSerializer?
>
> // CLoader::Result some variable size data run with a count
> class MyFooLoader : public CLoader
> {
>     void load_raw_data(char* raw_data, size_t length);
>     CLoader::Result get_save_data();
> }
>
> Where load_raw_data does an appropriate unpack event. And  
> get_save_returns you some stream of data that you need to dispose  
> of yourself. This could be an auto_ptr to a vector<char> that is  
> self maintaining, or it could be a pair<char*,size_t> that you need  
> to explicitly free in some fashion. (AM has 2-3 instances of the  
> latter around resource using functions, like sound_handles and  
> CResourceFile, not that I'm perfectly happy with them.)
>
> Thoughts? Comments? Examples of similar objects?
>
> I'm undecided on the return format of get_save_data and am  
> definitely not happy with the names load_raw_data and get_save_data.
>