<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Engine, Games, Releases, Version 1.9.</i>
My personal goal was to get something released around Christmas, as has been the tradition in past years. However, due to time constraints this was not possible. Also, the goals of the 1.9 release were redefined in October/November, adding to the workload. Now, one might ask why was this done? The major reason is that the codebase as a whole needs to be refined so that it is more future-proof and a better foundation for 3rd party development. As redundancies between the games are reduced and more functionality is moved into the engine, it will become easier to fix bugs and maintain the code. Once the planned changes such as engine-side map data have been implemented, it should be much easier to improve netgames and fix the bugs currently remaining.
And of course, since we are talking about an increment to the minor version number, significant changes are called for.
At the moment I am working with Dani to update the game-side code to conform to the new requirement of having to access map data such as sectors and lines through a set of engine functions specifically reserved for this purpose. This is called the Doomsday Map Update API (DMU). It has several benefits. The engine will now learn about each change to map data as the change occurs. Hitherto games have been able to make changes at any time, and the engine has had to poll through all the data and check if any of it has changed compared to the previous known state. This is quite inefficient and complicated. The Doomsday netgame server currently works using this kind of polling, and benchmarks show it to be quite a performance hog. Even the renderer needs to rely on polling in certain situations. Another benefit of DMU is that it reduces the games' dependency on the engine. Specifically, DMU narrows the dependencies more closely to the actual Doomsday Public API. Since the beginning of the project, games have had direct access to certain data arrays maintained by the engine. If for some reason the arrays changed the games would be automatically broken. Not a great thing for maintaining compatibility between releases. Thinking forward, we want to be in a situation where we can replace the entire engine while providing the same API to the games. That way the game logic can be transitioned to a next-generation engine with a minimum amount of work and high level of accuracy.
Now that DMU has been added, all map data is internal to the engine and not directly visible to the games. This means quite a bit of code needs to be updated, since as you would expect, map data is accessed in numerous places in the games. The amount of work needed for refactoring the games is the largest drawback.
The current status is that DMU API is mostly complete, although not all map data is yet accessible. I have been concentrating on updating jHexen to use DMU. This work is about halfway complete. Dani is working on updating jDoom and jHeretic.
I don't dare make any predictions on release dates. One thing is for certain, though. We are in for an extended beta testing period, because of the magnitude of changes done for DMU, and other various changes (which Dani will probably tell about at some point). It is entirely possible that we have been introducing a host of new bugs as we have been refactoring the code.