Week 18/2014: libdoomsday
We are in the process of preparing a new patch for 1.14. There are a couple of important fixes upcoming, for instance a save bug in Hexen that would reset the state of the other maps in the same hub.
I have begun working on 1.15 in earnest. We have big plans for this version.
I started with a bit of spring cleaning by removing some obsolete files from the installation, mostly related to the old UI that has now been replaced.
One of the long-running threads in the development of Doomsday is increasing modularity in the code base. Modularity is very important because it enforces well-organized and clean dependencies between components, making the code easier to maintain and develop further. We started out with one Doomsday executable that could run both as a client and server. That was split to two separate executables, but with plenty of code that was compiled twice, using different build settings. Now, we're working towards moving the truly shared code into a libary of its own, with the goal of having neatly separate client and server applications with no redundant code.
To this end, I added a new library called "libdoomsday" (doomsday.dll or libdoomsday.so in the bin folder). I then cleaned up and moved a couple of the most central Doomsday subsystems into the new library: the console (variables and commands) and FS1 (the original Doomsday file system; FS2 is the new one developed originally for Hawthorn). Once all the shared subsystems have been relocated, we can proceed to upgrading them with the Doomsday 2 architecture in mind.
These changes are already available in the unstable builds, and while I've checked that there are no major regressions, the reshuffling of code may have induced small issues. Let us know if you run into any new problems.
My next step is to move another central subsystem to libdoomsday: the DED definition parser and database. Since the objective is to improve the 3D model renderer, and 3D model resources rather heavily depend on definitions, it makes sense to get this subsystem in better shape before tackling any rendering tasks.
I have begun working on 1.15 in earnest. We have big plans for this version.
I started with a bit of spring cleaning by removing some obsolete files from the installation, mostly related to the old UI that has now been replaced.
One of the long-running threads in the development of Doomsday is increasing modularity in the code base. Modularity is very important because it enforces well-organized and clean dependencies between components, making the code easier to maintain and develop further. We started out with one Doomsday executable that could run both as a client and server. That was split to two separate executables, but with plenty of code that was compiled twice, using different build settings. Now, we're working towards moving the truly shared code into a libary of its own, with the goal of having neatly separate client and server applications with no redundant code.
To this end, I added a new library called "libdoomsday" (doomsday.dll or libdoomsday.so in the bin folder). I then cleaned up and moved a couple of the most central Doomsday subsystems into the new library: the console (variables and commands) and FS1 (the original Doomsday file system; FS2 is the new one developed originally for Hawthorn). Once all the shared subsystems have been relocated, we can proceed to upgrading them with the Doomsday 2 architecture in mind.
These changes are already available in the unstable builds, and while I've checked that there are no major regressions, the reshuffling of code may have induced small issues. Let us know if you run into any new problems.
My next step is to move another central subsystem to libdoomsday: the DED definition parser and database. Since the objective is to improve the 3D model renderer, and 3D model resources rather heavily depend on definitions, it makes sense to get this subsystem in better shape before tackling any rendering tasks.