[WMCoolmon]

I've been considering adding compiled (binary) table support to FS2, starting with ships.tbl, along with appropriate convertors and possible special programs. But, before I start seriously working on it, do any of the more experienced coders know how much of a speed increase this will give?

My proposed format for "ships.ctb":

Code: [Select]

struct ships_ctb
{
     char Header[4] = 'FSHT';
     int Version; //Whatever FS version this is implemented in
     
     {
          char wash_chunk[4] = 'WASH';
          int chunklen;
         
          int num_washes; // < MAX_ENGINE_WASH_TYPES
          engine_wash_info washtypes[num_washes];
     }
     
     {
          char ship_chunk[4] = 'SHIP';
          int chunklen;
         
          int num_ships; // < MAX_SHIP_TYPES
          ship_info shiptypes[num_ships];
     }
     
     {
          char precedence_chunk = 'PSHP';
          int chunklen;
         
          char default_ship[NAME_LENGTH];
          int num_prec_ships; //< MAX_PLAYER_SHIP_CHOICES
          char prec_ship_names[num_prec_ships];
     }
}

[Goober5000]

Um - why?  The only difference this will make is when the game is initially loaded.  Afterwards, all the table information will be stored in arrays and such.  Since FS2 will never re-load table information, you really don't need to worry about it.

[WMCoolmon]

For some reason I thought FS2 loaded the data from ships.tbl into memory every mission.

[mikhael]

My two cents:

Bad idea. The tables (as much as I hate their layout) are already in the perfect format for what they are. Only in cases where you have limited storage would you want to compress them. You won't see a huge boost in load performance by converting a raw text file into a smaller binary. Reading text just isn't that slow.

Now, if you can do something to make loading POF and mission data faster without breaking backward compatibility, THAT'D improve load times.

[penguin]

Yeah, with something like this, binary is probably bad... it would load a little faster, but debugging becomes a bear.  Most of my RL work deals w/ parsing massive text files, mostly in Perl.

I think part of the problem is not that missions (and the other .tbl files) are text, it's the syntax... the parser ends up being way more complex than it needs to be.  It's been one of my pet peeves from the beginning (some strings are quoted, some aren't; some lists are space-delimited, others have commas, etc).  Don't even get me started on the # $ + leading characters.

A more regular and orthogonal file structure would not only make the parser faster, but the parser code would be smaller, more robust, and more easily extensible.  

Contrast this with the sexp structure -- it's LISP-based, and is about as clean and simple as it gets.  So it's easy to parse, fairly easy to read, simple for a machine to generate (from FRED or whatever), and it can be extended without breaking anything else.  I wish they used a LISP-like syntax for all the TBL stuff.