Week 19/2014: Definitions
Last week I was revising the way how DED definitions are handled internally.
The code that reads DED definitions and stores them in memory is among the oldest in Doomsday. This is stuff that I wrote during the first years of the project, as it was required to support multiple alternative game plugins. The code badly needs updating; it uses cumbersome memory management conventions and lacks any object-orientation, making it unfriendly to work with.
Simplifying things a bit, there are two kinds of definitions in the engine:
For compatibility reasons, there isn't much that can be changed about the latter kind (runtime) definitions: for instance, the games expect to have an array of all mobj states available to them for instant access to the state data. However, the raw definitions are internal to the engine and can be changed more freely.
During the past week I have been reorganizing the DED code with the goal of cleaning up and clarifying it without changing any of its functionality. This is now pretty much complete, allowing me to progress to the next step: applying the modern C++ concepts and classes that the Doomsday 2 libraries offer.
I intend to use Doomsday Script compatible data structures for storing the raw definitions. This will then allow using ScriptedInfo as the parser — which in turn effectively gives us a concrete implementation of DED 2.0. The old DED parser will still hang around for backwards compatibility, though. I expect that it will ultimately become a plugin that converts old DED files into a DED 2.0 compatible format.
The code that reads DED definitions and stores them in memory is among the oldest in Doomsday. This is stuff that I wrote during the first years of the project, as it was required to support multiple alternative game plugins. The code badly needs updating; it uses cumbersome memory management conventions and lacks any object-orientation, making it unfriendly to work with.
Simplifying things a bit, there are two kinds of definitions in the engine:
- "Raw" definitions: DED files are parsed and the values are stored in arrays without much further processing.
- Runtime definitions are produced from the raw definitions. The resulting data is then shared as-is with the game plugins.
For compatibility reasons, there isn't much that can be changed about the latter kind (runtime) definitions: for instance, the games expect to have an array of all mobj states available to them for instant access to the state data. However, the raw definitions are internal to the engine and can be changed more freely.
During the past week I have been reorganizing the DED code with the goal of cleaning up and clarifying it without changing any of its functionality. This is now pretty much complete, allowing me to progress to the next step: applying the modern C++ concepts and classes that the Doomsday 2 libraries offer.
I intend to use Doomsday Script compatible data structures for storing the raw definitions. This will then allow using ScriptedInfo as the parser — which in turn effectively gives us a concrete implementation of DED 2.0. The old DED parser will still hang around for backwards compatibility, though. I expect that it will ultimately become a plugin that converts old DED files into a DED 2.0 compatible format.