-
Notifications
You must be signed in to change notification settings - Fork 110
fe_man_binary
\
The front end control flow will be deisgned in the FEMan tool. The FEMan already has a output format which allows files to be saved. However, this format is somewhat restrictive due to it’s text nature and the fact that considerable parsing is required at load time. To compensate for this, we will create a binary format which is optimised for our game’s particular UI. This format is essentially a subset of the FEMan text format, as some data is removed. However, there is additional data which is derived from parsing the user-defined text strings.
\
An additional feature of the binary output format is that it can convert special strings into control ID numbers. It will do this by parsing a special header file which will be shared with the game. This header file is essential because these same numbers will be used by the game. This feature is exactly the same as the way Windows defines control ID’s with resource files. One difference we will employ is that we will not support advanced preprocessing to keep this header file parsing simple.
\
These files will likely be created as an export option from the FEMan tool. However, because the files are already saved in a text format, we may opt to support a command-line tool suitable for makefiles.
\
The extension for the files will be .FIB. it should be noted that this is not chosen because it stands for anything in particular, but simply because it sounds cool.
The file will have a header with the following format:
Name
Type and size
Usage
Ident. string
8 bytes
Compared to <Bananna> to verify correct file format.
Version #
16-bit word
low byte is minor version #, high byte major version #
Nscreens
16-bit word
Number of screens in this file
\
Because this data is only used at load time, it can be discarded after the file is loaded. However, this will not save much RAM because the header is quite small and there will be few of them.
\
Immediately following the header will be a list of headers for each screen. These headers will have the following format:
Name
Type and size
Usage
Pname
32-offset
Fixed up to a pointer to name string
Flags
32-bit word
Control behaviour of screen.*
Nlinks
16-bit word
Number of links in this screen
Natoms
16-bit word
Number of UI ‘atoms’ in this screen
Plinks
32-bit word
Offset to the start of the screen link structures.
Patoms
32-bit word
Offset to start of FE atom structures.
*Currently defined screen bit field flags include:
-
None yet!
These flags will be prefixed with ‘FS_’ for Front end Screen flag.
\
After the files are loaded, links between them will be fixed up as pointers so we needn’t keep any index of them around. However, the loading code will have to maintain a list of entry points by index.
Each entry in a list of screen links will have the following format
Name
Type and size
Usage
Pname
32-bit offset
Fixed up to a name pointer. Name may be NULL if none exists.
Flags
32-bit word
Controls behaviour of link.*
Pl~~inkTo
32-bit offset
Name of screen to link to.
*Currently defined flag bit fields include:
-
Enabled. This flag can be used to disable links if they need to be disabled.
-
Default ‘next’ link.
-
Default ‘previous’ link.
These flags will be prefixed with ‘FL_’ for Front end Link flag.
Each individual ‘atom’ in the front end will have a structure to describe it. It will have the following format:
Name
Type and size
Usage
Pname
32-bit offset
Fixed up to a name pointer. Passed to FE processor functions.
Type
16-bit word
Control type enumeration (user region, static text, button, check box, toggle button, scroll bar, text entry, list view expand button, title bar.)
Flags
16-bit word
Controls behaviour and appearance of control.*
Content color
32-bit RGBA
Color of the main body of control.
Border color
32-bit RGBA
Color of the border of the window.
Bounding rectangle
4 32-bit numbers
Specify location (of top-left corner) and size (width x height) of control.
Reserved
12 bytes
Used for control-specific data and future expansion.
\
*The flags will include bit fields for:
-
Default ‘next’ link control.
-
Default ‘previous’ link control.
-
Screen exit. This would be useful, for example, for an ‘OK’ or ‘Cancel’ button in a dialog.
These flags will be prefixed with ‘FA_’ for Front end Atom flag.
Because the UI elements have names, we will place all the name strings here. Any number of them can exist in any order and they will be NULL terminated. All references to them will be an offset from the beginning of the file. This will permit them to be easily fixed up to a pointer.
\