Revision e5b9ad6c
Added by danij almost 17 years ago
Files
- added
- modified
- copied
- renamed
- deleted
- doomsday
- engine
- portable
- include
- dam_loader.h (diff)
- dam_main.h (diff)
- dam_read.h (diff)
- dam_reject.h (diff)
- de_dam.h (diff)
- edit_map.h (diff)
- mapdata.hs (diff)
- p_bmap.h (diff)
- p_mapdata.h (diff)
- p_maptypes.h (diff)
- r_world.h (diff)
- src
- bsp_edge.c (diff)
- bsp_level.c (diff)
- bsp_node.c (diff)
- dam_loader.c (diff)
- dam_main.c (diff)
- dam_read.c (diff)
- edit_map.c (diff)
- p_bmap.c (diff)
- p_data.c (diff)
- include
- portable
- engine
New map loading architecture.
I wasn't happy with the way the first implementation of the engine-side map loading was going so I've redesigned it from the ground up. We now support loading only one map format - our bespoke Doomsday archived map format.
Upon being instructed to load a map, Doomsday first checks the map cache to see if we have a cached map we can load. If so, it is loaded directly. If not, we collect the lumps associated with the given map and publish them to any map converter plugins currently registered in the hopes that one of them recognizes the format. A map converter plugin loads the data from the lumps and transforms them into a local representation appropriate to the format being read. The map data is then transferred engine-side using the new map editing interface which can be used to build maps at runtime.
Once the transfer is complete, Doomsday then transforms the map data from the specialized editable format into our runtime map format (this includes building the BSP). At this point and if map caching is enabled, the entire map plus all additional required data structures are archived to the map cache for later use.
In practice, the code is a bit on the messy side currently (as can be expected from such large changes) but that will improve as the kludges are worked out and the API matures.