Tag: autobuilder

Down for the count

Autobuilder & Tracker offline

After 10 years of service, the PC running Doomsday’s autobuilder VMs has died. Probable culprit looks like the PSU, so I’ll replace it with a new one and (fingers crossed) the machine can still be resuscitated to full working condition. In the meantime, there will be no new unstable builds. Fortunately the AppVeyor and Travis CI builders should keep the boat afloat until the autobuilder is up and running again.

Another casualty of this hardware failure is the bug/feature tracker that was running on the same PC. The tracker will likewise be offline for now.

Focus navigation

Recently I’ve been working a lot on UI focus navigation. The ultimate goal is to allow using Doomsday without ever touching the mouse, i.e., with only the keyboard or a gamepad. Continue reading Down for the count

Refinement

I came down with a small cold so progress has been somewhat slow recently. My main focus continues to be the Home UI.

I’ve mostly been applying small bug fixes and improvements, such as correcting errors in the Home layout. The Tutorial was also crashing because it was trying to reference a removed UI element. There is now a new settings dialog for configuring the UI. This includes a new setting for slightly scaling down the fonts and other UI elements. This should be particularly helpful when using smaller display resolutions. Continue reading Refinement

Focus adjustments

I took a good look at the project roadmap in the Tracker and decided it was time to do some spring cleaning.

I’ve now updated the plan for the 2.x releases so that each version has a specific focus. For instance, the 2.0 release will focus on the Home UI and basic package management, and the 2.1 release will focus on multiplayer improvements.

While the roadmap is just a plan and plans may always change, defining a clear focus area for each version will help in pushing things forward. Not doing this would mean that each release has the risk of ballooning feature creep and features would likely not be fully baked.

Another topical issue to note is that due to the autobuilder upgrade, the stable 1.15 builds have been suspended until the stable build environment is updated to work with the new builder setup. However, I’m placing my focus on finishing features for the 2.0 stable release, so I don’t expect many fixes for 1.15 in the near future.

Now with twice the bits

I took a short break from the UI work to perform an autobuilder upgrade. The biggest changes are that the autobuilder now produces a new 64-bit Windows MSI package (including Start menu shortcuts), and an RPM package built on Fedora Core 23 (also 64-bit). This means all platforms now have a 64-bit package and Windows additionally has the old 32-bit one as well.

Launchpad builds both 32 and 64 bit packages for Ubuntu. All new Launchpad builds will be done on 16.04.

The upgraded Windows autobuilder uses a newer compiler (VS 2015, Visual C++ 14) and the latest version of Qt (5.6). I’ve also started signing the Windows executables and MSI packages so that you’ll have some assurance of their origin.

These changes may have caused regressions so keep an eye out for any odd behavior. Let us know how it goes!

The changes are also now reflected in the build repository here on dengine.net. For the time being I’ve linked the builds feed directly to the Autobuilder pages to access the latest files. Eventually I’ll rework the pages for builds and downloads — I’ve been eyeing the system for a backend redesign.

Bug reports have been indicating that recent work in the 2.0 unstable builds has caused some file handling issues. I took a closer look and noticed that in many cases, files written to the runtime folder were still being created using standard C I/O functions. This meant they were completely bypassing Doomsday’s internal file system and making assumptions that are no longer valid. I updated all the code that writes files to make use of Doomsday 2 APIs, including .cfg files, temporary MIDI music files, screenshots, the network ID (“client.id”), and creation of subdirectories in the runtime folder. This should take care of all these issues related to Doomsday being unable to write or save files at runtime.

These file fixes are currently in my Home UI work branch, but they will be merged into the master branch in the near future, along with the first iteration of the Home UI.

Game profiles, autobuilder upgrade

Progress has been somewhat slow recently. The central new component I’ve been working on is game profiles. They represent the combination of a game and a list of packages to be loaded with that game — much like a Snowberry profile. A key feature of the Home UI is to let you create and manipulate game profiles.

You may recall that a few years ago we added renderer appearance profiles to manage the various renderer settings. The implementation of these was tied to the old console variable system, but there was a good portion of code that was reusable also for game profiles. I refactored the appearance profiles to extract the generic parts that deal with saving and loading profiles to/from an Info document, and generalized the concept of a profile. That allowed me to rather easily implement game profiles. In practice, the profiles will be written to a file called “configs/game.dei” under the runtime folder.

Now that Ubuntu 16.04 is around the corner, the autobuilder server is due for a system upgrade. My plan is to get rid of the 32-bit Linux builders (Launchpad should take care of that), and only set up builders for 64-bit Ubuntu and Fedora. The Windows builder will be using Windows 10 and the upcoming Qt 5.6 with MSVC2015. I should be finally able to configure a 64-bit build also for Windows (fingers crossed!).

Consolidation

You may recall that last year, I decided to move my developer blog posts from the forums onto a separate blog. A number of other Doomsday web resources have also been sprouting outside dengine.net (like the bug tracker and commit tag index). When it came time to renew hosting of the website, I came to realize that it was time to sort out this situation and commit to the idea of a consolidated web presence for Doomsday — this was the motivation for moving to a domain of our own in the first place.

Continue reading Consolidation

Pi the Successor

Upon hearing the news about Raspberry Pi 2, I was immediately interested: a quad-core processor? That could run four Doomsday multiplayer servers without breaking a sweat! I jumped into the web browser to place a preorder without hesitation.

I then remembered my trusty Raspberry Pi model B, which has been lying around unused of late. Perhaps I could employ it as an autobuilder client, to replace my old Mac Mini? Compared to a disk-spinning, fan-blowing Mac Mini, a completely quiet and tiny Raspberry Pi seems much better. Nowadays the Mac Mini has only been running nightly API documentation updates and other documentation generation tasks, so the relatively slow Raspberry Pi CPU shouldn’t be a problem.

Continue reading Pi the Successor