Skip to content
This repository has been archived by the owner on Nov 14, 2018. It is now read-only.

fe_man_binary

aheadley edited this page Jan 17, 2014 · 1 revision

Format for Front End data files:

\

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.

Header:

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.

\

Format of each screen:

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.

Format of each link:

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.

Format of each control atom:

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.

Name string data:

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.

\