On Week 11/2012
skyjake:
It was an unusual week as far as our automated build system was concerned, with five builds instead of the usual two. I spent a couple of days fixing (and breaking) the autobuilder, after which I resumed work on the Qt refactoring.
The week started a little wobbly with build 437 broken on Unix (gcc compiled) platforms. That was fixed in 438, along with a few other shady memory-related issues.
Since fixes for several crashes had accumulated in the master branch, we decided it was a good idea to update the stable 1.9.7 release with some of the fixes included. This meant that Wednesday's build 439 was made from the "stable" branch instead of the master; the stable currently holds 1.9.7 while we work on the next release, 1.9.8, in the master.
This was the first time ever we've done an update to a stable build. In addition to highlighting some deficiencies in our automated build system, it revealed that it would be better if stable builds were not labeled with build numbers, only by their release names, as people using unstable builds are keen to just focus on the build number. This prompted a change in the build scripts: for stable builds henceforth, the build number is only shown by the version command. Otherwise it just shows the version number and a possible patch level. For instance, under the new rules build 439 would be labeled 1.9.7-1. For instance, the Windows installer would be doomsday_1.9.7-1.exe. (This naming convention is already in use for source tarballs.)
Unfortunately, after these changes the scripts were left broken, which meant Friday's build 441 failed to produce any binary packages. Also, when generating the changelog for the build, it didn't check which version the previous build was from, so it generated a long list of all the changes between the stable and master branches. I fixed the autobuilder in time for Saturday's new build 442.
So far I've been focusing on the Mac OS X platform in my Qt refactoring, and it has been progressing at a nice pace. The refactoring of the window manager is pretty much complete for now. The API has been future-proofed with more object-orientedness and no assumption about the number of windows in use. (In 1.9.8, only one window will still be supported, though.) I wrote new code for changing display modes, giving the engine full visibility to which modes are available, so that the right ones are listed in the control panel. Also, the engine will now persistently store the window configuration, so that the same settings are restored on the next launch. Thus we can begin scaling back the display configuration options in the launcher and start relying on the more accurate information available in the engine itself. This is the beginning of a road that will see Snowberry dropped completely; I'll talk more about this later...
When it comes to the mouse, the new Qt based input code is in place and everything except mouse wheel events are being processed appropriately. The wheel requires some additional thinking because modern "wheels" need more of a gesture recognition approach (e.g., Mac trackpads where you can swipe in any direction). We could later model the wheel as a 2-axis controller in the engine, but for now I'll just restore the previous behavior of up/down (left/right) wheel signals.
The keyboard is fully working on the Mac. It was a little tricky because the engine makes the assumption that all keyboard bindings are done to physical keys rather than the symbols produced by the keys. For instance, even though Shift+1 generates a ! character, the engine must still execute the binding for the 1 key regardless of the Shift key state. Fortunately key events contain both platform-specific virtual key codes and the native scan codes (if available), so it's just a matter of mapping these to the engine's own DDKEY constants.
The joystick still uses SDL so it will be unaffected by these changes, as long as SDL itself doesn't conflict with the Qt based application core. At least on the Mac it's working fine.
My plan for this week is to spend a few moments looking at Mac-specific compilation issues and then start moving to the Windows platform for the Qt refactoring. For the Mac we are currently only distributing 32-bit Universal binaries compatible with OS X 10.4 or newer. Modern Macs are all 64-bit, so at some point in the near future I'll introduce a 64-bit only Intel build for OS X 10.6+.
DaniJ:
I ran into a small roadblock with my work on our BSP builder at the beginning of last week. Closer inspection of our glBSP 2.24 derived node builder revealed some logic which jarred somewhat with my understanding of the algorithm. However before I could get stuck in to examining it in detail, a more urgent issue related to the newly released 1.9.7-1 patch release was brought to our attention.
Skyjake has already covered the release itself and the subsequent naming convention changes. However another important aspect of this was the apparent confusion the build numbering gave rise to among the user community. It became clear that because the autobuilder was now producing builds from multiple branches that dengine.net's build repository interface was no longer suitably representative of it.
After some initial discussion a new design for this interface was produced, which organised build events within a two-dimensional "build graph" according to the Doomsday version number in effect on the branch targeted during the build. In light of the minor roadblock I had encountered in my work on the node builder, I decided that some background processing was needed to solve that particular problem and consequently opted to spend most of my Deng development time over the following two-three days implementing the new build repository design.
Our new look build repository is now live and we hope you will agree that it is both easier to use and more illustrative of the autobuilder's configuration.
The time away from the BSP builder issues proved worthwhile. On returning to the problem I found I had already validated the solution it demanded. With that issue now resolved I expect this work to progress much more swiftly over the coming week.
It was an unusual week as far as our automated build system was concerned, with five builds instead of the usual two. I spent a couple of days fixing (and breaking) the autobuilder, after which I resumed work on the Qt refactoring.
The week started a little wobbly with build 437 broken on Unix (gcc compiled) platforms. That was fixed in 438, along with a few other shady memory-related issues.
Since fixes for several crashes had accumulated in the master branch, we decided it was a good idea to update the stable 1.9.7 release with some of the fixes included. This meant that Wednesday's build 439 was made from the "stable" branch instead of the master; the stable currently holds 1.9.7 while we work on the next release, 1.9.8, in the master.
This was the first time ever we've done an update to a stable build. In addition to highlighting some deficiencies in our automated build system, it revealed that it would be better if stable builds were not labeled with build numbers, only by their release names, as people using unstable builds are keen to just focus on the build number. This prompted a change in the build scripts: for stable builds henceforth, the build number is only shown by the version command. Otherwise it just shows the version number and a possible patch level. For instance, under the new rules build 439 would be labeled 1.9.7-1. For instance, the Windows installer would be doomsday_1.9.7-1.exe. (This naming convention is already in use for source tarballs.)
Unfortunately, after these changes the scripts were left broken, which meant Friday's build 441 failed to produce any binary packages. Also, when generating the changelog for the build, it didn't check which version the previous build was from, so it generated a long list of all the changes between the stable and master branches. I fixed the autobuilder in time for Saturday's new build 442.
So far I've been focusing on the Mac OS X platform in my Qt refactoring, and it has been progressing at a nice pace. The refactoring of the window manager is pretty much complete for now. The API has been future-proofed with more object-orientedness and no assumption about the number of windows in use. (In 1.9.8, only one window will still be supported, though.) I wrote new code for changing display modes, giving the engine full visibility to which modes are available, so that the right ones are listed in the control panel. Also, the engine will now persistently store the window configuration, so that the same settings are restored on the next launch. Thus we can begin scaling back the display configuration options in the launcher and start relying on the more accurate information available in the engine itself. This is the beginning of a road that will see Snowberry dropped completely; I'll talk more about this later...
When it comes to the mouse, the new Qt based input code is in place and everything except mouse wheel events are being processed appropriately. The wheel requires some additional thinking because modern "wheels" need more of a gesture recognition approach (e.g., Mac trackpads where you can swipe in any direction). We could later model the wheel as a 2-axis controller in the engine, but for now I'll just restore the previous behavior of up/down (left/right) wheel signals.
The keyboard is fully working on the Mac. It was a little tricky because the engine makes the assumption that all keyboard bindings are done to physical keys rather than the symbols produced by the keys. For instance, even though Shift+1 generates a ! character, the engine must still execute the binding for the 1 key regardless of the Shift key state. Fortunately key events contain both platform-specific virtual key codes and the native scan codes (if available), so it's just a matter of mapping these to the engine's own DDKEY constants.
The joystick still uses SDL so it will be unaffected by these changes, as long as SDL itself doesn't conflict with the Qt based application core. At least on the Mac it's working fine.
My plan for this week is to spend a few moments looking at Mac-specific compilation issues and then start moving to the Windows platform for the Qt refactoring. For the Mac we are currently only distributing 32-bit Universal binaries compatible with OS X 10.4 or newer. Modern Macs are all 64-bit, so at some point in the near future I'll introduce a 64-bit only Intel build for OS X 10.6+.
DaniJ:
I ran into a small roadblock with my work on our BSP builder at the beginning of last week. Closer inspection of our glBSP 2.24 derived node builder revealed some logic which jarred somewhat with my understanding of the algorithm. However before I could get stuck in to examining it in detail, a more urgent issue related to the newly released 1.9.7-1 patch release was brought to our attention.
Skyjake has already covered the release itself and the subsequent naming convention changes. However another important aspect of this was the apparent confusion the build numbering gave rise to among the user community. It became clear that because the autobuilder was now producing builds from multiple branches that dengine.net's build repository interface was no longer suitably representative of it.
After some initial discussion a new design for this interface was produced, which organised build events within a two-dimensional "build graph" according to the Doomsday version number in effect on the branch targeted during the build. In light of the minor roadblock I had encountered in my work on the node builder, I decided that some background processing was needed to solve that particular problem and consequently opted to spend most of my Deng development time over the following two-three days implementing the new build repository design.
Our new look build repository is now live and we hope you will agree that it is both easier to use and more illustrative of the autobuilder's configuration.
The time away from the BSP builder issues proved worthwhile. On returning to the problem I found I had already validated the solution it demanded. With that issue now resolved I expect this work to progress much more swiftly over the coming week.