Although understanding database buildup within the BGL graphics system isn't a prerequisite to creating and displaying scenery, it definitely helps to have a cursory understanding of how databases are designed in BGL. BGL database design is made up of the following items, to be discussed in this topic:
The first step in database buildup is the creation of the object list. The front-end processor retrieves the object data from all of the BGL files and puts it into the object list. The object list is just that, a list of objects created by the front-end processor in virtual memory; the list is actually one large piece of inline BGL code. The BGL graphics interpreter executes the list of objects.
Technically, there are two object lists—the one in use and the one being built. At Flight Simulator startup, there isn't an object list; Flight Simulator displays a message that scenery is being built while the first object list is built by the front-end processor. After the first object list is built, the BGL graphics system has scenery to work with and projects it, repeatedly, at a high frame rate by interpreting and reinterpreting the BGL code. This continues until significant plane movement occurs and a new database with more geographically correct scenery is needed. At this point, a new object list is built in a frame-interleaved manner to avoid display pauses. Once the new object list is fully built (over the course of many display frames), it's made available to the BGL graphics system. The "old" object list is discarded and its memory is freed up for use by the "new" object list.
The BGL header includes many different pointers to all the different data sections. All the scenery information is in the header, but how is the information pulled into the BGL graphics system, the navaids systems, and other Flight Simulator systems and used? The process of retrieving and using this data can be broken down into three parts: the seed scan, the object scan, and random interrogation.
At Flight Simulator startup or when the user has moved a preset distance from the last valid visual location, new scenery data needs to be “pulled in”; these scenarios trigger a seed and object scan. At Flight Simulator startup, all .bgl files are scanned and their headers are loaded into memory as a file list. The scenery system can then use these headers for all future database scans to quickly decide which files are "in bounds" and have information of the type being requested.
Note: When booster processors, CD scenery, and scenery libraries are used, systems such as the booster processors determine when a new set of BGL files are made available and trigger a file list rebuild.
Assuming the file list already exists, the first part of the seed and object scan is the seed scan. In this phase, a square matrix called a seed map is set up by the front-end processor. Each cell in this square matrix represents a level 13 seed. The seed map is made up of 40 x 40 seeds and includes 1600 entries. The user's location is approximately in the middle of the seed map, so there are about twenty level 13 seed distances to the horizon. Level 13 seeds are 4.9km at the equator and about 3.75km or 2.3 miles at Chicago’s latitude; the seeds encompass about a 40-mile radius around the user.
All the BGL files that have seed data and are within the range of the seed map’s bounds are scanned. Large seeds, such as level 8 and 9 seeds, fill large areas that they overlap on this seed map. Small seeds, such as level 12 and 13 seeds, fill only small areas or only a single entry on the map. Seed priority is taken into account as the map is being filled; that is, small seeds have priority over large ones, and seed priority codes can override the level priorities. When all the BGL files with seeds have been scanned and the map filled, the seed scan is complete.
Once a seed map is complete, the front-end processor converts the seeds into textured rectangles (or a series of textured polygons, for mountains) and puts them into the form of BGL objects in the object list. The 40x40 seed map has the potential to create 1600 polygons, but there is a lot of optimization that can be done to reduce this to a much lower number, resulting in higher display rates. In most cases, a complete seed map can be reduced to a couple dozen rectangular objects. When you're designing seeds, keep this in mind; a seed database that includes lots of random seeds, especially small ones, will create lots of individual seed objects that have to be processed and reduce the frame rate. Alternatively, adjacent seeds with identical properties are combined to form larger rectangular objects.
Once all the seed objects have been added to the object list, the front-end processor performs an object scan. During an object scan, the front-end processor cycles through all the files in the file list and scans the files that have objects and are within the user's visual bounds. The object headers that define each object’s size and range (such as large_object_header) are stripped off and the pure BGL graphics code is added sequentially to the object list for each object. Once the last object has been processed, a bgl_return opcode is added at the end of the object list and the list is complete.
The object list structure shown in the following table summarizes the preceding descriptions of the database buildup of the object list.
| Item | Function | Inserted by |
| BGL opcode | Indicates BGL database. | bglobj16.asm, object16_scan, alloc_and_setup |
| Seed objects | Defines seeds for scanned area. | bglobj16.asm, object16_scan, seed_loop |
| Page fault opcode | If seed objects beyond 16K, cues dbase scanners to flip page. | bglobj16.asm, object16_scan element_next_action |
| Seed objects | See earlier description. | |
| File marker | Indicates file number that the following object came from. (Represents file list item number in front-end processor; specifies the DOS path that the object came from). | bglobj16.asm, object16_scan, object_loop, MAP_WINDOW_AND_GET_OBJECT |
| Object | BGL code fragments. | bglobj16.asm, object16_scan, object_loop MAP_WINDOW_AND_GET_OBJECT |
| File marker | See earlier description. | |
| Object | See earlier description. | |
| File marker | Included for the next object, which won't fit. Marker is extraneous. | |
| Page fault | ||
| File marker | Included on the (new) 16K page to replace preceding marker. | |
| Object | See earlier description. | |
| File marker | Included for the next object, but there isn't one. Marker is extraneous. | |
| BGL RETURN opcode | Indicates end of database. | bglobj16.asm, object16_scan |
Notes:
Because of the use of scenery libraries, it's important to keep track of which files and paths each BGL object originates from. For example, if the scenery system encounters a bgl opcode for a textured polygon, the system must be able to find the scenery directory it came from so that it can search the associated texture subdirectory for the actual texture. To track file location, place a file marker instruction inline in the object list every time a new scenery file is opened. When the BGL interpreter encounters a file marker, it sets the current scenery file to the file indicated by the marker. Any objects that request textures after the marker is set use the current scenery file to reference textures.
When the scenery system calls a library object, it has to determine whether or not object is already in memory. In the scenery system, each library object is given its own memory segment, separate from the object list. If the object doesn't already exist in memory, the file list is scanned and the file that has library objects within the identified range is found. The file is then opened and the library object is loaded into its own memory segment; future calls to this library object don't require file access because the library object now resides in memory.
When a user tunes the navigation radio, Flight Simulator systems request navaid data from the front-end processor. For example, if the VOR receiver frequency is changed, the VOR radio system makes a call to the front-end processor, giving a geographic location and a frequency. The front-end processor goes through the file list and finds any BGL files that have VOR channels that correspond to the requested frequency. These files are further screened based on the geographic information in the header in the file list; that is, there's no need to search a New York scenery file if the user is in California. Finally, the scenery files that include frequency and geographic location matches are opened and the appropriate VOR channel is identified and tuned in.
Note: The front-end processor finds navaid data extremely quickly by doing as much filtering as possible using the memory-resident file list. When tuning a VOR frequency, the user may see the disk light flash, but there isn't a noticeable pause in frame rate.
In Flight Simulator, dialog boxes that include airport facilities information call the front-end processor as needed to retrieve textual information. Access time isn’t as important when working with a dialog box, but the front-end processor is very efficient and quick at retrieving this information.