On Week 15/2012
skyjake:
Last week I was focusing on bugs and managed to do a number of significant fixes. You can follow our progress toward 1.9.8 in the to-do list.
We are starting the 1.9.8 Candidate phase now with build 472. While there are inherent challenges in trying to enforce a strict time limit due to the leisure-time nature of the project, I am hoping we can finish the Candidate phase in 3 weeks this time. This should be doable providing we focus strictly on the stable 1.9.8 todo items, and no Real Life commitments get in the way.
Regardless of whether we can hold on to this planned schedule, I'm happy about the effect this is having on our development practices. Previously, it was all too easy to be lured away in the fun of writing new code and refactoring. However, this was preventing us from making stable releases: any piece of completely new code needs a certain amount of extra work before it is suitable for wide-spread distribution and use. The Candidate phases are specifically intended for this part of the work, which hitherto has not been specifically addressed. It is not always fun, but it is mandatory for stable software.
I've started a new discussion thread today for 1.9.8 candidate testing. Please give the new builds a try and see what kind of issues you can find.
DaniJ:
Last week I completed refactoring work to the BSP builder which was merged to the master for Friday's build 469.
The big change is that we now dynamically construct the actual BSP data objects used in-game (rather than an intermediate representation). This has many benefits, not least because we can now rebuild the BSP for the current map at any time. This is a key enabler for what will ultimately result in in-game map editing.
Another small but certainly not insignificant change is the handling of what is known as the "one-sided window effect", used by mods to create 'windows' from one sector into another without making them traversable by enemies. This construct is now modelled within the BSP data objects, removing the need for special case handling in the rest of the engine. These changes are the cause of some new regressions in various maps, resulting in a fatal error at runtime (e.g., near the hidden staircase behind the glass window in Hexen's Winnowing Hall). These regressions will be fixed over the course of the coming week as the renderer (among others) is updated to handle the revised representation.
Doomsday's BSP builder works natively with 64bit double floating-point precision and since then my work has focused on updating the rest of the playsim to use the same representation. This work progressed well although I narrowly missed the start of the candidate phase. As such, I have held back on merging this to master until I'm sure it won't result in too much upheaval. I expect I'll have this merged in the next day or so at which point I'll shift my focus to readying the code for the 1.9.8 release.
Last week I was focusing on bugs and managed to do a number of significant fixes. You can follow our progress toward 1.9.8 in the to-do list.
We are starting the 1.9.8 Candidate phase now with build 472. While there are inherent challenges in trying to enforce a strict time limit due to the leisure-time nature of the project, I am hoping we can finish the Candidate phase in 3 weeks this time. This should be doable providing we focus strictly on the stable 1.9.8 todo items, and no Real Life commitments get in the way.
Regardless of whether we can hold on to this planned schedule, I'm happy about the effect this is having on our development practices. Previously, it was all too easy to be lured away in the fun of writing new code and refactoring. However, this was preventing us from making stable releases: any piece of completely new code needs a certain amount of extra work before it is suitable for wide-spread distribution and use. The Candidate phases are specifically intended for this part of the work, which hitherto has not been specifically addressed. It is not always fun, but it is mandatory for stable software.
I've started a new discussion thread today for 1.9.8 candidate testing. Please give the new builds a try and see what kind of issues you can find.
DaniJ:
Last week I completed refactoring work to the BSP builder which was merged to the master for Friday's build 469.
The big change is that we now dynamically construct the actual BSP data objects used in-game (rather than an intermediate representation). This has many benefits, not least because we can now rebuild the BSP for the current map at any time. This is a key enabler for what will ultimately result in in-game map editing.
Another small but certainly not insignificant change is the handling of what is known as the "one-sided window effect", used by mods to create 'windows' from one sector into another without making them traversable by enemies. This construct is now modelled within the BSP data objects, removing the need for special case handling in the rest of the engine. These changes are the cause of some new regressions in various maps, resulting in a fatal error at runtime (e.g., near the hidden staircase behind the glass window in Hexen's Winnowing Hall). These regressions will be fixed over the course of the coming week as the renderer (among others) is updated to handle the revised representation.
Doomsday's BSP builder works natively with 64bit double floating-point precision and since then my work has focused on updating the rest of the playsim to use the same representation. This work progressed well although I narrowly missed the start of the candidate phase. As such, I have held back on merging this to master until I'm sure it won't result in too much upheaval. I expect I'll have this merged in the next day or so at which point I'll shift my focus to readying the code for the 1.9.8 release.